12.4. Detecting Attacks

12.4. Detecting Attacks

A good administrator must do everything to nip in the bud any attack attempts on his or her system. What is the first thing hackers do to break in to a system? They collect information about the system, as was discussed at the beginning of this book. Hackers try to learn as much as possible about the system they want to break in to, and administrators must do everything to give as little information as possible about their system or, even better, throw hackers off the track with some false information.

The simplest and initial information-gathering technique is port scanning. To determine who tried to scan ports on your machine, when, and from where, you have to detect any nonstandard port events. Doing this manually is difficult, and a good specialized program is called for.

Automated port-scanning detection programs are a rather good attack-detection tool but, unfortunately , not in all cases. For example, popular servers are scanned often. I believe that such servers as www.yahoo.com or www.microsoft.com are scanned thousands if not millions of times a day. It is useless to pay attention to each of these countless scans . The most important thing is that automatic attack detection consumes computing resources, and sometimes a quite substantial amount. If every scanning attempt is logged, hackers can devise attack-imitating packets. Then all the server will do is handling these supposed attacks. The effect will be a classical DoS attack, because the server will no longer process client requests .

However, detecting scanning attempts on a company or home network server is a certain way to prevent a break-in.

Another shortcoming of automated scanning detection is that you will not be able to use your own security-scanning utilities, because their activity will be interpreted as an attack by the scanning-detection utilities. Consequently, when you perform scanning yourself, you have to disable the scanning-detection utilities for your scanning to work.

The Klaxon Utility

One of the simplest and most effective scanning-detection utilities is Klaxon ( www.eng.auburn.edu/users/doug/second.html ). The utility monitors ports unused by the system, and when it detects attempts to access them it gathers as much information as possible about the IP address, from which the scanning is conducted , and saves it in a log file.

The program is simple to install. After installing the program to the /etc/local/klaxon directory, add the following lines to the /etc/inetd.conf file:

 # # Local testing counterintelligence # rexec   stream  tcp  nowait  root    /etc/local/klaxon klaxon rexec link    stream  tcp  nowait  root    /etc/local/klaxon klaxon link supdup  stream  tcp  nowait  root    /etc/local/klaxon klaxon supdup tftp    dgram   udp  wait    root    /etc/local/klaxon klaxon tftp 

The preceding directives redirect services to the Klaxon utility and you can log who and when attempts to access these services.

This is useful because the remote command execution (REXEC) service is not needed for regular users and is mostly sought by hackers to penetrate the system. If an attempt, even an unsuccessful one, to access the REXEC service was made from some address, you should make a note that someone from this IP address is casing your server for vulnerabilities, and keep your eyes open for it.

I recommend installing Klaxon on no more than three services, because too many ports may cause the hackers to become suspicious. Moreover, with Klaxon installed on more than five ports, repeated scanning can divert system resources to Klaxon, resulting in a successful DoS attack.

The PortSentry Utility

This program comes in source codes and has to be extracted from the archive at sourceforge .net/projects/sentrytools and compiled. This should present you with no difficulties.

Extract the program by executing the following command:

 tar xzvf portsentry-1.2.tar.gz 

In my case, the program was extracted into the portsenty_beta directory. The directory name may be different on your machine because the program version may have changed by the time this book is published. The extraction directory and the file being extracted are displayed during the extraction process in the directory_name/file_name format.

Open the newly-created directory with the source codes and execute the following command in it:

 cd portsentry_beta 

The PortSentry program works under all UNIX-like system, such as Solaris, FreeBSD, OpenBSD, and, of course, Linux. When compiling the program, you have to explicitly specify the operating system installed:

 make linux 

By default, the program is installed into the /usr/local/psionic directory; the install directory, however, can be changed by specifying the necessary directory as the value for the INSTALLDIR parameter in the Makefile file. The executable file is built by the following command:

 make install 

To view the logs created by the utility, you also have to install the Logcheck program. It is available from the same site as the PortSentry program. It is installed in the same way as the PortSentry utility using the following commands:

 tar xzvf logcheck-1.1.1.tar.gz cd logcheck-1.1.1 make linux make install 

By default, the Logcheck program installs into the /usr/local/etc directory. The directory can be changed by editing the INSTALLDIR parameter in the Makefile file.

The program's configuration settings are located in the /usr/local/psionic/portsentry/portsentry.conf file. By default, all settings are commented out and you have to remove the comments from the necessary settings.

