Examination of Datagram Fields II

1
1
Network Traffic Analysis
Using tcpdump
Judy Novak
Judy Novak
Johns Hopkins University Applied Physics Laboratory

Examination of Datagram Fields II
All material Copyright  Novak, 2000, 2001. All rights reserved.
2
2
IP Header Fields
This page intentionally left blank.
3
This page intentionally left blank.
3
IP Header
0 15 16 31
20
bytes
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
4
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.
5
5
Mutant IP Version

•
isic software can generate bad IP versions
•
Done to test the integrity of receiving host IP stack
isic -s 10.10.10.10 -d 1.1.1.1 -p 10 -V 100
source IP dest IP #packets %bad IP versions
15:44:34.376749 10.10.10.10 > 1.1.1.1: ip-proto-117 1260 [tos 0x83]
0
383 04f8 0001 0000 0675 0383 0a0a 0a0a
01010 0101 b91e 6f98 55d4 5c7c a64b 3367
72c8 e1c4 5c03 7fc1 5cd9 ea3e d96a 1207
c293 e28c 9cb5
version = 0
The isic software is intended to test the integrity of a receiving host’s IP stack. It can also be used to
see how firewalls or intrusion detection systems react to mutant packets. We generate the command
and specify a source IP of 10.10.10.10 and specify a target host of 1.1.1.1. The source IP is a decoy
host, while the destination IP is an actual host. We can specify the number of packets to be sent
using the –p option – in this case 10. And, using the –V option we can specify the number of packets
that will have bad IP versions – in this case, all of the packets.
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.
6
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.
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
1 1 1 1 0 0 0 0 Mask byte
ip[0] & 0xf0 != 0x40
ip[0] & 0xf0 != 64
2
7
2
6
2
5
2
4
2
3
2
2
2
1
2

0
Because we are dealing with only the high-order nibble of the first byte, we want to preserve all
original bits found in this field and discard all bits found in the low-order nibble. So, if we chose a
mask of all 1’s in the high-order nibble and all 0’s in the low-order nibble, that ought to accomplish
this.
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 in
the high order nibble would fall in the 2
6
position in the entire byte which is 64. So, you can
represent this as a 0x40 or you could even say 64 decimal.
8
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:
/>•
If tcpdump doesn’t know name of protocol, displays as
ip-proto-#
15:44:34.376749 10.10.10.10 > 1.1.1.1: ip-proto-117 1260 [tos 0x83]
0383 04f8 0001 0000 0675
0383 0a0a 0a0a
01010 0101

You have already learned that the IP protocol number indicates the type of service that follows the IP
header. tcpdump will know the more common of these protocols and will often display them with
the standard display – such as icmp or udp. But, if tcpdump doesn’t know the name of the
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.
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 (
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
1 open icmp
2 open igmp
6 open tcp
17 open udp
Conveniently, later versions of nmap have the ability to scan a host for open protocols. This is done
using the –sO option. The target host is scanned for all 256 possibilities of protocols. Protocols are
deemed as open when no ICMP error message is returned to say that they are unreachable.
10
10

Output of Protocol Scan
07:30:31.405513 scanner.net > target.com: ip-proto-134 0 (DF)
07:30:31.405581 scanner.net > target.com: ip-proto-100 0 (DF)
07:30:31.405647 scanner.net > target.com: ip-proto-15 0 (DF)
07:30:31.405899 target.com > scanner.net: icmp: target.com protocol 124
unreachable (DF)
07:30:31.788701 scanner.net > target.com: ip-proto-132 0 (DF)
07:30:32.119538 target.com > scanner.net: icmp: target.com protocol 166
unreachable (DF)
07:30:34.098715 scanner.net > target.com: ip-proto-109 0 (DF)
07:30:34.098782 scanner.net > target.com: ip-proto-129 0 (DF)
07:30:34.098849 scanner.net > target.com: ip-proto-229 0 (DF)
07:30:32.779583 target.com > scanner.net: icmp: target.com protocol 236
unreachable (DF)
07:30:34.099557 target.com > scanner.net: icmp: target.com protocol 109
unreachable (DF)
The nmap scan will scan all 256 different protocol types. A host that receives this type of scan
should respond with a protocol unreachable message to any protocols that it doesn’t support.
While the supported protocols of a host are mildly interesting, the more important reconnaissance
from this type of scan is that the host is alive. This is a more stealthy type of scan that may not cause
an intrusion detection system to alarm. However, if the site has a “no ip unreachable” statement on
the outbound interfaces of the gateway router or blocks outbound ICMP, this information will not be
leaked to the scanner. In that instance, the scan will be useless.
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.
12
12
Type of Service Byte
Precedence bits
unused
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.
13
13
TOS Future Versions
Differentiated Services Byte
ECN-capable
(0x02)
Congestion
Experienced
(0x01)
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.
14
14
When Does tcpdump Print
TOS?
hping2 -o 00 -S 10.10.10.10
1.1.1.1.1365 > 10.10.10.10.0: S 2058498470:2058498470(0) win 512
1.1.1.1.1366 > 10.10.10.10.0: S 1423431115:1423431115(0) win 512
hping2 -o 10
-S 10.10.10.10
1.1.1.1.1863 > 10.10.10.10.0: S 1126628061:1126628061(0) win 512 [tos 0x10]
1.1.1.1.1864 > 10.10.10.10.0: S 1641963266:1641963266(0) win 512 [tos 0x10]
hping2 -o ff
-S 10.10.10.10
1.1.1.1.1366 > 10.10.10.10.0: S 127899453:127899453(0) win 512 [tos 0xff]
1.1.1.1.1367 >10.10.10.10.0: S 793924862:793924862(0) win 512 [tos 0xff]
tcpdump prints the TOS field when it is non-zero. To verify this, hping2 was used to generate some
traffic while tcpdump was capturing it. The –o option in hping2 sets a hexadecimal value for the
TOS. The –S option was selected to generate a SYN and the destination IP is 10.10.10.10.
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.
15

15
Multiple TOS Bits Set
00:07:21.873679 myhost.com.1259 > www.abc.com.https: S
1169887925:1169887925(0) win 8192 <mss
536,nop,nop,nop,nop,nop,nop,timestamp[|tcp]> (DF) [tos 0x3]
00:08:56.174117 myhost.com.1260 > www.abc.com.https: S
416337007:416337007(0) win 8192 <mss
536,nop,nop,nop,nop,nop,nop,timestamp[|tcp]> (DF) [tos 0x5]
00:09:03.179514 myhost.com.1262 > www.abc.com.https: S
1319421773:1319421773(0) win 8192 <mss
536,nop,nop,nop,nop,nop,nop,timestamp[|tcp]> (DF) [tos 0x7]
00:06:11.534400 myhost.com.1253 > www.abc.com.https: S
484044887:484044887(0) win 8192 <mss
536,nop,nop,nop,nop,nop,nop,timestamp[|tcp]> (DF) [tos 0xc]
Although only one TOS bit is supposed to be set, we find that sometimes applications (for whatever
reason) set multiple ones. In the above traffic, it appeared that myhost.com sent the same type of
traffic (secure web) with different TOS values and multiple bits set.
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.
16
16
Don’t Fragment (DF) Flag
•
Datagram must not be fragmented
•
If set and fragmentation required, datagram
discarded
•

Used for MTU discovery
•
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
have to be on a network with a larger MTU than the final destination host. In this case, one packet
among a series of others would have the DF set. The NID would receive the packet and accept it,
yet the end host would never receive the packet since fragmentation would be required, yet the DF
was set.