TCP Flooding

TCP handshake

C S

SYNC

SYNS, ACKC

ACKS

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

SYNC1 Listening

Store dataSYNC2

SYNC3

SYNC4

SYNC5

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

169.237.5.23168.150.241.155

169.237.7.114

TCP Buffers

Half-open connection; Waiting for

ACK

Completed handshake; connection

open

emptybuffer

SYN-flood

128.120.254.1128.120.254.2128.120.254.3128.120.254.4128.120.254.5128.120.254.6128.120.254.7128.120.254.8128.120.254.9128.120.254.10128.120.254.11128.120.254.12128.120.254.13128.120.254.14169.237.7.114128.120.254.15

TCP Buffers

Half-open connection; Waiting for

ACK

Completed handshake; connection

open

emptybuffer

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, 0.0.0.0, 127.0.0.0, 10.0.0.0, 192.168.0.0, 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 32

32 0

5 bits

MSS

3 bits

Cookie=HMAC(t, Ns, 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_numberack-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