1 / 55

DDoS Defense by Offense

DDoS Defense by Offense. Walfish, M., Vutukuru, M., Balakrishnan, H., Karger, D., (MIT) and Shenker, S. (UC Berkeley), SIGCOMM ’06 Presented by Ivanka Todorova for CSCE 715. Introduction Applicability Design Implementation Evaluation Concerns Conclusions Questions. Outline.

teddyr
Download Presentation

DDoS Defense by Offense

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DDoS Defense by Offense Walfish, M., Vutukuru, M., Balakrishnan, H., Karger, D., (MIT) and Shenker, S. (UC Berkeley), SIGCOMM ’06 Presented by Ivanka Todorova for CSCE 715 DDoS Defense by Offense

  2. Introduction Applicability Design Implementation Evaluation Concerns Conclusions Questions Outline DDoS Defense by Offense

  3. Introduction DDoS Defense by Offense

  4. Defense against application-level distributed denial-of service (DDoS) attacks Way of dealing with the attack as it occurs, not a prevention mechanism Overview DDoS Defense by Offense

  5. Overview • Without Speak-up • With Speak-up DDoS Defense by Offense

  6. Many Internet servers have “open clientele” Appeal over a classic ICMP link flood Requires far less bandwidth The attack is “in-band” Bots attack web sites by using computationally expensive requests Application-level DDoS? DDoS Defense by Offense

  7. Current defenses focus on slowing down/stopping the attack Good clients are crowded out in these defense systems They need a mechanism to speak up while server is under an attack Application-level DDoS DDoS Defense by Offense

  8. Over-provision massively Detect and block - disadvantages Profiling CAPTCHA-based defenses Capabilities Charge all clients in a currency Taxonomy of Defenses DDoS Defense by Offense

  9. Currency-based defense bandwidth as the currency The central mechanism is the server front-end, the thinner Thinner protects the server from overload performs encouragement in the form of a virtual auction Speak-up DDoS Defense by Offense

  10. Applicability DDoS Defense by Offense

  11. How much aggregate bandwidth does the legitimate clientele need for speak-up to be effective? How much aggregate bandwidth does the legitimate clientele need for speak-up to leave them unharmed by an attack? Couldn’t small Web sites, even if defended by speak-up, still be harmed? Because bandwidth is a communal resource, doesn’t the encouragement to send more traffic damage the network? Questions DDoS Defense by Offense

  12. Adequate link bandwidth Adequate client bandwidth Conditions to Make it Work DDoS Defense by Offense

  13. No pre-defined clientele Non-human clientele Unequal requests or spoofing or smart bots Conditions to win over other defenses DDoS Defense by Offense

  14. Design DDoS Defense by Offense

  15. Design Goal • Allocate resources to competing clients in proportion to their bandwidths • If this goal is met, modest over-provisioning is enough to satisfy good clients • Idealized server provisioning requirement DDoS Defense by Offense

  16. Limiting requests to the server to c per second Revealing the available bandwidth Proportional Allocation Required Mechanisms DDoS Defense by Offense

  17. Random Drops and Aggressive Retries Dropping requests at random to reduce the rate to c Clients send repeated retries Thinner admits incoming requests with some probability p Price for access, r, is the number of retries Variations of Speak-up DDoS Defense by Offense

  18. Variations of Speak-up • Why not enforce one outstanding retry per client? • Because of spoofing and NAT • Two cases to consider • Good clients can afford the price • Good clients cannot afford the price • They do not get service at rate g DDoS Defense by Offense

  19. Explicit Payment Channel When server is overloaded, a requesting client opens a separate payment channel A contending client sends stream of bytes on this channel Thinner tracks how many bytes each contending client sends Variations of Speak-up DDoS Defense by Offense

  20. Server notifies thinner when ready for a new request Thinner holds a virtual auction Two main differences with previous scheme Choice of scheme depends on application Variations of Speak-up DDoS Defense by Offense

  21. Robustness to Cheating • Theorem • 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 • Assumption – requests are served with perfect regularity, i.e. every 1/c seconds • True regardless of the service rate c • Theory vs. Practice DDoS Defense by Offense

  22. If all requests are treated equally, an attacker can get a disproportionate share of the server by sending only the hardest requests “Hardness” of a computation The thinner breaks time into quanta Each request is seen as comprising equal-sized chunks Heterogenous Requests DDoS Defense by Offense

  23. If a client’s request is made of x chunks, the client must win x auctions for one request The thinner extracts an on-going payment until the request completes The thinner can SUSPEND, RESUME, and ABORT requests Heterogenous Requests DDoS Defense by Offense

  24. The thinner holds a virtual auction for every quantum v is the currently active request and u is the contending request that has paid the most If u has paid more than v If v has paid more than u Time-out and ABORT any request that has been SUSPENDED for some period Heterogeneous Requests DDoS Defense by Offense

  25. Implementation DDoS Defense by Offense

  26. Any JavaScript-capable Web browser can use the system Thinner returns HTML to the client with server’s response When the server is not free, the thinner returns JavaScript to the Web client that causes it to automatically issue two HTTP requests How it Works DDoS Defense by Offense

  27. Evaluation DDoS Defense by Offense

  28. 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 If more than w requests are outstanding, the client puts the new request in a backlog queue If a request is in this queue for more than 10 seconds, it times out Setup and Method DDoS Defense by Offense

  29. This model describes the behavior of both good and bad clients Bad clients send requests faster and have concurrent requests Good client: λ=2, w=1 Bad client: λ = 40, w=20 Experiments run with 50 clients, each with 2 Mbits/s of access bandwidth (B+G=100 Mbits/s) Setup and Method DDoS Defense by Offense

  30. Validating the Thinner’s Allocation Speak-up’s Latency and Byte Cost Adversarial Advantage Heterogeneous Network Conditions Good and Bad Clients Sharing a Bottleneck Impact of Speak-up on Other Traffic Experiments DDoS Defense by Offense

  31. Validating the Thinner’s Allocation • Question 1: Do clients get service in proportion to bandwidth? • 50 clients connect to the thinner over a 100 Mbits/s LAN, each has 2 Mbits/s of bandwidth • Fraction of good clients, , varies and the server’s capacity c = 100 requests/s DDoS Defense by Offense

  32. Validating the Thinner’s Allocation DDoS Defense by Offense

  33. Validating the Thinner’s Allocation • Question 2: What happens when we vary the capacity of the server? • is the minimum value of c at which all good clients get service, if speak-up is deployed and if speak-up allocates server in proportion to bandwidth • 25 good and 25 bad clients, each with a bandwidth of 2 Mibts/s • c=50, 100, 200 DDoS Defense by Offense

  34. Validating the Thinner’s Allocation DDoS Defense by Offense

  35. Same setup as last experiment – c varies, 50 clients, G=B=50 Mbits/s Latency Cost DDoS Defense by Offense

  36. Latency Cost DDoS Defense by Offense

  37. Byte cost “Upper Bound” plots the theoretical average price, (G+B)/c Byte Cost DDoS Defense by Offense

  38. Byte Cost DDoS Defense by Offense

  39. Adversarial Advantage • Question: What is the minimum value of c at which all of the good demand is satisfied? • Experiment with the same conditions as above (G=B=50 Mbits/s; 50 clients) but for more values of c • All of the good demand is satisfied at c=115, only 15% more than • Conclusion DDoS Defense by Offense

  40. Investigate the server’s allocation for different client’s bandwidth Assign 50 clients to 5 categories 10 clients in category i (1 ≤ i≤ 5) have bandwidth 0.5i Mbits/s and connected to the thinner over a LAN All clients are good Server’s capacity c =10 requests/s Heterogeneous Network Conditions DDoS Defense by Offense

  41. Heterogeneous Network Conditions DDoS Defense by Offense

  42. Now look at effect of varied RTT Each request has at least one quiescent period, the length of which depends on the RTT Assign 50 clients to 5 categories 10 clients in category i (1 ≤ i≤ 5) have RTT = 100i ms Each have bandwidth 2 Mbits/s, and c=10 requests/s Two cases: all clients good and all clients bad Heterogeneous Network Conditions DDoS Defense by Offense

  43. Heterogeneous Network Conditions DDoS Defense by Offense

  44. 30 clients, each with a bandwidth of 2 Mbits/s, connect to the thinner through a common link l Bandwidth of l is 40 Mbits/s, clients generate 60 Mbits/s 10 good, 10 bad clients, each with bandwidth 2 Mbits/s, connect to the thinner directly through a LAN Server’s capacity c=50 requests/s Vary number of good and bad clients behind l Good and Bad Clients Sharing a Bottleneck DDoS Defense by Offense

  45. Good and Bad Clients Sharing a Bottleneck DDoS Defense by Offense

  46. The clients behind l together capture half of the server’s capacity “Bottleneck service” is the portion of the server captured by all clients behind l Good clients get less than the bandwidth-proportional allocation because bad clients “hog” l Effect on good clients more pronounced when bottleneck’s bandwidth is a smaller fraction of clients’ combined bandwidth Good and Bad Clients Sharing a Bottleneck DDoS Defense by Offense

  47. What happens when a TCP endpoint, H, shares a bottleneck link, m, with clients that are currently uploading dummy bytes? When H is a TCP sender When H is a receiver For request-response protocols like HTTP Impact of Speak-up on Other Traffic DDoS Defense by Offense

  48. Experiment with H as a receiver and investigate effects on HTTP download 10 good speak-up clients sharing a bottleneck link, m, with H, a host that runs the HTTP client wget m has a bandwidth of 1 Mbit/s and one-way delay 100 ms Each of the 11 clients has a bandwidth of 2 Mbits/s Thinner fronting a server with c=2 requests/s and a separate Web server, S Impact of Speak-up on Other Traffic DDoS Defense by Offense

  49. Impact of Speak-up on Other Traffic DDoS Defense by Offense

  50. Download times inflate considerably However, this experiment is very pessimistic: large RTTs, highly restrictive bottleneck bandwidth (20x smaller than demand), low server capacity Obviously, speak-up is the exacerbating factor but it will not have the same effect on every link Impact of Speak-up on Other Traffic DDoS Defense by Offense

More Related