DDoS Defense by Offense
Michael Walfish, Mythili Vutukuru, Hari
Balakrishnan, David Karger, and Scott Shenker
Presented by:
Boris Kurktchiev and Kimberly Yonce
Overview
➲
What is a Distributed Denial of Service
attack?
●
●
●
DoS – attacker cripples a server by sending legitimate
looking requests that consume computational
resources (e.g. CPU and disk space). This type of an
attack is usually performed on the application layer.
DDoS – is the same thing as DoS but instead of
having a single point of attack the victim is bombarded
from different locations on the Internet.
Examples - Bots attacking websites by: requesting
large files, making queries of search engines, and
issuing computationally expensive requests.
Overview
Overview
➲
Speak-Up – a victimized server encourages
all clients, resources permitting, to
automatically send higher volumes of traffic.
➲
Why do we want to do this?
●
The good clients crowd out the bad ones, thereby
capturing a much larger fraction of the server's
resources than before.
The Present Situation
➲
Over-provision Massively – a company can
theoretically purchase enough computational power in
order to withstand such massive attacks. However, in
most cases they purchase large link capacity and try
to conserve computation.
● Companies are going to 3rd party providers and are
paying $12,000 and upwards a month for DDoS
protection.
● Companies such as AT&T, MCI and Prolexic absorb
the bandwidth/computational costs of a DDoS.
The Present Situation
➲
Detect and Block – this approach tries to distinguish
between good and bad clients. The techniques
employed in this category are powerful because they
seek to block or explicitly limit unauthorized users, but
their discrimination can err. For example, they cannot
handle heterogeneous requests easily.
● The three most commonly used techniques are IP
profiling, CAPTCHAs and capabilities.
The Present Situation
➲
Detect and Block
●
●
●
IP Profiling is used by Cisco to protect from distributed
denial-of-service (DDoS) attacks by performing per-flowlevel attack analysis, identification and mitigation to block
specific attack traffic.
CAPTCHA an acronym for "Completely Automated Public
Turing test to tell Computers and Humans Apart" is a type
of challenge-response test used in computing to determine
whether or not the user is human by usually using distorted
images.
A capability refers to a value that references an object
along with an associated set of access rights. A capability is
a communicable, unforgeable token of authority. A
capability is typically implemented as a privileged data
structure that consists of a section that specifies access
rights, and a section that uniquely identifies the object to be
accessed.
The Present Situation
➲
Charge all clients in a currency – here an
attacked server gives a client service only
after it pays in some currency (e.g. CPU,
memory cycles or money).
●
Speak-Up is such a service and we are going to
be discussing it exclusively for the rest of the
presentation.
Speak-Up
➲
➲
Speak-Up implements the Charge all clients in a
currency method of protection. In order to do this
Speak-Up utilizes a server front end called the Thinner.
Thinner – protects the server from overload and
performs encouragement. This is achieved by:
● Virtual auction – when the server is overloaded the
Thinner causes each new client to automatically
send a congestion controlled stream of dummy
bytes on a separate payment channel. When the
server is ready to process the request the thinner
selects the client that has sent the most bytes.
Speak-Up
Speak-Up
➲
➲
In order to achieve this Virtual Auction
Speak-Up implements the Thinner as a web
front end. The Thinner performs
encouragement by giving JavaScript to
unmodified web clients that makes them
send large HTTP POSTs. The POSTs are
the bandwidth payment used in the Virtual
Auction.
Note that Speak-Up relies on the availability
of upload bandwidth of the clients.
Speak-Up
➲
How much bandwidth does a client need in
order to be serviced?
●
Speak-up helps good clients no matter how much
bandwidth they have. It either ensures that the good
clients get all the service they need or increases the
service they get (compared to an attack without speakup), by the ratio of their available bandwidth to their
current usage, which is expected to be extremely high.
Speak-Up
➲
How much bandwidth do we need in order
to be unharmed by the attack?
●
This depends on the server's spare capacity when not
attacked. For example, if a server has 50% spare
capacity then the legitimate clients can retain full
service if they have the same aggregate bandwidth as
the attacking clients. On the other hand, if the spare
capacity is 90% then the legitimate clientèle needs
only 1/9 of the aggregate bandwidth of the attacking
clients.
Speak-Up
➲
Won't small Web sites still be harmed?
●
Yes, they will. However, the idea is that since we have
good prevention methods for defending against large
but dumb bot net attacks, the attackers will start using
smaller but smarter bot nets in order to achieve their
goals, thus making speak-up applicable for small
websites as well.
Speak-Up
➲
If we are using so much bandwidth won't we
damage the network as a whole?
●
It inflates traffic only to servers that are currently under
attack, which is a very small fraction of servers, thus
the increase in total traffic is minimal.
Speak-Up
➲
What are the minimal conditions for SpeakUp to work to our advantage?
●
●
Adequate link bandwidth – the protected service
needs enough link bandwidth to handle the incoming
request stream.
Adequate client bandwidth – the good clients must
have in total roughly the same order magnitude (or
more) bandwidth as the attacking clients.
Speak-Up
➲
What are the ideal conditions for Speak-Up?
●
●
●
No predefined clientèle – otherwise the server can
install filters or use capabilities to permit traffic only
from their clients.
Non-human clientèle – if the clientèle is exclusively
human, one can use proof of humanity tests.
Unequal requests – we can charge clients more/less
depending on the requests.
Robustness to Cheating
➲
A theorem that describes Speak-Up in
action. Note that the theorem assumes that
requests are served in a perfect regularity
pattern (i.e. every 1/c seconds):
●
In a system with regular service intervals, any client
that continuously transmits an ε fraction of the average
bandwidth received by the thinner gets at least an ε/2
fraction of the service, regardless of how the bad
clients time or divide up their bandwidth.
Robustness to Cheating
➲
In order to explain the theorem we’re going
to use the following notations:
●
●
●
●
●
➲
X = a client
t = number of auctions X must wait
k = number of auctions X wins
t1 = number of auctions that occur until X’s first win, t2
= number of auctions that occur until X’s second win,
etc.
Think of the bandwidth that X delivers for every
auction as dollars.
Thus,

