itis 6167/8167: network security weichao wang. 2 contents icmp protocol and attacks udp protocol and...
TRANSCRIPT
ITIS 6167/8167: Network Security
Weichao Wang
2
Contents
• ICMP protocol and attacks
• UDP protocol and attacks
• TCP protocol and attacks
3
• TCP: Transmission Control Protocol– The most loved and hated protocol– Various protocols have been developed to
replaced it, but not work very well
4
• The need for stream delivery– Out of order– Packet delay– Packet loss– Packet duplicate
5
• TCP’s properties– Stream orientation
• TCP treats data as continuous flow of bytes• The sequence of the sent and received data are exactly the
same
– Virtual circuit connection– Buffered transfer
• Application can determine the size of the pieces of the information it wants to transfer
• Protocol software will divide the information into segments• Usually use a segment with a reasonable size• Can use “push” option to force transfer without buffering
6
• Unstructured stream– TCP does not honor structured data stream– It is the application’s responsibility to understand the
data structure
• Full duplex connection: transfer in both directions (can close one direction while keeping the other active)
• Reliability– Positive acknowledgement with retransmission
7
• Layer structure
8
• TCP ports– TCP uses ports to identify applications– A connection is identified by four items
• Source IP and protocol port number• Destination IP and protocol port number
– A given TCP port number can be shared by multiple connections on the same machine because they will have different source IP and port numbers
9
• Reserved TCP port number– Port number can be 0 to 65535– 0 to 1024 are reserved for well known services
• 7: echo• 13: Daytime• 21: FTP• 22: SSH• 23: TELNET• 25: SMTP• 53: DNS• 79: Finger• 80: HTTP
10
• TCP segment format
11
• HLEN: length of segment header measured in 32 bits
• Checksum: over (pseudo header, TCP header, TCP data)
12
• CODE Bits: the purpose and contents of the segment
13
• Sliding window mechanism– Used for flow control– Operate at the byte level, instead of packet or
segment level (why)– An example of the sliding window
14
15
• In the window:– Octets through 2 have been sent and
acknowledged– Octets 3 to 6 have been sent but not
acknowledged– Octets 7 to 9 have not been sent but can be
sent– Octets 10 and above cannot be sent
16
• Receiver’s window:– Receiver maintains a window, it is different
from the sender’s window– It indicates how many more bytes the receiver
can accept– Bytes falling out of the window will be
discarded
17
• TCP allows the window size to change over time– In each acknowledgement, the WINDOW size
identifies how many more octets the receiver can accept. It can be viewed as the buffer size at the receiver side.
– If the window size increases, the sender move the sliding window forward and send more octets
– If the window size decreases, stop sending new bytes to the remote side. (not necessarily back move the window)
– Window size can be 0
18
• Out of band data– TCP treats data like streams, what if we have
some data of emergency and cannot wait till the end of the stream?
– Example: Control-C to stop the program– Urgent code bit can be used to specify this
kind of data– Urgent pointer: specify where the data ends
19
• Acknowledgement number: the next byte the receiver expects to receive– The ACK focuses on the continuous data that
have been received. The isolated pieces will not be acknowledged.
– There are versions supporting selective retransmission
20
• Timeout and retransmission– The packets can get lost because of various
reasons– A timer will be started for every sent segment– If timer expires, we will resend the segment– Figuring out the appropriate timeout:
• If it is too short, too many resend• If it is too long, cannot respond to packet lost
properly
21
• Deriving the timeout– Measure the round trip time b/w the packet
and ack– Using a weighted average value– Timeout = constant * RTT– How to handle resent packets?– There are tens of papers discussing this issue
22
• Congestion control– The sender and receiver windows only handle
problems at the end points. Packet may get lost at the intermediate routers
– TCP uses congestion window
allowed win = min(receiver win, congestion win)
– Routers drop packets when congestion happens, leading to retransmission
23
• Retransmission leads to worse congestion• To reduce congestion, TCP uses two methods
– Multiplicative decrease congestion avoidance: when a packet loss happens, reduce the congestion window by half. Back off the retransmission timers for the packets still in window
– Slow start recovery: for a new connection or after a congestion, start the window at one segment, increase the window by one segment after every received ack
– Is this slow enough???
• Other schemes for congestion control– Congestion avoidance: after the congestion
window reaches a threshold, add one segment after each RTT
– Fast retransmission: resend packets when multiple ACK with the same ACK number received
– Fast recovery: reduce the window to the threshold
24
25
• Silly window and countermeasures– The receiver’s window is full– It fetches one byte from the window every
time and sends an ACK– One more byte will be sent from the sender– Very low efficiency– How to avoid silly window:
• Receiver’s view• Sender’s view
26
• PUSH bit: forcing data delivery– If we are using TCP for an interactive
terminal, holding data may lead to bad interfaces. User cannot see key stroke results.
– TCP provides a PUSH bit to force data delivery without delay
– The PUSH bit also tells the receiver to handle the data immediately
27
• Establishing TCP connection: 3 way hand shake
• Three way hand shake accomplish two things:– Both sides ready for the transmission– Both sides agree the initial sequence number
• Initial sequence number– Each machine should choose this at random– Non-random sequence has security problems
28
29
• Closing a TCP connection– TCP can close the connection in one direction
by sending a FIN packet– Once the connection is closed, TCP will not
accept more data. Data can still flow in the opposite direction.
– When both ends close the connection, the resources can be released
30
31
• The above figure only illustrates the perfect world– Timed wait period in the state machine of TCP– For emergency condition, use connection
RESET
32
• TCP Connection reset– Abnormal condition arise and we need to
break the connection.– Send a segment with RST bit set– Both sides will cut the connection and release
all the resources.– If not authenticated, can be used for attack.
33
34
• The problem of TCP connection over very high speed connection:– the Window size is too small.
35
36
• Attacks on TCP• SYN flood
– The earliest DoS attacks– Attacker sends the first SYN packet, initiates the
connection– Never bother to send the ack– The victim allocates resources and maintains the half-
open connection for a duration of time (75 sec in many systems)
– The SYN packets with spoofed IP source address
37
• The data falling out of the receiver’s window will be discarded. So guessing the current window is an important step for many attacks on TCP.– Inject invalid packet to the TCP connection– Blind reset attack
• Security of Initial Sequence Number (ISN)– The attacker wants to know what the ISN is– If on the same network, sniff the packet– Otherwise, guess the sequence number
38
• Is it hard to guess the sequence?– It is a 32 bit number– If the window size is w, you need to send
(2^32) / w packets.– If w = 16K byte, you need to send (2^32) /
(2^14) = 2^18 packet = 262K pkt– If you can send out 4K pkt/second, you will
need about 65 seconds
39
• Initial window size for various OS and the packets needed to guess the sequence number– Win 2K Sp4, Win XP Sp1: 64K Byte (66K pkt)– HP-UX11: 32K Byte (131K pkt)– Nokia IPSO, Cisco IOS 12.x, Win 2K Sp1,
Win 2K Sp3: 16K Byte (262K pkt)– Linux 2.4.28: 5.8 K byte (735K pkt)
40
• Windows 2K, Linux, and Solaris: can adjust the initial window size
41
• Guess the source port:– Every TCP connection is labeled by two pairs
of (IP, port number)– If the attack packet is not correctly labeled by
the IP and port, it will be discarded– It is not too difficult to determine 3 out of the 4
parameters:• Destination IP and port number (server side)• Source IP (this is your victim)
42
• If the ports are randomly assigned at the source side, there are thousands of possibilities.
• It will be very difficult for the attacker to correctly guess both valid window sequence and the port number: if identify sequence number needs 1 minute, now we need thousands of minutes.
• So many scan packets can be easily identified• Most connections will not last for thousands of
minutes
43
• Unfortunately, most OS allocate port numbers in order (Windows and Linux). OpenBSD starts to use random numbers since 1996.
• Several examples of relationship b/w allocated port numbers– Cisco IOS 12.x: add 1 or add 512– Windows 2000 and XP: add 1– Linux 2.4.18: add 1– Nokia IPSO: add 1
44
45
• ICMP attacks on TCP– ICMP error reporting packets contain the IP
header and first 8 bytes of the original packet– Include the source port, destination port, and
sequence number of TCP– How can we authenticate the packet– Several attacks
• Blind connection reset• Blind throughput reduction• Blind performance degrading
46
• RFC 1122 classifies the ICMP error messages into those reporting “hard errors” and “soft errors”
• ICMP has the source quench messages• RFC 1191 defines Path MTU discovery to figure
out the MTU along a path. It uses (fragment needed but DF set) to figure this out.
• ICMP for IPv6 may still be vulnerable to some attacks
47
• RFC 1122 requires that TCP must respond to ICMP error messages
• Thus, the source IP and port, and destination IP and port will be in the ICMP packet
• No authentication methods are defined
• Attacker can generate fake ICMP packets to impact TCP connections
48
• Possible solutions and their restraints– RFC 1812 says that “ICMP message should contain
as much information as possible from the original packet as long as it is not longer than 576 bytes”
– The original IP packet cannot be authenticated if we do not have the whole packet
– Authentication b/w• End nodes• End node and routers
49
• TCP should check the following fields in the original IP packet causing the ICMP message before taking action– TCP sequence number (already implemented
in Linux, OpenBSD, FreeBSD, and NetBSD)– TCP port randomization– Ingress and egress packet filtering
50
51
• Blind connection reset attack
• TCP handles ICMP error reports as follows:– If it is a hard error, abort the connection– If it is a soft error, retransmit data until
connection timeout
52
• In RFC 1122, it says– ICMP type 3 (destination unreachable), code 2
(protocol unreachable), code 3 (port unreachable), and code 4 (fragment but DF) are all hard errors
– Attacker can use these ICMP messages to reset TCP connections even when they are off path
– Some OS will extrapolate ICMP errors across TCP connections. And multiple connections can be impacted by a single ICMP packet
53
• Countermeasures– Reconsider the “hard” errors
• Type 3, code 2 (protocol unreachable) should appear during the establishment procedure. Otherwise, treated as a soft error
• Type 3, code 3 (port unreachable) should also be treated as soft errors if TCP has its own methods to handle port listening problems
• Type 3, code 4 (fragment but DF): do not set this bit unless you have already figure out the MTU on the path
• Implemented in FreeBSD, OpenBSD, NetBSD, and Linux
54
• Delay the connection reset– Delay the reset until the packet has been
received for a certain amount of time, and the data packets have been retransmitted for a certain number of times. (the idea is that if we are making progresses, there is no hard errors.)
55
56
• Blind Throughput reduction– RFC 1122 requires nodes to react to source
quench ICMP messages– Some OS will use slow start and set the size
to one segment– Now we send one packet every RTT, the
throughput is low
57
• Countermeasures– RFC 1812 shows that source quench is
ineffective to congestion– TCP has its own congestion control– Solution: ignore source quench ICMP– Linux, FreeBSD, OpenBSD, and NetBSD
adopt this since 2004 and 2005.
58
59
• Blind performance degrading attack– We can use (fragment but DF) to detect the
path MTU– Attacker can use this ICMP message to attack
TCP by sending a very small MTU value– Now the performance is impacted since the
header/data ratio changes– If the MTU is set too small, no data can be
actually sent
60
• Countermeasures– A method similar to the “delayed reset” will be
used– The MTU will change only when the packet
has been retransmitted for a certain number of times
– Implemented in OpenBSD and NetBSD since 2005