9.8 Other IDSs

The "traditional" concept of an IDS is not the only weapon in the arsenal of network defense. If your security policy dictates, there are other network elements that can be included as part of an overall IDS strategy.

Intrusion detection systems are beneficial in that they will alert you as to suspicious network activity. A problem, however, is determining if the detected attack was successful. Ideally, logging of all access should be performed on a separate host that is itself secure. As security goes, however, it is difficult to ever know with certainty that your system, your IDS, or your logging is secure. Furthermore, either a network-based IDS or a host-based IDS only detects attacks and other network-based behavior. It does not, however, indicate if legitimate changes have occurred to the host over the network or if someone has gained physical access to the host itself, either via the terminal or a floppy disk. Most network-based IDSs are not able to pick up such misuse or changes. If positive knowledge of network access is required, then a file integrity checker is required.

A file integrity checker is a software program that computes MD5 hash sums of all programs on a given host. For each file or executable, an individual hash sum is computed. This sum is then recorded. The purpose of file integrity software is to allow network administrators to monitor the thousands of files and executable programs that are on any given host. At periodic intervals or when the network administrator suspects some sort of network compromise, the file integrity checker can be run again. If the new MD5 hash is different from the old hash value, it is easy to surmise that some sort of change has occurred to the file.

In some instances, file changes would be expected. For example, files stored in a cache or temporary folder would be expected to have changed. Other files may have been changed during normal use, such as a database or user folders. Executable files, however, should rarely if ever change. It is up to the system administrator to determine which file changes are likely and legitimate and which are not. All commercial file integrity checking software allows configuration so that network administrators can omit certain often-used files from the checking procedure.

File integrity checkers do not allow you to determine what change has occurred. Thus, the report will not tell you that the item in column B, line 45 has changed from $401.85 to $4018.50, for example. They will only tell you that the file itself has changed. Thus, file integrity checkers are not appropriate for determining what has changed in the file, only that the file itself has been modified.

The success of file integrity checkers relies on the integrity of the MD5 hash. It therefore is not advised to store the hash values on the same host that you are attempting to protect. The reason for this is that either the file integrity checker software program itself could be Trojanized to protect other compromised programs, or the hash values themselves could be modified to reflect any modified binaries. Ideally, the hash values would be recorded on a floppy disk or CD and then stored in a secure location until the next check occurs.

File integrity checkers are essential for determining if changes are made to any given host. Network administrators can attempt to manually monitor their hosts, but this proves to be an overwhelming and, in the end, futile task. A typical UNIX installation contains about 60,000 files and even a bastion host, with all unnecessary files removed, will still contain more than 15,000 files. It would be an unreasonable use of administrator time to search through these files looking for access times and changes. Many Trojan rootkits ^[1] contain modified programs that hide changes to programs and often hide entire backdoor applications on the host computer by omitting the applications from directory listings and listings of running processes. Thus, even the most astute and capable network administrators will not be able to determine if their systems have been compromised simply by going over the files on their own.

While a file integrity checker may be considered a necessity in many installations to ensure the integrity of host machines, the other item to be discussed is an informative, but few would argue essential, tool for network security.

The tools that attackers are using against network systems are always evolving. Tools that exploit vulnerabilities from last year become obsolete as systems are patched. New tools are then developed to take advantage of new vulnerabilities. For network security professionals, the problem is how to determine what the new attacks are before they are used against your network to cause damage or compromise sensitive information. A novel approach to this problem is to create a system with the sole intent of it being attacked and broken into. This is known as creating a "honeypot."

A honeypot, as the name suggests, is an attractive-looking server on a network that is only placed there with the intent of it being broken into. An IP-invisible separate system, acting as a network sniffer, will be set up to record all packets destined for the host. Once a break-in occurs, the packet data will be examined to determine the method that the attacker used to compromise the system. Once the method is understood, the real network servers can then be protected against the new threat.

