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