IP Behavior II Frag mentation

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 5 More Fragmentation Theory • Reassembled by the receiving host • All fragments: – Must share a common fragment identification number –

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 1

IP Behavior II

Frag men ta tion

Hello, my name is Judy Novak, I work for Jacob and Sundstrom in the Computer Security and

Incident Response Team at the Army Research Lab as a security analyst Stephen Northcutt invited me

to develop this talk because fragmentation is so important to understand if you are responsible for computer and network security I’d like to take a moment to give credit and gratitude to my technical editor, Bill Ralph of the Naval Surface Warfare Center Shadow team

Attackers use fragmentation to mask their probes and exploits Some intrusion detection systems do not support packet reassembly and therefore do not detect activity where the signature is split over multiple datagrams There are availability, or denial of service attacks such as ssping, that use highly fragmented traffic to exhaust system resources Finally, some sophisticated persons of mal-intent use fragmentation to try to circumvent filtering routers These are all reasons that you may want to learn about fragmentation, the topic of the webcast

By understanding how this facet of IP works, you will be equipped to detect and analyze fragmented traffic and discover if it is normal fragmentation or fragmentation used for other purposes

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 2

Objectives

• Discuss fragmentation concepts

• Examine “normal” fragmentation

• Examine “abnormal” fragmentation

We will look at fragmentation to see what is happening at the datagram level We need to be aware

of “normal” fragmentation before we can identify “abnormal”; we’ll examine both of these in today’s webcast

• Reassembled by destination host

• Can be used to bypass routers or intrusion detection

systems

The next slide is titled “Fragmentation theory” Fragmentation occurs when an IP datagram

travelling on a network has to traverse a network with a maximum transmission unit (MTU) that is smaller than the size of the datagram For instance, for Ethernet, the maximum transmission unit or maximum size for an IP datagram is 1500 bytes If a datagram needs to traverse an Ethernet network and is larger than 1500 bytes, it will have to be fragmented by a router that is directing it to the Ethernet network Fragmentation can also occur when a host needs to put a datagram on the network that exceeds the MTU; in some instances this will be fragmented

Fragments will continue on to their destination where they will be reassembled by the destination host It is even possible for fragments to become further fragmented if they cross an MTU smaller than the fragment size While fragmentation is a perfectly normal and naturally occurring event, it is possible to craft fragments for the purposes of avoiding detection by routers and intrusion detection systems that don’t deal well with fragmentation

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 5

More Fragmentation Theory

• Reassembled by the receiving host

• All fragments:

– Must share a common fragment identification number

– Must tell what offset in original unfragmented datagram

– Must tell length of data payload

– Must tell whether another fragment follows this one

• Each fragment encapsulated in IP datagram

Continuing with concepts on slide “More fragmentation theory”, we examine what kind of

information the fragments must carry for the destination host to reassemble them back to the original unfragmented state This information is:

• A common fragment identification number This is cloned from a field in the IP header known as the IP identification number, also called the fragment ID

• Each fragment must say what its place or offset is in the original unfragmented packet

• Each fragment must tell the length of the data carried in the fragment

• Finally, the fragment must know whether more fragments follow this one

This information will be contained in the IP header The IP header will be placed in an IP datagram followed by an encapsulated fragment All TCP/IP traffic must be wrapped within IP because IP is the protocol responsible for getting the packet delivered

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 6

The Fragment ID

• Each fragment has identifying number - fragment ID

• Taken from IP identification field

• Value set by a host sending datagram

• Value usually increases by 1 for each new datagram sent

• tcpdump output of unfragmented datagram IP

identification value:

ping.com > 192.168.244.2: icmp: echo request (ttl 240, id 202)

Slide “The fragment ID” examines the origin of the field that identifies fragments The IP

identification value is a 16 bit field found in the IP header of all datagrams This uniquely identifies each datagram sent by the host Typically, this value is incremented by 1 for each datagram sent by that host

When the datagram becomes fragmented, all fragments created from this datagram will contain this same IP identification number, or the fragment ID The tcpdump output in this slide shows an IP identification number of 202 for a datagram that is not fragmented If this datagram were to be fragmented on the way to its destination, all fragments created from this datagram would share a fragment ID of 202

