Lecture 23: Network Primer
7/15/2003
CSCE 590
Summer 2003
TCP Header
0
1
2
Source Port
4
3
Destination Port
5
6
7
Sequence Number
8
9
10
11
Acknowledgement Number
12
13
Hdr Len
14
U A P R S F
R C S S Y I
G K H T N N
Reserved
16
17
Window Size
18
TCP Packet Checksum
20
21
15
19
Urgent Pointer
22
23
Options (Variable length padded with 0’s)
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
TCP Fields
• Source port and Destination port:
– 16 bit fields valid values (0)1-65535
– Destination port, some listening server
– Source port – random, usually chosen above
1023 and called ephemeral
– Source ports should change with each new
session/connection
What’s Weird?
22:08:48.495489
4096
22:08:48.495588
4096
22:08:48.495616
4096
22:08:48.495643
4096
22:08:48.495668
4096
22:08:48.495693
4096
22:08:48.495718
4096
22:08:48.495743
4096
22:08:48.495768
4096
22:08:48.495793
4096
129.252.41.100.62505 > 129.252.176.4.890: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.627: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.461: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.1000: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.199: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.265: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.7597: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.826: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.645: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.84: S 3938526924:3938526924(0) win
What’s Weird?
22:19:30.481578
22:19:31.478737
22:19:32.478824
22:19:33.478916
22:19:34.478995
22:19:35.479099
22:19:36.479179
22:19:37.479293
22:19:38.479382
22:19:39.479463
129.252.41.10.2140 > 129.252.176.4.0:
129.252.41.10.2141 > 129.252.176.4.0:
129.252.41.10.2142 > 129.252.176.4.0:
129.252.41.10.2143 > 129.252.176.4.0:
129.252.41.10.2144 > 129.252.176.4.0:
129.252.41.10.2145 > 129.252.176.4.0:
129.252.41.10.2146 > 129.252.176.4.0:
129.252.41.10.2147 > 129.252.176.4.0:
129.252.41.10.2148 > 129.252.176.4.0:
129.252.41.10.2149 > 129.252.176.4.0:
S
S
S
S
S
S
S
S
S
S
1860807593:1860807593(0) win 512
1456794212:1456794212(0) win 512
2100191735:2100191735(0) win 512
1628560220:1628560220(0) win 512
1658245839:1658245839(0) win 512
858387126:858387126(0) win 512
1898100889:1898100889(0) win 512
164501792:164501792(0) win 512
1225583647:1225583647(0) win 512
324333867:324333867(0) win 512
Sequence Numbers
• Uniquely identifies the intial byte of each TCP
segment sent
• Keeps track of all data sent and received
• Should change for all new TCP segments sent
(retries have the same since they are duplicates)
• ISN – Initial Sequence Number – 1st sequence
number in session (each side picks one)
ISN Prediction
• Can fingerprint operating systems by how
they generate ISNs
• If it is a predictable pattern, can hijack a
session
• Nmap keeps an OS fingerprint database and
with the –O option and judges how difficult
TCP Sequence Prediction might be
Now What’s Weird?
22:08:48.495489
4096
22:08:48.495588
4096
22:08:48.495616
4096
22:08:48.495643
4096
22:08:48.495668
4096
22:08:48.495693
4096
22:08:48.495718
4096
22:08:48.495743
4096
22:08:48.495768
4096
22:08:48.495793
4096
129.252.41.100.62505 > 129.252.176.4.890: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.627: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.461: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.1000: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.199: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.265: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.7597: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.826: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.645: S 3938526924:3938526924(0) win
129.252.41.100.62505 > 129.252.176.4.84: S 3938526924:3938526924(0) win
Acknowledgement Numbers
• Receiving host must tell sending host it got
the data with an acknowledgement (ack)
• 32 bit number representing the next byte of
data receiving host expects = last received
sequence number + 1
• Has to be > 0, zero is impossible
22:08:48.495489 129.252.41.10.62677 > 129.252.176.4.80: S 3938526924:3938526924(0)
win 2048
22:08:48.495588 129.252.176.4.80 > 129.252.41.10.62677: S 373851632:373851632(0)
ack 3938526925 win 8576 <mss 1460? (DF)
What’s Weird?
23:12:26.100485 hostA.48776 > machineB.25: . ack 0 win
2048 <wscale 10,nop,mss 265,timestamp 1061109567
0,eol>
TCP Flags
• Tells the state of a TCP segment
–
–
–
–
–
–
SYN – session establishment (tcpdump = S)
FIN – session termination (F)
RST – session abort (R)
ACK – acknowledgement of received data (ack)
PUSH – send buffered data up to application (P)
URG – send data with higher priority (interrupts like
<CTRL-C>) (urg)
• Flags only make sense in particular combinations
TCP Three-Way Handshake
Host A
Host B
Send SYN seq = x
Receive SYN
Send SYN seq = y;
ACK = x+1
Receive SYN + ACK
Send ACK = y+1
Receive ACK
TCP Three-Way Handshake
•
•
•
•
SYN
SYN + ACK
ACK
Thereafter SYN + ACKs
TCP Three-Way Handshake
23:49:23.440874 129.252.41.10.57839 > 129.252.41.2.80: S
440460922:440460922(0)win 5840 <mss 1460,sackOK,timestamp
114681793 0,nop,wscale 0> (DF)
23:49:23.441040 129.252.41.2.80 > 129.252.41.10.57839: S
431660388:431660388(0)ack 440460923 win 5792 <mss
1460,sackOK,timestamp 2458279816 114681793,nop,wscale 0>
(DF)
23:49:23.441084 129.252.41.10.57839 > 129.252.41.2.80: . ack
431660389 win 5840 <nop,nop,timestamp 114681793 2458279816>
(DF)
TCP Three-Way Handshake
23:49:23.440874 129.252.41.10.57839 > 129.252.41.2.80: S
440460922:440460922(0)win 5840 <mss 1460,sackOK,timestamp 114681793
0,nop,wscale 0> (DF)
23:49:23.441040 129.252.41.2.80 > 129.252.41.10.57839: S
431660388:431660388(0)ack 440460923 win 5792 <mss 1460,sackOK,timestamp
2458279816 114681793,nop,wscale 0> (DF)
23:49:23.441084 129.252.41.10.57839 > 129.252.41.2.80: . ack 1 win 5840
<nop,nop,timestamp 114681793 2458279816> (DF)
23:49:23.441212 129.252.41.10.57839 > 129.252.41.2.80: P 1:104(103) ack 1 win
5840 <nop,nop,timestamp 114681793 2458279816> (DF)
23:49:23.441370 129.252.41.2.80 > 129.252.41.10.57839: . ack 104 win 5792
<nop,nop,timestamp 2458279816 114681793> (DF)
23:49:23.442322 129.252.41.2.80 > 129.252.41.10.57839: . 1:1449(1448) ack 104
win 5792 <nop,nop,timestamp 2458279816 114681793> (DF)
23:49:23.442354 129.252.41.10.57839 > 129.252.41.2.80: . ack 1449 win 8688
<nop,nop,timestamp 114681793 2458279816> (DF)
Gracefully Ending a Connection
• Gracefully – FIN
–
–
–
–
One side sends a FIN/ACK
The other side sends an ACK (One side closed)
Then the other side sends a FIN/ACK
And the first side sends an ACK (Two sides closed)
• Both sides should close their half of the full
duplex connection
• Sometimes they don’t.
Gracefully Ending a Connection
23:49:23.443343 129.252.41.10.57839 > 129.252.41.2.80: F
440461026:440461026(0)ack 431662073 win 8688
<nop,nop,timestamp 114681793 2458279816> (DF)
23:49:23.443489 129.252.41.2.80 > 129.252.41.10.57839: F
431662073:431662073(0)ack 440461027 win 5792
<nop,nop,timestamp 2458279817 114681793> (DF)
23:49:23.443532 129.252.41.10.57839 > 129.252.41.2.80: . ack
431662074 win 8688 <nop,nop,timestamp 114681793 2458279817>
(DF)
Abruptly Ending a Connection
• RESET halts it abruptly
00:20:30.427166 129.252.41.2.22 > 129.252.41.10.57878: P
2398201982:2398202990(1008) ack 2394778362 win 16704
<nop,nop,timestamp 2458466499 114868474> (DF)
00:20:30.427265 129.252.41.10.57878 > 129.252.41.2.22: R
2394778362:2394778362(0) win 0 (DF)
Invalid Flag Combinations
• Why?
–
–
–
–
–
Evading detection systems
Network mapping
Port scanning
OS fingerprinting
Could just be a corrupt packet
• Ex. Can’t start and end a session in the same
packet
• Reserved bits are used for fingerprinting too
Hdr Len
Reserved
U A P R S F
R C S S Y I
G K H T N N
Window Size
What’s Weird?
23:12:26.100477 129.252.41.10.48775 > 129.252.176.4.25: SFP
1933921669:1933921669(0) win 2048 urg 0 <wscale 10,nop,mss
265,timestamp 1061109567 0,eol>
23:12:26.100850 129.252.176.4.25 > 129.252.41.10.48775: S
4253896955:4253896955(0) ack 1933921670 win 65535 <mss
1260,nop,wscale 0,nop,nop,timestamp 0 0> (DF)
23:12:26.100866 129.252.41.10.48775 > 129.252.176.4.25: R
1933921670:1933921670(0) win 0 (DF)
TCP Retries
• What if a packet doesn’t get acknowledged?
• Eventually sender resends the exact packet
• Waits a little longer between each retry:
– 3seconds, 6 seconds, 12 seconds, etc
– Different Oses use different backoff algorithms
• What might cause retries?
– Destination host went down, ICMP message didn’t get
through
– Packet filtering device silently dropping
– RESET sent, but we didn’t get it
TCP Retries – Guess Which
23:46:04.527781 10.10.33.4.1140 > 129.252.41.16.22: S
698192483:698192483(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
23:46:07.509678 10.10.33.4.1140 > 129.252.41.16.22: S
698192483:698192483(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
23:46:13.518688 10.10.33.4.1140 > 129.252.41.16.22: S
698192483:698192483(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
23:46:25.537689 10.10.33.4.1140 > 129.252.41.16.22: S
698192483:698192483(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
------------------------------------------------------------------23:46:40.529581 10.10.33.4.39344 > 129.252.41.16.22: S
698192483:698192483(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
23:46:41.509678 10.10.33.4.39345 > 129.252.41.16.22: S
698735981:698735981(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
23:46:53.518688 10.10.33.4.39378 > 129.252.41.16.22: S
698654463:698654463(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
23:46:53.923679 10.10.33.4.39379 > 129.252.41.16.22: S
699129230:699129230(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
TCP Options
• At the end of the header
– MSS: Maximum Segment Size
– Window Scale: allows window receive buffers to be >
65535
– Timestamp: carries a timestamp for each segment
– Selective Acknowledgement: non-contiguous segments
can be acknowledged
– No Operation: NOP, padding to 4-byte boundaries
– End of List Option: pad final option to 4 byte boundary
• More OS fingerprinting possibilities
– Not all OSes support all options
– OSes list options in different orders
TCP Window Size
• Receiving host’s TCP buffer size for connection
• Flow control
– Window size changes dynamically as data is received
– Size of zero means stop sending data for a while
– Gtes bigger than zero when it can take more data
• Initial window sizes can be used for OS
fingerprinting (surprise!)
• Labeled with a “win” in tcpdump
References
• Highly recommend:
• http://www.sans.org/resources/tcpip.pdf