Outline Definition Pointtopoint network denial of service Smurf

Outline • Definition • Point-to-point network denial of service – Smurf • Distributed denial of service attacks • TCP SYN Flooding and Detection

Objectives • Understand the concept of Do. S attacks and its current threat trends • Understand the SYN flooding attacks and be able to detect at the network level and defense them (SYN cookie)

Denial of Service Attack Definition • An explicit attempt by attackers to prevent legitimate users of a service from using that service • Threat model – taxonomy from CERT – Consumption of network connectivity and/or bandwidth – Consumption of other resources, e. g. queue, CPU – Destruction or alternation of configuration information • – Malformed packets confusing an application, cause it to freeze Physical destruction or alternation of network components

Status • Do. S attacks increasing in frequency, severity and sophistication – 32% respondents detected Do. S attacks (1999 CSI/FBI survey) – August 6, 2009, several social networking sites, including Twitter, Facebook, Livejournal, and Google blogging pages were hit by DDo. S attacks • Aimed at Georgian blogger "Cyxymu". – Internet's root DNS servers attacked on • Oct. 22, 2002, 9 out of 13 disabled for about an hour • Feb. 6, 2007, one of the servers crashed, two reportedly "suffered badly", while others saw "heavy traffic” • An apparent attempt to disable the Internet itself

Two General Classes of Attacks • Flooding Attacks – Point-to-point attacks: TCP/UDP/ICMP flooding, Smurf attacks – Distributed attacks: hierarchical structures • Corruption Attacks – Application/service specific • Eg, polluting P 2 P systems

Smurf Do. S Attack 1 ICMP Echo Req Src: Dos Target Dest: brdct addr Do. S Source 3 ICMP Echo Reply Dest: Dos Target gateway Do. S Target • Send ping request to brdcst addr (ICMP Echo Req) • Lots of responses: – Every host on target network generates a ping reply (ICMP Echo Reply) to victim – Ping reply stream can overload victim Prevention: reject external packets to brdcst address.

Distributed DOS Stacheldraht is a classic example of a DDo. S tool. Bad. Guy Unidirectional commands Handler Agent Agent Coordinating communication Agent Attack traffic Victim

Can you find source of attack? • Hard to find Bad. Guy – Originator of attack compromised the handlers – Originator not active when DDOS attack occurs • Can try to find agents – Source IP address in packets is not reliable – Need to examine traffic at many points, modify traffic, or modify routers

Attack using Trin 00 • In August 1999, network of > 2, 200 systems took University of Minnesota offline for 3 days – scan for known vulnerabilities, then attack with UDP traffic – once host compromised, script the installation of the DDo. S master agents – According to the incident report, took about 3 seconds to get root access

Targets of Attack • End hosts • Critical servers (disrupt C/S network) – Web, File, Authentication, Update – DNS • Infrastructure – Routers within org – All routers in upstream path

The DDo. S Landscape

Attack Tools Over Time binary encryption “stealth” / advanced scanning techniques High Tools denial of service packet spoofing sniffers Intruder Knowledge GUI distributed attack tools www attacks automated probes/scans back doors network mgmt. diagnostics disabling audits hijacking burglaries sessions Attack Sophistication exploiting known vulnerabilities password cracking Attackers password guessing Low 1980 Source: CERT/CC 1985 1990 1995 2001

(D)Do. S Tools Over Time • 1996 - Point-to-point • 1997 – Combined w/ multiple tools • 1998 - Distributed (small, C/S) • 1999 - Add encryption, covert channel comms, shell features, auto-update, bundled w/rootkit – trin 00, Stacheldraht, TFN 2 K • 2000 - Speed ups, use of IRC for C&C • 2001 - Added scanning, IRC channel hopping, worms include DDo. S features – Code Red (attacked www. whitehouse. gov) – Linux “lion” worm (TFN) • 2002 - Added reflection attack • 2003 – IPv 6 DDo. S

Outline • Definition • Point-to-point network denial of service – Smurf • Distributed denial of service attacks – Trin 00, TFN, Stacheldraht, TFN 2 K • TCP SYN Flooding and Detection/Defense

SYN Flooding Attack • 90% of Do. S attacks use TCP SYN floods • Streaming spoofed TCP SYNs • Takes advantage of three way handshake • Server start “half-open” connections • These build up… until queue is full and all additional requests are blocked

TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments • initialize TCP variables: – seq. #s – buffers, flow control info (e. g. Rcv. Window) Three way handshake: Step 1: client host sends TCP SYN segment to server – specifies initial seq # – no data Step 2: server host receives SYN, replies with SYNACK segment • client: connection initiator – server allocates buffers • server: contacted by client – specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data

TCP Handshake C S SYNC Listening SYNS, ACKC Store data Wait ACKS Connected

TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) source port # dest port # sequence number acknowledgement number head not UA P R S F len used checksum Receive window Urg data pnter Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept

SYN Flooding C S SYNC 1 SYNC 2 SYNC 3 SYNC 4 SYNC 5 Listening Store data

SYN Flooding Explained • Attacker sends many connection requests with spoofed source addresses • Victim allocates resources for each request – New thread, connection state maintained until timeout – Fixed bound on half-open connections • Once resources exhausted, requests from legitimate clients are denied • This 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!

Flood Detection System on Router/Gateway • Can we maintain states for each connection flow? • Stateless, simple detection system on edge (leaf) routers desired • Placement: First/last mile leaf routers – First mile – detect large Do. S attacker – Last mile – detect DDo. S attacks that first mile would miss • What metrics can capture the SYN flooding attacks?

TCP Connection Management: Closing Step 1: client end system sends TCP FIN control segment to server Step 2: server receives FIN, client closing replies with ACK. Closes connection, sends FIN. Step 4: server, receives ACK. Connection closed. closing FIN timed wait – Enters “timed wait” - will respond with ACK to received FINs FIN ACK Step 3: client receives FIN, replies with ACK. server closed ACK closed

Detection Methods (I) • Utilize SYN-FIN pair behavior • Or SYNACK – FIN • Can be both on client or server side • However, RST violates SYN-FIN behavior – Passive RST: transmitted upon arrival of a packet at a closed port (usually by servers) – Active RST: initiated by the client to abort a TCP connection (e. g. , Ctrl-D during a telnet session) • Often queued data are thrown away – So SYN-RSTactive pair is also normal

SYN – FIN Behavior

SYN – FIN Behavior • Generally every SYN has a FIN • We can’t tell if RST is active or passive • Consider 75% active

Vulnerability of SYN-FIN Detection • Send out extra FIN or RST with different IP/port as SYN • Waste half of its bandwidth

Detection Method II • SYN – SYN/ACK pair behavior • Hard to evade for the attacking source • Problems – Need to sniff both incoming and outgoing traffic – Only becomes obvious when really swamped

Preventing Denial of Service • Do. S 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 • Cookies ensure that the responder is stateless until initiator produced at least two messages – Responder’s state (IP addresses and ports of the connection) is stored in a cookie and sent to initiator – After initiator responds, cookie is regenerated and compared with the cookie returned by the initiator

SYN Cookies C S SYNC Compatible with standard TCP; simply a “weird” sequence number scheme SYNS, ACKC Listening… Does not store state sequence # = cookie Cookie must be unforgeable F(source addr, source port, and tamper-proof dest addr, dest port, F=Rijndael or crypto hash coarse time, server secret) Client should not be able to invert a cookie ACKS(cookie) More info: http: //cr. yp. to/syncookies. html Recompute cookie, compare with the one received, only establish connection if they match

Backup Slides

False Positive Possibilities • Many new online users with long-lived TCP sessions – More SYNs coming in than FINs • An overloaded server would result in 3 SYNs to a FIN or SYN-ACK – Because clients would retransmit the SYN

Source Address Validity • Spoofed Source Address – random source addresses in attack packets – Subnet Spoofed Source Address - random address from address space assigned to the agent machine’s subnet – En Route Spoofed Source Address - address spoofed en route from agent machine to victim • Valid Source Address - used when attack strategy requires several request/reply exchanges between an agent and the victim machine - target specific applications or protocol features

Attack Rate Dynamics Agent machine sends a stream of packets to the victim • Constant Rate - Attack packets generated at constant rate, usually as many as resources allow • Variable Rate – Delay or avoid detection and response – Increasing Rate - gradually increasing rate causes a slow exhaustion of the victim’s resources – Fluctuating Rate - occasionally relieving the effect - victim can experience periodic service disruptions

Up to 1996 • Point-to-point (single threaded) – SYN flood – Fragmented packet attacks – “Ping of Death” – “UDP kill”

1997 – Combined attacks • Targa – bonk, jolt, nestea, newtear, syndrop, teardrop, winnuke • Rape – teardrop v 2, newtear, boink, bonk, frag, fucked, troll icmp, troll udp, nestea 2, fusion 2, peace keeper, arnudp, nos, nuclear, sping, pingodeth, smurf 4, land, jolt, pepsi

1998 • fapi (May 1998) – UDP, TCP (SYN and ACK), ICMP Echo, "Smurf" extension – Runs on Windows and Unix – UDP comms – One client spoofs src, the other does not – Built-in shell feature – Not designed for large networks (<10) – Not easy to setup/control network • fuck_them (ADM Crew, June 1998) – Agent written in C; Handler is a shell script – ICMP Echo Reply flooder – Control traffic uses UDP – Can randomize source to R. R (where 0<=R<=255)

1999 • More robust and functional tools – trin 00, Stacheldraht, TFN 2 K • Multiple attacks (TCP SYN flood, TCP ACK flood, UDP flood, ICMP flood, Smurf…) • Added encryption to C&C • Covert channel • Shell features common • Auto-update

2000 • More floods (ip-proto-255, TCP NULL flood…) • Pre-convert IP addresses of 16, 702 smurf amplifiers – Stacheldraht v 1. 666 • Bundled into rootkits (tornkit includes stacheldraht) http: //www. cert. org/incident_notes/IN-2000 -10. html • Full control (multiple users, by nick, with talk and stats) – Omegav 3 • Use of IRC for C&C – Knight – Kaiten • IPv 6 DDo. S – 4 to 6 (doesn’t require IPv 6 support)

Single host in DDo. S

2001 • Worms include DDo. S features – Code Red (attacked www. whitehouse. gov) – Linux “lion” worm (TFN) • Added scanning, BNC, IRC channel hopping (“Blended threats” term coined in 1999 by Aus. CERT) – “Power” bot – Modified “Kaiten” bot • Include time synchronization (? !!) – Leaves worm

Power bot foo: oh damn, its gonna own shitloads foo: on start of the script it will erase everything that it has foo: then scan over foo: they only reboot every few weeks anyways foo: and it will take them 24 hours to scan the whole ip range foo: !scan status Scanner[24]: [SCAN][Status: ][IP: XX. X. XX. 108][Port: 80][Found: 319] Scanner[208]: [SCAN][Status: ][IP: XXX. X. XXX. 86][Port: 80][Found: 320]. . . foo: almost 1000 and we aren't even close foo: we are gonna own more than we thought foo: i bet 100 thousand [11 hours later] Scanner[129]: [SCAN][Status: ][IP: XXX. X. XXX. 195][Port: 80][Found: 34] Scanner[128]: [SCAN][Status: ][IP: XXX. X. XXX. 228][Port: 80][Found: 67]

2002 • Distributed reflected attack tools – d 7 -p. H-orgasm – drdos (reflects NBT, TCP SYN : 80, ICMP) • Reflected DNS attacks, steathly (NVP protocol) and encoded covert channel comms, closed port back door – Honeynet Project Reverse Challenge binary http: //project. honeynet. org/reverse/results/project/020601 -Analysis. IP-Proto 11 -Backdoor. pdf

2003 • Slammer worm (effectively a DDo. S on local infrastructure) • Windows RPC DCOM insertion vector for “blended threat” (CERT reports “thousands”) • More IPv 6 Do. S (requires IPv 6 this time) – ipv 6 fuck, icmp 6 fuck