Previous Section  < Day Day Up >  Next Section

4.4 IDS Evasion

When dealing with networks that use intrusion detection systems such as Snort, you must be aware of any other tools that can bypass security restrictions. If an attacker can disguise his activities from your IDS, you may not be aware of the attack until it is too late. There are a variety of strategies employed by attackers to hide their actions.

Some of the tools we've already discussed have components that help hide their traffic from your IDS. Nmap has the ability to throttle the packets it sends when scanning so that packets are sent so slowly that they do not trigger portscan detection mechanisms. Another nmap evasion technique is to generate numerous packets in addition to the actual scan. These packets have forged source addresses and the actual scan gets lost in the noise. This technique does not keep the IDS from noticing the portscans; instead, it generates so many alerts that determining the actual source is more difficult.

The web scanner nikto has an IDS evasion mode, as well. As of Version 1.10, LibWhisker's anti-IDS methods have been enabled in the event you wish to test your IDS. Depending on how recently you updated your signatures, the anti-IDS feature may or may not be able to circumvent your IDS. It may have greater luck bypassing proprietary intrusion detection systems whose signatures have not been recently updated. Refer to the help file for additional options. You enable the IDS evasion mode by appending the -evasion+ option and the preferred IP address.

Another strategy for evading detection is to encrypt traffic; encrypted packets will not match the signatures and thus won't trigger alerts. sslproxy is a useful tool for encrypting web scans; it negotiates an SSL connection with an SSL-enabled web server. The proxy then sends the scan across this encrypted tunnel. Any web-based attack activity can be sent across the tunnel, effectively making it invisible to the IDS.

Stick is a program that is still in the works. Its author is considering releasing to the public. It is labeled an "IDS stress tool" and is used to evaluate the bottleneck in a production environment. During testing it caused the ISS Real Secure IDS Version 5.5 to turn itself off due to errors. The ISS Real Secure sensor died two seconds after the attack with Stick began. The same results occur with other IDS solutions, including Snort.

The concept behind Stick is a simple one: overwhelm a network intrusion detection system with so many alerts using valid signatures that the security administrator can no longer distinguish between false positives and legitimate alerts. According to the author, Stick uses a Snort rule set and a C program via lex that, when compiled, produces an IP packet capable of triggering that rule from a spoofed IP range (or all possible IP addresses) into a target IP range. A function is produced for each rule and a loop executes all rules in random order. The tool currently produces 250 alarms per second. A Linux-based Snort IDS will hit 100% CPU and start dropping packets at this level of attack. So far, the author has only released the Stick source code to IDS vendors. More information regarding Stick is available in the author's "Papers" section. The one titled "Fun with Packets: Designing a Stick" by Coretez Giovanni is particularly useful for explaining how Stick works and how to overwhelm IDS devices.

Two other tools that can be used for stress-testing an IDS machine prior to gaining access or slipping in undetected are Snot and Fragroute. The former is similar to Stick in that it triggers false Snort alerts using a Snort rules file for its input. This both overwhelms and confuses the IDS since the security administrator can no longer tell the difference between the false positives caused by snot or any real alerts triggered by the attacker. Snot is basically an IDS evasion tool. It attempts to randomize the sequence of rules or alerts generated so that a "Snot generation" rule is not triggered by Snort. Snot is easily executed on a Linux or Unix-based system. Here is an example of Snot:

snot -r snort.rules -s -d -l 10

Snot first reads in the snort.rules file, sends packets with a source address from anywhere on the CIDR-notated /24 network that resolves to, and then transmits the packets to, sleeping for up to 10 seconds per packet.

If your CIDR notational skills are lacking, refer to the following URL for a refresher course:

However, there are rules within Snort that do account for these types of attacks and do alert administrators that a Stick/Snot attack is underway. Using the -z command-line switch in concert with the stream4 code, Snort generates alerts warning the administrator when it sees these types of anti-IDS attacks. The -z switch runs without arguments. If the -z switch is specified, Snort only sends alerts (for TCP traffic) on streams that have been established via a three-way handshake or streams where cooperative bi-directional activity is observed, i.e., where some traffic went one way and something other than a RST or FIN was seen returning to the originator. With the -z option enabled, Snort completely ignores TCP-based Stick/Snot "attacks" and logs other malicious packets normally. In other words, Snort operates as usual and is not confused by an IDS evasion tool.

If you suspect a Snot/Stick attack is underway against your system, initiate Snort using the correct flags. For example, here is how you might start the Snort command on machine A with the -z option enabled:

# snort -i eth0 -c /etc/snort/snort.conf -l /var/log/snort -z

Running Snot on machine B while targeting machine A appears as follows:

# /usr/local/bin/snot -r snortrules.txt -d -s -n 16384

The snortrules.txt file is a default snort.conf configuration in which all rules are gathered in one file. The address belongs to machine A, the target of the Snot attack. As such, machine A operating as a Snort sensor continues to see only regular traffic and not a surplus of false positives generated by a Snot attack.

The second application, Fragroute, intercepts, modifies, and rewrites egress traffic to a given host. It complicates normal traffic to such a degree that an IDS does not know what to do with certain packets. It features a simple ruleset language to delay, duplicate, drop, fragment, overlap, print, reorder, segment, source-route, or otherwise monkey with all outbound packets destined for a target host, with minimal support for randomized or probabilistic behavior, unlike Snot, which attempts to randomize the inserted rules. According to the author, Dug Song, this tool was written in good faith to aid in the testing of network intrusion detection systems, firewalls, and basic TCP/IP stack behavior. He, as well as many others, asks that security administrators not abuse this software. It is provided for testing local network security.

The Fragroute application does require additional libraries, specifically the libevent file. This library is also available for download from Dug Song's site. Once installed, the fragroute application is then compiled. The binary is placed in the /usr/local/sbin/ along with Firewalk and the Nessus daemon. The fragroute program uses the following syntax for execution:

# /usr/local/sbin/fragroute -f <file> <destination>

Replace the <file> variable with a snort.rules file and the <destination> variable with a valid IP address, preferably one associated with an IDS monitoring box. There are additional variables that randomize the rules, change the TCP packet size, and set other options. Familiarize yourself with this application's use on a test machine before attempting to use it on a production IDS box. The last thing you want to do is bring down an operating IDS and blind yourself to real attacks.

Snort can also detect these types of attacks. There is a default fragroute rule included with the standard Snort rules. Here is a sample alert generated by a fragroute attack:

alert ip any any -> any ( sid: 1791; rev: 2; msg: "BACKDOOR fragroute 

trojan connection attempt"; reference: bugtraq,4 898; classtype: trojan-activity;)

With the current version of Snort, most of these IDS evasion techniques can be detected and countered. Like most aspects of network security, it is a case of the attackers developing new methods and the defenders developing new countermeasures against the attacks. Once these countermeasures become accepted practice, the attackers develop counter-countermeasures, ad infinitum.

    Previous Section  < Day Day Up >  Next Section