1. slide 1 Attacks on TCP/IP

2. slide 2 Security Issues in TCP/IP uNetwork packets pass by untrusted hosts Eavesdropping (packet sniffing) uIP addresses are public Smurf attacks uTCP connection requires state SYN flooding uTCP state is easy to guess TCP spoofing and connection hijacking

3. slide 3 network Packet Sniffing uMany applications send data unencrypted ftp, telnet send passwords in the clear uNetwork interface card (NIC) in “promiscuous mode” reads all passing data Solution: encryption (e.g., IPsec), improved routing

4. slide 4 “Smurf” Attack gateway victim 1 ICMP Echo Req Src: victim’s address Dest: broadcast address Looks like a legitimate “Are you alive?” ping request from the victim Every host on the network generates a ping (ICMP Echo Reply) to victim Stream of ping replies overwhelms victim Solution: reject external packets to broadcast addresses

5. slide 5 TCP Handshake CS SYN C SYN S, ACK C ACK S Listening… Spawn thread, store data (connection state, etc.) Wait Connected

6. slide 6 SYN Flooding Attack S SYN C1 Listening… Spawn a new thread, store connection data SYN C2 SYN C3 SYN C4 SYN C5 … and more

7. slide 7 SYN Flooding Explained uAttacker sends many connection requests with spoofed source addresses uVictim allocates resources for each request New thread, connection state maintained until timeout Fixed bound on half-open connections uOnce resources exhausted, requests from legitimate clients are denied uThis is a classic denial of service attack Common pattern: it costs nothing to TCP initiator to send a connection request, but TCP responder must spawn a thread for each request (asymmetry!)

8. slide 8 Preventing Denial of Service uDoS is caused by asymmetric state allocation If responder opens new state for each connection attempt, attacker can initiate thousands of connections from bogus or forged IP addresses uCookies ensure that the responder is stateless until initiator produced at least 2 messages Responder’s state (IP addresses and ports of the con- nection) is stored in a cookie and sent to initiator After initiator responds, cookie is regenerated and compared with the cookie returned by the initiator

9. slide 9 SYN Cookies [Bernstein and Schenk] CS SYN C Listening… Does not store state F(source addr, source port, dest addr, dest port, coarse time, server secret) SYN S, ACK C sequence # = cookie F=Rijndael or crypto hash Recompute cookie, compare with with the one received, only establish connection if they match ACK S (cookie) Compatible with standard TCP; simply a “weird” sequence number scheme More info: http://cr.yp.to/syncookies.html