1 / 15

TCP SYN Flooding & Countermeasures

Learn about TCP SYN flooding attacks, server handshake data, half-open connections, and effective countermeasures to safeguard against such cyber threats.

jmccarver
Download Presentation

TCP SYN Flooding & Countermeasures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP Flooding

  2. C S SYNC Listening Store data SYNS, ACKC Wait ACKS Connected TCP handshake

  3. 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

  4. C S SYNC1 Listening SYNC2 Store data SYNC3 SYNC4 SYNC5 SYN Flooding

  5. 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

  6. Half-open connection; Waiting for ACK Completed handshake; connection open empty buffer TCP SYN flooding TCP Buffers 169.237.5.23 168.150.241.155 169.237.7.114

  7. Half-open connection; Waiting for ACK Completed handshake; connection open empty buffer SYN-flood TCP Buffers 128.120.254.1 128.120.254.2 128.120.254.3 128.120.254.4 128.120.254.5 128.120.254.6 128.120.254.7 128.120.254.8 128.120.254.9 128.120.254.10 128.120.254.11 128.120.254.12 128.120.254.13 128.120.254.14 169.237.7.114 128.120.254.15

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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 32 0 t mod 32 MSS Cookie=HMAC(t, Ns, SIP, SPort, DIP, DPort) 5 bits 3 bits

  13. SYN-Cookies SYN ack-number • 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 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

  14. 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

  15. 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

More Related