k
i 1
●
ti  t
This is due to the fact that in the first auction 1 dollar is
spent to defeat it, in the next auction 2 dollars is spent
to defeat it, etc. This continues until ti-1 dollars are
spent to defeat it.
Robustness to Cheating
Therefore, 1  2    (t1  1)  t1(t1  1) / 2
dollars are spent to defeat X before it wins.
➲ Also, the total dollars spent by the other
clients over the t auctions is at least:
➲
t2
t
t2
t
i 1 2k 2  2  2k  2
k
➲
Adding the t dollars spent by X, the total
number of dollars spent is at least
t2
t

2k
2
Robustness to Cheating
➲
➲
Thus the fraction of the total spent by X,
which we called ε, is at most 2 /(t / k  1)
It follows that k / t     / 2
2
i.e. X receives at least an ε/2 fraction of the
service.
Robustness to Cheating
➲
One weakness of the theorem is that it is an
unreasonable assumption that requests are
served with perfect regularity.
●
An example of this would be if many request
fulfillments are bunched in a tiny interval during
which X has not yet paid much, bad clients can
cheaply outbid it during this interval.
Robustness to Cheating
➲
Also, the theorem assumes that a good
client pays at a constant currency rate. This
is not true.
●
●
First the payment channel is implemented in TCP
which means that the client has to accommodate
TCP's slow start before it gets a bigger chunk of
bandwidth.
Second the payments are made using a series of large
HTTP POSTs during which there is an inactive period
of time which amounts to two RTTs between the
Thinner and the client.
Robustness to Cheating
➲
The theorem can account for this behavior
due to the fact that if a good client has a
small fraction of the total bandwidth
(causing it to spend a lot of time paying),
and if the HTTP POST is big compared to
the bandwidth-delay product, then the
client's fraction of service is not noticeably
affected (because the waiting periods are
smaller than the time spent paying at full
rate).
Robustness to Cheating
➲
So why is the theorem good? We make no
assumptions about the attacker's behavior.
●
●
The fact that the theorem depends only on the total
bytes sent (in an interval) by other clients.
Also, the theorem assumes that we are dealing with
“smart” attackers, who know exactly when to send
more traffic to the auction. (e.g. When a good client's
bid is small).
Robustness to Cheating
➲
So what does this mean for us? - It means
that we have to increase the amount of
provisioning we have to do in order to be
able to absorb such “smart” behavior.
However, the amount which is required is
still far less than without the use of SpeakUp.
Setup & Implementation
➲
The Thinner is written in C++ as an OKWS
(Web server, specialized for building fast
and secure Web services) service using the
SFS toolkit (a secure, global network file
system with completely decentralized
control). All of this was run on top of a Linux
2.6 kernel bed.
Setup & Implementation
➲
When the server becomes overloaded the
Thinner starts issuing requests to the clients
using JavaScript
●
●
●
●
●
●
This causes the client to send two HTTP requests: (1) the
actual request to the server, and (2) a 1mb HTTP POST that is
dynamically constructed by the browser and holds dummy data
(the 1MB limit ensures compatibility with most browsers)
The second request is the payment channel
If the client wins the auction, request (2) is terminated and
request (1) is given to the server.
Otherwise (2) completes, thus no service is provided yet and
the Thinner continues to issue JavaScript to the browser
making it send more POSTs.
The process continues until the client wins an auction.
The Thinner correlates the client's payments with its request
via an “id” field in both HTTP requests.
Setup & Implementation
➲
➲
➲
All of the experiments are run on the
Emulab testbed (experimental network
environment of clustered PCs).
The tests were run on a 3 Ghz Xeon
processor with 2GB of RAM.
The clients used a custom Python Web
client to connect to the Thinner using
various network topology setups.
Setup & Implementation
➲
➲
➲
➲
➲
All of the experiments run for 600 seconds
All the clients are connecting from different
hosts in the Emulab environment
Each client’s requests are driven by a
Poisson process of rate λ requests/s.
A client never allows more than a
configurable number w (the window) of
outstanding requests.
This is used to model good (G) vs. bad (B)
clients.
●
Bad clients send requests faster than good clients,
and bad clients send requests concurrently. (λ=40
w=20 for bad vs. λ=2 w=1 for good)
Speak-Up in Action
➲
➲
➲
➲
The following figure shows how Speak-Up
allocates the server's resources in
proportion to its aggregate bandwidth.
There are 50 clients which are connecting to
the Thinner over a 100Mbits/s LAN.
Each client has 2 Mbits/s of bandwidth
Also the amount of good clients is changed
periodically.
Speak-Up in Action
➲
➲
➲
Server allocation when
c = 100 requests/s as
a function of G/(G+B)
where G = good and B
= bad clients
Results with using
Speak-Up turn out
close to the ideal line.
Without Speak-Up,
bad clients capture
more of the server.
Speak-Up in Action
➲
➲
The next figure investigates the different
provisioning regimes.
G (good clients) and B (bad clients) are
fixed and we measure the server's
allocation when its capacity c is <,=,> than
the minimum value of c at which all good
clients get serviced.
Speak-Up in Action
➲
➲
Server allocation to
good and bad clients
and the fraction of
good requests that are
served when SpeakUp is “OFF” or “ON”.
As c increases the
number of good
requests served also
increases with all good
requests being served
when c=200.
Speak-Up in Action
➲
➲
➲
➲
➲
The following figure shows us Speak-Up's
performance when good and bad clients
share a bottleneck link (ℓ) vs. the bandwidth
proportional ideals.
There are 30 clients, each with c = 2 Mbits/s
and they are connected through ℓ.
Where the bandwidth of ℓ = 40Mbits/s
Also, there are 10 good and 10 bad clients
that connect directly through a LAN.
The server's capacity is c = 50 requests/s
Speak-Up in Action
➲
➲
➲
“Bottleneck service”
refers to the portion of
the server captured by
all of the clients behind
ℓ.
The left bar which is the
actual break down is
worse for the good
clients than the middle
bar which shows the
bandwidth-proportional
allocation.
This is because the bad
clients hog ℓ and crowd
out the good clients.
Problems
➲
➲
The research seems to focus primarily on Web
traffic and its properties (e.g. HTTP) and does not
mention if it will be useful for any other situation or
protocol. (They do mention the availability of some
tools that allow UDP to be protected, but do not go
in depth as to whether that is true or not).
The researchers have not done a market survey,
thus all their findings are theoretical.
Problems
➲
➲
There is no good way to accommodate clientèle
(good and bad) coming from the same location.
There is extra hardware (the Thinner) that has to sit
in front of any server we want to protect by SpeakUp.
Recommendation
➲
Based on the figures shown earlier, we can
recommend Speak-Up for use by bigger
companies who can afford the extra
bandwidth capacity it requires and also,
does not have clientèle coming from the
same sources. A good example would be
Yahoo! or MSN web portals.