This tcpdump output was generated using the -vv option This is a verbose option which says to list the time to live value and the IP identification values along with normal output

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 7

Ethernet Datagram Packaging

Ethernet (MTU = 1500)

20 byte IP

Turning to the slide “Ethernet datagram packaging”, we see that a datagram travelling on Ethernet

has a maximum transmission unit of 1500 bytes Each datagram must have an IP header which is typically 20 bytes, but can be more if IP options are included

If you recall, the IP header contains information such as the source and destination IP numbers It is considered the “network” portion of the IP datagram since routers use the information found in the

IP header to direct the datagram towards its destination Encapsulated after the IP header is some kind of data This data can be an IP protocol such as tcp, udp or ICMP For instance, if this data were tcp, it would include a tcp header and tcp data

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 8

Fragmentation using ICMP

echo request

ICMP data

IP header

ICMP header

20 8 4000 bytes of ICMP data

4028 total bytes in IP datagram

Ethernet MTU = 1500

1500 bytes 1500 bytes 1068 bytes

(ICMP echo request)

Original 4028 byte fragment broken into 3 fragments of 1500 bytes or less

On slide “Fragmentation using an ICMP echo request”, we have a datagram of 4028 bytes This

is an ICMP echo request bound for an Ethernet network that has an MTU of 1500 So, the 4028 byte datagram will have to be divided into fragments of 1500 bytes or less Each of these 1500 byte fragmented packets will have a 20 byte IP header so that leaves 1480 bytes maximum for data for each fragment Let’s examine what each of the individual three fragments looks like

Normally, you shouldn’t encounter a 4,000+ byte echo request And, if you do, examine it until you become cross-eyed because something isn’t kosher The reason that this was used for the example and for instructive purposes is that in the Windows ping, there is a -l switch that allows you to say how big you want the echo request to be This allowed the generation and capture by tcpdump of the packets you see in the upcoming several slides to validate all the information delivered to you is correct

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 9

The Breakdown

ICMP data

20 8 4000 bytes of ICMP data

4028 total bytes in pre-fragmented IP datagram

1472 + 1480 + 1048 = 4000 bytes of ICMP data

= 20 byte IP header

Looking at the slide, “The Breakdown”, let’s see how each fragment is actually formed Before the

IP datagram is sent on the link that has an MTU of 1500 bytes, we see that is has a total of 4028 bytes total

What we have seen is that this IP datagram will be divided into three separate fragments each with a cloned IP header The original header is paired with the first fragment and two new headers of 20 bytes each have to be created for the second and third fragments So, we really need a total of 4068 bytes to send all of this traffic

The first fragment gets the original IP header, along with the 8 bytes of the ICMP header for a running total of 28 bytes With a maximum datagram size of 1500 bytes, 1472 bytes remain for ICMP data The second fragment gets a cloned IP header of 20 bytes, and has the remaining 1480 bytes for ICMP data The final fragment again gets a 20 byte IP header and carries the final 1048 bytes of ICMP data As a cross check, we see that we have 1500 + 1500 + 1068 bytes of data sent for a total of 4068 bytes

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 10

The first fragment

IP header

ICMP header ICMP echo request

20 8 1472

Offset = 0 Length = 1480 More Fragments = 1

Looking at the slide “The first fragment” we turn our concentration to the initial fragment in the

fragment train The “original” IP header will be cloned to contain the identical fragment

identification numbers for the first and remaining fragments Remember, all fragments must be carried in an IP datagram An IP datagram requires an IP header to direct it to its destination

The first fragment is the only one that will carry with it the ICMP message pseudo-header

As we see, the first fragment has a 0 offset, a length of 1480 bytes, 1472 bytes of data and 8 of ICMP header, and more fragments follow so that more fragments flag is set

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 11

Composition of the first fragment

First fragment 1500 total bytes in IP datagram

Protocol = ICMP

Fragment ID = 21223

More Fragments Flag = 1

Fragment Offset = 0

Data Length = 1480

Type = ICMP echo request

Slide “Composition of the first fragment” explains the configuration of the first fragment in the

fragment train The first 20 bytes of the 1500 bytes are the IP header The next 8 bytes are occupied

by the ICMP header Recall that this was an ICMP echo request that has an 8 byte pseudo-header in its original packet The remaining 1472 bytes are for ICMP data

