Examination of Datagram Fields II

4-bit 4-bit IP 8-bit TOS 16-bit total length in bytes version header length 16-bit IP identification number 3-bit flags 13-bit fragment offset 8-bit time to live TTL 8-bit protocol 16

Trang 1

Trang 2

IP Header Fields

This page intentionally left blank

Trang 3

4-bit 4-bit IP 8-bit TOS 16-bit total length (in bytes)

version header

length 16-bit IP identification number 3-bit

flags 13-bit fragment offset

8-bit time to live

(TTL)

8-bit protocol 16-bit header checksum

32-bit source IP address

32-bit destination IP address

options (if any)

data

Trang 4

IP Version

• Found in first nibble of first byte offset of IP

header

• Valid value 4 (IPv4) – future value of 6 (IPv6)

• Receiving host must check this value

• If not valid, silently discarded

• Possible insertion attack if NID does not reject

This field must be validated by a receiving host and if not valid, the datagram will be discarded and

no error message will be sent to the sending host RFC 1121 states that the datagram must be silently discarded if an invalid value is discovered So, crafting a datagram with an invalid IP version would serve no purpose other than to test if the receiving host complies with the RFC

If a packet arrives at a router with an invalid IP version, it should be rejected So using this as a means of an insertion attack would be rather difficult unless the attacker is on the same network where the NID is If that happens and a series of packets are sent to the end host, with an invalid IP version and a NID does not reject them, this would be an insertion attack – something the NID accepts that the destination host should surely reject

Trang 5

5

Mutant IP Version

• isic software can generate bad IP versions

• Done to test the integrity of receiving host IP stack

We have captured the output sent using tcpdump Because standard tcpdump doesn’t reveal the IP version, we have to examine it by looking at the output in hexadecimal We see that a bogus version

of 0 has been generated

Trang 6

Filter Writing Exercise

• What would the tcpdump filter be to find a value in the IP

version field that is not equal 4?

IP Version IP header length high-order nibble low-order nibble

First byte of the IP header (0 offset)

Suppose you wanted to write a filter that would examine the IP version number and spit out any records that did not have a value of 4 in this field The IP version is found in the high-order in the 0 offset byte of the IP header Remember, you will have to mask out the low order nibble

Trang 7

7

Answer

• What would the tcpdump filter be to find a value in the IP

version field that is not equal 4?

IP Version IP header length high-order nibble low-order nibble

Next, we figure out that this mask byte is a hex f0 and we must do a boolean AND operation of this mask byte with the original byte Hence, the filter becomes ip[0] & 0xf0 != 0x40 Remember, because we are dealing with the high-order nibble, we are really dealing with a factor of 16 A 4 inthe high order nibble would fall in the 26 position in the entire byte which is 64 So, you can

represent this as a 0x40 or you could even say 64 decimal

Trang 8

IP Protocol Number

• Found in 9 th byte offset of IP header

• Indicates the type of embedded protocol

• List of supported protocols found at:

embedded protocol, it will display it as ip-proto-#, where # is the decimal representation of the protocol In the output above, tcpdump found a 0x75 value in the protocol field and presents it on output as ip-proto-117

Trang 9

9

Scanning IP Protocols

• nmap can scan all 256 possible protocol numbers

• Determines what protocols are active on a host

• Negative responses can be used for host mapping

nmap -sO target

Starting nmap V 2.54BETA1 by fyodor@insecure.org (

www.insecure.org/nmap/ )

Interesting protocols on myhost.net (192.168.5.5):

(The 250 protocols scanned but not shown below are in state: closed)

Protocol State Name

Trang 10

Output of Protocol Scan

07:30:31.405513 scanner.net > target.com: ip-proto-134 0 (DF)

07:30:31.405899 target.com > scanner.net: icmp: target.com protocol 124

unreachable (DF)

Trang 11

11

Detecting Protocol Scans

• Following tcpdump filter will detect protocol

scan:

icmp[0] = 3 and icmp[1] = 2

• Recommendation is to always filter for this, rare

false alarm

To detect a protocol scan, add the above filter to your existing tcpdump filters This will look for the ICMP protocol unreachable message You use this filter for traffic that is leaving your network There should be few instances of legitimate protocol unreachable messages

Trang 12

Type of Service Byte

minimize delay

(0x10)

maximize throughput

(0x08)

maximize reliability

(0x04)

minimize cost

(0x02)

Precedence used by router to

determine which packet to send

first when several packets are

queued for transmission to the

