Using overlapping IP fragmentation to avoid detection by an IDS has been around for a long time.  We know how to solve this problem.  The best option in my opinion is to use a tool such as OpenBSD's pf packet filter [1] to scrub our packets eliminating all the fragments (pfSense [2] makes this easy to deploy).  However, this option is not without its caveats [3].  You could simply configure your IDS to alert for and/or drop any overlapping fragmented packets.   Overlapping fragments should not exist in normal traffic.   Another option is to configure the IDS to reassemble the packets the same way the endpoint reassembles them.  Snort's frag3 preprocessor will reassemble the packets based on the OS of the target IP and successfully detect any fragmented attacks that would work against a given target host.  Problem solved right?  There is another opportunity for attackers to use differences in the fragmentation reassembly engines to his advantage.  What happens when the IDS analyst turns to their full packet capture to understand the attack?  If the analyst's tools reassemble the packets differently than the target OS the analyst may incorrectly dismiss the TRUE positive as a FALSE positive.

Today, with the low cost of disk drives, more and more organizations can afford to maintain full packet captures of everything that goes in and out of their network.  If you are not running full packet capture, you really should look into it.  I don't think there is a better way to understand attacks on your network then having full packet captures.  One great option is to install Daemonlogger [4] on the Linux/BSD distribution of your choice.  This was an option I used for many years.  Today, I use the Security Onion distro [5] by Doug Burks. If you want a free IDS with full packet capture that you can quickly and easily deploy, Security Onion is a great option.

Once you have the full packet capture, how do you find the fragmented attacks?  You could try reassembling them with Wireshark.  Let's check that out and see what happens.  Security Onion has scapy installed so let's use that to generate some overlapping fragments.  I'll generate the classic overlapped fragment pattern illustrated by the paper “Active Mapping: Resisting NIDS Evasion Without Altering Traffic” by Umesh Shankar and Vern Paxson [6] and then further explained in “Target Based Fragmentation Assembly” by Judy Novak [7].

Now open up our "fragmentpattern.pcap" with Wireshark and see what we see.

If you compare the reassembled pattern to what was outlined in Judy Novak's paper you will recognize the BSD reassembly pattern.  So you will see all the attack packets that are targeted at a host using the BSD reassembly methodology, but not ones targeted at other reassembly policies (First, Last, BSD-Right and Linux).   You would not see overlapping fragmentation attacks targeted at both Windows and Linux.  However, Security Onion now (as of build 20120518 [8] ) has a Python script called "reassembler.py". If you provide reassembler.py with a pcap that contains fragments, it will reassemble the packets using each of the 5 reassembly engines and show you the result.  It will even write the 5 versions of the packets to disk so you can examine binary payloads as the target OS would see them.  Let's see what reassembler does with the fragmented packets we just created.

Now you can see exactly what the IDS saw and make the correct decision when analyzing your packet captures.   If using the Onion isn't an option for you, you can download reassembler.py direct from my SVN  http://baggett-scripts.googlecode.com/svn/trunk/reassembler/.   How do you handle this?   What are some other ways to solve this problem?  Leave a comment.

Security Onion creator Doug Burks and I are teaching together in Augusta GA June 11th - 16th.  Come take "SEC503 Intrusion Detection In-Depth" from Doug or "SEC560 Network Penetration Testing and Ethical Hacking" from me BOOTCAMP style!  Sign up today! [9]

Mark Baggett

@MarkBaggett

http://www.indepthdefense.com

[1] http://www.freebsd.org/doc/handbook/firewalls-pf.html
[2] http://www.pfsense.org/
[3] http://sysadminadventures.wordpress.com/2010/11/02/why-pfsense-is-not-production-ready/
[4] http://www.snort.org/snort-downloads/additional-downloads
[5] http://securityonion.blogspot.com/
[6] http://www.icir.org/vern/papers/activemap-oak03.pdf
[7] http://www.snort.org/assets/165/target_based_frag.pdf
[8] http://securityonion.blogspot.com/2012/05/security-onion-20120518-now-available.html
[9] http://www.sans.org/community/event/sec560-augusta-jun-2012