Examination of Datagram Fields III

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

Examination of Datagram Fields III
All material Copyright  Novak, 2000, 2001. All rights reserved.
2
2
TCP Fields
This page intentionally left blank.
3
3
TCP Header
0 15 16 31
20
bytes
options (if any)
data (if any)
16-bit source port number 16-bit destination port number
32-bit sequence number
32-bit acknowledgement number
4-bit
header
length
reserved
(6-bits)
U A P R S F

R C S S Y I
G K H T N N
16-bit window size
16-bit checksum
16-bit urgent pointer
This page intentionally left blank.
4
4
TCP Ports
•
16-bit fields representing source and destination
ports
•
Valid values 1 – 65535
•
Initial source port ephemeral range > 1023
•
Multiple connections attempted, source ports
should change
The port fields are two separate 16-bit fields in the TCP header, one for source and another for
destination ports. The valid range of values is between 1 and 65535; the use of port 0 is typically a
“signature” of some sort.
When a source host wishes to connect to a destination host, an ephemeral port is typically selected in
the range of ports greater than 1023. For each new sending connection that the host attempts that is
not a retry, a different ephemeral port should be selected.
5
5
Source Port Mutation
nmap –sS sparky
09:40:43.964215 verbo.47247 > sparky.1548: S 2401927088:2401927088(0) win

2048
09:40:43.964412 verbo.47247
> sparky.24: S 2401927088:2401927088(0) win
2048
09:40:43.964465 verbo.47247
> sparky.1547: S 2401927088:2401927088(0) win
2048
09:40:43.964553 verbo.47247
> sparky.2564: S 2401927088:2401927088(0) win
2048
09:40:43.964604 verbo.47247
> sparky.1484: S 2401927088:2401927088(0) win
2048
09:40:43.964642 verbo.47247
> sparky.1460: S 2401927088:2401927088(0) win
2048
09:40:43.964695 verbo.47247
> sparky.628: S 2401927088:2401927088(0) win
2048
09:40:43.964748 verbo.47247
> sparky.1112: S 2401927088:2401927088(0) win
2048
This is output from running nmap with the option of sending a host a SYN scan. You’ll notice that
nmap uses a default behavior of using a static source port for this scan. This is a signature of this
scan; if this followed normal behavior, you would expect to see the source port numbers
incrementing in the ephemeral port range.
6
6
Destination Port Mutation
hping2 –S sparky

09:44:13.882207 verbo.1788 > sparky.0
: S 1553132317:1553132317(0) win 512
09:44:14.876837 verbo.1789 > sparky.0
: S 1894028093:1894028093(0) win 512
09:44:15.876836 verbo.1790 > sparky.0
: S 2032501562:2032501562(0) win 512
09:44:16.876832 verbo.1791 > sparky.0
: S 851202745:851202745(0) win 512
09:44:17.876843 verbo.1792 > sparky.0
: S 1659659021:1659659021(0) win 512
09:44:18.876836 verbo.1793 > sparky.0
: S 731953738:731953738(0) win 512
Now, look at the default behavior that hping2 exhibits doing a SYN scan. It increments the source
port as we expect, however it uses destination port 0 as its default target. The intent of this type of
scan obviously is not to find a listening port. This type of scan would be used to elicit a RESET
response to see if a host is alive and in so doing perhaps examine other traits of the responding
datagram.
7
7
Sequence Numbers
•
32-bit number that uniquely identifies the initial
byte of segment data
•
Should change for each new (non-retry) TCP
segment sent
•
Initial sequence number (ISN) represents first
sequence number in TCP exchange
•

