Network-Level Intrusion Detection Systems | Protect Your Information with Intrusion Detection (Power)

As follows from the historical overview of intrusion detection technology, initial investigations were carried out by means of the analysis of the log files created by the operating system and various applications. This analysis was aimed at finding specific records that characterize potential attacks or anomalous activities. In practice, however, intrusion detection systems based on log-file analysis have proved unable to detect many attacks. Because of this, developers have concentrated their attention at the network level.

The main limitation of the first intrusion detection systems was that log files were only accessed at the level of the OS, DBMS and specific applications. The further growth of networks requiring control at all levels of the information-system infrastructure led to the development of so-called kernel-based and network-based intrusion detection systems, i.e., intrusion detection systems running at the OS-kernel level and at the network level.

Thanks to the algorithms implemented in network-level intrusion detection systems, they have access to all data transmitted via the network. Since such systems run at a different computer than the controlled host, there is no negative impact on the controlled host's performance.

Working Mechanism

As the analysis of currently available network-level intrusion detection systems shows, all of these systems use the network traffic as their data source and analyze it for attack indications. It is also possible to analyze log files created by network hardware and software (such as routers, firewalls or protocol analyzers) that register all of the traffic that it processes. Ideally, these tools are able to function in any network but, in practice, these intrusion detection systems identify security policy violations in shared media networks, where a single connection line is used by several computers, one computer at a time. These systems function on the basis of Ethernet (and, consequently, Fast Ethernet and Gigabit Ethernet) technologies, Token Ring and FDDI. This is because of the fact that, in such networks, one computer can access all packets transmitted within a network segment. This property significantly reduces the cost of intrusion detection systems, since the traffic between these hosts can be controlled by a single intrusion detection system independently from the number of networked hosts within the network segment.

When hosts are connected by individual lines (such as ATM), it is necessary to install the intrusion detection system between each pair of interacting hosts. But the expense involved in such a system makes it a less attractive option. Because of this, current examples of network-level intrusion detection systems support network technologies with shared media. On the other hand, there are also ATM solutions, such as Dragon Sensor.

