distributed denial of service attacks cs 236 advanced computer security peter reiher may 20, 2008

Lecture 8CS 236, Spring 2008

Distributed Denial of Service AttacksCS 236

Advanced Computer Security Peter Reiher

May 20, 2008


Groups for This Week

1. Golita Behnoodi, Andrew Castner, Yu-Yuan Chen

2. Darrel Carbajal, Chia-Wei Chang, Faraz Zahabian

3. Chien-Chia Chen, Michael Cohen, Mih-Hsieh Tsai

4. Jih-Chung Fan, Zhen Huang, Nikolay Laptev

5. Vishwa Goudar, Abishek Jain, Kuo-Yen Lo

6. Michael Hall, Chen-Kuei Lee, Peter Peterson

7. Chieh-Ning Lien, Hootan Nikbakht, Peter Wu

8. Jason Liu, Sean McIntyre, Ionnis Pefkianakis


Distributed Denial of Service (DDoS) Attacks

• Goal: Prevent a network site from doing its normal business

• Method: overwhelm the site with attack traffic

• Response: ?


The Problem


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


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 . . .?


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


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


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


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


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


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


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


Basic Defense Approaches

• Overprovisioning

• Dynamic increases in provisioning

• Hiding

• Tracking attackers

• Legal approaches

• Reducing volume of attack


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


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


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


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


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


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


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


Some Sample Defenses

• D-Ward

• Pushback

• DefCOM

• SOS


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


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


D-WARD in Action

requestsrepliesD-WARD

D-WARD

attacks


A Sample of D-Ward’s Effectiveness


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


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


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


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


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


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


DefCOM Performance


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


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


36

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


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


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?


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?


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?


Basic Approach

• What is our basic testing approach?

• Set up a four machine testbed like so:

TargetRate limiter

ClassifierTraffic source


Or One Like This?

alert generator

classifier

classifier

corecore


Or One Like This?


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?


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?


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?


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?


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?


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?


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?


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?


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


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

distributed denial of service attacks cs 236 advanced computer security peter reiher may 20, 2008

Documents