tcp flooding
DESCRIPTION
TCP Flooding. C. S. SYN C. Listening. Store data. SYN S , ACK C. Wait. ACK S. Connected. TCP handshake. 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 - PowerPoint PPT PresentationTRANSCRIPT
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