ISN used to fingerprint operating system
The TCP sequence numbers are used to uniquely identify the beginning byte of each TCP segment that is sent.
This is a way to keep track of all the TCP data that is sent and all that is received in a TCP stream. Most
times, there is more TCP data than can be sent with one TCP segment. Since TCP is a connection-oriented,
reliable protocol, we have to have a mechanism to account for data being sent and received. In part, that is
done using TCP sequence numbers.
These sequence numbers should not be repeated unless there is a retry of the same connection. The initial
sequence number (ISN) is the first sequence number that is used in the TCP exchange between the sending
hosts. Each host in the exchange selects a unique initial sequence number when sending the initial SYN
connection to the other host.
The formula that hosts use to select their initial sequence number is examined by nmap to help fingerprint the
operating system. There is a file that comes with nmap, nmap-os-fingerprints, that has a list of different
operating systems. Given a set of tests that will be executed by nmap against a target host, if the received
values exactly match the ones listed for the OS, it is classified as that particular OS.
The first test executed by an OS fingerprinting nmap scan is one that examines the initial sequence numbers
generated from sending connections to a listening port. Different TCP/IP stacks use different formulas to
generate the ISN. Some of the older operating systems used a predictable increment for each new connection,
but someone watching and sniffing could hijack a connection using this information as was done in the
infamous Mitnick attack. Other operating systems have a time-dependent formula that predictably increases
the ISN based on a given time change.
8
8
Sequence Number Prediction
nmap –O win98
(The 1522 ports scanned but not shown below are in state: closed)
Port State Service
139/tcp open netbios-ssn
TCP Sequence Prediction: Class=trivial time dependency
Difficulty=1 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98

Using nmap to scan the host win98 and identify the operating system using the –O option, it
discovers that the generation of initial sequence numbers is based on a formula using a “trivial time
dependency”. And, it reports that predicting a new TCP sequence number would be a “trivial joke”.
Windows NT, Windows 95 and Windows 98 all use this same formula. The best type of formula for
generating unpredictable sequence numbers is one that is truly random which is what operating
systems such as Linux 2.0 kernels use.
9
9
Sequence Number Mutation
nmap –sS sparky
09:40:43.964215 verbo.47247 > sparky.1548: S 2401927088:2401927088(0) win
2048
09:40:43.964412 verbo.47247 > sparky.24: S 2401927088
:2401927088(0) win
2048
09:40:43.964465 verbo.
47247 > sparky.1547: S 2401927088:2401927088(0) win
2048
09:40:43.964553 verbo.47247 > sparky.2564: S 2401927088
:2401927088(0) win
2048
09:40:43.964604 verbo.47247 > sparky.1484: S 2401927088
:2401927088(0) win
2048
09:40:43.964642 verbo.47247 > sparky.1460: S 2401927088
:2401927088(0) win
2048
09:40:43.964695 verbo.47247 > sparky.628: S 2401927088
:2401927088(0) win
2048

09:40:43.964748 verbo.47247 > sparky.1112: S 2401927088
:2401927088(0) win
2048
Looking at the nmap output again that does a SYN scan of a host, we see it has a signature of a static
TCP sequence number along with the static source port number.
10
10
Acknowledgement Numbers
•
TCP is a connection-oriented protocol
•
Sending host knows receiving host has gotten data by an
acknowledgement
•
ACK number is 32-bit number
•
Represents the next byte of data receiving host expects: (last
received sequence number + 1)
•
Valid value should be greater than 0
07:48:09.134305 verbo.62638 > win98.netbios-ssn: S 3742735770:3742735770(0)
win 2048
07:48:09.134515 win98.netbios-ssn > verbo.62638: S 3982854:3982854(0) ack
3742735771
win 8576 <mss 1460> (DF)
The method that TCP uses to ensure that data is received is via an acknowledgement. This is done
using the acknowledgement number which is a validation that the receiving host did indeed get the
data. The acknowledgement number sent by the receiving host actually represents the next expected
sequence number.
Because a SYN connection consumes one sequence number, and since the acknowledgement value

is one more than this sequence number, a valid acknowledgement number must be greater than 0.
nmap can attempt to identify live hosts by sending a remote host a TCP connection with an
unsolicited ACK flag set. The desired response to this is a RESET from the remote host which
indeed indicates that the remote host is alive regardless of whether the scanned port is listening or
not. Current versions of nmap have a telltale signature because the ACK flag is set, yet the
acknowledgement number is 0.
Above the sending host verbo, has an initial sequence number of 3742735770. The receiving host,
win98, acknowledges this by indicating that the next sequence number it expects to receive is
374173577.
11
11
TCP Flags
•
Tell the state of a given TCP segment
•
SYN – session establishment
•
FIN – session termination
•
RST – session abort
•
ACK – acknowledgement of received data
•
PUSH – send data
•
URG – send data with higher priority
•
Valid flag combinations
•
Invalid flag combinations

