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

Now, after discussing the general problems common to all classes of intrusion detection systems, let's analyze network-level tools. This class of tools includes the most popular systems.

Networks with Switching

Networks with switching pose quite a lot of problems for network-level intrusion detection systems, as well as for network analysis in general. There are many possible ways to solve this problem. However, they all are not always satisfactory. More detailed information on this topic was provided in Chapter 10.

Networks with Channel Encryption

Obviously, if traffic is encrypted, it is impossible to detect any attack within it. A detailed illustration of this case was provided in Fig. 1.7. Thus, despite the fact that encryption strengthens security and prevents intruders from accessing the data being transmitted, if the encryption capabilities are incorrectly used, they become an obstacle to ensuring proper security. Do not forget that attacks can also be encrypted! The problem becomes especially important in distributed networks that have several offices communicating via public networks that are protected using VPN devices. If the intruder manages to penetrate one of the remote affiliates, he or she can use the VPN connection to penetrate another office, and the perimeter protection tools, including intrusion detection systems, will not notice anything.

Another problem relates to the fact that most hacker tools—especially the newer releases of Trojan horses and tools for implementing distributed attacks (such as TFN2K)—encrypt all commands and other traffic used for communication between their components. This also prevents security administrators from detecting and stopping unauthorized activity within a reasonable time.

Modems

Network-level intrusion detection systems can not always detect and identify attacks directed to network hosts in which modems are installed. If a modem is used as an entry point to the corporate network, it is relatively easy to detect attacks performed via that modem. On the other hand, host-level intrusion detection systems and security scanners (such as Internet Scanner or System Scanner) provide a more efficient way of solving this problem than network-level intrusion detection systems do.

Shortage of Resources

Network-level intrusion detection systems are installed in the most critical network segments. They must be capable of operating at the speeds provided by the network equipment, as well as of analyzing and storing information collected from hundreds of network hosts. Obviously, it is not easy to find an IDS that can satisfy these requirements.

The most common problems caused by resource shortages are briefly covered below.

High-Speed Networks

Currently, the network sensors of intrusion detection systems can not successfully handle attacks in heavily overloaded network segments (that operate at speeds above 100 Mbit/sec). Although there are solutions that are capable of handling such intense traffic, they are still quite rare and very expensive. The list of such systems includes RealSecure Gigabit Sensor and the Cisco Catalyst 6500 IDS Module. All these products allow you to detect an attack in Gigabit traffic, and some of them can operate in ATM networks.

Size and Number of Processed Packets

The number of packets processed per second and the average packet size are very important parameters of any network-level intrusion detection system. As was shown in Chapter 10, these parameters primarily influence the efficiency of the intrusion detection system.

Various Modifications of Attack Signatures

The number of signatures in the IDS database also influences the IDS throughput. Notice that when speaking about this parameter, we mean signatures rather than security events. For example, for the attack on the PHF CGI script mentioned in Chapter 2, there might be several interchangeable attack signatures:

GET /CGI-bin/phf
HEAD /CGI-bin/phf
GET /%63%67%69%2d%62%69%6e/phf
GET //CGI-bin/phf
GET /CGI-bin/foobar/../phf
GET /CGI-bin/./phf
GET%00/CGI-bin/phf

Taking this into account, the formula provided in Chapter 10 can be rewritten as follows:

   Throughput = number of processed packets * average packet size * number   of signatures in the database * average size of the signature

For example, for the data provided above that has 4000 signatures (supposing that the average signature size is 20 bytes), the required throughput will be 3,600,000,000,000 (for 1500-byte packets) or 153,600,000,000 (for 64-byte packets) operations per second. Currently, such a performance can not be attained by general-purpose computers. Because of this, most existing intrusion detection systems miss some modifications of known signatures.

There is yet another problem related to the modification of attack templates. As I mentioned earlier, most intrusion detection systems operate on the principle of comparing fragments of network packets to a pattern (template). Using databases of well-known attacks enables you to identify the attacks that are highly probable. However, such systems can be easily deceived by simply introducing minor changes to the template. The list below provides several examples of this technique [Cohen1-99].

Inserting additional characters with no particular meaning into the attack commands and data, which usually prevents the IDS from detecting such an attack.
Replacing spaces with tab characters in commands that implement an attack.
Changing the delimiter character in the system (for example, the space character can be replaced by %), which will cause specific problems in detecting the unauthorized activity. For example, a URL such as "dir/examples attack/attack.asp" can be replaced by "/dir/examples%20attack/attack.asp."
Redefining the standard sequence of actions taken when implementing an attack. For example, if the attack has the same effect when performing the commands "a;b;c" as when issuing the "b;a;c" sequence of commands, most intrusion detection systems will recognize the first attack, but will fail to identify the second variant.
Defining a macro for a parameter used for attack implementation, such as "$P" instead of "/etc/passwd," or "%SystemRoot%" instead of "c:\winnt."
Creating a script containing the commands issued when implementing an attack. If this operation is carefully planned, the intrusion detection system will fail to correlate the script name and the commands, which will result in a false negative.

