DDoS Defense by Offense

1
DDoS Defense by Offense

• Michael Walfish, Mythili Vutukuru, Hari
  Balakrishnan, David Karger, and Scott Shenker
• Presented by
• Boris Kurktchiev and Kimberly Yonce

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

3
Overview
4
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.

5
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 ATT, MCI and Prolexic absorb
  the bandwidth/computational costs of a DDoS.

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

7
The Present Situation

• Detect and Block
• IP Profiling is used by Cisco to protect from
  distributed denial-of-service (DDoS) attacks by
  performing per-flow-level 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.

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

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

10
Speak-Up
11
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.

12
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 speak-up), by the ratio of their
  available bandwidth to their current usage, which
  is expected to be extremely high.

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

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

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

16
Speak-Up

• What are the minimal conditions for Speak-Up 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.

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

18
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 e fraction
  of the average bandwidth received by the thinner
  gets at least an e/2 fraction of the service,
  regardless of how the bad clients time or divide
  up their bandwidth.

19
Robustness to Cheating

• In order to explain the theorem were 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 Xs
  first win, t2 number of auctions that occur
  until Xs second win, etc.
• Think of the bandwidth that X delivers for every
  auction as dollars.
• Thus,
• 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.

20
Robustness to Cheating

• Therefore,
• 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
• Adding the t dollars spent by X, the total number
  of dollars spent is at least

21
Robustness to Cheating

• Thus the fraction of the total spent by X, which
  we called e, is at most
• It follows that
• i.e. X receives at least an e/2 fraction of the
  service.

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

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

24
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).

25
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).

26
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 Speak-Up.

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

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

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

30
Setup Implementation

• All of the experiments run for 600 seconds
• All the clients are connecting from different
  hosts in the Emulab environment
• Each clients 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 w20 for bad vs. ?2 w1 for
  good)

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

32
Speak-Up in Action

• Server allocation when c 100 requests/s as a
  function of G/(GB) 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.

33
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 lt,,gt than the minimum value of c
  at which all good clients get serviced.

34
Speak-Up in Action

• Server allocation to good and bad clients and the
  fraction of good requests that are served when
  Speak-Up is OFF or ON.
• As c increases the number of good requests served
  also increases with all good requests being
  served when c200.

35
Speak-Up in Action

• The following figure shows us Speak-Up's
  performance when good and bad clients share a
  bottleneck link (l) vs. the bandwidth
  proportional ideals.
• There are 30 clients, each with c 2 Mbits/s and
  they are connected through l.
• Where the bandwidth of l 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

36
Speak-Up in Action

• Bottleneck service refers to the portion of the
  server captured by all of the clients behind l.
• 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 l and crowd
  out the good clients.

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

38
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
  Speak-Up.

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