TCP Flooding

TCP handshake C S SYN C SYN S, ACK C ACK S Listening Store data Wait Connected

TCP handshake ● What is stored at the server in the handshake? – TCP Control Block (TCB) keeps track of what the server “agreed to” ● > 280 bytes ● FlowID, timer info, Sequence number, flow control status, out-of-band data, MSS, other options agreed to – Half-open TCB entries exist until timeout – Fixed bound on half-open connections ● Resources exhausted  requests rejected

SYN Flooding C S SYN C1 Listening Store data SYN C2 SYN C3 SYN C4 SYN C5

TCP SYN flooding ● Basic problem – No client authentication of packets before resources allocated ● Attacker sends many connection requests – Spoofed source addresses – RSTs quickly generated if source address exists – No reply for non-existent sources ● Attacker exhausts TCP buffer to w/ half-open connections

TCP SYN flooding TCP Buffers Half-open connection; Waiting for ACK Completed handshake; connection open empty buffer

SYN-flood TCP Buffers Half-open connection; Waiting for ACK Completed handshake; connection open empty buffer

TCP SYN flooding counter-measures ● End host – Reduce half-open timeout value ● May deny legitimate access – Increase backlog queue ● Increase in resource usage – Disable non-essential services ● Router – Ingress filtering to prevent spoofing

TCP SYN flooding counter-measures ● Firewall – Full connection proxy ● Terminates handshake, re-establishes connection on valid 3-way handshake ● Must not be vulnerable to SYN flooding? ● Must translate each subsequent packet – Semi-transparent ● Spoofs ACKs optimistically when receiving SYN/ACK ● Subsequent (duplicate) ACK let through or RST generated if ACK not received

TCP SYN flooding counter-measures ● Active monitoring (synkill) – synkill ● keep track of source IP addresses – null (never seen), good (seen to be OK before) – new (seen, but not sure yet if spoofed) – bad (non-existent, , , , , etc.) ● Send RST packets for bad source IP addresses ● Send ACK packets for new, potentially spoofed IP addresses – degrade service if you can't tell for sure – if ACK or RST received, place in “good” – if ACK or RST not observed, reclassify IP as bad ● Reclassify periodically ● ACK/RST spoofing is a problem

TCP SYN cookies ● General idea – Client sends SYN w/ ACK number – Server responds to Client with SYN-ACK cookie ● sqn = f(src addr, src port, dest addr, dest port, rand) ● Server does not save state – Honest client responds with ACK(sqn) – Server checks response – If matches SYN-ACK, establishes connection

TCP SYN cookie ● Server's TCP SYN/ACK seqno encodes a cookie – seqno = 32-bits ● t mod 32 => counter to ensure seqno's increase every 64sec ● MSS => encoding of server MSS (can only have 8 settings) ● Cookie => easy to create and validate, hard to forge blindly t mod bits MSS 3 bits Cookie=HMAC(t, N s, SIP, SPort, DIP, DPort)

SYN-Cookies ● Modified TCP Handshake ● Example of “stateless” handshake – client ● sends SYN packet and ACK number to server ● waits for SYN-ACK from server w/ matching ACK number – server ● responds w/ SYN-ACK packet w/ initial SYN-cookie sequence number ● Sequence number is cryptographically generated value based on client address, port, and time. ● No TCP buffers are allocated – client ● sends ACK to server w/ matching sequence number – server ● If ACK is to an unopened socket, server validates returned sequence number as SYN-cookie ● If value is reasonable, a buffer is allocated and socket is opened.. Spoofed packets will not consume TCP buffers SYN ack-number SYN-ACK seq-number as SYN-cookie, ack-number NO BUFFER ALLOCATED ACK seq_number ack-number+data SYN-ACK seq-number, ack-number TCP BUFFER ALLOCATED

Status? ● Support exists in all modern operating systems ● Not turned on by default....Why? – Not sure, but it... ● May break some options such as large windows ● Assumes TCP parameters that are negotiated do not change

Cookies for the “bad guy” ● TCP SYN cookies – Used by good guy to securely keep track of valid half- open connections using constant-state at the server – Encode information in destination seqno ● Inverse TCP SYN cookies – Used by bad guy to securely keep track of valid half- open connections using constant-state at the client – Encode information in the source port/seqno – Allows for high-speed scanning