In an earlier article, I discussed the fundamentals of datagram fragmentation and explained how it can affect the speed of your network. I also mentioned the vulnerabilities all networks have to malicious fragments. In this article, I will go more in depth on the topic of determining if the fragmented packets on your network are part of a denial of service (DoS) attack.

A DoS example
To analyze traffic, you need to understand how datagram fragmentation works and what characteristics distinguish accidental fragmentation from malicious fragmentation. The security threat begins when pieces of packets arrive at a firewall or filtering router. For example, suppose an IP packet specifies TCP port number 80 (http) and goes through a firewall. One of the packets is marked with an offset that causes the datagram to be reassembled with the later packets overwriting part of the initial, approved packets. Let’s further assume that this is all part of a malicious DoS attack, and the IP port number gets overwritten and changed to 23 (telnet). That’s right, your packet filter has just reassembled a malicious datagram on the other side of your network’s firewall protection. All you can do to protect your network from this sort of attack is to either make certain your filtering device reassembles datagrams before they’re passed to the filter or use multiple firewall layers.

Know your packets
With Ethernet packets limited in length to 1,500 bytes and ATM packets to less than 60 bytes, it’s understandable that IP packets, which can have a maximum size of 500K bytes, become fragmented before they reach their final destination. But the biggest problem for most administrators encountering a system slowdown is determining whether you’re actually suffering a DoS attack using fragmented packets. It’s important to determine this before you undertake a major project to fix any possible fragmentation problem.

If you perform a TCPdump, you will see packet address information that looks something like this:
11:04:21.642741 > (frag 11111:1480@4440+)

What we have here is a fragmented packet carrying an ID of 11111 and a data length of 1,480 bytes. After the @ sign, you can read the offset (4440) of this fragment and see from the plus sign (+) that there are more fragments to follow. By analyzing the same ID number for a series of packets, you can determine whether this is part of a malicious attack or just a collection of lost fragments filling up your buffers until they’re flushed.


TCPdump is a popular UNIX utility developed by Lawrence Berkeley National Laboratory that displays details of various network operations. You can obtain a recent copy of this widely used network analyzer at theTCPdump Web site.

What to look for
You can ignore the time stamp that appears at the beginning of each record. Because the packets may follow different paths, these will not necessarily be in correct sequence. Begin by searching for a fragment that looks like this: frag 11111:1480@0+. The important part is the zero after the @ sign, indicating that it is the first fragment of the datagram. If the zero is missing, it could indicate that the fragment got lost someplace on the way to your firewall. Alternatively, if the capture sensor was inside the firewall, the initial fragment contained something to cause it to be filtered out. In that case, other fragments got through because they didn’t contain the initial fragment of the datagram that “triggered” the firewall to filter out the packet as forbidden or dangerous. If the packet is not reassembled or the firewall does not remember the “state” of the first fragment, it’s not smart enough to reject the rest of the packets.

Your next step is to look for a packet that looks similar to this: frag 11111:1480@4440. Here, the field to look for is the last one containing a plus sign. If you find a packet with 11111 ID and no plus sign, the router will keep waiting for the final fragment to arrive—and it will never time out. Another clue that you are under attack is when a number of fragments of the same datagram appear with an identical offset. This is the basis of a DoS attack.

Have you ever dealt with a DoS attack?

If you’d like to share your opinions or experiences, start a discussion below or send the editor an e-mail.