•
Done for detection evasion purposes
•
Mapping
•
Port scanning
•
Done for OS fingerprinting
•
Manifestation of packet corruption
TCP flags are used to indicate the state of a given TCP connection or session. The SYN flag starts
the session and the FIN flag terminates a session gracefully. A RESET is used to abort a session.
The ACK flag is set to indicate an acknowledgement of data by the receiver. The ACK flag is set on
all connections after the initial SYN. The PUSH flag is typically used to tell the sending host to
write all of its buffered data to send to the destination host. It is possible to send data without the
PUSH flag set. Finally, the URGENT flag is used to indicate that this data has the highest priority,
for instance an interrupt by a CNTL-C to abort the current process and data exchange would require
higher priority.
The TCP flags have many different valid combinations. And, there are many different invalid
combinations that are used for different purposes. Early on in the evolution of IDS’s, many would
examine traffic for initial SYN attempts only. Scanners realized this and would send a SYN/FIN
combination that might elicit a response from a host. Different OS TCP/IP stacks respond
differently to mutant flag settings so this is used to attempt to fingerprint the operating system.
Finally, just because you see mutant TCP flag combinations, it is not an indication of malicious
behavior. Packets can and do get corrupted and it is possible for TCP flags to be unnaturally set after
some kind of corruption.
12
12
TCP Byte Reserved Bits
URG ACK PSH RST SYN FINReserved

Unused: If set, possible indication of OS mapping
Until very recently, the two high-order bits of the TCP byte were known as the reserved bits. They
had no purpose and the value found in the bits should be 0. However, when tools such as Queso and
nmap came along, it was discovered that these bits could be used to try to help fingerprint a remote
system’s operating system. Different operating system TCP/IP stacks would respond uniquely when
these bits were set.
Some would reset the bits to 0 and others would simply leave them with the current value. Hence,
some categorizations could be made of the remote host’s operating system TCP/IP stack. This alone
would not be enough to inform the scanner of the operating system, but used in conjunction with
several other tests, the operating system could be conjectured with a high probability.
13
13
Explicit Congestion
Notification (ECN)
URG ACK PSH RST SYN FIN
ECN-echo
Congestion
Window
Reduced (CWR)
Remember back when we were discussing the type of service byte, we introduced a future purpose for the
two low-order bits known as Explicit Congestion Notification (ECN)? The intent was for a router to be
able to notify a sender that there was congestion in the network and to reduce its sending rate.
Well, how exactly does that occur? Currently as discussed in the ECN RFC 2481, the only transport
capable of reacting to that congestion notification is TCP. So, TCP has to be prepared to deal with this.
The RFC suggests using the two high-order bits of the TCP flag byte as fields for ECN. The bit to the right
of the high-order bit will be known as the ECN-echo bit. This bit will be turned on when TCP receives a
packet that has the TOS ECN-capable bit and the Congestion Experienced bits both set in the IP header.
This assumes that both end-points of the TCP conversation are ECN capable and that is determined during
the three-way handshake.
If TCP sets the ECN-echo bit, the purpose is to inform the sender to reduce the rate at which it is sending

data because there is congestion between the sender and receiver. Upon receipt of a TCP segment with the
ECN-echo bit set, the sender will reduce its congestion window (loosely speaking – the size of the sending
buffer) by half. Once it reacts in this manner, it will turn on the Congestion Window Reduced (CWR) bit
to inform the other side of the conversation that remedial action to reduce congestion has occurred. This
bit is found in the high-order bit of the TCP byte flag.
While this mechanism will help reduce the number of packets dropped, it is anticipated that many IDS’s
that exist, will begin to alarm on these new TCP flag bytes being used. Right now, most uses of these bits
are for scanning purposes only. Also, some packet-filtering devices will not allow in TCP segments with
these bits set. So, much customization will have to be done to smoothly introduce ECN.
14
14
ECN Detection With
tcpdump 3.5
nmap –O sparky
verbo.60608 > sparky.discard: S [ECN-Echo
]
1981655162:1981655162(0) win 2048 <wscale 10,nop,mss
265,timestamp 1061109567[|tcp]>
<4500 003c 3d06 0000 3906 8c6b 0101 8f05
0101 8f64> [ecc0 0009 761d a87a 0000 0000
a042 0800 fd47 0000 0303 0a01 0204 0109
080a 3f3f 3f3f]
0 1 2 3 4 5 6 7 8 9 10 11
12 13
TCP
flag
byte
< > IP Header
[ ] TCP Header
R R A U P R S FSR

