Transcript DoS

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
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.
DDOS
BadGuy
Unidirectional commands
Handler
Agent
Agent
Agent
Handler
Agent
Agent
Handler
Agent
Agent
Agent
Coordinating
communication
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
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
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
• 1998 - Distributed (small, C/S)
• 1999 - Add encryption, covert channel comms, shell
features, auto-update, bundled w/rootkit
• 2000 - Speed ups, use of IRC for C&C
• 2001 - Added scanning, BNC, IRC channel hopping
• 2002 - Added reflection attack, closed port back
door, Worms include DDoS features
• 2003 - IPv6 (back to 1996…)
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
• point-to-point:
RFCs: 793, 1122, 1323, 2018, 2581
• full duplex data:
– one sender, one receiver
– bi-directional data flow
in same connection
• reliable, in-order byte
steam:
– no “message boundaries”
• pipelined:
– MSS: maximum segment
size
• connection-oriented:
– handshaking (exchange
of control msgs) init’s
sender, receiver state
before data exchange
– TCP congestion and flow
control set window size
• send & receive buffers
socket
door
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
segment
• flow controlled:
socket
door
– sender will not
overwhelm receiver
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
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
SYN Flooding
C
S
SYNC1
SYNC2
SYNC3
SYNC4
SYNC5
Listening
Store data
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
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
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
Backup Slides
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