You are on page 1of 5

3/1/12

Why Is DDoS Hard to Solve?


1.
2.
3.
4.
5.
6.
7.

A simple form of a=ack


Designed to prey on the Internets strengths
Easy availability of a=ack machines
A=ack can look like normal trac
Lack of Internet enforcement tools
Hard to get cooperaJon from others
EecJve soluJons hard to deploy

1. Simplicity Of A=ack
Basically, just send someone a lot of trac
More complicated versions can add renements, but
thats the crux of it
No need to nd new vulnerabiliJes
No need to worry about Jming, tracing, etc.
Toolkits are readily available to allow the novice to
perform DDoS
Even distributed parts are very simple

2. Preys On Internets Strengths


The Internet was designed to deliver lots of trac

From lots of places, to lots of places

DDoS a=ackers want to deliver lots of trac from


lots of places to one place
Any individual packet can look proper to the Internet
Without sophisJcated analysis, even the enJre ow
can appear proper

3. Availability Of A=ack Machines


DDoS is feasible because a=ackers can enlist many
machines
A=ackers can enlist many machines because many
machines are readily vulnerable
Not hard to nd 1,000 crackable machines on the
Internet

ParJcularly if you dont care which 1,000

Botnets numbering hundreds of thousands of hosts


have been discovered

Internet Resource UJlizaJon


Internet was not designed to monitor resource
uJlizaJon

Most of it follows rst come, rst served model

Many network services work the same way


And many key underlying mechanisms do, too
Thus, if a villain can get to the important resources
rst, he can o^en deny them to good users

Cant We Fix These VulnerabiliJes?


DDoS a=acks dont really harm the a=acking
machines
Many people dont protect their machines even
when the a=acks can harm them
Why will they start protecJng their machines just to
help others?
Altruism has not yet proven to be a compelling
argument for for network security

3/1/12

4. A=acks Resemble Normal Trac


A DDoS a=ack can consist of vast number of requests
for a web servers home page
No need for a=acker to use parJcular packets or
packet contents
So neat ltering/signature tools may not help
A=acker can be arbitrarily sophisJcated at mirroring
legiJmate trac

In principle
Not o^en done because dumb a=acks work so well

What Is the Internet Lacking?


No validaJon of IP source address
No enforcement of amount of resources used
No method of tracking a=ack ows

Or those controlling a=ack ows

No method of assigning responsibility for bad


packets or packet streams
No mechanism or tools for determining who
corrupted a machine

5. Lack Of Enforcement Tools


DDoS a=ackers have never been caught by tracing or
observing a=ack
Only by old-fashioned detecJve work

The Internet oers no help in tracing a single a=ack


stream, much less mulJple ones
Even if you trace them, a clever a=acker leaves no
clues of his idenJty on those machines

6. Poor CooperaJon In the Internet

Its hard to get anyone to help you stop or trace or


prevent an a=ack
Even your ISP might not be too cooperaJve
Anyone upstream of your ISP is less likely to be
cooperaJve

Defenses there might not work well (rewall example)

There are eecJve soluJons under research

But they require deployment near a=ackers or in the Internet


core
Or, worse, in many places

A working soluJon is useless without deployment

Hard to get anything deployed if deploying site


gets no direct advantage

ISPs more likely to cooperate with each other, though

Even if cooperaJon occurs, it occurs at human


Jmescales

7. EecJve SoluJons Hard To Deploy


The easiest place to deploy defensive systems is near
your own machine

Really, only when theyre dumb enough to boast about


their success

The a=ack might be over by the Jme you gure out who
to call

Resource LimitaJons
Dont allow an individual a=ack machine to use many
of a targets resources
Requires:

AuthenJcaJon, or
Making the sender do special work (puzzles)

AuthenJcaJon schemes are o^en expensive for the


receiver
ExisJng legiJmate senders largely not set up to
handle doing special work
Can sJll be overcome with a large enough army of
zombies

3/1/12

Hiding From the A=acker


Make it hard for anyone but legiJmate clients to
deliver messages at all
E.g., keep your machines idenJty obscure
A possible soluJon for some potenJal targets

But not for others, like public web servers

To the extent that approach relies on secrecy, its


fragile

Resource MulJplicaJon

As a=acker demands more resources, supply them


EssenJally, never allow resources to be depleted
Not always possible, usually expensive
Not clear that defender can keep ahead of the a=acker
But sJll a good step against limited a=acks
More advanced versions might use
Akamai-like techniques

Some such approaches dont require secrecy

Filtering A=ack Streams

Trace and Stop A=acks


Figure out which machines a=acks come from
Go to those machines (or near them) and stop
the a=acks
Tracing is trivial if IP source addresses arent
spoofed

Tracing may be possible even if they are spoofed

May not have ability/authority to do anything


once youve found the a=ack machines
Not too helpful if a=acker has a vast supply of
machines

Filtering Vs. Rate LimiJng

The basis for most defensive approaches


Addresses the core of the problem by limiJng the
amount of work presented to target
Key quesJon is:

In mulJple places?

Filtering drops packets with parJcular characterisJcs

If you get the characterisJcs right, you do li=le collateral


damage
At odds with the desire to drop all a=ack trac

What do you drop?

Good soluJons drop all (and only) a=ack trac


Less good soluJons drop some (or all) of everything

Where Do You Filter?


Near the
source?

In the network
core?

Rate limiJng drops packets on basis of amount of


trac

Can thus assure target is not overwhelmed


But may drop some good trac

You can combine them (drop trac for which you


are sure is suspicious, rate-limit the rest) but you
gain a li=le

Near the
target?

3/1/12

Filtering LocaJon Choices

Filtering LocaJon Choices


Near target
Near source
In core

Near target

Easier to detect a=ack


Sees everything
May be hard to prevent collateral damage
May be hard to handle a=ack volume

Near source
In core

Filtering LocaJon Choices


Near target
Near source

May be hard to detect a=ack


Doesnt see everything
Easier to prevent collateral damage
Easier to handle a=ack volume

In core

Filtering LocaJon Choices


Near target
Near source
In core

Easier to handle a=ack volume


Sees everything (with sucient deployment)
May be hard to prevent collateral damage
May be hard to detect a=ack

How Do You Detect A=acks?


Have database of a=ack signatures
Detect anomalous behavior

By measuring some parameters for a long Jme and sejng


a baseline

By dening which behavior must be obeyed starJng from


some protocol specicaJon

DetecJng when their values are abnormally high

How Do You Filter?


Devise lters that encompass most of anomalous
trac
Drop everything but give priority to legiJmate-
looking trac

It has some parameter values


It has certain behavior

3/1/12

DDoS Defense Challenges

Need for a distributed response


Economic and social factors
Lack of detailed a=ack informaJon
Lack of defense system benchmarks
Diculty of large-scale tesJng
Moving target