Intrusion detection in Linux system
Recommended: LONGERTREE Published: May 23, 2001 Readings: 110
-------------------------------------------------- ------------------------------
Introduction
This article focuses on several host-based intrusion detection systems on the Linux platform. Moreover, I will also introduce how to install these packages, what are the use of these packages and in what circumstances.
System security 101
This article assumes that you already have some basic knowledge of system security. Moreover, some basic safety precautions have been taken to prevent intrusion from the Internet. These measures include:
l The firewall used to prevent TCP and UDP ports in the system from being utilized by hackers. For example, a set of basic firewall rules for web servers must ensure that this computer can only be accessed with TCP / IP protocol by TCP port 80 (typically HTTP protocol).
l Disables unnecessary daemon. For example, a web server only requires only one process to process a request for web pages. Processes with unrelated to processing web requests, such as RPC / PortMap services, NFS services, X font services, DNS domain name services, and other programs must be prohibited from running. In the Red Hat Linux system, programs like NTSYSV or TKSYSV are usually used to disable unnecessary daemon or services.
l From editing "/etc/inetd.conf", unnecessary ports are prohibited. In general, many ports in the "/etc/inetd.conf" file are set to be valid after installation. Editing this file and deletes unnecessary rows or comments is the most basic security measures, and such security measures must be used in all systems.
Security line
In this article, I will discuss multi-level solutions to ensure system security. If any layer of security is destroyed, other security lines can also protect the system. Multi-level system security structure is as shown in Chart 1.
Each layer in the figure provides more data protection on the above layer. For example, the first layer is a firewall. Once the firewall is broken, the second layer is also the port Sentry program, but also to provide protection.
The third fourth level in the system is the LIDS and Logcheck programs, respectively, once port Sentry is inadvertent, and they will provide further protection.
Monitor connection request
The first layer after the firewall is a package used to monitor the connection request. The PortSentry package (http://www.psionic.com/abacus/portsentry) provides a simplicity of how to complete this task.
What does PortSentry use?
PortSentry is a monitor that monitors TCP / IP port activity. Port activities monitored by PortSentry will be reported and certain parameters can be set, including access to the system further access based on the source of port activity. This is a very important defense measure, because hackers will try to explore the weakness of the system (scanning through port scan) before the invasion. Detect "exploration" or port scan, you can thoroughly prevent potential hacker intrusion systems to make hackers can't start truly attacks after scanning ports.
Install Portsenty
For Red Hat Linux users, PortSentry's RPM package can be found in the Red Hat Contrib FTP site. This site has mirrors around the world, view www.redhat.com to find the nearest mirror site closest. I can't determine if there is a Portsntry package in a .deb format, but I think there will be it.
It is also easy to install PortSentry for other Linux systems.
Recommended configuration
PortSentry can run in many modes, including a wide variety of TCPs and UDP "Secret" mode. I like to bind PortSentry and some TCP ports, these ports are: (a) not being used; (b) is well known to the port that is easily attacked. For example, port 143 (IMAP2), port 111 (portmap) and port 23 (telnet) are easily attacked, so I don't use these ports in my own system, but these ports of my web server are It has been scanned within 24 hours. In order to make PortSentry run in basic TCP mode, you must ensure that there is such a line in the startup script of the system:
PortSentry -tcp
Moreover, it is also guaranteed TCP_Ports rows that contain ports that make you need to monitor the TCP_Ports line in PortSentry.conf.
Response option
The "response options" section in the "PortSentry.conf" file allows you to set what to take when the portSentry will take when the port has an abnormal activity. The way I use is to let ipchains block further attacks. This will remove the annotation below in the "PortSentry.conf" file:
Kill_route = "/ sbin / ipchains -i input -s $ target $ -j deny -l
In the system where the port is scanned, "-L" at the end of the line is removed, and the connection request can be saved, so that the space occupied by the log file can be saved.
Monitoring system log
The role that uses a firewall protection system and software similar to PortSentry is that they can monitor and block attempts to connect to the idle ports in the system. This prevents the system from attacking the system with the "scan-intrusion" method.
If the system needs to run a specific service (for example, running Apache on the web server, running bind on the DNS server) and the hacker discovers a security vulnerability in the service software, the firewall and portSentry cannot prevent hackers from attacking the system. When there is a security vulnerability as a BIND software running on the DNS server, and hackers have discovered this security-hazard computer by scanning a specific port (DNS port) of the computer and launch an attack through this port, firewall and portsentry will Seeing such intrusion as a normal access to the system.
Logcheck
Logcheck (http://www.psionic.com/abacus/logcheck/) is a very useful program to check that there is no exception activity. Logcheck Scan Different System Log Files (in the Linux system in the "/ var / log" directory), once an abnormal situation is found, use the Email to inform the system administrator. If there is a hacker attempt to attack your system or have attacked your system in the log file, you can find some spider marts.
Install Logcheck
Logcheck's RPM software package can be obtained on the Red Hat Contrib FTP server like PortSentry. Installing the LogCheck's RPM package or use the source code installation (please see the install file provided in the source code) is very simple.
Configuring logcheck
Logcheck has four main profiles. These files are saved in the "/ etc / logcheck" directory in the RPM version. Under normal circumstances, only "logcheck.ignore" and "logcheck.violations.ignore" files need to be modified. After the Logcheck is installed, what you need to do is:
l Run a logcheck with a standard profile. This will generate a large output file, this file can be deleted. l After 24 hours, run a logcheck again. This will detect some new items in the log file after the last run, and will generate a little bit but still a large output file. Read this output file carefully.
l Some of the messages that don't consider (according to your own judgment) for some messages in the log file (according to their own judgment). Add this identity string to the "logcheck.violations.ignore" file for the message of the "Security Violations" section. For additional messages (in the "Unusual System Events section), add the identity string into the" LogCheck.Ignore "file.
l Repeat the above process every 12-24 hours within a week. Until by continuously adding the identity string in the ".Ignore" file, it is filtered out, and finally there are only those messages that really need to be viewed in the daily reports of Logcheck.
Note that after the installed software package is installed, LogCheck is set to run once a hour by default. However, in general, in addition to the very important system that requires regular monitoring, just run once a day. Just move the "/etc/cron.Hourly/logcheck" file to the "/etc/cron.daily" directory to solve the problem.
Kernel-based intrusion detection
The kernel-based intrusion detection is a very new technique for Linux. The kernel-based intrusion detection system now available is LIDS, at http://www.lids.org/. (Translator Note: This is the project hosted by the Chinese. Everyone should support it)
What is LIDS?
LIDS is an intrusion detection and prevention system based on Linux kernel.
LIDS's prevention measures include the power to limit ROOT (usually fully controlled the entire system), and do not allow him to arbitrarily change the important part of the system. Other important features of LIDS include: enhanced file system protection, preventing direct access to port or memory, preventing direct access to disk and protecting log files. LIDs can also prevent certain systems from "action", for example, install SNIFFER software and changing firewall rules.
LIDS documentation
LIDS will be difficult to install relative to PortSentry and Logcheck. Fortunately, the LIDS site is about the LIDS project, including the installation and configuration guide.
Install LIDS
First, before installing the LIDS, you must ensure that there is the latest version of the LIDS Patch (I use 0.9) and the correct kernel version. I use the latest kernel from the Red Hat Updates FTP site (2.2.14-12) because this version has amended some security issues. You have to have the source code of the kernel being used.
LIDS is now mainly used for the 2.2.14 version of the kernel. I installed the LIDS in the Red Hat 6.2 system, which already includes the built-of-in-2 card. Before installing the LIDS, I downloaded the latest version of the kernel (download from ftp.redhat.com/updates/ or other mirror site) and according to http://www.redhat.com/support/docs/howto/kernel-upgrade/ The instruction of kernel-upgrade.html is installed.
I also downloaded the latest kernel source code, or it can be obtained from ftp.redhat.com/updates/. Install the source code with the following command:
RPM -UHV kernel-Source-2.2.14-12.i386.rpm
Then, compile and install the Lidsadm program:
CD /usR/local/src/security/lids-0.9/lidsadm-0.9make
Make Install
Generate a RIPEMD-160 password (this will be installed into the kernel):
LIDSADM -P
The encrypted password obtained by the password I entered "Anypass" is "D502D92BFEAD11D1EF17887C9DB07A78108859E8".
Then, I copied the standard Red Hat kernel profile to the "/ usr / src / linux" directory:
CD / USR / SRC / Linux / Configs /
CP kernel-2.2.12-i686.config ..
Then, install the LIDS Patch with the following command:
CD / USR / SRC
PATCH -P0> / TMP / B
MV / TMP / B /ETC/inetd.conf
KILLALL-HUP inetd
After reading this file, we will find hackers:
l Create a directory (/ usr / lib / ...) in the system. Use the ftp command from hacker's own computer (200.192.58.201 is a simple hacker tool on an IP address in Brazil).
l Unzip the hacker tool, hacker tools include binary programs with Trojan horses, which will be installed in the system.
l With Trojan horses covering NetStat, PS, TCPD, Syslogd, and PStree. These programs are used to report the system, displaying the running process, displaying the port already opened, and so on.
l Leave a back door program (/ usr / lib / pt07), which is installed and started. Please note that because hackers have installed their own PS, PStree, and NetStat, this latter program is invisible to the system.
What can we learn from the middle?
First, note that the LIDS cannot prevent the system from being invaded by hackers. A hacker can attack a process that runs with root permissions with a buffer overflow to get a shell running with root privileges.
Once hackers have successfully invaded the system, we can see how LIDs minimize the loss:
l LIDS, after using CAP_LINUX_IMMUTABLE, you can prevent the Trojan horse's binary from being placed in "/ bin", "/ usr / bin", "/ usr / sbin", and "/ usr / lib" directory. These directorys we generally be marked as "immutable" (Chattr i) so that these directories will not be changed. Please note that there is no LIDS. We can also mark these directory as unable to use "Chattr I", but LIDs can even prevent root users from changing this "immutable" tag.
Like, it is necessary to fail to change the file with the "touch -t" command to change the file, because these files are marked with "Chattr I" as inseparable.
l If the "/ usr / lib" directory is identified as an immutable even even the first command "MKDIR / USR / LIB / ..." can not succeed.
LIDS can't prevent the system from being invaded by hackers, but it is possible to minimize hacker intrusion. Even if a back program is installed in the system (for example, in the "/ tmp" directory PT07), because the PS, NetStat and PStree in the system are there without Trojan horses, it is easy to find the latter program, I You can "kill" this back program.
If you don't have LIDS installed, we can't know what hackers have done this backdoor program, then they have to reinstall the system.
OpenWall: Another defense is another system similar to the LIDS is OpenWall (http://www.openwall.com/linux/). OpenWall has some features of LIDS, and there is an OpenWall Patch even allows the stack to become unauthorized. Below is a few words extracted from the OpenWall Readme file:
Most buffer overflow exploits are based on overwriting a functions return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non-executable, buffer overflow vulnerabilities become harder to exploit.
Another way to exploit a buffer overflow is to point the return address to a function in libc, usually system (). This patch also changes the default address that shared libraries are mmap () ed at to make it always contain a zero byte. This Makes It Impossible To Specify Any More Data (Parameters to the Function, Or More Copies of the Return Address When Filling with a pattern), - In Many Expliits That Have to do with asciiz strings.
Recently, there are some kernel patches that integrate LIDS and OpenWall on the LIDS website. Integrate some security features of LIDS and OpenWall to a kernel's PATCH.
summary
Using a series of multi-level security tools in the Linux system, you can prevent the system from being attacked by hackers to a certain extent, and protect the system from invading or destroying. The "intrusion point" of the hacker invasion system is mainly concentrated in the network, and many hackers can be prevented from being attacked and prevented by the system kernel patch.
It should be noted that there may be a potential security vulnerability in the system. Regardless of whether Daemon in the system runs with root or non-root privileges, there may be potential security vulnerabilities. It has been vigilant for these security vulnerabilities.
Author: David Elson translation: Brimmer
Source: http://www.netsword.net
