Lecture 17 Page 1 CS 236, Spring 2008 Distributed Denial of Service (DDoS) Attacks • Goal: Prevent a network site from doing its normal business • Method: overwhelm the site with attack traffic • Response: ?
Lecture 17Page 1CS 236, Spring 2008
Distributed Denial of Service (DDoS) Attacks
• Goal: Prevent a network site from doing its normal business
• Method: overwhelm the site with attack traffic
• Response: ?
Lecture 17Page 2CS 236, Spring 2008
The Problem
Lecture 17Page 3CS 236, Spring 2008
Characterizing the Problem
• An attacker compromises many hosts– Usually spread across Internet
• He orders them to send garbage traffic to a target site
• The combined packet flow overwhelms the target– Perhaps his machine
– Perhaps his network link
– Perhaps his ISP’s network link
Lecture 17Page 4CS 236, Spring 2008
Why Are These Attacks Made?
• Generally to annoy
• Sometimes for extortion
• If directed at infrastructure, might cripple parts of Internet
– So who wants to do that . . .?
Lecture 17Page 5CS 236, Spring 2008
Attack Methods
• Pure flooding– Of network connection– Or of upstream network
• Overwhelm some other resource– SYN flood– CPU resources– Memory resources– Application level resource
• Direct or reflection
Lecture 17Page 6CS 236, Spring 2008
Why “Distributed”?
• Targets are often highly provisioned servers
• A single machine usually cannot overwhelm such a server
• So harness multiple machines to do so
• Also makes defenses harder
Lecture 17Page 7CS 236, Spring 2008
Yahoo Attack• Occurred in February 2000• Resulted in intermittent outages for
nearly three hours• Attacker caught and successfully
prosecuted• Other companies (eBay, CNN,
Microsoft) attacked in the same way at around the same time
Lecture 17Page 8CS 236, Spring 2008
DDoS Attack on DNS Root Servers
• Concerted ping flood attack on all 13 of the DNS root servers in October 2002
• Successfully halted operations on 9 of them• Lasted for 1 hour
– Turned itself off, was not defeated• Did not cause major impact on Internet
– DNS uses caching aggressively• Another (less effective) attack in February 2007
Lecture 17Page 9CS 236, Spring 2008
DDoS Attack on Estonia
• Occurred April-May 2007
• Estonia removed a statue that Russians liked
• Then somebody launched large DDoS attack on Estonian gov’t sites
• Took much of Estonia off-line for ~ 3 weeks
• Recently, DDoS attack on Radio Free Europe sites in Belarus
Lecture 17Page 10CS 236, Spring 2008
How to Defend?
• A vital characteristic:– Don’t just stop a flood– ENSURE SERVICE TO
LEGITIMATE CLIENTS!!!• If you deliver a manageable amount of
garbage, you haven’t solved the problem
Lecture 17Page 11CS 236, Spring 2008
Complicating Factors
• High availability of compromised machines– At least tens of thousands of zombie machines
out there• Internet is designed to deliver traffic
– Regardless of its value• IP spoofing allows easy hiding• Distributed nature makes legal approaches hard• Attacker can choose all aspects of his attack
packets– Can be a lot like good ones
Lecture 17Page 12CS 236, Spring 2008
Basic Defense Approaches
• Overprovisioning
• Dynamic increases in provisioning
• Hiding
• Tracking attackers
• Legal approaches
• Reducing volume of attack
Lecture 17Page 13CS 236, Spring 2008
Overprovisioning
• Be able to handle more traffic than attacker can generate
• Works pretty well for Microsoft and Google
• Not a suitable solution for Mom and Pop Internet stores
Lecture 17Page 14CS 236, Spring 2008
Dynamic Increases in Provisioning
• As attack volume increases, increase your resources
• Dynamically replicate servers
• Obtain more bandwidth
• Not always feasible
• Probably expensive
• Might be easy for attacker to outpace you
Lecture 17Page 15CS 236, Spring 2008
Hiding
• Don’t let most people know where your server is
• If they can’t find it, they can’t overwhelm it
• Possible to direct your traffic through other sites first
– Can they be overwhelmed . . .?
• Not feasible for sites that serve everyone
Lecture 17Page 16CS 236, Spring 2008
Tracking Attackers
• Almost trivial without IP spoofing• With IP spoofing, more challenging• Big issue:
– Once you’ve found them, what do you do?
• Not clear tracking actually does much good• Loads of fun for algorithmic designers,
though
Lecture 17Page 17CS 236, Spring 2008
Legal Approaches
• Sic the FBI on them and throw them in jail• Usually hard to do• FBI might not be interested in “small fry”• Slow, at best• Very hard in international situations• Generally only feasible if extortion is
involved– By following the money
Lecture 17Page 18CS 236, Spring 2008
Reducing the Volume of Traffic
• Addresses the core problem:– Too much traffic coming in, so get rid of
some of it• Vital to separate the sheep from the goats• Unless you have good discrimination
techniques, not much help• Most DDoS defense proposals are variants
of this
Lecture 17Page 19CS 236, Spring 2008
Approaches to Reducing the Volume
• Give preference to your “friends”• Require “proof of work” from
submitters• Detect difference between good and
bad traffic– Drop the bad– Easier said than done
Lecture 17Page 20CS 236, Spring 2008
Some Sample Defenses
• D-Ward
• Pushback
• DefCOM
• SOS
Lecture 17Page 21CS 236, Spring 2008
D-WARD
• Core idea is to leverage a difference between DDoS traffic and good traffic
• Good traffic responds to congestion by backing off
• DDoS traffic responds to congestion by piling on
• Look for the sites that are piling on, not backing of
Lecture 17Page 22CS 236, Spring 2008
The D-Ward Approach
• Deploy D-Ward defense boxes at exit points of networks– Use ingress filtering here to stop most spoofing
• Observe two-way traffic to different destinations• Throttle “poorly behaved” traffic• If it continues to behave badly, throttle it more• If it behaves well under throttling, back off and
give it more bandwidth
Lecture 17Page 23CS 236, Spring 2008
D-WARD in Action
requestsrepliesD-WARD
D-WARD
attacks
Lecture 17Page 24CS 236, Spring 2008
A Sample of D-Ward’s Effectiveness
Lecture 17Page 25CS 236, Spring 2008
The Problem With D-Ward• D-Ward defends other people’s networks
from your network’s DDoS attacks
• It doesn’t defend your network from other people’s DDoS attacks
• So why would anyone deploy it?
• No one did, even though, if fully deployed, it could stop DDoS attacks
Lecture 17Page 26CS 236, Spring 2008
Pushback
• Goal: Drop attack traffic to relieve congestion• Detect congestion locally
– Drop traffic from high-bandwidth aggregates• Push back the rate limits to the routers sending
those aggregates– Who will then iterate
• Rate limits pushed towards attack sites– Or other sites with high volume
Lecture 17Page 27CS 236, Spring 2008
Can Pushback Work?• Even a few core routers are able to control
high-volume attacks– But issues of partial deployment
• Only traffic for the victim is dropped• Drops affect a portion containing the attack
traffic• But will inflict collateral damage on
legitimate traffic– Traffic sharing controlled links with
attack traffic likely to be harmed
Lecture 17Page 28CS 236, Spring 2008
DefCOM
• Different network locations are better for different elements
• Near source good for characterizing traffic• Core nodes can filter effectively with small
deployments• Near target it’s easier to detect and
characterize an attack• DefCOM combines defense in all locations
Lecture 17Page 29CS 236, Spring 2008
DefCOM in Action
alert generator
classifier
classifier
corecore
DefCOM instructs core nodes to
apply rate limits
Core nodes use information from
classifiers to prioritize traffic
Classifiers can assure priority for good traffic
Lecture 17Page 30CS 236, Spring 2008
Benefits of DefCOM
• Provides effective DDoS defense
• Without ubiquitous deployment
• Able to handle higher volume attacks than target end defenses
• Offers deployment incentives for those who need to deploy things
Lecture 17Page 31CS 236, Spring 2008
DefCOM Performance
Lecture 17Page 32CS 236, Spring 2008
SOS
• A hiding approach
• Don’t let the attackers send packets to the possible target
• Use an overlay network to deliver traffic to the destination
• Filter out bad stuff in the overlay
– Which can be highly provisioned
Lecture 17Page 33CS 236, Spring 2008
How SOS Defends• Clients are authenticated at the overlay entrance• A few source addresses are allowed to reach the
protected node– All other traffic is filtered out
• Several overlay nodes designated as “approved”– Nobody else can route traffic to protected
node• Good traffic tunneled to “approved” nodes
– They forward it to the server
Lecture 17Page 34CS 236, Spring 2008
Can SOS Work?• Should successfully protect
communication with a private server:
– Access points distinguish legitimate from attack communications
– Overlay protects traffic flow
– Firewall drops attack packets
• What about attacking overlay?
– Redundancy and secrecy might help here
Lecture 17Page 35CS 236, Spring 2008
SOS Advantages and Limitations+ Ensures communication of “confirmed” user
with the victim+ Resilient to overlay node failure+ Resilient to DoS– Does not work for public service
– Clients must be aware of overlay and use it to access the victim
– Traffic routed through suboptimal path– Still allows brute force attack on links entering the
filtering router in front of client– If the attacker can find it