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 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) 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 • DoS attacks increasing in frequency, severity and sophistication – 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 – DoS attack on major DNS providers bring Internet to morning crawl (10/21/2016) 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 Smurf DoS Attack 1 ICMP Echo Req Src: Dos Target Dest: brdct addr DoS Source 3 ICMP Echo Reply Dest: Dos Target gateway 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 Prevention: reject external packets to brdcst address. Distributed DOS Stacheldraht is a classic example of a DDoS tool. BadGuy Unidirectional commands Handler Agent Agent Agent Handler Agent Agent Handler Agent Agent Agent Coordinating communication Agent Agent Attack traffic Victim 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 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 DDoS Landscape Attack Tools Over Time binary encryption “stealth” / advanced scanning techniques Tools High 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)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 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 SYN Flooding Attack • The most classical DoS attacks • 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. RcvWindow) 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 SYNC1 SYNC2 SYNC3 SYNC4 SYNC5 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 DoS attacker – Last mile – detect DDoS attacks that first mile would miss • What metrics can capture the SYN flooding attacks? 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 • 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 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 with the one received, only establish connection if they match Backup Slides 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 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 v2, newtear, boink, bonk, frag, fucked, troll icmp, troll udp, nestea2, fusion2, peace keeper, arnudp, nos, nuclear, sping, pingodeth, smurf, smurf4, 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.R.R (where 0<=R<=255) 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 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) Single host in DDoS 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 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] 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 binary http://project.honeynet.org/reverse/results/project/020601-AnalysisIP-Proto11-Backdoor.pdf 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