same output interface

Type of service

used by router to

select routing path

when multiple paths

are available

Type of Service Bits

The Type of Service (TOS) field is byte 1 of the IP header The 3 high-order bits are used to represent a 3-bit preference field that prioritizes the traffic The unused bit must be 0 Only one of the TOS bits should be set A value of all zero’s means normal service RFC 1349 discusses the TOS in detail

An application or protocol sets a TOS and routers make decisions of how to route packets based on the TOS A packet that has a TOS to minimize delay is one such as telnet where response time is the overriding concern A packet that has a TOS to maximize throughput is one where there is much data to be sent such as with ftp An application that sets the TOS to maximize reliability wishes to avoid packet loss such as routing protocols Finally, a TOS that minimizes cost travels over a link which is least costly

As far as the precedence field, the larger the number, the higher the priority of the packet This, of course, assumes that a router is capable of analyzing and handling this field

Trang 13

Explicit Congestion Notification (ECN) Bits

It seems that the Type of Service byte has undergone several rounds of alterations since its incipient purpose One of these alterations in RFC 2481 calls for the two low-order bits of the TOS byte to be used for Explicit Congestion Notification The purpose here is that some routers are equipped to do Random Early Detection (RED) of the possibility of packet loss

When congestion is severe, it is possible that a router can drop packets RED attempts to mitigate this condition by calculating the possibility of congestion in the queue and marking packets that might otherwise be dropped as experiencing congestion If the ECN-capable bit is set in the TOS above, that indicates that the sender is ECN-aware If the sender is ECN-aware, the router will attempt not to drop the packet, but instead send it with the Congestion Experienced CE bit enabled and the receiver knows to reduce the sending rate We’ll discuss the receiver’s response in more detail when we cover the TCP fields Currently, this mechanism is available only for TCP

Trang 14

In the first execution of hping2, the TOS is set to 00 (that is normally the default for hping2, but it is explicitly set for demonstration purposes) There is no TOS output from tcpdump Next the TOS is set to hexadecimal 10 and we see it printed out with the final 0 truncated Finally, the value of hexadecimal ff is selected and we see it displayed.

Trang 15

This doesn’t appear to be malicious, rather, a disregard or lack of attention to the TOS Sampling a day’s worth of tcpdump traffic from a monitored site, by far, most packets had a TOS byte of all zeros The TOS bits and the precedence bits were largely ignored for several years, but they are coming into vogue with applications such as OSPF.

Trang 16

Don’t Fragment (DF) Flag

• If set and fragmentation required, datagram

discarded

• Used for OS identification

• Possible insertion attack

The DF flag is set when fragmentation is not to occur If a router discovers that a datagram needs to

be fragmented, but the DF flag is set, the datagram is dropped and a message”unreachable - need to frag (MTU size)” is delivered to the sending host Most current routers will include the MTU size of the smaller link that required the fragmentation

Fragmentation comes with some overhead so it is desirable if it can be avoided If one fragment is not delivered, all fragments will have to be re-sent Because of this, some protocols sending data will send a discovery packet with the DF flag set If the packet goes from source to destination without any ICMP errors, then the selected datagram size of the discovery packet is used for

subsequent packets If an ICMP message is returned with an unreachable error – need to frag message and the MTU is included, then the protocol resizes the datagram so that fragmentation does not occur Some operating system TCP/IP stacks set the DF flag on certain types of packets and nmap will use this as one of the tests to try to fingerprint the operating system

An attacker can use the DF as a means of an insertion attack This would mean that the NID would

Trang 17

17

More Fragments Flag

• Used to indicate more fragments follow current

fragment

• Should appear on all but last fragment

• Fragmentation identified by:

• MF = 1

• Non-zero fragment offset

The more fragments (MF) is one of the fields that tells about a fragment train All fragments except the final one should have the MF flag set The way that a receiving host will detect fragmentation is that this flag is set or that the fragment offset field in the IP header is non-zero

Trang 18

listening port on destination host

• Destination host sets a timer when first fragment

received

• If all fragments have not been received and timer

expires, IP reassembly time returned

Another mapping technique is to try to elicit an ICMP IP reassembly time exceeded message from hosts on a scanned network This can be done by sending an incomplete set of fragments to hosts that are being mapped For this to work properly, the destination host has to be listening on the port that is scanned If it does, when it receives the first fragment, it will set a timer If the timer expires and the receiving host has not received all the fragments, it will send the ICMP reassembly time exceeded error back to the sending host

