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
– 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
 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 3 ICMP Echo Reply
Src: Dos Target Dest: Dos Target
Dest: brdct addr

DoS
gateway DoS
Source 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 Handler Handler Coordinating

communication

Agent Agent Agent Agent Agent Agent Agent Agent 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 Tools
scanning techniques
High
packet spoofing denial of service

sniffers distributed
attack tools
Intruder www attacks
Knowledge
automated probes/scans
GUI
back doors
disabling audits network mgmt. diagnostics
hijacking
burglaries sessions
Attack exploiting known vulnerabilities
Sophistication
password cracking

password guessing
Attackers
Low
1980 1985 1990 1995 2001
Source: CERT/CC
 (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

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

SYNC Listening

Store data
SYNS, ACKC

Wait
ACKS

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

C S

SYNC1 Listening
SYNC2
Store data
SYNC3

SYNC4

SYNC5
 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?
 TCP Connection Management: Closing
Step 1: client end system
sends TCP FIN control
client server
segment to server
closing
Step 2: server receives FIN,
FIN

replies with ACK. Closes

connection, sends FIN. ACK
closing
FIN
Step 3: client receives FIN,
replies with ACK.

timed wait
ACK

– Enters “timed wait” - will closed

respond with ACK to
received FINs
closed
Step 4: server, receives ACK.
Connection closed.
TCP Connection Messages
 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

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
 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
Listening…

Compatible with standard TCP;

Does not store state
SYNS, ACKC
simply a “weird” sequence number scheme

sequence # = cookie

F(source addr, source port, Cookie must be unforgeable

dest addr, dest port, and tamper-proof
F=Rijndael or crypto hash
coarse time, server secret) Client should not be able
to invert a cookie

ACKS(cookie) Recompute cookie,

compare with with the one
received, only establish
connection if they match

More info: http://cr.yp.to/syncookies.html

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]

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
http://project.honeynet.org/reverse/results/project/020601-Analysis-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