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
to hide their actions.
Some of the tools we've already discussed have
that help hide their traffic from your IDS. Nmap has the ability to
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
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
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
option and the preferred IP address.
Another strategy for
detection is to encrypt traffic; encrypted packets will not match the signatures and thus won't trigger alerts.
is a useful tool for encrypting web
; 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.
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
itself off due to errors. The ISS Real Secure sensor died two seconds after the attack with Stick
. 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
alerts. According to the author, Stick uses a Snort rule set and a C program via
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
. 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
. 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 www.somerandomhost.org/24 -d somesnortuser.com -l 10
Snot first reads in the
file, sends packets with a source address from
on the CIDR-notated
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: http://jodies.de/ipcalc/.
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
command-line switch in concert with the
code, Snort generates alerts warning the administrator when it sees these types of anti-IDS attacks. The
switch runs without arguments. If the
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
, i.e., where some traffic went one way and something other than a RST or FIN was seen returning to the originator. With the
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
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
# snort -i eth0 -c /etc/snort/snort.conf -l /var/log/snort -z
Running Snot on machine B while targeting machine A appears as
# /usr/local/bin/snot -r snortrules.txt -d 192.168.10.254 -s 192.168.10.0/24 -n 16384
file is a default
configuration in which all rules are gathered in one file. The address 192.168.10.254 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
of false positives generated by a Snot attack.
The second application,
, 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
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,
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
along with Firewalk and the Nessus daemon. The fragroute program uses the following syntax for execution:
# /usr/local/sbin/fragroute -f <file> <destination>
variable with a
file and the
variable with a valid IP address, preferably one associated with an IDS monitoring box. There are additional
that randomize the rules, change the TCP packet
, 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 -> 220.127.116.11 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
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.