TCP Flag Byte = 0x42
TOS
tcpdump version 3.5 has the capability to detect if the ECN bits of the TCP flag byte are set. It finds
that the TCP flag byte has a hex value of 0x42. This means that the SYN flag is set and that the bit
to the right of the high-order bit is also set. This correlates to the new ECN-echo flag. So, tcpdump
3.5 detects this and reports that the ECN-echo flag is set. Yet, this is not really the case.
This traffic was generated using nmap with the –O option to fingerprint. The hosts participating in
this conversation are not ECN-capable. One of the tests that nmap conducts is setting one of the
“bogus” TCP flag bits to see how the receiving host responds. This is really nothing more than
operating system fingerprinting. So, tcpdump is really reporting a “false alarm” of the ECN-echo bit
being set.
If this were an actual case of true ECN flag setting, the packet would have to have a non-zero Type
of Service (TOS) value. Remember, that in order for ECN to be used for TCP talkers, the two hosts
had to be ECN-capable. This was signaled via the TOS bit that was to the left of the low-order bit.
In other words, the TOS value would be a 0x02. So you begin to see the problem that packet
capturing software and intrusion detection systems face; they must distinguish actual ECN traffic
from fingerprinting traffic. To date, this doesn’t appear to be happening.
15
15
Filter Writing Exercise
URG ACK PSH RST SYN FINReserved
What would the tcpdump filter be to determine if
either/both of the TCP flag reserved bits is set?
Since it can be quite informative to know when a record has one or both of the TCP reserved bits set,
it would behoove us to have a tcpdump filter that would extract such records. As a hint, you might
want to try to use the greater than (>) sign to discover if one or both bits are set.
16
16
Answer
URG ACK PSH RST SYN FINReserved

Any of the following filters would extract a record with a non-zero
value in either of the two high-order bits:
tcp[13] & 0xc0 != 0
tcp[13] > 0x3f
tcp[13] > 63
2
3
2
2
2
1
2
0
2
3
2
2
2
1
2
0
If we go back to the original way we’ve masked the flag bits, we find that we want to look for bits
set in either the high-order bit or the one following that. The high-order bit is in the 2
3
position or 8
and the one following it is in the 2
2
position or 4. These added together give a decimal 12 or 0xc.
We then take this filter and AND it with the value found in tcp[13] and look for a non-zero result.
Alternatively, we can use the greater than sign to try to see if we have a non-zero value in the high-

order bits. Thus if we turn on all the 6 low-order bits, we have a value of 0x3f. This can also be
expressed in decimal as 63.
17
17
Sample Mutant Flags
nmap –O win98
20:33:16.409759 verbo.47322 > win98.netbios-ssn: SFP
861966446:861966446(0) win 3072 urg 0 <wscale 10,nop,mss
265,timestamp 1061109567[|tcp]>
20:33:16.410387 win98.netbios-ssn > verbo.47322: S 49904150:49904150(0)
ack 861966447 win 8215 <mss 1460> (DF)
nmap –O sparky
20:37:00.738412 verbo.50107 > sparky.echo: SFP
2326441544:2326441544(0)
win 2048 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
nmap –O linux
20:44:50.370158 verbo.42318 > linux.ftp: SFP
1749165064:1749165064(0) win
1024 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
When nmap is placed in OS fingerprinting mode with the –O option, it will send some mutant flag
combinations when an open port is discovered. The mutant combination of SYN/FIN/PUSH is sent
to the Windows port 139 and amazingly enough it responds with an acknowledgement! When the
same technique is attempted on a Solaris and Linux host, there is no response from the listening
ports, which is the behavior that would conform to RFC specifications.
18
18
TCP Connection Retries
•
Repeated attempt to connect to TCP port
•

