outline definition point-to-point network denial of service – smurf distributed denial of service...
TRANSCRIPT
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
• 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.
gatewayDoSSource
DoSTarget
1 ICMP Echo ReqSrc: Dos TargetDest: brdct addr
3 ICMP Echo ReplyDest: Dos Target
Distributed DOS
Handler
Agent Agent Agent Agent Agent Agent AgentAgent Agent Agent
Victim
Unidirectional commands
Attack traffic
Coordinating communication
BadGuy
Handler Handler
Stacheldraht is a classic example of a DDoS tool.
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
High
Low
1980 1985 1990 1995 2001
password guessing
password cracking
exploiting known vulnerabilities
disabling audits
back doors
hijacking sessions
sniffers
packet spoofing
GUIautomated probes/scans
denial of service
www attacks
Tools
Attackers
IntruderKnowledge
AttackSophistication
“stealth” / advanced scanning techniques
burglaries
network mgmt. diagnostics
distributedattack tools
binary encryption
Source: CERT/CC
Attack Tools Over Time
(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
• 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
SYN Flooding Attack
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 segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence numberacknowledgement numberReceive window
Urg data pnterchecksum
FSRPAUheadlen
notused
Options (variable length)
URG: urgent data (generally not used)
ACK: ACK #valid
PSH: push data now(generally not used)
RST, SYN, FIN:connection estab(setup, teardown
commands)
# bytes rcvr willingto accept
countingby bytes of data(not segments!)
Internetchecksum
(as in UDP)
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, 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
FIN
server
ACK
ACK
FIN
closing
closing
closedti
med w
ait
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• 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 CookiesC S
SYNC Listening…
Does not store state
F(source addr, source port, dest addr, dest port, coarse time, server secret)
SYNS, ACKC
sequence # = cookie
Cookie must be unforgeable and tamper-proofClient should not be able to invert a cookie
F=Rijndael or crypto hash
Recompute cookie, compare with with the onereceived, only establish connection if they match
ACKS(cookie)
Compatible with standard TCP;simply a “weird” sequence number scheme
More info: http://cr.yp.to/syncookies.html
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 DynamicsAgent 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)
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 binaryhttp://project.honeynet.org/reverse/results/project/020601-Analysis-IP-Proto11-Backdoor.pdf