Honeypots are most useful against the most common types of attackers on the Internet — script kiddies. Following precompiled exploits, these users, with a limited amount of technical skill, are able to do a great deal of damage to networks and hosts. This class of threat is also the group most likely to compromise any available server — the more, the better. It is not that a honeypot cannot be used to record the actions of more experienced attackers; it is simply that the group of highly experienced attackers is more astute at investigating their targets and tend to attack hosts that in some way further their ultimate goals — not anything that simply looks interesting or is easy to exploit.

Honeypot products are available that can emulate a number of operating systems. If you need, for example, a server that emulates an Apache Web server running Red Hat Linux 6.0, then you select that as a configuration option. If you wish to change it to an IIS server, select another option. Because a honeypot is primarily a learning tool, however, one of the best ways to make one is to configure it yourself using actual server software. At the same time you are learning the attack techniques of Internet threats, you are also increasing your own skill at securing Internet servers against these attacks. The simplest honeypot is simply a server that is set up and runs no services. Because the server really does not serve any network resources, any access to the server itself should be considered suspicious. I have worked on several networks where Windows servers have been set up in exactly this manner. The administrator account was changed from "administrator" to another account, and attempts to access this server as an administrator automatically generated an alert.

To maximize effectiveness, a honeypot should be configured with some degree of network security. This accomplishes two goals. The first is that the amount of knowledge that would be gleaned from well-known attacks is minimal. Sufficient documentation can usually be found to protect your servers and it would take time better spent on other projects to determine the attack vector in any case. If you are going to go through the effort of creating a honeypot, then you will want to make sure that you get the maximum value from it.

The second reason for configuring the honeypot with a modicum of security is that a totally unprotected server may look suspicious. Although the number of unsecured servers and hosts on the Internet is still depressingly large, attackers are wising up to the existence of honeypots and may be suspicious of a large network block and a single totally unsecured server.

The placement of a honeypot can vary, depending on the goals of the server. Most organizations will place them outside their normal firewall. This allows easy access to the server from the outside, but does not put their network at risk should the bait be taken. It is not uncommon, however, to place the honeypot on the internal network in order to catch employees who may be more curious than their corporate security policy allows.

In either location, a network sniffer, or even an IDS, should be placed to capture all traffic sent to the honeypot. Because it is assumed that the host itself will be compromised, no trust should be placed in the logs of the device as a method of determining a sequence of events in the event of an attack. As with normal IDS placement, the sniffer or IDS sensor host interface address should not be configured with an IP address. This will allow the device to sniff traffic, but be rendered invisible from the perspective of the IP layer. Printing the logs to CD media or in hard copy may also provide interesting information regarding the actions of the attacker once your system is compromised.

While few better learning tools exist, the use of honeypots as a security mechanism can be complicated. Some organizations create honeypots for the purpose of actually trapping and prosecuting individuals and groups attempting to compromise a host. The line between enticement and entrapment can be pretty thin. Enticement is legal, but entrapment is not. Simply placing an attractive host on a network with several well-placed vulnerabilities would be an example of enticement. It is up to the attackers to discover the host and take advantage of the situation. Entrapment, on the other hand, would be actions that "pull" the user to the host for logging their activity. For example, advertising pirated software on a newsgroup and then recording the actions of all who log on looking for such files would be considered entrapment.

Actively attracting the attention of Internet threats would generally lead to other unpleasant consequences. While the hope may be to capture and prosecute such individuals, in reality, the network administrator may find that the responsible individuals are outside the jurisdiction or reach of their local or national law enforcement agencies. This would result in a lot of work tracking down attackers, only to find an angry group of attackers in a part of the world that the network administrator cannot affect. For all their trouble, network administrators may find that they have attracted too much attention in the form of hacking attempts on production systems and distributed denial-of-service attacks on the network as a whole. While the honeypot is an interesting device for learning about network attacks and protecting network resources, it is probably not the preferred vehicle for capturing attackers. The argument could be made that it would provide the information required to determine the attacker's mode of attack, but your normal security procedures should be providing that information anyway.

^[1]A root kit is a collection of programs that allow attackers to easily cover their activities on the host and access the host at their convenience at a later time.