Just as lazy as most people, hackers also try to automate routine processes. There have been a number of utilities released intended for automating attacks, such as Snot or Stick. For example, the Snot utility creates random packets based on the Snort IDS database. These random packets contain noise data that have no influence on the attack, but that are different from the attack signature contained in the Snort database. Other automated tools for deceiving intrusion detection systems include Stick, Whicker, etc.

Scanning Distributed in Time

Intrusion detection systems encounter difficulties when it is necessary to log a large amount of network traffic for a long time. Thus, they will have difficulties with detecting time-distributed scanning (implemented, for example, by using the -sI parameter with the Nmap v3 scanner) when the intruders address a specific port or address for several minutes or even hours. Such a scanning technique significantly complicates attack detection by an intrusion detection system.

Causing IDS Failures

Besides the problems that we have already covered, IDSs themselves can become the target of attacks. Causing an IDS to fail will enable the intruders to penetrate the corporate network without being noticed, and then to perform any unauthorized actions.

"Blinding" the Sensor

Most intrusion detection systems have problems when handling high-speed networks. As a result, if there is a heavy network workload, the sensor will start to miss some attacks, or may even fail. Thus, the intruder can neutralize the IDS by generating a large amount of traffic. This attack is possible in a few cases. First, it can be implemented by an intruder who is capable of generating a large amount of traffic within the same network segment in which the sensor is located. Secondly, this attack is viable when implementing a distributed attack on perimeter hosts. In this case, several dozens, hundreds, or even thousands of hosts can send packets at speeds ranging from 28.8 Kbit/sec to 64 Kbit/sec. With the large number of participants, the attack will have the effect of a flood, causing the attacked host to fail. Finally, there is a third, simpler and more dangerous approach. Using this technique, there is no need to generate a large amount of traffic or employ thousands of hosts to organize a distributed attack. Rather, it is sufficient to just imitate non-existent attacks to which the IDS is to react. In this case, the management console will be flooded with lots of false positive messages, making it impossible to detect the real attack among them. This attack is very dangerous in itself. What's even worse, there are special tools to automate this type of attack, such as Stick, which generates a false attacks with spoofed addresses based on Snort rules at a speed of 250 alarms per second.

Denial of Service

An intrusion detection system operating at the network level is a very complex system that is also vulnerable to DoS attacks. Some such problems are covered in [Paxson1-98]. All Denial of Service attacks on an intrusion detection system can be divided into the following two categories.

Overload attacks
Crash attacks

Overload attacks imply the creation of conditions under which the intrusion detection system will fail to (or simply will not) process or store the analyzed data. A Log Flood attack is a typical example of such an attack. If implemented successfully, it disrupts the operation of the event logging system or overwrites the recorded events (including the events that prove the presence of an attack in the network traffic). Fig. 12.6 shows the event log of an application vulnerable to such attacks (Event Viewer).

click to expand
Fig. 12.6. Event Viewer

To eliminate the possibility of such an attack on the intrusion detection system, one can use various mechanisms. For example, RealSecure Network Sensor implements the Event Propagation mechanism, which allows you to reduce the number of events displayed on the console and stored in the database, thus protecting it from overflowing. Another advantage of this mechanism lies in the fact that it does not distract the administrator's attention with meaningless events.

The second class of attacks is similar to overloading. However, in contrast to the first class of attacks, which can be registered at least implicitly, the situation is more complicated with the second class. For example, the intruder can exploit bugs in the IDS code in order to cause it to fail. This is what happened with the outdated version of the RealSecure Network Sensor (v. 3.2.2), which failed when processing fragmented traffic. This type of attack is especially dangerous to systems that capture network traffic using an OS driver rather than a custom driver working directly with the network adapter. If this is the case, the intruder can exploit vulnerabilities of the network protocol stack of the operating system. As a result of such an attack, not only the OS will fail, but all applications as well.

Simple Deception

This section describes easy ways of deceiving intrusion detection systems. More sophisticated methods of bypassing IDSs are covered in [Cohen2-99], [RFP1-99], and other sources.

Fragmentation

Fragmentation is a mechanism of dividing IP packets into a set of smaller fragments. When receiving such packets, the TCP/IP device reassembles them and passes them to the target device, or repeats the fragmentation and transmits them further. Most intrusion detection systems can not restore fragmented IP packets. This results in the possibility of them being bypassed, or even causing them to fail. This vulnerability is very dangerous, since currently there are specialized tools for fragmenting normal network traffic (such as FragRouter).

Changing Default Values

