3 - 1

Fragmentation - SANS 2000 - 2003

1
Frag men ta tion
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.
3 - 2
Fragmentation - SANS 2000 - 2003
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; well examine both of these in todays
webcast.
3 - 3
Fragmentation - SANS 2000 - 2003
3
Normal Fragmentation
Fragmentation can be a very normal and naturally occurring effect of traffic travelling among
variously sized networks. We will consider the theory and composition of normal fragmentation first
to acquaint you with how it should operate.
3 - 4
Fragmentation - SANS 2000 - 2003
4
Fragmentation theory
Occurs when maximum transmission unit (MTU) smaller
than datagram
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 dont deal well with fragmentation.
3 - 5
Fragmentation - SANS 2000 - 2003
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.
3 - 6
Fragmentation - SANS 2000 - 2003
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
Newer TCP/IP stacks randomizing this value
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, although we the trend now is to have TCP/IP stacks randomize this value.
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.
3 - 7
Fragmentation - SANS 2000 - 2003
7
Ethernet datagram packaging
Ethernet (MTU = 1500)
20 byte IP
header
1480 bytes of embedded data
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.
3 - 8
Fragmentation - SANS 2000 - 2003
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. Lets examine what each of the individual three fragments looks like.
Normally, you shouldnt encounter a 4,000+ byte echo request. And, if you do, examine it until you
become cross-eyed because something isnt 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.
3 - 9
Fragmentation - SANS 2000 - 2003
9
The Breakdown
ICMP data
20 8 4000 bytes of ICMP data
4028 total bytes in pre-fragmented IP datagram
1472 ICMP data 1480 ICMP data 1048
1500 1500 1068
1472 + 1480 + 1048 = 4000 bytes of ICMP data
= 20 byte IP header
Looking at the slide, The Breakdown, lets 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.
3 - 10
Fragmentation - SANS 2000 - 2003
10
The first fragment
IP header
ICMP header
ICMP echo
request
20 8 1472
Offset = 0
Length = 1480
More Fragments = 1
ICMP data
IP Header
1500 total bytes
ICMP data IP Header
20 8 1472
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.
3 - 11
Fragmentation - SANS 2000 - 2003
11
Composition of the first fragment
First fragment 1500 total bytes in IP datagram
20 8 1472 ICMP data bytes
Protocol = ICMP
Fragment ID = 21223
More Fragments Flag = 1
Fragment Offset = 0
Data Length = 1480
IP Header
ICMP pseudo-header
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 pseudo-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. The 1480 bytes of data represents the 8 byte
ICMP pseudo-header followed by the first 1472 bytes of the ICMP data; it does not include the IP
header.
3 - 12
Fragmentation - SANS 2000 - 2003
12
The second fragment
1480
Offset = 1480
Length = 1480
More Fragments = 1
ICMP data
IP Header ICMP data
20 1480
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.
3 - 13
Fragmentation - SANS 2000 - 2003
13
Composition of the second
fragment
Second fragment 1500 total bytes in IP datagram
20 1480 ICMP data bytes
Protocol = ICMP
Fragment ID = 21223
More Fragments Flag = 1
Fragment Offset = 1480
Data Length = 1480
IP Header
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 doesnt 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.
3 - 14
Fragmentation - SANS 2000 - 2003
14
The third fragment
1048
Offset = 2960
Length = 1048
More Fragments = 0
IP Header
20 1048
1068 total bytes
ICMP data
ICMP data
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.
3 - 15
Fragmentation - SANS 2000 - 2003
15
Composition of the final
fragment
Third fragment 1068 total bytes in IP Datagram
20 1048 ICMP data bytes
Protocol = ICMP
Fragment ID = 21223
More Fragments Flag = 0
Fragment Offset = 2960
Data Length = 1048
IP Header
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.
3 - 16
Fragmentation - SANS 2000 - 2003
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
ID
Number 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 weve 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, lets 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.
3 - 17
Fragmentation - SANS 2000 - 2003
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 dont maintain this information. They look at each
fragment as an individual entity and dont connect it with previous or subsequent packets.
If a particular packet doesnt 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.
3 - 18
Fragmentation - SANS 2000 - 2003
18
The Dont 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 Dont 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 dont
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.
3 - 19
Fragmentation - SANS 2000 - 2003
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 536) (DF)
MTU = 536
Send traffic to host.ru, DF set
Datagram too big, cant fragment
mail.mysite.com
router.ru host.ru
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
dont fragment flag was set. The stimulus for this reply was that mail.mysite.com attempted to send
a datagram larger than 536 bytes to host.ru with the DF flag set. router.ru finds that the datagram
must traverse a smaller network with an MTU of 536 bytes and fragmentation is necessary.
When router.ru examines the record, it finds that the dont 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 536 so fragmentation doesnt occur or
remove the DF flag so fragmentation can occur and then resend the datagram.
3 - 20
Fragmentation - SANS 2000 - 2003
20
Malicious Fragmentation
We now examine the topic of fragmentation used for purposes other than the intended ones.
3 - 21
Fragmentation - SANS 2000 - 2003
21
Ping O Death fragmentation attack
Uses fragmented ICMP packets for denial of service
Very large datagram crafted using fragments
When reassembled by victim host, maximum IP
datagram size of 65,535 bytes exceeded
Causes some vulnerable hosts to crash or freeze
The Ping O Death fragmentation attack slide discusses a denial of service attack which uses a
ping system utility to create an IP packet that exceeds the maximum 65,535 bytes of data allowed by
the IP specification. The oversize packet is then sent to a victim host. Systems may crash, hang, or
reboot when they receive such a maliciously crafted packet. This attack is not new, and all OS
vendors should have fixes in place to handle the oversize packets.
3 - 22
Fragmentation - SANS 2000 - 2003
22
Ping O Death
Hostile Host
Victim Host
Frag 1 Frag 2 Frag3 Frag x
Total byte length of fragments > 65,535
Reassembled length > 65,535
65535
In the pictorial representation of Ping O Death slide, we see a hostile host crafting an oversized
IP datagram from smaller fragments. When the victim host receives these fragments and attempts to
reassemble them, it may experience a denial of service failure when its reassembled datagram length
exceeds 65,535 bytes.
3 - 23
Fragmentation - SANS 2000 - 2003
23
tcpdump output of Ping O Death
attack
evilping.com > victimhost.com: icmp: echo request (frag 56980:1480@0+)
evilping.com > victimhost.com: (frag 56980:1480@1480+)
evilping.com > victimhost.com: (frag 56980:1480@2960+)
evilping.com > victimhost.com: (frag 56980:1480@4440+)
evilping.com > victimhost.com: (frag 56980:1480@5920+)

