Filtering on IP Fragment Fields


What about IP fragments? I hate ‘em. For one reason, people use fragmented IP packets to try to get through firewalls. For another reason, if you don’t get all fragments within the TTL value of the first fragment received, you might as well dump ‘em all -- they all need to be resent. Dumb, eh?

So let’s build a filter that looks to see if there are fragments on the network. This will be a binary filter.

There are three places that you need to look in the IP header to determine whether fragments are in use:

  • the May Fragment bit setting (0=may fragment/ 1=may not fragment)

  • the More To Come/Last Fragment bit setting (0=last fragment/1=more to come)

  • the Offset field value (0=first fragment of a set)

The following chart illustrates the unique values found in fragment packets as compared to packets that are not or can not be fragmented.

Packet Type

May Frag

More/Last

Offset

First fragment

0

1

0

Middle fragment

0

1

not 0

Last fragment

0

0

not 0

Unfrag. packet A

0

0

0

Unfrag. packet B

1

0

0

Unfragmented packet A is a regular packet that just simply doesn’t need to be fragmented. Unfragmented packet B is a packet that can not be fragmented -- the application has set the May Fragment bit to 1 indicating that the packet cannot be fragmented.

There are specific patterns that are unique to fragmented traffic. We can use these patterns to identify all fragments that cross a network.

We’ll be able to differentiate the fragment packets from unfragmented data by the way we put the patterns together.

Packet Type

 

First fragment

May Fragment; More to Come; Offset 0

Middle fragment

May Fragment; More to Come; Offset NOT 0

Last fragment

May Fragment; No More; Offset NOT 0

How do these patterns differ from the ones seen in unfragmented packets? Let’s compare:

Packet Type

 

Unfrag. Packet A

May Fragment; No More; Offset 0

Unfrag. Packet B

May NOT fragment

Again, remember that Unfrag. Packet B has the May Fragment bit set to 1 which indicates that the packet cannot be fragmented.

You need to set up binary filters to catch these bit patterns. Many analyzers change the offset value when you choose “binary” as the filter type. They will provide the offset value based on bits, not bytes. For example, the flags field is at offset 0x06 when the byte hex format is selected. The flags field offset is at 0x30 when the binary format is selected. That 30 in hex is equivalent to 48 in decimal which is equivalent to 6 bytes into the packet (6 bytes times 8 bits = 48 bits).[9]

Another consideration is that these fields are adjacent, as shown in Figure 44.

click to expand
Figure 44: The offset value used for the Flags and Fragment Offset fields is 30.

When we build the patterns for these filters, we need to keep in mind that the first bit (Reserved) will be set to 0. Fortunately, the Flags and Fragment Offset fields are consecutive. This way, we can build a single pattern that matches multiple patterns, if we want.

If we build a binary pattern that looks for the value 000000000000000 (15 bits of zeros) at offset 0x31 (the start of the May Fragment field), we’d catch packets that may be fragmented, but do not have additional fragments defined (the fourth fragment filter).

Now let me give you my idea of how I’d build this filter set. I’ll only build filters that match the packets I want -- I will not actually build filters on packets that I am not interested in.

Packet Type

 

First fragment

May Fragment; More to Come; Offset field=0

Offset 0x31: 01 (2 bits)

Offset 0x33: 0000000000000

Middle fragment

May Fragment; More to Come; Offset field NOT 0

Offset 0x31: 01 (2 bits)

Offset 0x33: NOT 0000000000000

Last fragment

May Fragment; No More; Offset field NOT 0

Offset 0x31: 00 (2 bits)

Offset 0x33: NOT 0000000000000

As you can see, I’m most interested in the values at offset 0x31 and 0x33. Figures 45 through 47 depict the patterns used to catch the first, middle and last fragment of the set.

click to expand
Figure 45: The first pattern will be used to catch the first and middle fragments.

click to expand
Figure 46: The second pattern will be used to specify that the fragment is the first one. We’ll also use this pattern with the NOT operand to find middle or last fragments.

By combining the patterns shown in Figures 45 and 46 using the AND operand, you can catch all the first fragments of a set.

By combining the patterns using the NOT operand (More Fragment; More to Come and NOT Offset = 0), you can catch the middle fragments of a set.

Now let’s add one more pattern to catch the last fragment of a set. Figure 47 shows a new pattern that looks for an indication that there are no more further fragments.

click to expand
Figure 47: The “More to Come” bit is set to 0 indicating this would be the last fragment of the set.

In order to differentiate between the last fragment of a set and a single packet set (a single packet that did not need fragmentation), we need to build a filter that looks for the pattern seen in Figure 47 (no more fragments) and NOT the pattern seen in Figure 46 (offset = 0).

All in all, we have three combinations that we are looking for. When we put these together on the Sniffer, the summary should look something like Figure 48.

click to expand
Figure 48: This filter looks for packets that match one of three pattern sets. Cool!

See! You can build filters that look for all types of packets on the network -- you really just need to know that offset and value.

[9]Math sucks, eh? Wouldn’t it be nice if everyone counted in decimal on this stuff?




Packet Filtering. Catching the Cool Packets.
Packet Filtering: Catching the Cool Packets
ISBN: 1893939383
EAN: 2147483647
Year: 2000
Pages: 65

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net