Transcript Introduction CS 239 Security for Networks and System

Distributed Denial of Service
Attacks
CS 236
Advanced Computer Security
Peter Reiher
May 20, 2008
CS 236, Spring 2008
Lecture 8
Page 1
Groups for This Week
1.
2.
3.
4.
5.
6.
7.
8.
Golita Behnoodi, Andrew Castner, Yu-Yuan Chen
Darrel Carbajal, Chia-Wei Chang, Faraz Zahabian
Chien-Chia Chen, Michael Cohen, Mih-Hsieh Tsai
Jih-Chung Fan, Zhen Huang, Nikolay Laptev
Vishwa Goudar, Abishek Jain, Kuo-Yen Lo
Michael Hall, Chen-Kuei Lee, Peter Peterson
Chieh-Ning Lien, Hootan Nikbakht, Peter Wu
Jason Liu, Sean McIntyre, Ionnis Pefkianakis
CS 236, Spring 2008
Lecture 8
Page 2
Distributed Denial of Service
(DDoS) Attacks
• Goal: Prevent a network site from
doing its normal business
• Method: overwhelm the site with
attack traffic
• Response: ?
CS 236, Spring 2008
Lecture 8
Page 3
The Problem
CS 236, Spring 2008
Lecture 8
Page 4
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
CS 236, Spring 2008
Lecture 8
Page 5
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 . . .?
CS 236, Spring 2008
Lecture 8
Page 6
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
CS 236, Spring 2008
Lecture 8
Page 7
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
CS 236, Spring 2008
Lecture 8
Page 8
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
CS 236, Spring 2008
Lecture 8
Page 9
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
CS 236, Spring 2008
Lecture 8
Page 10
DDoS Attack on Estonia
• Occurred April-May 2007
• Estonia moved 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
CS 236, Spring 2008
Lecture 8
Page 11
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
CS 236, Spring 2008
Lecture 8
Page 12
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
CS 236, Spring 2008
Lecture 8
Page 13
Basic Defense Approaches
•
•
•
•
•
•
Overprovisioning
Dynamic increases in provisioning
Hiding
Tracking attackers
Legal approaches
Reducing volume of attack
CS 236, Spring 2008
Lecture 8
Page 14
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
CS 236, Spring 2008
Lecture 8
Page 15
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
CS 236, Spring 2008
Lecture 8
Page 16
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
CS 236, Spring 2008
Lecture 8
Page 17
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
CS 236, Spring 2008
Lecture 8
Page 18
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
CS 236, Spring 2008
Lecture 8
Page 19
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
CS 236, Spring 2008
Lecture 8
Page 20
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
CS 236, Spring 2008
Lecture 8
Page 21
Some Sample Defenses
•
•
•
•
D-Ward
Pushback
DefCOM
SOS
CS 236, Spring 2008
Lecture 8
Page 22
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
CS 236, Spring 2008
Lecture 8
Page 23
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
CS 236, Spring 2008
Lecture 8
Page 24
D-WARD in Action
D-WARD
requests
replies
attacks
D-WARD
CS 236, Spring 2008
Lecture 8
Page 25
A Sample of D-Ward’s Effectiveness
CS 236, Spring 2008
Lecture 8
Page 26
The Problem With D-Ward
• D-Ward defends other people 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
CS 236, Spring 2008
Lecture 8
Page 27
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
CS 236, Spring 2008
Lecture 8
Page 28
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 of traffic that
contains the attack traffic
• But will inflict collateral damage on
legitimate traffic
– Traffic sharing controlled links with
attack traffic likely to be harmed
CS 236, Spring 2008
Lecture 8
Page 29
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
CS 236, Spring 2008
Lecture 8
Page 30
DefCOM in Action
Classifiers can assure
priority for good traffic
DefCOM instructs
core nodes to
apply rate limits
core
core
classifier
classifier
CS 236, Spring 2008
alert
generator
Core nodes use
information from
classifiers to
prioritize traffic
Lecture 8
Page 31
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
CS 236, Spring 2008
Lecture 8
Page 32
DefCOM Performance
CS 236, Spring 2008
Lecture 8
Page 33
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
CS 236, Spring 2008
Lecture 8
Page 34
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
CS 236, Spring 2008
Lecture 8
Page 35
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
CS 236, Spring 2008
36
Lecture 8
Page 36
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
CS 236, Spring 2008
Lecture 8
Page 37
How Do We Test DDoS Defense?
• What are the core claims about each
defense?
• Which of those are least plausible or
most risky?
• How do we prioritize among many
things we could test?
CS 236, Spring 2008
Lecture 8
Page 38
Performance Questions
• How well does each defend against attacks?
• Does it damage performance of normal
traffic?
• Can it run fast enough for realistic cases?
• How much does partial deployment pattern
matter?
• Does regular traffic pattern matter?
• Does attack traffic pattern matter?
• Can the defense be used as an attack tool?
CS 236, Spring 2008
Lecture 8
Page 39
How Do We Test?
• Let’s concentrate first on the core issue
of whether the system defends
– Using DefCOM as an example
• How do we propose to test that?
CS 236, Spring 2008
Lecture 8
Page 40
Basic Approach
• What is our basic testing approach?
• Set up a four machine testbed like so:
Traffic
source
CS 236, Spring 2008
Classifier Rate Target
limiter
Lecture 8
Page 41
Or One Like This?
core
core
alert
generator
classifier
classifier
CS 236, Spring 2008
Lecture 8
Page 42
Or One Like This?
CS 236, Spring 2008
Lecture 8
Page 43
If It’s Not the Simple One . . .
•
•
•
•
•
•
What is the topology?
How many edge nodes?
Organized into how many subnets?
How many core nodes?
Connected how?
And how do we arrange the routing?
CS 236, Spring 2008
Lecture 8
Page 44
Is the Base Case Full Deployment?
• And what does that mean in terms of where
we put classifiers and filtering nodes?
• If it’s not full deployment, what is the
partial deployment pattern?
– A single pattern?
– Or treat that as a factor in experiment?
CS 236, Spring 2008
Lecture 8
Page 45
Metrics
• What metric or metric should we use to
decide if DefCOM successfully defends
against DDoS attacks?
• Utilization of the bottleneck link?
• Percentage of dropped attack packets?
• Percentage of legitimate packets delivered?
• Something else?
CS 236, Spring 2008
Lecture 8
Page 46
Workload
• Probably two components:
– Legitimate traffic
– Attack traffic
• Where do we get them from?
• If we’re not using the simple topology,
where do we apply them?
CS 236, Spring 2008
Lecture 8
Page 47
The Attack Workload
• Basically, something generating a lot of
packets
• But is there more to it?
• Do we care about kind of packets?
• Pattern of their creation?
• Contents?
– Header?
– Payload?
• Do attack dynamics change during attack?
• Which nodes generate attack packets?
CS 236, Spring 2008
Lecture 8
Page 48
The Legitimate Workload
•
•
•
•
•
What is it?
How realistic must it be?
How do we get it?
Where is it applied?
Is it responsive to what happens at the
target?
• Cross-traffic?
CS 236, Spring 2008
Lecture 8
Page 49
How Much Work Must We Do?
• Do we just define one set of conditions and test
DefCOM there?
• If not, what gets varied?
– Deployment pattern?
– Attack size in packets?
– Number of attacking nodes?
– Legitimate traffic patterns?
– Size of target’s bottleneck link?
– Accuracy of classification?
– Something else?
CS 236, Spring 2008
Lecture 8
Page 50
Generalizing
• If we get a test right for DefCOM, can
we just swap in another defense?
• Or do we need to customize the
experiment for each defense?
– To what extent?
– In what ways?
CS 236, Spring 2008
Lecture 8
Page 51
Other DDoS Research Issues
• DDoS is a largely unsolved problem
• Are there fundamentally different
approaches to solutions?
• Will small changes to existing approaches
make them work?
• Or is it motivation?
– If we cared enough, we’d deploy a
working system
CS 236, Spring 2008
Lecture 8
Page 52
One More Big Issue
• Design choices of today’s Internet favor
DDoS
– Tries to deliver all traffic
– Doesn’t verify source addresses
– Doesn’t allow receiver control
• Would the problem be easier in a
redesigned Internet?
– Always consider the redesign alternative
CS 236, Spring 2008
Lecture 8
Page 53