Detecting IDS Evasion


I have these great rules, but I went to Defcon and saw H.D. Moore (available here: use IDS evasion to bypass Snort's rules. How can I defend against that?


Snort is a signature-based IDS. Most of the methods of evading signature-based IDS systems rely on disguising the attack in a way that doesn't match the standard signature. There will always be someone who writes some great evasion technology to bypass your signature-based IDS. However, all hope is not lost; Snort has several preprocessors that will help normalize the traffic.

  • If the attacker is using multiple small packets to disguise the attack, use the stream4 preprocessor.
  • If the attacker is attempting to disguise the attack by breaking a packet up into small fragments, use the frag2 preprocessor.
  • If the attacker is attempting to use arpspoofing to gain access, use the arpspoof preprocessor.
  • If the attacker is attempting to use an alternative method of writing a path (/etc/passwd or /home/simon/../../etc/passwd, for example), use the http_inspect preprocessor.


Preprocessors are plug-ins to Snort that take data off the network and reassemble it in a similar format to the way it finally reaches the target. There are a number of ways to attempt to evade a signature-based IDS, and they all rely on making the packets fail to match the signature. Snort has several preprocessors and components that will help detect or ignore several types of IDS evasion tactics. For example, the http_inspect preprocessor can be very useful in fighting attacks that try to obfuscate the attack by hiding in Unicode or other character sets. Snort can also use its stream4 preprocessor to help rebuild packets that try to hide in a flood of seemingly nonessential packets. The frag2 preprocessor attempts to reassemble fragmented packets and detect when they have state problems. The following sections include detailed information on using preprocessors to protect against IDS evasion techniques.


The stream4 preprocessor reassembles a number of packets to interpret the payload. If we assume for a moment that the string "open sesame" will activate a trap door letting in an attacker, we would write a Snort rule that detects "open sesame" as a string. If the attacker then breaks the string up into smaller packets, say "o," "p," "e," "n," etc., the string wouldn't match. However, when the smaller packets were reassembled by the target machine, the string would still exist. stream4 does this reassembly for Snort and allows you to write a rule to detect the attack string, regardless of the number of packets in which it is sent.

preprocessor stream4: 

Stream4 is included by adding the previous line to your snort.conf file. Table 3-2 lists configuration options for the stream4 preprocessor:

Table 3-2. Configuration options for the stream4 preprocessor




This option sets stream4 to detect port scans that are not using the standard TCP handshake as the scan method.


This option sets stream4 to detect problems with the way the TCP stream is keeping state. This could indicate a number of hijacking attacks.


This option disables the alerts given by stream4 relating to attempts to evade the IDS using packet stream related attacks. It should be disabled only if you are getting a large number of false positives.


This option sets the maximum difference that will be allowed in the routing lengths of different packets in the same session. Generally, packets should have very similar time-to-live fields, and large discrepancies are typical of an attempt to hijack a session.


This option keeps statistics on each session that stream4 deals with. These statistics are written out to a file either in machine format, which is plain text, or binary, which is the standard Snort unified output.


This turns off stream reassembly for all ports except those explicitly specified.


This sets the time that stream4 will cease to watch a session that has ceased to be active.


This option makes stream4 log the packet that it has reassembled when it creates an alert.


This sets the maximum amount of memory that stream4 can consume in keeping track of the state of sessions.

clientonly / serveronly / both

This option specifies which parts of the session should be reassembled.


This specifies which ports should be reassembled if you set the noinspect option.



The frag2 preprocessor reassembles fragmented packets. An attack using fragmented packets is similar to one using multiple packets; it makes use of the ability to reduce a packet into smaller packets within an IP network. This allows packets to traverse networks with a smaller maximum transmission unit (MTU) size. The process is similar to breaking up a string, although the break point need not necessarily send complete characters. In addition, this type of attack would be used with tools like Snot and Sneeze to try and flood the IDS sensors with bad data. However, using the frag2 preprocessor and running Snort with a -z flag will help defend against this type of attack. This is due to the fact that the -z option tells Snort to only alert on streams that have established a three-way handshake. While this will defend against stateless attack tools like Snot and Sneeze, it does ignore some attacks that don't need an established connection, such as several new DDoS tools that use a single Syn-flagged TCP packet for their commands. One solution to this problem is to enable -z only on certain sensors. On others, set rules for stateless detection.

Frag2 is included using the following line in your snort.conf file:

preprocessor frag2: 

Frag2 takes the options listed in Table 3-3.

Table 3-3. Configuration options for the frag2 preprocessor




This option tells frag2 to drop a fragment, if it hasn't received the following fragment within the timeout.


This option specifies how much memory frag2 can use to keep track of fragmented packets.


This option specifies the minimum time-to-live that a packet must have before Snort bothers with it: if the IDS is n hops away from the target and the ttl is n - 1 hops, it can be immediately discounted.


This option sets the maximum difference that will be allowed in the routing lengths of different packets in the same session. Generally, packets should have very similar time-to-live fields, and large discrepancies are typical of an attempt to hijack a session.


This option detects errors in the state of the fragment streamfor example, two or more fragments of the same number.



The arpspoof preprocessor detects Address Resolution Protocol (ARP) spoofing attacks. These attacks convince machines that they should send network traffic for a certain host or hosts to the attacker's machine instead of the correct destination. Used properly, this also allows eavesdroppers to listen in on a switched network, where normally they would receive nothing. On the down side, there is very little that is automatic about this rule. You need to specify each host individually along with the correct ARP address. You do this by inserting the following lines into your snort.conf file:

preprocessor arpspoof

preprocessor arpspoof_detect_host: 00:09:5B:3B:CE:E6

The arpspoof preprocessor can also detect unicast ARP requests (ARP is normally broadcast). You turn on unicast alerting by using the -unicast option on the arpspoof preprocessor line in snort.conf.

preprocessor arpspoof: -unicast



What if the attack came over HTTP? The http_decode preprocessor normalizes HTTP requests. This means that it translates the many ways of writing a URL into one single format that you can more easily scan for a specific string. If an attacker sends Code Red with Unicode encoding tagged to the packet:

GET / HTTP/1.0

with the help of the http_inspect preprocessor, that's turned into the attack of:

GET /default.ida HTTP/1.0

You can add the http_decode preprocessor to your snort.conf with the following line:

preprocessor http_decode

This monitors all traffic to port 80 by default. If you wish to monitor other ports, you need to specify these as a list on the preprocessor line, as follows:

preprocessor http_decode: 80 8080 8000

After this list, you can specify any of the options listed in Table 3-4.

Table 3-4. Configuration options for the http_decode preprocessor




Decodes Unicode to normal ASCII text.


Decodes Unicode from the alternative IIS representation. Use if you have IIS servers.


Decodes strings that have been encoded in HEX twice. For example, an attacker sends a URL with %255c in it. The %25 decodes as the % sign, so this will decode as %5c, which in turn decodes as /.


This changes all slashes to lean the right way. So all are changed to /.


This translates tab characters to spaces. This is an attack targeted at Apache, which translates all tabs to spaces, so a string with spaces can be obfuscated by use of tab characters.


This ceases processing if http_decode detects an invalid hex character (e.g., %GG). This is advisable if you are running Apache servers, which will also drop any requests with incorrect hex.


This drops everything after the parameter marker in a string. So in a GET method form, it ignores everything after the ?.


This detects certain abnormal conditions. For example, any HTTP command over 10 characters long is flagged, because the longest normal HTTP request is only seven characters long.

Used in combination, these preprocessors should cover you for most of the possible evasion methods that are likely to be put forward by 99 percent of your attackers. You should bear in mind, though, that new attacks appear daily (or even hourly), so keeping Snort up to date is vital. All the previously discussed preprocessors (with the exception of fnord) are in active development and have regular updates. Using all these preprocessors and keeping evasion in mind when writing rules should help prevent attacks from sneaking past your Snort sensors. For more information on preprocessors, see Chapter 4.

See Also

H.D. Moore's metasploit framework ( for some tools to test evasion techniques

Snort Users Manual

Countermeasures from Rules

Installing Snort from Source on Unix

Logging to a File Quickly

How to Build Rules

Detecting Stateless Attacks and Stream Reassembly

Managing Snort Sensors

Generating Statistical Output from Snort Logs

Monitoring Network Performance


show all menu

Snort Cookbook
Snort Cookbook
ISBN: 0596007914
EAN: 2147483647
Year: 2006
Pages: 167
Similar book on Amazon © 2008-2017.
If you may any questions please contact us: