Outline

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

2. Objectives • Understand the concept of DoS 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)

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

4. Status • DoS attacks increasing in frequency, severity and sophistication • 32% respondents detected DoS attacks (1999 CSI/FBI survey) • August 6, 2009, several social networking sites, including Twitter, Facebook, Livejournal, and Google blogging pages were hit by DDoS 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

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

6. Smurf DoS Attack 1 ICMP Echo ReqSrc: Dos Target Dest: brdct addr 3 ICMP Echo ReplyDest: Dos 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 gateway DoSTarget DoSSource Prevention: reject external packets to brdcst address.

7. Distributed DOS Stacheldraht is a classic example of a DDoS tool. BadGuy Unidirectional commands Handler Handler Handler Coordinating communication Agent Agent Agent Agent Agent Agent Agent Agent Agent Agent Attack traffic Victim

8. Can you find source of attack? • Hard to find BadGuy • 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

9. Attack using Trin00 • 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 DDoS master agents • According to the incident report, took about 3 seconds to get root access

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

11. The DDoS Landscape

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

13. (D)DoS 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 • trin00, Stacheldraht, TFN, TFN2K • 2000 - Speed ups, use of IRC for C&C • 2001 - Added scanning, IRC channel hopping, worms include DDoS features • Code Red (attacked www.whitehouse.gov) • Linux “lion” worm (TFN) • 2002 - Added reflection attack • 2003 – IPv6 DDoS

14. Outline • Definition • Point-to-point network denial of service • Smurf • Distributed denial of service attacks • Trin00, TFN, Stacheldraht, TFN2K • TCP SYN Flooding and Detection/Defense

15. SYN Flooding Attack • 90% of DoS 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

16. Recall:TCP sender, receiver establish “connection” before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) client: connection initiator server: contacted by client 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 server allocates buffers specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data TCP Connection Management

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

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

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

20. 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!

21. 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 DoS attacker • Last mile – detect DDoS attacks that first mile would miss • What metrics can capture the SYN flooding attacks?

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

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

24. SYN – FIN Behavior

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

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

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

28. Preventing Denial of Service • DoS 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

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

30. Backup Slides

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

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

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

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

35. 1997 • Combined attacks • Targa • bonk, jolt, nestea, newtear, syndrop, teardrop, winnuke • Rape • teardrop v2, newtear, boink, bonk, frag, fucked, troll icmp, troll udp, nestea2, fusion2, peace keeper, arnudp, nos, nuclear, sping, pingodeth, smurf, smurf4, land, jolt, pepsi

36. 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.R.R(where 0<=R<=255) 1998

37. 1999 • More robust and functional tools • trin00, Stacheldraht, TFN, TFN2K • 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

38. 2000 • More floods (ip-proto-255, TCP NULL flood…) • Pre-convert IP addresses of 16,702 smurf amplifiers • Stacheldraht v1.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) • Omegav3 • Use of IRC for C&C • Knight • Kaiten • IPv6 DDoS • 4to6 (doesn’t require IPv6 support)

39. Single host in DDoS

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

41. 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 100thousand [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] Scanner[24]: [SCAN][Status: ][IP: XX.XX.XX.42][Port: 80][Found: 3580] Scanner[208]: [SCAN][Status: ][IP: XXX.XXX.XXX.156][Port: 80][Found: 3425] Scanner[65]: [SCAN][Status: ][IP: XX.XX.XXX.222][Port: 80][Found: 3959] bar: cool

42. 2002 • Distributed reflected attack tools • d7-pH-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 binaryhttp://project.honeynet.org/reverse/results/project/020601-Analysis-IP-Proto11-Backdoor.pdf

43. 2003 • Slammer worm (effectively a DDoS on local infrastructure) • Windows RPC DCOM insertion vector for “blended threat” (CERT reports “thousands”) • More IPv6 DoS (requires IPv6 this time) • ipv6fuck, icmp6fuck