For example, for monitoring ports the configuration file contains three port-monitoring options. To enable monitoring of the selected ports, remove the pound sign (#) from the corresponding entry. For example, the uncommented third port-monitoring option looks like the following:

 TCP_PORTS="1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667" UDP_PORTS="1,7,9,69,161,162,513,635,640,641,700,32770,32771,32772" 

In addition to the monitoring capabilities, the program has an excellent security feature: When it detects an attack attempt, the utility can configure the firewall to prohibit any traffic from the address, from which the attack was attempted. By default, this feature is also disabled and is enabled by removing the comments (the pound sign) from the corresponding directives.

The firewall most often used in Linux is ipchains . It is configured by the following directive:

 KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l" 

Before doing this, make sure that the firewall is installed at the specified directory (/sbin/ipchains). This can be done by executing the following command:

 which ipchains 

If you are using the iptables firewall instead of ipchains , it is configured by the following directive:

 KILL_ROUTE="/usr/local/bin/iptables -I INPUT -s $TARGET$ -j DROP" 

I consider the capability for an automatic firewall configuration in response to attack detection powerful indeed. On the other hand, any program can make a mistake and disallow access to someone that should not be blocked. Hackers can imitate an attack as coming from another user 's address your boss's, for example. PortSentry cannot tell who is hiding behind any address and will cut your boss off from the Internet. This will not be a welcome development.

I conducted an experiment in my test system and tried to throw packets requesting connection to various ports at the server with the source IP address set to different addresses. This rendered the server inaccessible from those IP addresses. You, however, should control how the monitoring program configures the firewall; otherwise , hackers can flood your server with requests and deny other computers access to it.

The monitoring program is launched by the following commands:

 /usr/local/psionic/portsentry/portsentry -atcp /usr/local/psionic/portsentry/portsentry -audp 

The first command launches monitoring of the TCP ports, and the second one starts monitoring of the UDP ports. All activities of the program are saved in a log file, which can be viewed using the Logcheck program. I recommend that this program to be scheduled execute regularly (no less frequently than every 15 minutes) and inform the administrator about system happenings.

Start by configuring the Logcheck program. Open the /usr/local/etc/logchecksh file and add the following entry to it (if it is not already in there):

 "mailto:SYSADMIN=[e-mail]" 

Replace [e-mail] with the email address, to which you want notification messages about log entries created by PortSentry to be sent. To run the /user/local/etc/logcheck.sh script every specified period, use the crontab service.

To test the program, I configured it as described previously and started the CyD NET Utils ( www.cydsoft.com ) port scanning utility. It showed only the first two ports as opened. Even though more than one port had been open, the rest of them were closed for the port-scanner program. On the Linux server, I executed the cat /etc/ hosts .deny command to view the /etc/hosts.deny file, which stores the IP addresses of all computers prohibited to connect to the server.

The last entry in the displayed file contents was the IP address of the computer, from which I conducted the port scanning:

 ALL:    192.168.77.10 

The PortSentry program reacted rapidly and efficiently , adding to the /etc/hosts.deny file a prohibition for using any service from the 192.168.77.10 address. This prohibition can only be removed by deleting the corresponding directive in the /etc/hosts.deny file.

It must be said that some ports can be used intensively enough in the process of normal operations for the program to interpret this as a break-in attempt. Such are the ident (113) and NetBIOS (139) ports. It is best if these ports are not included in the list of ports to monitor. Find the ADVANCED_EXCLUDE_TCP and ADVANCED_EXCLUDE_UDP entries in the /usr/local/psionic/portsentry/portsentry.conf file and add the necessary ports to the lists. By default, the following ports are excluded from monitoring:

 ADVANCED_EXCLUDE TCP="113,139" ADVANCED_EXCLUDE UDP="520,138,137,67" 

As you can see, ports 113 and 139 are already excluded from being monitored .

The LIDS Utility

Even though I do not like to patch the kernel, I consider the Linux intrusion detection/defense system (LIDS) packet worthy of consideration because it offers comprehensive capabilities and makes it possible to enhance system security significantly.

The configuration files are encrypted, which makes modifying them difficult. It is not that easy to shut down the utility, because it requires knowing the system administrator's password.

Detection of port scanning attempts is a small fraction of what this utility packet can do. One of the handy LIDS features is being able to limit file access not on the user level but on the program level. This expands the rights-assignment capabilities and enhances the overall security. For example, the ls and cat programs and text editors can be disallowed to work with the /etc directory. This will make it difficult for hackers to view the /etc/passwd file.

Installing LIDS is not an easy task because it requires patching the kernel source code, compiling the patched codes, and installing the kernel. Here is where some problems may be encountered , because there is no guarantee that the patched kernel will work as intended. The source codes may become corrupted and not compile. When a new kernel version is introduced, it should be tested on a test machine before installing it on the production system. There still is a chance that the new kernel will not work properly on the production machine even after it has been checked on a test machine. But not updating the kernel is not an option, because failure to do this may result in faulty operation in the future.

You can obtain detailed information on LIDS at the utility's official site ( www.lids.org ).