Continuing with our series on network security monitoring with NetFlow, I’d like to discuss a strategy for detecting IP fragmentation attacks with Scrutinizer. The bestiary of network threats is vast. We, as virtuous NetFlow knights must stay ever vigilant and sometimes adopt unconventional strategies for vanquishing foes seen and unseen. First, I’d like to cover the basics of IP Fragmentation exploits. Then I’d like to propose some strategies for monitoring these little beasties in Scrutinizer. So grab your NetFlow swords, dragon slayers. Network village isn’t going to defend itself…
IP Fragmentation: What is it?
Often lumped in with other forgotten wonders of TCP/IP, fragmentation is a critical service frequently overlooked. There are far more detailed resources on packet fragmentation out there, so let’s just do a quick recap: Should a host want to transmit a packet over a network whose packet length is larger than the network’s maximum transmission unit (MTU), that packet will be split in to several smaller packets. There are three key fields in the IP headers of these fragmented packets which help the destination host reassemble the original packet.
- Fragment ID – This is the same thing as the IP header identification field. It’s our way of keeping track of which original packet this fragment is a part of.
- Fragbits – A three bit long field that is used to determine if the packet is indeed a fragment, and if more fragments of this fragment ID should be expected.
- Fragment offset – This is how the destination keeps track of which piece of the original packet this fragment is. Think of it as how far into the original packet this fragment picks up from.
Having a good grip on how these fields work is important. It’s in the manipulation of these fields that IP fragmentation exploits are performed. It’s also how we’re going to draft a monitoring strategy and tune our NetFlow exporters and Scrutinzer. After all, a sword’s only as good as its last sharpening.
The Beasties: What Terrors Lurk Within the Fragments?
Between operating systems, there are differences in how the reassembly of fragments is performed and how overlapping fragments are handled. If you’re interested in some of the details, Judy Novak’s ”Target-Based Fragmentation Reassembly” breaks down some of these differences using the Paxson/Shankar model.
There are also differences with the implementation of IP fragmentation between IPv4 and IPv6. Mainly the fragmentation fields have been moved out of the IP header and into their own extended header.
Despite the intricacies, the basic attack methodology is the same. The fragmentation offset of subsequent fragments is used to backtrack and overwrite critical information in the first fragment. Often this is port numbers or TCP flags, and often it is setting these to values that would have been blocked by a firewall or IDS had they been in the original packet.
To The Armory: What Will We Need?
To monitor for IP fragmentation exploits with NetFlow we’re going to need to turn to the power of Flexible Netflow. We’ll also need some extra fields beyond the typical Flexible NetFlow config. If fragmentation ID, Fragment offset, and packet length are the values we’re interested in, let’s match and collect these fields in our flow record. Once these indicators are part of our netflow export, we can use a netflow analyzer to look for distinctive patterns of IP fragmentation exploits.
To enable these as key fields, add this to your flow record:
Match ipv4 id
Match ipv4 fragmentation flags
Match ipv4 fragmentation offset
Enabling these as key fields will create a flow for each fragmented packet. We’ll use these flows in our NetFlow analyzer to watch for suspicious patterns.
Slaying the Beast: What’s Our Battle Plan?
Now that we’ve forged our flows to give us the fragmentation fields, think of what we can do within Scrutinizer! All the same features that make Scrutinizer great for network monitoring can be applied in a security context. Reports, Filters, thresholds, and alarms are now all at our disposal. What are we looking for? Since we’ve added match statements for FragmentID and FragmentOffset, a unique flow will be created for each fragment of a packet. If the packet counts of these flows are greater than 1 it could indicate some fragmentation foolery. The same goes for the offset number itself. As I described earlier, a very low offset could indicate an attacker crafting malicious fragments in an attempt to overwrite header information.
Keep an eye on the packet length of these fragments as well. Very small fragments that are not the final fragment could very well be playing a part in a denial of service attack.
There are a myriad ways to exploit IP fragmentation, the important part is to be just as clever as the bad guys to stay one step ahead.
A Call to Arms!
I hope this not only gave you some insight into detecting IP fragmentation exploits, but also gave you some ideas on how you can think outside of the box with NetFlow. It seems too often we follow convention without thinking of how we can repurpose the systems we already have at our disposal. Swords can be beaten into plow shares and flexible NetFlow can be fine-tuned to give us greater detail into our networks. So keep tinkering with those flows, NetFlow knights! There is an ever-growing list of foes out there. Netflow, and your own creativity, is one of your best weapons against them.
If you have questions or your own network security strategies with NetFlow, by all means contact us.