It is unknown why this method of scanning would be selected over a straight port scan Unless the destination network has no IDS to examine fragments, this is potentially as noisy a scan as a non-fragmented port scan

Trang 19

12:05:30.731783 sparky > verbo: icmp: ip reassembly time exceeded (DF)

time out ~ 1 minute

To simulate this scan, the hping2 command is enlisted It is first executed with the –S option to send

a SYN, a destination port of 139, -p 139, and the –x option to set the more fragment flag One packet is sent to the destination host win98, which as you might guess is a Windows 98 host listening

on TCP port 139

The fragment sent is actually the entire SYN packet – 20 header bytes and 20 data bytes There is no data left to send, but the receiving host has no way of knowing this since the MF flag is set You can see that the MF flag is set by looking at “+” in the output above of tcpdump The Windows host took approximately a minute and 5 seconds to time out the fragment reassembly clock That is when you see the IP reassembly time exceeded message returned The Linux (2.2.12-20 kernel) host took about a half a minute to time out, and a Solaris 2.7 host took about a minute to time out to respond to incomplete fragments sent to destination port 21

Trang 20

IP Reassembly Time Exceeded

07:53:19.592273 dns.querier.1421 > dns.ru.domain: 4202+ (31)

07:53:29.150706 dns.ru > dns.querier: (frag 63694:30@400)

07:53:29.154481 dns.ru.domain > dns.querier.1421: 4202 6/8/8 (72) (frag

63694:80@0+)

07:53:29.154490 dns.ru > dns.querier: (frag 63694:80@320+)

07:53:49.612886 dns.querier > dns.ru: icmp: ip reassembly time exceeded [tos 0xc0]

The activity in the above slide is unique First, dns.querier issues DNS query number 4202 to dns.ru About 10 seconds later, you see dns.ru respond to the query, however it appears that it responds in fragments Each fragment but the last is 80 bytes long This is strange because this implies that the MTU is 100 (80 data bytes plus a minimum of 20 IP bytes) MTU’s are usually not this small

Next, what is also strange is that the fragments almost appear to be generated in reverse order The final fragment is sent first (30@400), the initial fragment then arrives, and the intermediate

fragments arrive in descending order It appears that all the fragments arrive, perhaps not in

chronological order, but none appears to be missing Yet, we still appear to have an ip reassembly time exceeded message generated by the receiving host – dns.querier There appears to be no overtly obvious reason for this

Trang 21

NXDomain 0/1/0 (72) (frag 64904:80@0+) [tos 0x20]

07:54:20.901968 dns.querier > dns.ru: icmp: ip reassembly

time exceeded [tos 0xc0]

The activity on the previous slide appeared to be a fluke, yet we see that activity between the same two hosts about the same time, elicited another ip reassembly time exceeded message The pattern is very similar to what we just witnessed You see dns.querier query DNS server dns.ru for query number 4204 Then dns.ru generates the response in fragments beginning with the last first Again, the fragment length is 80 bytes

And, we see that dns.querier again responds with an ip reassembly time exceeded message in response to what it believes to be incomplete fragments Yet, visually, there doesn’t appear to be anything wrong with the fragments that were received The receiving host dns.querier should not have problems with reassembling fragments that do not arrive in order

Trang 22

What is Happening?

dns.querier dns.ru

Fragment 1 Fragment 2 Fragment x

ICMP reassembly time exceeded

In order for an ICMP ip reassembly time message to be generated, the receiving host recognizes that all fragments have not arrived for a given fragment train when the fragmentation timer expires Yet, looking at the output from the previous slides, it appears that all the fragments were sent, albeit in reverse order This was quite baffling since dissecting the datagrams yielded no new clues

The output is from a sensor which resides outside the packet filtering device Another sensor is located inside the packet filtering device When this same traffic was examined on the inside sensor,

it was discovered that only the first fragment was allowed through the packet filtering device This made no sense at all

This packet filtering device was stateful and the traffic had originated inside our network All fragments should have been allowed in An initial thought was perhaps the packet filtering device was blocking traffic because of the small fragment size, yet if this were so, none of the packets should have been allowed through It appears that the packet filtering device is not properly

processing these fragments

Tiêu đề	Examination of datagram fields ii
Tác giả	Judy Novak
Trường học	Johns Hopkins University Applied Physics Laboratory
Thể loại	bài luận
Năm xuất bản	2001

Định dạng
Số trang	40
Dung lượng	239,03 KB