Download DoS

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
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
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
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
• 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)
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
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)
32 bits
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?
TCP Connection Management: Closing
Step 1: client end system
sends TCP FIN control
segment to server
Step 2: server receives FIN,
client
server
closing
replies with ACK. Closes
connection, sends FIN.
closing
replies with ACK.
– Enters “timed wait” - will
respond with ACK to
received FINs
Step 4: server, receives ACK.
Connection closed.
timed wait
Step 3: client receives FIN,
closed
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-RSTactive pair is also normal
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
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
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