As I already mentioned, some intrusion detection systems presume that the source or destination ports unambiguously identify the protocol used for communication between several hosts. For example, port 80 corresponds to HTTP, port 23 to Telnet, port 31337 to the BackOrifice Trojan, etc. However, the intruder can use standard protocols on non-standard ports (for example, assign port 8081 to HTTP) or change the default ports, which will prevent some intrusion detection systems from processing such "non-standard" traffic.

Address Spoofing

Quite often, the attacker uses address spoofing—i.e., replaces his or her actual address with a false one, which complicates the detection of the attack source in a timely manner. For example, the Nmap scanner can generate packets containing decoy addresses, which will stuff the log file of the intrusion detection system. For an administrator, it is rather difficult to determine which addresses registered as the sources of attack are real and which have been spoofed by the intruder. Although the problem of detecting the real address of the attack source relates to the incident response problem that will be covered later, this problem is not the one to be neglected.

The Problem with UNICODE

There is yet another problem that could have been covered in the section dedicated to the modification of attack signatures. However, since this problem is rather important, I've decided to discuss it in a separate section. This problem comes about due to the fact that not all network-level intrusion detection systems can identify attacks using the UNICODE data format. Currently, UNICODE is supported by most software tools and standards, including Java, LDAP, XML, MS IIS, Apache, MS Office 2000, etc. The UNICODE standard uses the UTF-8 conversion scheme to convert UNICODE characters into sequences with a length from one to 4 bytes. Compatibility with ASCII is ensured using UTF-8. UNICODE allows you to have several representations for a single character. For example, the backslash "\" can be represented by the following hex values: 5C (single-byte sequence), C19C (two-byte sequence), and E0819C (three byte sequence). For all applications supporting UTF-8, these three values are identical. Although quite recently the UNICODE Consortium abolished multiple representation for UTF-8 characters and released the "UTF-8 Corrigendum" document, applications developed before this document was published still support the outdated UTF-8 standard.

The next vulnerability related to UNICODE is caused by the fact that different applications or operating systems can interpret different UNICODE characters (also known as code points) similarly. For example, in [Hacker1-01], it was reported that MS IIS operating in Windows 2000 Advanced Server interprets the following UNICODE characters as "A": U+0041, U+0100, U+0102, U+0104, U+01CD, U+01DE, and U+8721. If we take into account the fact that IIS is case-insensitive (which means that it does not distinguish between uppercase and lowercase characters), we can easily draw the conclusion that the "A" character can be described by 30 different UNICODE combinations. Similarly, "E" has 34 representations, "I" 36, "O" 39, and "U" 58. By multiplying these values, we get 83,060,640 different combinations that can be used for the "AEIOU" string. Notice that all these representations will be interpreted absolutely equally.

One of the first UNICODE-related security problems described by [Xforce1-00] is related to MS IIS 4.0 and 5.0. For example, an attempt to access the following URL resulted in disk formatting:

   http://www.domain.com/../../winnt/system32/cmd.exe?/c+format+c:

This was due to the fact that the ".. /.." fragment was capable of bypassing IIS 5.0 security and getting to the root directory of the web server. However, direct access to the specified address resulted in deletion of the ".. /.." and the display of an error message. Still, replacing this address with a URL containing a UNICODE fragment, such as:

   "http://www.bank.ru/..%c1%9c../winnt/system32/cmd.exe?/c+format+c:''

allows you to execute an unauthorized command. Similar results can be obtained by using the following UNICODE fragments instead of "..%1c%9c..": "..%c1%1c..," "..%c0%9v..," "..%c0%af..," "..%c0%qf..," "..%c1%8s..," "..%c1%9c..," "..%c1%pc..," etc.

Sophisticated Deception

Skillful intruders can use more complicated methods of deceiving or bypassing intrusion detection systems. These methods of evasion are described in [Ptacek1-98]. The original version of this document is available at the following address: http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps (the HTML version can be viewed at the following address: http://www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.HTML).

Let's consider one of the newer methods of bypassing an intrusion detection system. The RealSecure Network Sensor system provides the Event Propagation mechanism, which allows you to decrease the number of events displayed on the console and registered in the database. This mechanism, originally used to make intrusion detection systems less vulnerable to a DoS attack, can also be used for malicious purposes. For example, if the intruder knows that a network sensor stops registering FTP_Put events after detecting 100 such events logged in 2 minutes, it can imitate 100 normal FTP_Put events, and then perform the 101st—an FTP_Put operation containing an attack, which would not be displayed on the RealSecure console. RealSecure Network Sensor stops registering such events after the first 100 such events have been registered, and thus the hacker remains unnoticed. This example can serve as an additional illustration of the thesis that you should not inform all users of the specific features and individual settings of your security infrastructure in general, and the IDS in particular.