In addition to the normal fields carried in the IP header such as source and destination IP and protocol, in this instance, ICMP, there are fields that are specifically for fragmentation The

fragment ID with a value of 21223 will be the common link for all the fragments in the fragment train There is a field known as the more fragments flag that indicates that another fragment follows the current one In this first fragment, the flag will be set to 1 to indicate that more fragments do follow Also, the offset of the data contained in this fragment relative to the data of whole datagram must be stored For the first record, the offset will be 0 Finally, the length of the data carried in this fragment will be stored as the fragment length – in this fragment, the length will be 1480 This is the

8 byte ICMP pseudo-header followed by the first 1472 bytes of the ICMP data

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 12

The second fragment

1480

Offset = 1480 Length = 1480 More Fragments = 1

ICMP data

1500 total bytes

Looking at the slide “The second fragment” we focus on the next fragment in the fragment train

An IP header will be cloned from the “original” header with an identical fragment identification number, and most of the other data in the IP header such as the source and destination numbers will

be replicated for the new header Embedded after this new IP header will be 1480 ICMP data bytes

As we see, the second fragment has an offset of 1480, a length of 1480 bytes, and one more fragment follows so the more fragments flag is set

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 13

Composition of the second

fragment

Second fragment 1500 total bytes in IP datagram

Continuing with fragmentation on slide “Composition of the second fragment”, we examine the

IP datagram carrying the second fragment As with all fragments, it requires a 20 byte IP header Again, the protocol in the header will indicate ICMP The fragment identification number will remain 21223 And, the more fragments flag will be turned on because another fragment follows The offset is 1480 bytes into the data portion of the original ICMP message data The previous fragment occupied the first 1480 bytes This fragment will be 1480 bytes long as well and it is composed entirely of ICMP data bytes

It is worth noting that the ICMP pseudo-header in the first fragment doesn’t get cloned along with the ICMP data This means if you were to examine this fragment alone, you could not tell what the ICMP message type is – in this case ICMP echo request This becomes an important issue when we discuss filtering devices in a while

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 14

The third fragment

1048

Offset = 2960 Length = 1048 More Fragments = 0

Looking at the slide “The third fragment” we examine the final fragment in the fragment train

Again, an IP header will be cloned from the “original” header with an identical fragment

identification number, and other fields will be replicated for the new header Embedded in this new

IP datagram will be the final 1048 ICMP data bytes

As we see, the third fragment has an offset of 2960, a length of 1048 bytes, and no more fragments follow so the more fragments flag is 0

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 15

Composition of the final

fragment

Third fragment 1068 total bytes in IP Datagram

Slide “Composition of the final fragment” depicts the last fragment in the fragment train Again,

20 bytes are reserved for the IP header The remaining ICMP data bytes are carried in the data portion of this fragment The fragment ID is 21223, the more fragments flag is not set because this is the last fragment The offset is 2960 (this is the sum of the two 1480 byte previous fragments) There are only 1048 data bytes carried in this fragment comprised entirely of the remaining ICMP message bytes

This fragment, like the second one will have no ICMP pseudo-header and therefore no ICMP message type to reflect that this is an ICMP echo request

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 16

tcpdump output of fragmentation

ping.com > myhost.com: icmp: echo request (frag 21223:1480@0+)

ping.com> myhost.com: (frag 21223:1480@1480+)

ping.com> myhost.com: (frag 21223:1048@2960)

fragment IDNumber of data bytes in current fragment

Offset into the data that this fragment falls

More fragments to follow

Examining the tcpdump output on slide ”tcpdump output of fragmentation”, we see the three

different records representing the three fragments we’ve discussed This means that the host running tcpdump has collected the ICMP echo request after the fragmentation occurred

The first line shows ping.com sending an ICMP echo request to myhost.com The reason that tcpdump can identify this as an ICMP echo request is because the first fragment contains the 8 byte ICMP pseudo-header which identifies this as an ICMP echo request Now, let’s look at fragmentation notation at the right side of the record tcpdump convention for displaying fragmented output is the word “frag” appears followed by the fragment ID, 21223, in our example, followed by a colon The length of data in the current fragment follows, 1480, followed by an @ sign, and then you see the offset into the data, 0, since this is the first fragment The plus sign indicates that the more fragments flag is set

