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

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

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

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

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

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

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

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

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

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

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

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

14. 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)

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

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

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

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

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

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

21. SYN – FIN Behavior

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

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

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

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