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 Established in 1988, the CERT® Coordination Center (CERT/CC) is a center of Internet security expertise, located at the Software Engineering Institute, a federally funded research and development center operated by Carnegie Mellon University.

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 (9 out of 13) attacked on Oct 2002

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

Smurf DoS Attack gateway 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 1 ICMP Echo Req Src: Dos Target Dest: brdct addr 3 ICMP Echo Reply Dest: Dos Target gateway DoS Target DoS Source Prevention: reject external packets to brdcst address.

DDOS BadGuy Handler Handler Handler Victim Agent Agent Agent Agent Unidirectional commands Handler Handler Handler Coordinating communication Agent Agent Agent Agent Agent Agent Agent Agent Agent Agent Attack traffic Victim

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 In 4 hours, set up > 2,200 agents

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

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

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

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

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 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 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

TCP segment structure source port # dest port # application data 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F S R P A U head len not used Options (variable length) 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)

TCP Connection Management 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 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

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

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

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 server closing FIN ACK closing FIN ACK timed wait closed closed

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

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 Aborting a connection provides two features to the application: (1) any queued data is thrown away and the reset is sent immediately, and (2) the receiver of the RST can tell that the other end did an abort instead of a normal close. The API being used by the application must provide a way to generate the abort instead of a normal close. Example of RST reset. We can watch this abort sequence happen using our sock program. The sockets API provides this capability by using the "linger on close" socket option (SO_LINGER). We specify the -L option with a linger time of 0. This causes the abort to be sent when the connection is closed, instead of the normal FIN. We'll connect to a server version of our sock program on svr4 and type one line of input: bsdi % sock -LO svr4 8888 this is the client; server shown later hello, world type one line of input that's sent to other end ^D type end-of-file character to terminate client

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

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