The second record is somewhat different Notice that there is no ICMP echo request label This is because there is no ICMP pseudo-header to tell what kind of ICMP traffic this is The IP header will still have the protocol field set to ICMP, yet that is all you can tell looking at this fragment alone We see the tcpdump output lists the fragment ID of 21223, the current data length is 1480 and the offset is

1480 The plus sign signifies that the more fragments flag is set

The last line is very similar to the second one in format It shows the same fragment ID of 21223, it has a length of 1048 and a displacement of 2960 But, there is no more fragments flag in the final record, as we would expect

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 17

Fragmentation and a packet

filtering device

• Only first fragment carries protocol header

• If packet filter that is not stateful blocks inbound traffic:

– May block first fragment only

– Subsequent fragments may be allowed in

• Fragments reassembled:

– By destination host

– Not by packet filtering device incapable of keeping state

Slide “Fragmentation and a packet filtering device” covers fragmentation and how a packet filtering

device such as a router or firewall may deal with it The problem arises when such a device attempts to block traffic that is fragmented

Because only the first fragment of a fragment train will contain any kind of protocol header such as TCP, UDP, or ICMP, only this fragment will be prevented from entry into the network guarded by a packet filtering device incapable of examining state of a header field What we mean by state is that it appears obvious to us that any fragment sharing the fragment ID of the one that is blocked should also

be blocked However, some packet filtering devices don’t maintain this information They look at each fragment as an individual entity and don’t connect it with previous or subsequent packets

If a particular packet doesn’t match the blocking criteria, in this instance because of the absence of the ICMP pseudo-header, it will be allowed into the network This applies to TCP and UDP as well Fragmented TCP or UDP datagrams may contain their respective header information in the first fragment only Header information such as destination ports are often used as criteria upon which blocking is based So fragmented TCP and UDP are susceptible to the same shortcomings of a stateless packet filtering device

One final point to remember is that IP is not a reliable protocol and it is very possible for the first fragment that contains the protocol header information to be lost When this occurs, the packet

filtering device has an even more difficult job of allowing or denying traffic In fact, if one of the fragments does not arrive at the destination, all must be resent

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 18

The Don’t Fragment flag

• Located in the IP header

• If this flag is set, packet will not be fragmented

• If fragmentation required, datagram will be discarded

• May be set by sending host to determine smallest

MTU on path to destination

• Once determined, datagrams will be sent with a size

smaller than MTU

Moving to slide “The Don’t Fragment flag”, we discuss a new flag In some of the tcpdump output

we looked at in Part I of IP Behavior, you saw the letters DF in parentheses This means the don’t fragment flag is set As the name implies, if this flag is set, fragmentation will not be done on the datagram If this flag is set and the datagram crosses a network where fragmentation is required, the router will discover this, discard the datagram and send an ICMP error message back to the sending host

The ICMP error message will contain the MTU of the network that required fragmentation Some hosts intentionally send an initial datagram across the network with the DF flag set as a way to discover the MTU for a particular source to destination If the ICMP error message is returned with the smaller MTU, the host will then package all datagrams bound for that destination in small enough units to avoid fragmentation

IP Behavior II – SANS GIAC LevelTwo - ©2000, 2001 19

tcpdump output with DF flag set and

fragmentation required

11:30:55.270000 router.ru > mail.mysite.com: icmp:

host.ru unreachable - need to frag (mtu 308) (DF)

MTU = 308 Send traffic to host.ru, DF set

Datagram too big, can’t fragment

On slide “tcpdump output with the DF flag set and fragmentation required”, we see tcpdump

output from an ICMP message in which a router discovered that fragmentation was necessary, yet the don’t fragment flag was set The stimulus for this reply was that mail.mysite.com attempted to send a datagram larger than 308 bytes to host.ru with the DF flag set router.ru finds that the

datagram must traverse a smaller network with an MTU of 308 bytes and fragmentation is necessary

When router.ru examines the record, it finds that the don’t fragment flag is set and an ICMP message

is sent back to mail.mysite.com informing it of the problem Now, mail.mysite.com will either have

to package the datagrams to be smaller than the MTU of 308 so fragmentation doesn’t occur or remove the DF flag so fragmentation can occur and then resend the datagram