14.9. Detecting Break-ins

Timely break-in detection is important for organizing effective server defense. The earlier you find out that your system has been penetrated, the earlier you will be able react and avert negative consequences of the break-in. Remember that any system can be, and likely has been, broken into, but you should be able to detect these break-ins.

How can you go about this? There are many methods . I will consider the most interesting and effective of them.

4.9.1. Aware Means Protected

I often use an effective but difficult-to-implement method, which consists of informing the administrator when potentially dangerous programs are launched. The difficulty of the method is that you have to know how to program in Linux in at least one language. The preferable language is C, but Perl will also do. As a last resort, being able to write scripts (batch files) will suffice.

So, what does this method consist of? After entering the system, the hacker always starts looking around and trying to find a way to fortify his or her positions to remain in the system as long as possible and unnoticeable to the administrator. To this end, the hacker most often uses the who, su, cat, and similar commands. Your task is to place traps on these commands. For example, the code of the su program can be changed so that a message is mailed to the administrator every time it is invoked.

A message that a high-risk command has been executed by a user other than the administrator is a good cause to check the system for the presence of an intruder in it.

If you cannot program, you can manage only with the operating system means. Suppose that you want to be informed every time the who command is executed. Hackers often execute this command upon entering the system to find out whether the administrator is currently logged in. The directory, in which the command is located, can be found by executing the following command:

 which who

The displayed path will usually be /usr/bin/who.

Next, find out the file permissions by executing the following command:

 ls -al /usr/bin/who

The permissions for the who command file should be -rwxr-xr-x, or 755 in the numerical notation.

Rename the /usr/bit/who file as /usr/bin/system_who. This is done by executing the following commands:

 mv /usr/bin/who /usr/bin/system_who chmod 755 /usr/bin/system_who

Now, to execute the who command, it has to be invoked as system_who . The new file may become unexecutable, so the second command restores its file permissions.

Now create a dummy for the who file. This will be a file named who in the /usr/bin directory that will be executed when the who command is called. This is created by first executing the following command:

 cat /usr/bin/who

Now, everything entered from the console will be recorded into the /usr/bin/who file. Enter the following two lines:

 /usr/bin/system_who id  mail -n -s attack root@FlenovM

Exit the entry mode and save the file by pressing the <Ctrl>+<D> key combination. Change the file permissions of the just-created who file to -rwxr-xr-x, or 755 in the numerical notation.

Execute the who command. This will produce the expected results but also will send a letter to the administrator's mailbox. The letter will contain all parameters about the user who invoked the command as returned by the id command (Fig. 14.3).

Figure 14.3: An example of an attack notification email

The mechanism that produces this result functions as follows : When the who command is invoked, the custom who file is executed. This file contains two commands.

The first command /usr/bin/system_who executes the real system file who renamed as system_who.

The second command id mail -n -s attack root@FlenovM executes the id command and redirects its results to the mail program mail, which in turn sends them to the root@FlenovM mailbox. The -s option specifies the subject of the letter. The -n op tion inhibits reading of the /etc/mail.rc file upon the mail program start-up. I recommend specifying only these two options so that nothing would be displayed to alert the hacker that something is not right when the modified who command is executed.

In this way, all high-risk programs that should not be available to regular users can be modified.

Hackers most often do not check the utilities they launch, even though the telltale information can be readily discovered by executing the regular cat command:

 cat /usr/bin/who

This is where the shortcoming of using scripts becomes apparent: They can be viewed as regular text files. Programs written in C and then compiled into an executable file can show only the queer garbage when viewed in a text editor or other text viewers .

4.9.2. Honey Pot

In Section 4.11.7 , I considered the subject of organizing a network, in which the public resources are hosted on separate servers and are protected separately from the main network. I also touched upon the subject of creating sham servers to throw hackers off track. In this chapter, I will consider the subject of sham servers and networks, known as "honey pot" technology in the parlance, in more detail.

Its essence is as follows: A computer, or even a subnet of computers, is set up in a network that is filled with information to attract hackers' attention but that is useless. The computer, or the network, is made relatively easy to crack. The main function of such a computer or network is to track outside access and to register any break-ins.

Fig. 14.4 shows how a classical honey-pot network is organized. This network is protected from the Internet by a firewall. Behind the firewall are public resources and sham servers and workstations. This sham network is separated from the actual private network by another firewall.

Figure 14.4: Honey-pot network construction

When a hacker swallows the bait and starts rummaging in the honey-pot network, administrators can investigate where he or she came from without running the risk of destroying important data.

To prevent your trap from snatching everyone who touches, as well as from generating false alarms, its protections should be hard enough not to be circumvented by hackers using exploit programs. Otherwise, there will be hundreds, if not more, hackers caught in it every day, because a popular resource is scanned countless times daily.

I configure my honey-pot servers for maximum security but let the firewall protecting them (Firewall 1 in Fig. 14.4) pass practically all traffic into the public network. This kills several birds with one stone:

Hacker's suspicions are not aroused. A professional will immediately become suspicious if the protection is too weak and will not touch such a network with a ten- foot pole.
The system is not triggered by every beginning hacker who is using commonly-available exploits.
If the honey-pot system, which is protected as well as the real system, has been broken into, this means that the private network is also vulnerable. I can learn about this vulnerability by examining the techniques used by the hacker to penetrate the honey-pot network. In this way, attacks unknown to the security community until now can be detected and defense methods against such attacks can be devised.

As soon as I notice that the honey-pot server has been compromised, I undertake the following steps:

Analyze the vulnerability used by the hacker to obtain access. Having found the weak spot, I look for a patch and install it on the computers in the private network, to prevent the hacker from using this vulnerability to break into the sensitive area.
Determine the source of the break-in, such as the IP address or street address, and pass all this information on to law-enforcement agencies.

Because honey-pot systems do not process actual user requests , they do not require powerful hardware. Obsolete hardware that no longer can be used for modern applications will suffice. Any administrator always has old junk piled up in the office and used for spare parts .

If you don't have any old computers, you can use public servers for the honey-pot network. In essence, public servers are already supposed to maintain powerful monitoring and logging systems, differing from honey-pot servers only in that they should not have known vulnerabilities and easy passwords.

To prevent hackers from suspecting trickery and make them interested in the honey-pot systems, equipping such a system with strong defense is not enough. The computers have to do something and process some traffic. This can be achieved with the help of specially-developed utilities that imitate network operation on the honey-pot system. A computer that is just sitting there doing nothing sticks out like a sore thumb, and only a dummy will try to break into it.