Two network-level intrusion detection systems that have appeared quite recently deserve special mention. These are AirIDS (http://www.internetcomealive.com/clients/airids/general.php) and AirDefense (http://www.airdefense.net/products/index.shtm). Both systems are intended for intrusion detection in wireless networks based on the 802.11b standard.

Besides this, intrusion detection systems are characterized by another limitation - they are only able to analyze the most common protocol stacks. Among currently available intrusion detection systems, approximately 95% support the TCP/IP stack, while the remainder support SMB/NetBIOS. Commercial systems supporting IPX/SPX, not to mention other, even less common stacks, are quite rare.

The working mechanism of a network-level intrusion detection system is shown in Fig. 6.20. It comprises four main components, responsible for the following functions:

Packet capturing
Filtering and assembling fragments
Intrusion detection
Reacting to attacks

click to expand
Fig. 6.20. Components of the network-level intrusion detection system

If the network's equipment (for example, Cisco Catalyst 6500 IDS Module (in switch) or Cisco IOS Firewall Feature Set (in router) implements the intrusion detection system, then one of the network components takes the place of the network adapter. If the intrusion detection system is based on the principle of analyzing the log files created by the network equipment, this role is delegated to the appropriate log file (for example, the TCPdump log file). Depending on the source of the data for analysis (from the network adapter, switch components or the log file), the system component responsible for packet capturing might be based on different implementations. However, other components (filtering, recognition and reaction) remain unchanged.

The IDS software has two components.

The kernel that interacts with the network adapter, part of the network equipment or the log file storing the network traffic. The kernel is responsible for data capturing. In sophisticated intrusion detection systems that capture data from the network interface, this interaction is carried out by the intrusion detection system driver, which replaces the operating system driver. As well as improved efficiency, this enables the implementation of add-on functions such as stealth mode, which prevents the intruder from detecting and attacking the intrusion detection system itself. Simpler intrusion detection systems use and analyze data obtained from the operating system driver. In relation to the range of problems it solves, this kernel is similar to the protocol-analyzer kernel.
Software that decodes and analyzes the protocols used by the network adapter. The same software also implements the system logic used when the system detects an attack and reacts to it.

Packet Capturing

The first stage of the procedure is the capture of the network packets. As already mentioned, this algorithm can be implemented in different ways, depending on the source from which network packets are captured. At the time of writing, most network-level intrusion detection systems were built on the basis of normal or specialized computers running specialized software on a normal operating system and capturing network traffic from network adapters. Systems such as RealSecure Network Sensor, NetPowler, Snort, and so on are built according to this principle. In some other cases, the operating system is reduced to the minimum required set of functions in order to eliminate all unnecessary features that might intervene with the IDS's operation. This approach was used by the developers of RealSecure for Nokia and the VelociProwler Intrusion Detection Appliance (unfortunately, after Symantec purchased Axent, this solution was abandoned). In all cases, network traffic is captured from a normal network adapter, which can operate in the following two modes:

Normal mode, in which the NIC processes only the packets that are addressed to it
Promiscuous mode, in which the network adapter processes all packets transmitted within the network segment

If the intrusion detection system is set up in network equipment, network traffic can be obtained from the following sources:

Network-equipment backplane (Cisco Catalyst 6500 IDS Module is set up according to this principle)
Software servicing network equipment (Cisco IOS Firewall Feature Set is based on this principle)

Filtering

Despite the fact that intrusion detection systems have access to all captured network packets, not all such packets are subject to processing. For example, the system can not process packets for unsupported protocols. Another example is that of fragmented packets, which can also not be processed by some intrusion detection systems. The filtering module is responsible for ruling out packets that should be ignored by the intrusion detection system (for example, IPX traffic).

There are two types of filters:

System filters. These allow you to eliminate (or, conversely, to control) network traffic based on the data of the signatures to be recognized. For example, if the ColdFusion attack recognition system is operational, then the filtering module will trace HTTP traffic at TCP port 80.
User filters. User filters eliminate or, conversely, control traffic satisfying the pre-defined rules set by the intrusion detection system administrator. For example, if the controlled network contains only Windows hosts, then there is no need to search for the Tribe Flood Network attack within this network, as this attack is characteristic of the Linux or Solaris operating systems.

Attack Detection

The attack detection and recognition module is an important component of any intrusion detection system. The efficiency of the whole intrusion detection system depends on the effectiveness of this module. The recognition module uses various methods and criteria, which were covered in detail in Chapter 4.

Analysis of network traffic can be implemented using two methods - syntax parsing of specific network packets using regular expressions, or analysis of the entire session. Systems using the first method capture raw packets and pass them through a syntax analyzer, which searches these packets for matches with a specific pattern or signature [Graham1-00]. An example of such a pattern is the text fragment "etc/passwd," characteristic of an attempt at a brute force password attack or a request for transmission of the password file via the network.

These systems function on the basis of the following algorithm [NetworkICE1-00]:

The system selects one network frame from the captured traffic in order to scan it for signatures.
Beginning with the first byte of the network frame, the system selects a group of bytes of the same length as the signature under consideration. It then compares the two sets of bytes - the signature and selected packet fragment (Fig. 6.21).

Fig. 6.21. Comparison to the pattern (the second step)
If the two groups of bytes are identical, then an attack has been detected.
If the groups do not match, the system shifts one byte forward in the network frame sequence, and the process is repeats until the sequence ends (Fig. 6.22).

Fig. 6.22. Comparison to the pattern (fourth and subsequent steps)
When the intrusion detection system reaches the end of the network frame, it begins a comparison to the next signature, and proceeds until the end of the database is reached.
If no matches for known signatures have been found in the first network frame, the system starts analyzing the second frame, and the whole process repeats from the beginning.

The advantages and drawbacks of this method (which has become widely known as pattern matching) are outlined in Table 6.9.

Table 6.9. Advantages and Drawbacks of Pattern Matching
Advantages	Drawbacks

Ease of implementation	High percentage of false positives
High performance	Does not work when attack undergoes minor modifications
High precision of detection	Inapplicable to flow traffic (such as HTTP)
Independent from the protocol used

However, network traffic is more than simply a sequence of network packets. Therefore, systems based on analysis of the entire protocol are oriented toward the context of a network session, thus resulting in a reduction of false positives. They can distinguish between harmless and dangerous events. For example, they can distinguish between a security bulletin received via e-mail and containing text fragments such as "GET /CGI-bin/phf" from an HTTP request such as "GET /CGI-bin/phf." Session analysis can be done using one of two methods. The first method has become known as stateful pattern matching. Systems using this technology check each packet and trace their order. For example, suppose that the search pattern (GET /CGI-bin/phf) is divided into two packets - "GET /CGI-b" and "in/phf." The classical pattern-matching method will not detect this attack, since it is divided into two packets, neither of which matches the signature. Using stateful pattern matching, on the other hand, will enable you to detect this attack even if it is fragmented into 10 packets. The advantages and drawbacks of this method are described in Table 6.10.

Table 6.10. Advantages and Drawbacks of Stateful Pattern Matching
Advantages	Drawbacks

Ease of implementation	A relatively high percentage of false positives
High performance	Will not work if the attack is slightly modified
High precision of detection
Independent of the protocol used
A system using this method is harder to deceive

The next method, known as protocol decode-based analysis, is relatively easy to describe. It is based on searching for deviations from the RFC that describes specific protocols. Thus, everything that is not described in the RFC is considered a violation, and the system reports it using this principle. Certainly, contemporary intrusion detection systems can use any of these methods, depending on the situation. With respect to the attack indicators described in Chapter 4 - the exceeding of threshold values or network anomalies - special methods were developed for detecting attacks of these types. For example, the method using mathematical statistics became known as heuristic-based analysis [Cisco1-02].

The working mechanism of these systems differs from the previous one. An example of an algorithm illustrating this difference is outlined below:

The system selects one network frame from the captured traffic to scan it for signatures.
Knowing the format of the network frames characteristic for the Ethernet and higher-level protocols, we can decrease the number of possible operations, since it does not make sense to search for attack matches in the first bytes of the Ethernet frame, which contain source and destination addresses. Thus, the system goes to 13th and 14th bytes of a specific frame to determine the type of network-level protocol. In our case, this is the IP protocol with the value of Ox0800 (Fig. 6.23). It is important to note that, in this example, we are considering the Ethernet DIX (Ethernet II) frame format, which is used by default on workstations for transmitting IP traffic over the Ethernet. The size of the field identifying the higher-level protocol is 2 bytes. How can we detect which data format is in use - Ethernet DIX or, for example, 802.3/LLC, where this location contains the frame length field? Solving this problem is relatively easy. The Ethernet frame length can not exceed 1,500 bytes, and therefore, if a value exceeding 1,500 bytes (for an IP - 0x0800) appears in this field, then we are dealing with the Ethernet DIX (II) format.

Fig. 6.23. Analysis of the protocol as a whole (the second step)
The 10th byte of the IP header (24th byte from the beginning of the frame) identifies the transport-level protocol. The size of this field is one byte, and the value contained in this field is 6, which means that the higher-level protocol is TCP. Notice that, here, we have also filtered out some fields of the IP header, which are not necessary for the analysis (Fig. 6.24).

Fig. 6.24. Analysis of the protocol as a whole (the third step)
In the next step, we analyze the first two pairs of bytes in the TCP packet header. These are the source and destination ports (bytes 35 through 38 of the initial network frame). In our case, the destination port is port 80, which identifies the HTTP protocol (Fig. 6.25). If a non-standard port is used, the time required to detect the protocol will increase, which will result in a worse performance.

Fig. 6.25. Analysis of the protocol as a whole (the fourth step)
Skipping the next 20 bytes of the TCP packet header, we go directly to the data field (55th byte), which (for the HTTP protocol) starts with URL. It is necessary to note that, to decrease the size of the network frame being considered, some bytes were deleted. Here, we are looking the match for the "GET /cgi-bin/./phf" signature (Fig. 6.26). Naturally, when operating in alert mode, it is necessary to analyze TCP header flags and other parameters. Right now, however, I will only demonstrate a more efficient method of analyzing network traffic in comparison to the byte-to-byte analysis of each frame.

Fig. 6.26. Analysis of the protocol as a whole (the fifth step)
When the intrusion detection system reaches the end of the network frame, it begins a comparison with the next signature, and repeats the process until the database end is reached. This aspect is rather important, and I would like to draw special attention to it. The steps described here are repeated for each signature found in the IDS database and applicable to the HTTP protocol. Consequently, the more signatures are there in the database, the slower the system will operate.
If no matches for any of the known signatures have been found in the first network frame, the system starts analyzing the second network frame, and so on.

It is clear that, in contrast to the first algorithm, which requires 55 operations to accomplish the task, this algorithm allows the achievement of our purpose in only five steps.

However, systems in the first category have some advantages over protocol analysis systems. Since they analyze all traffic, they are able to detect attacks missed by other systems. For example, if the corporate web server is configured to use a non-standard port (for example, 8080 rather than 80), then an intrusion detection system based on protocol analysis will likely miss an attack to this server, as it will not compare the traffic of the non-standard port to the HTTP traffic (provided that it is not using the modified algorithm described above). Systems that analyze each packet are not bound to port numbers and can detect attacks in traffic directed to any of the available 65,535 ports.

Responding to Attacks

Simply detecting an attack is not enough; it is also necessary to react. When the intrusion detection system registers an attack, it provides a wide range of response options - from sending an alert to the security administrator and the network-management console, to reconfiguring routers and firewalls. These options vary from system to system. However, the most common types of reaction include sending an administrative alert to the console or via e-mail, closing the connection to the attacking host and/or logging the current session for subsequent analysis and collecting evidence and reconfiguring the network equipment.

Advantages of the Network-Level Intrusion Detection Systems

Network-level intrusion detection systems have some advantages over host-level intrusion detection systems. Most customers opt to purchase network-level intrusion detection systems because of the low operating expenses and quick reaction to suspicious events. Listed below are the main factors that make a network-level intrusion detection system one of the most important components of security policy implementation [ISS3-99].

Low Operating Expenses

Network-level intrusion detection systems do not need to be installed on each host. Since the number of hosts at which it is necessary to install IDS to cover the entire network is relatively small, the total operating cost of these systems in a corporate network is lower than that for the host-level intrusion detection systems. Moreover, in order to control a network segment, it is sufficient to have just one sensor, regardless of the number of hosts within the segment.

Network Attack Detection

Host-level intrusion detection systems generally do not process network packets and, thus, can not detect these types of attacks. Products such as RealSecure Server Sensor or Centrax are exceptions, since they include network components able to detect network attacks directed at a specific host. These intrusion detection systems can investigate the contents of packet data fields by searching and finding commands used in specific attacks. For example, if the intruder tries to find the BackOrifice server components in computers that are not currently infected, this becomes clear in an investigation of the data body of the packet. As was mentioned above, system-level tools do not usually work at the network level and, therefore, are unable to detect these attacks.

Difficulties in Concealing Traces of Unauthorized Activities

Once a network packet leaves the attacking host, it can not be returned. Thus, systems working at the network level analyze "live" traffic and detect attacks in real-time mode. As a result, intruders can not remove traces of unauthorized activity. The analyzed data includes information about the method of attack, as well as information that can be used to identify the intruder and serve as evidence in court. Since most intruders have a sound knowledge of system-authentication mechanisms, they are rather skillful when it comes to tweaking system logs in order to conceal traces of unauthorized activities. Consequently, this can have a negative impact on the efficiency of the system-level tools that rely on this information in order to detect attacks.

Real-Time Attack Detection and Response

These systems detect suspicious events and attack as they occur. Therefore, they send alerts and react much faster than systems that analyze log files. For example, an intruder carrying out a Denial of Service attack on the basis of the TCP protocol can be stopped by a network-level intrusion detection system, which sends a TCP packet with the Reset flag set in the header. Thus, the connection to the attacking host will be closed before the attack causes any damage to the target. Systems based on log file analysis do not detect attacks before the appropriate record appears in the log file and, thus, take response actions only after the event has been registered. Note that, by this time, important systems or resources might already have been compromised, or the computer running the host-level intrusion detection system might have already failed. Real-time notification allows quick response actions according to predefined parameters. The range of response actions varies from immediately stopping the attack to allowing the penetration in order to collect information on the attack and attacker.

Detection of Failed Attacks or Suspicious Activities

Network-level intrusion detection systems installed outside the firewall can identify attacks directed at the resources protected by the firewall, even if the firewall itself is able to thwart the attack attempt. Information collected by such a system might be very important for developing, evaluating and improving a security policy. Further, it is be helpful when evaluating the skill of the intruder.

Platform-Independence

Network-level intrusion detection systems do not depend on the operating systems installed in the corporate network, since they operate with the network traffic between all of the hosts within that network. For such intrusion detection systems, it does not matter which OS generated a specific packet, provided that the packet corresponds to the standards supported by the intrusion detection system.

Tools for Detecting DoS Attacks

Because the interest in tools for detecting and thwarting DoS attacks is constantly growing, I have decided to classify these tools as a separate category. This approach is additionally justified by the fact that these tools are actually different from other intrusion detection tools. Furthermore, some specialists even think that they are using a new approach, different from signature- or anomaly-based approaches to intrusion detection [Gong1-02]. Their main distinguishing feature lies in the fact that such systems, besides detecting an attack, are capable of thwarting or at least weakening it. Most companies that supply such solutions owe their success to the DDoS attack epidemics that took place in 2000. The list of these companies includes Mazu Networks, Asta Networks, Arbor Networks, etc. (http://www.networkcomputing.com/1225/1225f3.html). Other companies are also competing for this prospective market. For example, such solutions are supplied by TopLayer Networks, Radware, and ISS as well. Other market leaders also pay significant attention to this segment of the IDS market. For example, in late 2001, McAfee made an agreement with Mazu Networks, Asta Networks, and Arbor Networks to cooperate in the field of developing new methods of detecting.

Since such tools are oriented towards weakening or completely locking the attack, they are usually implemented in the form of a separate appliance, installed between the protected network and public networks. Thanks to this, such appliances are able to control all the network traffic. Such devices are also known as inline IDS.

The easiest method of locking attacks is to block the traffic between the two networks totally. However, this will result in locking all access to the protected devices. In other words, a device intended for protection against DoS attacks will itself present an obstacle to the normal operation of web servers, application servers, and so on. Because of this, this approach is only suitable for protection against a limited number of attacks (mainly those based on the ICMP protocol).

The second method of blocking DoS attacks implies traffic filtering based on the IP addresses of the intruders. This method is the most efficient. However, it works only if you are absolutely sure that the IP address in the header of a packet containing an attack really belongs to the intruder. Since tracing each unique address is quite a difficult, complicated, and resource-consuming task, some manufacturers use a simpler approach: They filter packets based on address ranges. However, when using this approach, you might not only lock access to intruders, but also to authorized users. But, for the moment, it is justified and viable.

The third method allows you to restrain network traffic and from time to time pass small fragments into a protected network. Although the part of traffic that is passed into the protected network might contain malicious traffic, the fact that there is so little will not allow protected hosts to fail. This method is rather efficient against a SYN Flood attack.

The last method of thwarting a DoS attack is similar to the methods used by classic intrusion detection tools. In this case, the system filters network traffic based on pre-defined attack indicators (the source port, TTL, the packet identifier, and so on).

It should be mentioned that tools of this type are not always implemented as standalone devices, such as FireProof from Radware (http://www.radware.com/) or TrafficMaster Enforcer from Mazu Networks (http://www.mazunetworks.com/). Sometimes these mechanisms are built into network equipment - into workload balancers, for example. This approach was adopted by Foundry Networks (http://www.foundrynetworks.com/) in ServerIron 400, and TopLayer Networks in AppSwitch 3500. Quite an interesting solution is supplied by Reactive Networks (http://www.reactivenetworks.com/). This company has created its own IDS, Flood-Guard, which is based on Dell hardware and the Linux operating system. However, this device does not itself block an attack. Rather, it uses access control lists on Cisco routers. Also note that any security mechanisms and additional equipment increase network workload, which results in a loss of performance.

Network Intrusion Detection Systems and Firewalls

Quite often, security administrators try to replace network intrusion detection systems with firewalls, hoping that the firewalls provide the necessary level of protection. Do not forget, however, that firewalls are simply systems based on predefined rules that allow or prohibit specific traffic to pass through them. Even firewalls based on "stateful inspection" can not determine for sure if an attack is indicated by the controlled traffic. All the firewall can determine is whether the traffic corresponds to the rule. In other words, firewalls, like any other security tools, have their own advantages, drawbacks and optimal areas of employment.

Consider a firewall that is configured in such a way as to block all connections except for TCP connections at port 80 (i.e., HTTP traffic). Thus, any traffic at port 80 is legal by the firewall's definition. On the other hand, an intrusion detection system also controls this traffic but, in contrast to firewall, also searches for attack indications in this traffic. The intrusion detection system ignores the question of the intended port This means that, despite the fact that an intrusion detection system works with the same data source (network traffic) as the firewall, they perform complementary functions. For example, an HTTP request such as GET /../../../etc/passwd HTTP/1.0, most likely indicates unauthorized access to a password file, while http://www.domain.com/asp. indicates an attempt to exploit the MS IIS vulnerability. Practically every firewall will permit this request and the usage of the specified URL. The intrusion detection system, on the other hand, will recognize this attack and block it.

The most common question about intrusion detection systems concerns the manner in which they can complement. One answer to this question is that they provide the classification of the security violations by attack source, independent of the question of whether the attack originates from an external or internal network. Firewalls act as a barrier between corporate (internal) networks and the outside world (public networks such as the Internet). They filter network traffic according to a predefined security policy. As was already demonstrated in Chapter 1, firewalls can not detect internal attacks or external attacks bypassing the firewall or exploiting firewall-configuration vulnerabilities. For intrusion detection systems, the origin of the attack is irrelevant. They function efficiently against attacks from within the internal network or from an external network.

Consider the following analogy. Think of a firewall as a metal detector set up at the entrance to the company's main building (analogous to your internal network). However, beside the main entrance, there are back doors and windows. Through technical methods or by deceiving the security services, an intruder can get by the metal detector carrying prohibited items. Thieves can also penetrate the building using the back doors or windows. Because of this, most buildings also have motion detectors and internal security personnel. In the same vein, it is necessary to have intrusion detection systems, which complement the protection provided by firewalls, which are a necessary, but not sufficient, component of network security.

Listed below are several advantages of using firewall/intrusion detection system combinations:

Double-checking of the firewall configuration and detecting configuration vulnerabilities (if network sensors are installed both before and after the firewall)
Detecting attacks that pass the firewall on a legal basis (for example, attacks against web servers, malignant applets etc.)
Detecting internal intruders

Taking these facts into account, some IDS manufacturers have started to integrate mechanisms for detecting network attacks into their firewalls (for example, the Cisco IOS Firewall Feature Set). However, as I mentioned above, most attempts at combining two technologies result in the inefficient operation of both. For example, it is not difficult to create attack signatures using the INSPECT language built into CheckPoint Firewall-1. However, CheckPoint has adopted another approach. It has concluded an agreement with ISS, licensed the RealSecure Network Sensor, and started to supply the CheckPoint RealSecure system to its customers. In April 2002, CheckPoint declared that it is going to develop its own IDS - SmartDefense - with an interface very similar to that of RealSecure. By the way, the similarity of the interfaces is a sore subject for many manufacturers. For example, some specialists think that the Cisco Secure Policy Manager interface is very much like that of CheckPoint Firewall-1.

Deception Systems

Usually, when it comes to deception in the field of information security, we immediately think about attempts by intruders to exploit vulnerabilities, or "back doors," to bypass the existing security mechanisms. This can include password theft, working on the account of legitimate users or unauthorized use of modems. However, intruders are not the only people for whom deception might prove to be useful. On the contrary, deception can be used with equal success to protect information resources. We do not usually think of as a security mechanism. Generally, when speaking about security and protection, we immediately think about contemporary firewalls, which block hackers' attempts to penetrate protected networks. Some even provide examples taken from science fiction, where Artificial Intelligence systems adapt to the behavior of the intruder and take adequate counter-measures. For example, William Gibson describes such a system in his novel "Neuromancer." But, if security is vital, you can not rely on firewalls to provide the required level of protection. If you need a truly powerful security system, you must also consider additional, non-standard protective mechanisms. This will help to deceive intruders accustomed to commonly known and actively promoted security tools.

There are many ways to use the deception for this purpose. Basing on the Dunnigan and Nofi classification [Cohen1-98], deception mechanisms are as follows:

Concealment
Camouflage
Misinforming

In one way or another, these mechanisms are useful in the standard activities of information-security departments. However, these mechanisms are also applied to ensure security in other areas (physical, economic, etc.) than information security.

In the field of information security, the first method - concealment - has found widespread applications. Concealing network topology using a firewall is an illustrative example of the use of this method for ensuring information security. Examples of "camouflage" include, for example, the usage of a UNIX-like GUI in a system running Windows. Intruders encountering such an interface will attempt to implement attacks that are effective against UNIX. This will increase the time required to implement a successful attack.

As a matter of fact, in most blockbuster movies about hackers, they could determine the OS type immediately - a brief look at the system prompt to enter the user name and password was usually sufficient. In contrast to other movie tricks, this is not an exaggeration. Generally, each OS has its own, system-specific method for identifying users. The login interface differs by font type, size, color login prompt text, position on the screen, etc. Camouflage allows you to protect yourself from attacks of this type.

Finally, as an example of misinformation, the usage of banners that inform the intruder of non-existent vulnerabilities is one example of note. For example, if your network uses Sendmail version 8.9.3, and the header that it returns states differently, intruders can waste a lot of time and resources attempting to exploit vulnerabilities characteristic of earlier sendmail versions (before 8.9.3).

Here, we will consider only the second and third classes of deception methods, because they are the least common and most interesting. Systems utilizing these methods actually emulate typical vulnerabilities that are non-existent in the protected objects. The use of tools based on camouflage or misinformation usually has the following effects:

They increase of the number of operations performed by the intruder. Since the intruder can not determine if the vulnerability found is real, additional time and effort is lost. Even additional efforts do not always help. For example, an attempt to initiate a brute-force attack on a non-existing or falsified file using a special password-checking utility (such as Crack for UNIX or L0phtCrack for Windows) will result in lost time without producing any effective result. The attacker will think that he or she was unable to crack the password, while the cracking software has actually been deceived.
They permit tracing of the attackers. While the intruders are trying to check the vulnerabilities detected, including falsified ones, security administrators can trace the whole sequence of their actions and take appropriate counter-measures.

Usually, an information system uses from five to 10 reserved ports (numbered from 1 to 1024). These ports include those responsible for services such as HTTP, FTP, SMTP, NNTP, NetBIOS, Echo, Telnet, etc. If the deception system emulates the usage of 100 or more ports, the time required for port scanning will increase proportionally. Now the intruder will find 100 or more open ports rather than five to 10. Besides this, detecting open ports is not sufficient. It is also necessary to take into account any vulnerabilities related to that port. Even if the intruder automates this task using the appropriate software (Nmap, SATAN etc.), the number of operations he or she must perform increases significantly, which makes the work less productive. At the same time, the intruder is constantly at risk, because he or she can be detected at any moment.

Deception systems have another specific feature. By default, attempts to access unused ports are ignored. Thus, active security tools might miss attempts at port scanning. On the other hand, if you are using a deception system, such actions will be detected on the first attempt.

Using deception systems, you can defeat intruders with their own weapons, and the situation does not aid the intruders, who earlier were one step ahead of security specialists. Including deception tools in security infrastructure is an interesting approach, and it can be very efficient, provided, of course, that it is used correctly. To improve the efficiency of a security system, it is recommended to combine a deception system with the intrusion detection system. This not only allows the detection of the intruder with the first attempt at an attack, but also provides time for a security administrator to trace the intruder and take efficient counteraction measures.

There are two classes of deception systems. Systems of the first class emulate services or vulnerabilities locally (i.e., on the same computer on which they run). Examples of such systems are the RealSecure OS Sensor, running in the so-called decoy mode, WinDog-DTK or the Deception Toolkit (DTK) system. Deception systems of the second class emulate whole computers, or even network segments, containing virtual hosts running various operating systems. An example of such a system is CyberCop Sting, or Honeyd. For misinforming, one can use the UkR.Nate system, which replaces the standard headers of common services (ftp, finger, pop3, smtp, telnet, ssh, lpd) and mimics the operating system on a protected host such as Linux, SunOS, FreeBSD, Windows NT, Digital Unix, SCO UnixWare, OpenBSD. This system also uses open ports characteristic to specific operating systems (for example, port 1433 for MS SQL in order to imitate Windows NT). Furthermore, this system uses an interesting mechanism of resisting remote OS fingerprinting - UST.AntiNmap.

But remember that deception systems are not universal tools that can prevent any attack. They simply help in cases of simple, unsophisticated attacks performed by beginners. However, if a qualified and skillful hacker attacks you, deception systems usually lose their efficiency. Preliminary traffic analysis allows intruders to detect fictitious ports. Modeling attacks and comparing the results with those produced by the real attacked system also allows the detection of the usage of deception tools. Furthermore, the incorrect configuration of a deception system will help the intruders to detect the fact they are being watched, and the intruders will stop the unauthorized activity. However, highly qualified hackers are not numerous, so the usage of deception systems can be helpful in most cases.

Currently, experts tend to use full-featured deception systems (honeynet) rather than standalone deception tools. This approach will provide a better and more detailed level of analysis. There is a special project named The Honeynet Project (http://www.honeynet.org), intended for studying hacker tools, methods, and motives.

The Deception Toolkit

The Deception Toolkit (DTK) is the first solution aimed at deceiving intruders attempting to penetrate the organization's network. This tool, developed by Fred Cohen, is intended to deceive automated security scanners by means of creating falsified vulnerabilities. Reports generated by security scanners can not help the intruder to determine which detected vulnerabilities are real and which are fictious. Thus, the intruder will have to spend time and resources checking all detected vulnerabilities, which will help the administrator to detect the attempt in time and, perhaps, even to trace the intruder.

The DTK can be customized easily according to the requirements of specific users. Usually, this programming is simply the creating a set of responses to the actions of attackers. For example, it is possible to create the sendmail banner returned in reply to an attempt to establish a connection to a specific port. This banner might include standard information on the program version, which is used by most security scanners when seeking the presence of vulnerabilities.

The DTK represents a set of programs written in C and Perl, and implementing the above-described mechanisms for deceiving intruders. These programs can be customized according to user preferences. The DTK can run on all operating systems supporting the TCP/IP protocol stack and having the Perl compiler implementation. For example, the DTK can run on most UNIX clones. DTK customization is performed by editing configuration files using any text editor. The DTK is a shareware program, which can be downloaded from http://all.net/contents/dtk.html. The DTK-Pro, the advanced version of this package, has all of the capabilities of the DTK, along with the following enhancements:

Centralized management of several DTK copies installed on different network hosts
Graphic user interface for DTK-Pro administrator (Fig. 6.27)
The ability to check the consistency of deception rules and several other functions

click to expand
Fig. 6.27. DTK-Pro GUI

CyberCop Sting

The CyberCop Sting system was developed by Network Associates, and is intended to emulate an Ethernet segment containing Cisco routers with IOS 11.2 and servers running Windows NT 4.0 and Solaris 2.6. All packets sent to modeled virtual hosts are traced, which enables the administrator to detect and trace the intruders while they attempt to attack non-existent hosts.

CyberCop Sting "creates" a virtual network on a dedicated Windows NT host. For Unix, one can use the Honeyd deception system, which supports FreeBSD, Linux, NetBSD, OpenBSD, POSIX, Solaris, and SunOS. Each of the virtual hosts has one or more IP addresses, to which one can send network traffic and obtain a "real" response. In more complicated cases, the virtual host can play the role of a packet repeater, sending packets to the invisible, but real, computer, which replies to all of the intruder's requests. The main advantage of CyberCop Sting lies in the fact that, to model a "lure" for intruders, you do not need a large amount of hosts and routers. The whole system resides on a single computer (Fig. 6.28).

click to expand
Fig. 6.28. The CyberCop Sting deception system

However, CyberCop Sting lacks the DTK's flexibility. For example, you can not specify emulated vulnerabilities and, even for standard network services that can be modeled by Sting, you will not be able to set specific responses for intruder requests. Furthermore, both the DTK and Sting lack powerful log-analysis mechanisms. Consequently, you will have to view hundreds, or even thousands, of text records to find the information you actually need. Despite the fact that there are third-party products that can serve this purpose (for example, WebTrends Log Analyzer), it would be very convenient to have built-in tools for log-file analysis.

Consistency Checker Systems

If, despite the presence of classical intrusion detection systems and other protective measures, the intruder still manages to penetrate the protected system, he or she usually attempt to install Trojan horse programs, edit system files, or cause the security system to fail. In most cases, these actions are reduced to editing certain files (executable files, dynamic link libraries, drivers, configuration files etc.).

Target-based analysis, also known as file-consistency checking, relies on passive methods of checking the consistency of the system and data files with the system objects (data flows, databases, registry keys) and their attributes. These consistency-checking methods have no significant influence on the functions of the controlled system. Consistency checkers use cryptographic checks for control checksums (CRC) to identify proof of the tweaking or falsification of the most important system objects or files. Algorithms implemented in these checks are characterized by the fact that even minor changes in function input data produce significant differences in the result. This means that minor deviations in the flow of input data will result in a significant difference in the CRC generated by the algorithm. These algorithms are resistant, which means that, provided that the input value is predefined, it is practically impossible to obtain the identical result for any other input value. This prevents the most common attacks against relatively simple algorithms of CRC generation, when hackers conceal the changes in file contents in such a way that the same CRC is generated both for the original and the modified file.

Consistency checkers work in an endless loop by processing files, system objects and their attributes for generating CRCs, then compare these results to the results generated in the course of the previous iteration and search for inconsistencies. If any difference is noticed, the product sends an administrative alert and registers the most probable time of the change.

Consistency control enables the implementation of an efficient monitoring strategy, focusing on the systems where data and process consistency is a matter of primary importance (for example, database management systems). This approach allows for the control of specific files, system objects and their attributes for changes, paying special attention to the result of an attack rather than to the details of its evolution. Detailed information on the advantages and drawbacks of consistency checkers is provided in Table 6.9.

Table 6.9a. Advantages and Drawbacks of Consistency Checkers
Advantages	Drawbacks

Any successful attack, as a result of which some files were modified - even if rootkits or packet-capturing tools were used- will be detected independently of whether signature analysis or statistical analysis was used for attack detection.	Contemporary implementations of this approach tend to work in batch mode. Therefore, they can not provide real-mode reaction to an attack.
Since consistency control is independent from old records of working modes, it will detect attacks that can not be detected by other methods.	Depending on the number of files, system objects and their attributes, for which control checksums are calculated, systems of this type can still have a negative impact on the performance of the controlled system.
This method allows for the reliable detection of both the location and the presence of attacks that modify the system (for example, Trojan horses).	These tools are not suitable for real-time intrusion detection, since they control attack results, rather than the processes of attack evolution.
Because this mechanism does not have a significant influence on the performance of the controlled system, consistency control can be useful for monitoring systems with medium bandwidth.
Consistency checkers are efficient for determining files that need to be replaced in order to restore the system, instead of complete reinstallation or restoring the system from the backup copy.

There are many consistency checkers, available both commercially and as shareware. As an example, I will consider a number of such systems here.

Tripwire

Initially, Tripwire (http://www.tripwiresecurity.com) was a shareware product. Later, however, the system was further developed by Tripwire Security, and is currently a commercial product. This system has several differences from similar shareware products, the first and the most important of which is the support of client/server architecture. In contrast to other systems, which run in stand-alone mode, Tripwire comprises two components - HQ Connector and HQ Console. The first component must be installed on remote hosts running various operating systems. It performs consistency control over the specified actions. The second component manages remote agents, collects information from those agents, and performs a centralized analysis of this information, generates reports, and performs other functions. Another distinguishing feature of Tripwire, which most other consistency checkers lack, is Windows support (systems of this class usually provide support for a large number of UNIX clones, but "dislike" Microsoft products). Tripwire supports the following operating systems: Windows NT, Solaris, Linux, AIX, HP-UX, IRIX and Tru64. The third important feature is the availability of a special language for describing consistency checking policy (Enhanced Policy Language).

To meet user requirements, Tripwire Security has also a released freeware version of this product, as part of the GNU project. It is known as Tripwire 1.3 ASR, and has the following differences from the commercial release:

No Windows support
No capability for sending CRC-change alert via e-mail
Limited number of controlled attributes (only nine, in contrast to the commercial version, which controls 14 attributes)
Limited capabilities of the report generator (no sorting, no details)
Lack of a centralized management console
No capability of changing check priorities, does not protect its own files from unauthorized access

AIDE and L5

According to some specialists, the AIDE (Advanced Intrusion Detection Environment) system - available for download from http://www.cs.tut.fi/~rammer/aide.htmp - and L5 (ftp://avian.org/src/hacks) are the best alternatives to the freeware version of Tripwire.

Gog&Magog

In contrast to the tools considered above, the Gog&Magog system (http://www.multimania.com/cparisel/gog/) not only generates and checks the control sum (according to the MD5 protocol) for selected files (in automatic mode), but also controls other file parameters (access rights, owner and so on).