evilping.com > victimhost.com: (frag 56980:1480@59200+)

evilping.com > victimhost.com: (frag 56980:1480@60680+)
evilping.com > victimhost.com: (frag 56980:1480@62160+)
evilping.com > victimhost.com: (frag 56980:1480@63640+)
evilping.com > victimhost.com: (frag 56980:1480@65120)
tcpdump output of Ping O Death attack displays how evilping.com fashions the fragments to
send to victimhost.com. Judging from the fragment lengths of 1480 bytes, we conclude that the
MTU is 1500 - 1480 bytes of data and 20 of IP header. This is the MTU of Ethernet.
We see the first fragment is an ICMP echo request because it carries the ICMP pseudo-header
identifying the ICMP message type. The first 6 fragments are displayed and then for space purposes,
we omit the middle fragments. We continue with the final 5 fragments. The fragment of interest is
the final fragment. It begins at an offset of 65120 bytes for a length of 1480 bytes. This brings the
the byte length to 66600. The maximum allowable IP datagram size of 65535 has been exceeded
and victimhost.com may suffer some ill consequences upon reassembly.
3 - 24
Fragmentation - SANS 2000 - 2003
24
tcpdump output of Teardrop attack
Examine the tcpdump output of the fragmented traffic
below
What is wrong with it?
evilfrag.com.139 > target.net.139: udp 28 (frag 242:36@0+)
evilfrag.com > target.net: (frag 242:4@24)
Examining tcpdump output of Teardrop attack, we see a new type of denial of service using
udp. The Teardrop attack exploits weaknesses in the reassembly process of fragments. The
Teardrop program creates fragments with overlapping offset fields. When these fragments are
reassembled at the destination host, some systems will crash, hang, or reboot. Again, this attack has
been around for several years so patches should be available for vulnerable systems.
The first fragment is not per specification because the length of the fragment is not evenly divisible
by 8. All fragments but the final one should have a payload divisible by 8 or they are considered
non-standard. The reason that fragment sizes need to be a multiple of 8 is because the value found in
the fragment offset field in the IP header is always multiplied by 8. This field is used to determine
the offset of the current fragment into the fragment train. Therefore, if it must be a multiple of 8, all
previous fragments must have payloads evenly divisible by 8.
3 - 25
Fragmentation - SANS 2000 - 2003
25
Teardrop attack
evilfrag.com.139 > target.net.139: udp 28 (frag 242:36@0+)
evilfrag.com > target.net: (frag 242:4@24)
Byte 0 Byte 24 Byte 27 Byte 35
Fragment 2
Fragment 1
If you look at slide Teardrop attack, youll see tcpdump output from Teardrop fragmentation.
The first fragment delivered is a UDP datagram which has a fragment ID of 242, a length of 36 data
bytes and an offset of zero. We represent this in the diagram in the patterned rectangles. It spans
bytes 0 through 35 inclusive.
Now, the second fragment comes along. It is associated with the first fragment because of fragment
ID of 242, it has a length of 4 and it begins at an offset of 24 bytes into the data portion. It is
depicted in the solid color in the middle. As you can see, it actually overlaps bytes 24 through 27 of
the first fragment. Some unpatched versions of operating systems cannot handle this anomaly and
will reboot or hang when an attempt is made to reassemble received Teardrop fragmentation.
3 - 26
Fragmentation - SANS 2000 - 2003
26
tcpdump Output of Unknown Activity
Examine the tcpdump output of the fragmented traffic
below
What is wrong with it?
evilfrag.com.139 > target.net.139: udp 10 (frag 242:18@0+)
evilfrag.com > target.net: (frag 242:116@48)
We investigate another instance of malicious activity in tcpdump output of unnamed attack.
While there is no known name for this type of activity, the guess is that this is an attempt at denial of
service by using udp much as the Teardrop attack used. While the teardrop attack used overlapping
fragments, this appears to be exploiting some kind of vulnerability with a gap in fragments.
There are a couple of possibilities for the explanation of the missing fragment. First, it is possible
that the fragment just got lost on its way to target.net and never reached it. The second, more likely
possibility is that it was some kind of intentional omission. The reason that the second explanation is
favored is because this fragmentation doesnt look like normal fragmentation.
Again, the first fragment payload is not a multiple of 8. Also, you typically dont see fragments that
are smaller than 512 bytes because MTUs are usually not that small.
3 - 27
Fragmentation - SANS 2000 - 2003
27
Unnamed Activity
evilfrag.com.139 > target.net.139: udp 10 (frag 242:18@0+)
evilfrag.com > target.net: (frag 242:116@48)
Fragment 1 Fragment 2
Byte 0 Byte 17 Byte 48 Byte 163
Missing Data
As we study the Unnamed Attack slide, we see what is going on with offsets. The first fragment
with fragment ID 242 begins at byte zero and has a length of 18 bytes. So, that means it spans bytes
0 through 17 inclusive.
The second fragment with fragment ID 242 begins at offset 48 and has a length of 116 bytes. This
fragment spans bytes 48 through 163 inclusive. As we observe, bytes 18 through 47 appear to be
missing. The suspicion is that this is crafted fragmentation since we are not likely to see MTUs
small enough to cause this naturally. Also, normal fragmentation definitely would not be divided as
we see in this slide.
In the ICMP section of this course, well see where a host that receives an incomplete set of
fragments will discard the fragments after a given amount of time. The time after which the
fragments are expired varies based on the operating system, but can be after half a minute or a
minute, for example. So, the above traffic should not be considered to be an attack. But it is possible
that someone may be attempting to see if target.net is alive by receiving an ICMP error message in
response.
3 - 28
Fragmentation - SANS 2000 - 2003
28
Fragmentation review
Necessary when datagram crosses a network smaller than the
datagram length
Datagram divided into fragments which will be reassembled by
the receiving host by using:
The fragment ID
The fragment offset
The fragment data length
The more fragments flag
DF flag can be used for MTU discovery to avoid fragmentation
Fragmentation can be used for malicious purposes
As slide Fragmentation review discusses, weve seen where fragmentation is a normal
occurrence for a datagram travelling from a larger to a smaller network. If a datagram requires
fragmentation along the path to the destination, a router on the network with the smaller MTU will
fragment the datagram if the dont fragment flag is not set.
Each fragment will be encapsulated in an IP datagram. Every IP header will contain information
such as the fragment ID, the offset, the length of the current fragment and whether other fragments
follow. The destination host will be responsible for reassembling the fragments and will use the
information included in the IP header to do so. The DF flag can be used as a mechanism to discover
the MTU to the destination host and provide more appropriate datagram packaging thus avoiding
fragmentation all together.
We examined several examples of malicious fragmentation. Most of our examples showed attempted
denial of service attacks against a victim host, the last exhibited stealth behavior to sneak past a
router.
3 - 29
Fragmentation - SANS 2000 - 2003
29
Quiz
1) Fragmented packets are reassembled by:
a) The destination host
b) The source host
c) Every router that examines the packet
d) There is no need to reassemble fragments
2) The first fragment in a normal fragment train will have the following:
a) The dont fragment flag set and a zero offset
b) The more fragments flag set and a zero offset
c) The dont fragment flag set and a non-zero offset
d) The more fragments flag set and a non-zero offset
This page intentionally left blank.
3 - 30
Fragmentation - SANS 2000 - 2003
30
Quiz (2)
3) The Ping O Death attack attempts to exceed an IP datagram size of
65535 bytes which represents:
a) The maximum length of an IP datagram header
b) The maximum length of a fragment offset
c) The maximum length of the TCP header
d) The maximum length of an IP datagram
4) Every normal fragment will have:
a) An IP header to assist in routing the datagram to its destination
b) 1480 bytes of data
c) 1500 bytes of data
d) A non-zero offset
This page intentionally left blank.
3 - 31
Fragmentation - SANS 2000 - 2003
31
Quiz (3)
5) Normal fragmentation occurs when:
a) The IP header in a datagram exceeds 20 bytes
b) A tcp session is terminated
c) The size of the datagram is greater than the MTU
d) The size of the datagram is less than the MTU
6) One common piece of shared information among all normal fragments
is:
a) The port numbers
b) The SYN number
c) The ACK number
d) The fragment ID
This page intentionally left blank.
3 - 32
Fragmentation - SANS 2000 - 2003
32
Quiz (4)
7) The Ping O Death exploit uses fragmentation to attempt a denial of
service by:
a) Sending fragments out of order
b) Sending fragments that when reassembled exceed the maximum IP
datagram size
c) Sending fragments that exceed the MTU size
d) Sending very small fragments
8) The fragment ID come from which of the following fields:
a) The time to live
b) The final octet of the source IP
c) The final octet of the destination IP
d) The IP identification
This page intentionally left blank.
3 - 33
Fragmentation - SANS 2000 - 2003
33
Quiz (5)
9) The dont fragment flag may be used by hosts as a discovery
mechanism to:
a) Fragment datagrams on byte boundaries
b) Let the destination host know fragmentation is occurring
c) Force the router to fragment the datagram
d) Find the MTU from source to destination in an attempt to avoid
fragmentation by packaging datagrams in a size smaller than the MTU
10) The final fragment in a normal fragment train should always have:
a) The dont fragment flag set
b) A zero offset
c) The FIN flag set
d) The more fragments flag set to zero to signify no more fragments
follow
This page intentionally left blank.
3 - 34
Fragmentation - SANS 2000 - 2003
34
Quiz (6)
Questions 11-15 pertain to this tcpdump output:
myhost.com > yourhost.com: icmp echo reply (frag 11259:1000@0+)
11) The + at the end of the tcpdump output signifies:
a) Dont fragment this datagram
b) More fragments follow
c) This is the final fragment
d) This is the first fragment
12) The fragment ID for this record is:
a) 0
b) 1500
c) 1000
d) 11259
This page intentionally left blank.
3 - 35
Fragmentation - SANS 2000 - 2003
35
Quiz (7)
myhost.com > yourhost.com: icmp echo reply (frag 11259:1000@0+)
13) The length of this fragment is:
a) 0
b) 1480
c) 11259
d) 1000
14) We know that this is the first fragment because:
a) The offset is 0
b) More fragments follow
c) It has a fragment ID
d) The length is less than 1500
This page intentionally left blank.
3 - 36
Fragmentation - SANS 2000 - 2003
36
Quiz (8)
myhost.com > yourhost.com: icmp echo reply (frag 11259:1000@0+)
15) Another reason that we know that this is the first fragment is because
it has an ICMP protocol header embedded in it. We can tell this by:
a) We see a source host
b) We see a destination host
c) We see this is an ICMP echo reply meaning that there is an ICMP
pseudo-header embedded in the datagram
d) We see a non-zero fragment ID
This page intentionally left blank.
3 - 37
Fragmentation - SANS 2000 - 2003
37
Quiz (9)
16) (T/F) Fragmentation can be a problem for routers that do not keep
track of state because they are unaware of previous and subsequent
fragments.
17) (T/F) The Teardrop attack attempts a denial of service by sending
overlapping fragments.
18) (T/F) The Dont Fragment flag is used to say more fragments follow.
19) (T/F) One of the possible purposes for sending malicious
fragmentation is for a denial of service.
This page intentionally left blank.
3 - 38
Fragmentation - SANS 2000 - 2003
38
Quiz (10)
20) (T/F) Normal fragments can bypass a filtering router because they
may contain only data and may not have protocol header fields upon
which filtering choices are based.
21) (T/F) Normal fragmentation can occur with the tcp protocol only, udp
and ICMP arent big enough to require fragmentation.
This page intentionally left blank.
3 - 39
Fragmentation - SANS 2000 - 2003
39
Quiz (11)
Questions 22 - 26 pertain to this tcpdump output:
evilfrag.com.139 > victim.net.139: udp 56 (frag 123:24@0+)
evilfrag.com > victim.net: (frag 123:16@64)
22) (T/F) The two related fragments overlap.
23) (T/F) The first fragment begins at byte 24 and has a length of 0.
24) (T/F) The second fragment begins at byte 64 and has a length of 16.
25) (T/F) The IP identification number for both these fragments is 123.
26) (T/F) No final fragment was sent.
This page intentionally left blank.
3 - 40
Fragmentation - SANS 2000 - 2003
40
Quiz (12)
Questions 27 - 30 pertain to this tcpdump output:
evilfrag.com.139 > victim.net.139: udp 56 (frag 456:40@0+)
evilfrag.com > victim.net: (frag 456:8@24)
27) (T/F) These two fragments overlap.
28) (T/F) The first fragment begins at byte 0 and has a length of 40.
29) (T/F) The second fragment begins at byte 8 and has a length of 24.
30) (T/F) Bytes 8 - 23 overlap for these two fragments.
Answers:
1) a 16) T
2) b 17) T
3) d 18) F
4) a 19) T
5) c 20) T
6) d 21) F
7) b 22) F
8) d 23) F
9) d 24) T
10) d 25) T
11) b 26) F
12) d 27) T
13) d 28) T
14) a 29) F
15) c 30) F
3 - 41
Fragmentation - SANS 2000 - 2003
41
Course Revision History
v1.0 - J. Novak Sep 20 00
v1.1 12-15-2000 (JHN) - (per recommendation of S. Northcutt) added slide The Breakdown
v1.2 edited by J. Kolde, minor formatting changes 16 Jan 2001
v1.3 edited by J. Novak, missing fragment clarification 23 Feb 2001
v1.4 edited by J. Novak, new router graphic 22 May 2001
v1.5 edited by J. Novak, minor edit p.27 6 July 2001
v1.6 - edited by J. Novak, intro changed, qualification on fragment offsets 5 July 2002.
v.1.7 edited by J. Novak, slide 6 added sentence to slide and notes (end of first paragraph) about
randomizing IPID now. Slide 9 slide color changes for IP header per Stephens request. Slide 11
last paragraph changed one sentence deleted and new last one added. Slide 19 changed MTU of
308 to 536 in all occurrences (slides and notes). Slide 23 added periods in middle of slide to show
break/continuation of records.