Outline Definition Point-to-point network denial of service –Smurf Distributed denial of service attacks –Trin00, TFN, Stacheldraht, TFN2K TCP SYN Flooding and Detection

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 –32% respondents detected DoS attacks (1999 CSI/FBI survey) –Yahoo, Amazon, eBay and MicroSoft DDoS attacked –About 4,000 attacks per week in 2000 –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 P2P systems

Smurf DoS Attack 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. gateway DoS Source DoS Target 1 ICMP Echo Req Src: Dos Target Dest: brdct addr 3 ICMP Echo Reply Dest: Dos Target

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

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

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

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

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

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

(D)DoS Tools Over Time Point-to-point 1997 – Combined w/ multiple tools Distributed (small, C/S) Add encryption, covert channel comms, shell features, auto-update, bundled w/rootkit –trin00, Stacheldraht, TFN, TFN2K Speed ups, use of IRC for C&C Added scanning, BNC, IRC channel hopping, worms include DDoS features –Code Red (attacked –Linux “lion” worm (TFN) 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

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 SYN Flooding Attack

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 full duplex data: –bi-directional data flow in same connection –MSS: maximum segment size connection-oriented: –handshaking (exchange of control msgs) init’s sender, receiver state before data exchange flow controlled: –sender will not overwhelm receiver point-to-point: –one sender, one receiver reliable, in-order byte steam: –no “message boundaries” pipelined: –TCP congestion and flow control set window size send & receive buffers

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

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 ) 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 Handshake C S SYN C SYN S, ACK C ACK S Listening Store data Wait Connected

SYN Flooding C S SYN C1 Listening Store data SYN C2 SYN C3 SYN C4 SYN C5

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?

TCP Connection Management: Closing 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. client FIN server ACK FIN closing closed timed wait 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-RST active pair is also normal

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

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

Tools for Network Security/Vulnerability Scanner

nmap nmap is an open-source port/security scanner – It’s primary function is the discovery and mapping of hosts on a network nmap is consistently voted as one of the most used security tools

nmap functions Host Discovery – Identifying computers on a network Port Scanning – Enumerating the open ports on one or more target computers Version Detection – Interrogating listening network services –listening on remote computers to determine the application name and version number OS Detection – Remotely determining the operating system from network devices

Nessus Nessus is an open-source vulnerability scanner –Public domain software, such as Nessus, isn't always inferior and sometimes it is actually superior ! –Technical support available at tenablesecurity.com Three steps 1.Run a port-scan (using nmap) on the target host to determine which ports are open 2.Once open ports are identified, Nessus runs a set of exploits on the open ports. Nessus assumes standard processes run on standard ports (i.e., http on port 80) 3.Check for and reporting vulnerabilities

Nessus Vulnerability Checking Vulnerability checks are implemented through plugins. –Plugins are written in Nessus Attack Scripting Language (NASL), a scripting language optimized for custom network interaction. New plugins are added as vulnerabilities are discovered. Many plugins check for a vulnerability by actually exploiting the vulnerability. The ‘safe checks’ option specifies that no vulnerability check capable of crashing a remote host be used (such as DOS attacks).

Backup Slides

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) 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 –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] 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

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 IP-Proto11-Backdoor.pdf IP-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