If no RESET received, connection attempted
again
•
Destination host down, no ICMP message sent
•
Packet-filtering device silently dropping
•
RESET sent, but host doesn’t receive it
•
Number of additional retries sent - operating
system dependent
•
Will finally give up connection attempt
What if a TCP connection is attempted, yet the host attempting the connection doesn’t receive a
response from the destination host? A destination host might not respond because it may not be up
or may not exist. A router may deliver an ICMP message about the destination host being
unreachable, but if the router has been silenced from delivering unreachable messages, the sending
host will never know that there is a problem. A destination host might be sitting behind some kind of
packet filtering device that blocks the connection inbound, yet silently drops the connection without
informing the sending host. It is also possible that the destination host responds positively
(SYN/ACK) or negatively (RESET/ACK), yet for some reason the sending host doesn’t receive
these replies.
Additional attempts will be made to contact the host in situations like this. The number of attempts
and the time intervals in which they are attempted varies by operating system. Eventually, the
sending host will cease the connection attempts.
19
19
TCP Retries
Which set is a retry?
16:03:40.763603 my.net.39344 > your.net.6000: S 523285584:523285584(0) win

8760 (DF)
16:03:41.919170 my.net.39345 > your.net.6000: S 523517577:523517577(0) win
8760 (DF)
16:03:53.348706 my.net.39378 > your.net.6000: S 528418601:528418601(0) win
8760 (DF)
16:03:53.491895 my.net.39379 > your.net.6000: S 528509044:528509044(0) win
8760 (DF)
17:14:18.726864 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF)
17:14:21.781140 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF)
17:14:27.776662 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF)
17:14:39.775929 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF)
Suppose you were looking at traffic output and you saw the above sets of connections. The first
represents several connections from my.net to your.net port 6000. The second represents another set
of connections from 1.1.1.1 to 192.168.44.63 to port 3128. Do you have any idea which set contains
multiple different connection attempts and which set represents retries?
20
20
Multiple Different Connections
16:03:40.763603 my.net.39344 > your.net.6000: S 523285584:523285584(0) win
8760 (DF)
16:03:41.919170 my.net.39345 > your.net.6000: S 523517577:523517577(0) win
8760 (DF)
16:03:53.348706 my.net.39378 > your.net.6000: S 528418601:528418601(0) win
8760 (DF)
16:03:53.491895 my.net.39379 > your.net.6000: S 528509044:528509044(0) win
8760 (DF)

source ports change sequence numbers change
The first set was the multiple different connections output. Let’s examine how we know this.
First of all, the source ports change; this is indicative of different connection attempts. Second, the
TCP sequence numbers also change, also indicative of different connection attempts. So, these are
unique connections from the same host to the the same destination host and port. These may have
been successful or not, we are looking at the SYN connections only in this output. We would have
to examine all the traffic from the connection to determine if the connection were successful.
21
21
Retry of Same Connection
17:14:18.726864 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF)
17:14:21.781140 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF)
17:14:27.776662 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF)
17:14:39.775929 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF)
source ports same sequence numbers same
The second set of connections was the series of retries. The source ports remain the same and the
TCP sequence numbers don’t change. This is not a fail-safe detection method – it is also possible
that the sender is crafting packets that use the same source ports and TCP sequence numbers.
22
22
Retry of Same Connection
17:14:18.726864 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380>(DF) (ttl 17, id 15697)
17:14:21.781140 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF) (ttl 17, id 33873)
17:14:27.776662 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win

8192 <mss 1380> (DF) (ttl 17, id 46113)
17:14:39.775929 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) win
8192 <mss 1380> (DF) (ttl 17, id 54353)
IP ID’s change
3 second time delta
6 second time delta
12 second time delta
Examining the set of retries a bit more – look at the time changes and the IP identification number
changes above. The IP identification numbers should change on a retry as well as a set of unique
connections. The sending host sends an entirely new datagram for the retry so the IP identification
number should increment (or wrap).
Now, look at the time changes between attempted retries. Between the first and second connection
attempts the wait is approximately 3 seconds. This doubles to 6 seconds between the second and
third. And, finally, this doubles again to 12 seconds between the third and fourth attempts. This
doubling of the backoff time might not always be seen – different operating systems use different
time-retry algorithms for the subsequent retries.
23
23
Different Retry Time Interval
10:08:23.472378 state.net.1739 > myhost.com.6346: S 72549644:72549644(0)
win 8192 (DF)
10:08:24.009256 state.net.1739 > myhost.com.6346: S 72549644:72549644(0)
win 8192 (DF)
10:08:24.504518 state.net.1739 > myhost.com.6346: S 72549644:72549644(0)
win 8192 (DF)
10:08:25.006168 state.net.1739 > myhost.com.6346: S 72549644:72549644(0)
win 8192 (DF)
~.5 second time delta
~.5 second time delta
~.5 second time delta

This is another set of retries, but the time interval at which each new attempt is made is fairly
constant at about half a second. This seems to make less sense than the previous backoff algorithm.
By doubling the time between retries, if the destination host is suffering some kind of temporary
problem, it may respond if we continue to wait. This algorithm has a more insistent approach of not
really waiting much time at all before attempting a retry.
24
24
TCP Options
•
Included at the end of TCP header
•
Maximum segment size (mss): Largest amount of TCP
data sent to another host
•
Window scale: Provides a window scale factor to allow
window receive buffers to be > 65535
•
Timestamp: Carries a timestamp for each segment
•
Selective acknowledgement: Allows non-contiguous
segments to be acknowledged
•
No operation: Pad options to 4-byte boundaries
•
End of list option: Pad final option to 4-byte boundaries
•
Can be used to do OS fingerprinting
•
Can be used for insertion attacks
TCP options are optional parameters that can specify different behavior than the default. These are

included at the end of the TCP header. The MSS can be sent on the SYN only and it represents the largest
TCP payload that a host will send. Remember that the total IP datagram will be at least 40 bytes more
than this accounting for the IP header and the TCP header. This is set once and not readjusted like the
window size. The optimum value for this is very close to the MTU – 40. This doesn’t account for header
options, though. If an MSS value is not announced, the communicating host will assume that it is 536
bytes. The reason this is used is to inform the remote host of the number of the maximum number of
bytes to send to avoid fragmentation.
The window scale is a way to allow a receiving TCP buffer to be larger than the 16 bit maximum value of
65,535. There is a multiplicative factor applied to the window size to make it larger. The timestamp is a
mechanism to time and compute round trip time for TCP exchanges. This is used to compute the
retransmission timer that helps recover from packet loss. The timestamp can also be used to make sure a
reused and old sequence number does not accidentally get included with a current exchange.
A newer option is the selective acknowledgement. Both sending and receiving hosts have to support this
option for it to be used. If selective acknowledgement is not used a host can only acknowledge the last
chronological sequence number it received. In other words, if a TCP segment is either lost or late in
arriving, subsequent arriving segments cannot be acknowledged. The selective acknowledgement allows
for all received segments to be acknowledged.
A couple of TCP non-options are supplied to pad the options to the required 4-byte boundaries. The 1-
byte NOP can be used to pad in the middle of the options list, and the 1-byte eol option is used to pad and
indicate the end of options.
Finally, TCP options have to be perfectly formatted or they will be rejected by the end-host. This
represents another possible insertion attack if the NID doesn’t properly examine them.
25
25
Fingerprinting With TCP
Options
nmap –O win98
14:00:46.999055 verbo.4238 > win98.netbios-ssn: S 2262117252:2262117252(0)
win 32120 <mss 1460,sackOK,timestamp 126481796 0,nop,wscale
0> (DF)

14:00:47.029487 win98.netbios-ssn > verbo.4238: S 26347543:26347543(0) ack
2262117253 win 8760 <mss 1460,nop,nop,sackOK
> (DF)
nmap –O sparky
13:58:18.387461 verbo.1565 > sparky.ftp: S 2115515674:2115515674(0) win
32120 <mss 1460,sackOK,timestamp 126466936 0,nop,wscale 0
> (DF)
13:58:18.392988 sparky.ftp > verbo.1565: S 3478333904:3478333904(0) ack
2115515675 win 10136 <nop,nop,timestamp 126470710
126466936,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF)
One of the ways that nmap fingerprints an operating system is by sending different TCP options to
the host and see how it responds. Not all operating systems support all the TCP options so this
assists in OS identification. Also, different operating systems will list the TCP options in different
order. Also, some of the options values echoed back will change. As Fyodor says, this is a “gold
mine” of information for classification.
The Windows host response to the options appears to indicate that it doesn’t support the timestamp
or wscale option. The Solaris host responds to the options probe and appears to support all the
options. However, it reorders them giving additional classification clues away.