1 / 47

DDoS Defense By Offense

DDoS Defense By Offense. Michael Walfish , Mythili Vutukuru , Hari Balakrishnan , David Karger , and Scott Shenker Presented by Sunjun Kim, Donyoung Koo. Outline. Introduction Application-level DDoS Attack Applicability of Speak-up Design of Speak-up Design approaches

newman
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 Michael Walfish, MythiliVutukuru, HariBalakrishnan, David Karger, and Scott Shenker Presented by Sunjun Kim, DonyoungKoo DDoS Defense by Offense

  2. Outline • Introduction • Application-level DDoS Attack • Applicability of Speak-up • Design of Speak-up • Design approaches • Two approaches • Implementation • Experimental Evaluation • Objections • Conclusion DDoS Defense by Offense

  3. Introduction DDoS Defense by Offense

  4. Overview • Defense against application-level DDoS • After occurrence • No prevention • Slow down attacks • For savvy attacker • Requirement of far less bandwidth • “in-band”, harder to identify & more potent • Example • Bots attacking Web sites • Requests for large files • Requests issuing computationally expensive cost DDoS Defense by Offense

  5. Application-level DDoS • Purpose • For exhaustion of server’s resources • No access, just for overwhelming • Characteristics • Cheaper • Proper-looking • Hard to identify DDoS Defense by Offense

  6. Example Of Application-level DDoS Good g Good c B server Bad DDoS Defense by Offense

  7. Defenses of DDoS • Over-provision • Additional resource purchase • Detect and Block • Profiling by IP address • CAPTCHA-based • Capabilities • Charge in a currency • No need for discremination DDoS Defense by Offense

  8. Speak-up : Intuition • Bad Clients are already exhausted • Already Full-bandwidth usage • Cannot respond to encouragement by Speak-up • Application-level DDoS attacks server resources • Not attacking network linkage • Total bandwidth may sufficient even with DDoS attack DDoS Defense by Offense

  9. Speak-up • Currency-based approach • Bandwidth for Currency • Central mechanism • Thinner, Server front-end • Thinner • Front-end to server • Protection of server from overload • Encouragement of clients • In the form of “Virtual auction” DDoS Defense by Offense

  10. Speak-up Good Good c B server Bad thinner DDoS Defense by Offense

  11. Applicability of Speak-up • How much aggregate Bandwidth by legitimate clientele? • If 90% spare capability : 1/9th than attacker • If 50% spare capability : same as attacker • For small site? (when legitimate clientele are small) • With combination of other defense mechanisms • Smaller botnets(but smarter) in the future • Possibility of damage to communal resources • Inflation only to servers under attack, very small fraction • “core”, absorption through over-provision DDoS Defense by Offense

  12. Conditions for Speak-up • Adequate Link Bandwidth for Server • To handle inflated speak-up traffic • Common deployment to be ISPs • Adequate Client Bandwidth • To be unharmed during an attack • In total, the same or more order of magnitude bandwidth • No pre-defined clientele • Non-human clientele • Unequal request, spoofing, or smart bots DDoS Defense by Offense

  13. Design of speak-up DDoS Defense by Offense

  14. Design Model • In a request-response server • Cheap for clients to issue • Expensive for server to provide • Variables for Modeling • Server capacity : c requests/sec • Demands from good clients : g requests/sec • (Max.) demands from bad clients : B requests/sec • Max. demands of good clients : G requests/sec • g << B • Server process • min( g, ) G g B thinner g g g B B c c c DDoS Defense by Offense

  15. Design Goal • Modest over-provisioning is enough for good clients • Good client demand is satisfied when • From the equation above, • If B=G, c = 2g • 50% spare capability required • If B=9*G, c=10g • 90% spare capability require DDoS Defense by Offense

  16. Required Mechanisms • Encouragement • Cause client to send more traffic • Proportional Reduction • Rate limiting • Way to limit requests to server • c requests/sec • Proportional Allocation • Admission of clients • At rates proportional to incoming bandwidth DDoS Defense by Offense

  17. Thinner Approach IRandom Drops And Aggressive Retries • Random dropping of requeststo the rate to c • Encouragement for dropped request • Immediate request for client to retry • “please-retry” signal • Taxing easier than identifying • Modification of scheme • Request pipelining • Pipe to the thinner full • Price r = 1/p • Client with affordable price, rate g as required • Client without affordable price, DDoS Defense by Offense

  18. Thinner Approach IIExplicit Payment Channel • Choosing client • Paying more price in “Payment auction” • Separate “Payment” channel • Thinner requests client to open Payment channel • Clients send congestion-controlled byte sequence to Thinner • Tracking # bytes by thinner • In virtual auction, # bytes = price • When server is available, thinner admits the winner, and terminates the payment channel. • Average price = DDoS Defense by Offense

  19. Comparison • Approach I • Approach II • Thinner should determine(which means, expect B,G) • Pays in-band • Simply select winning bidder • Pays on a separate channel- depends on application DDoS Defense by Offense

  20. Robustness To Cheating • Approach II cannot claim that good clients get • Theorem • If any client transmit ε fraction of average bandwidthit can get at least ε/2 fraction of service • Key idea : one client should spend their bandwidth to defeat other clients, so it’s hard to win forever. • Over-provision by factor of 2 • 100% more provision than ※15% in evaluation Still proportional! DDoS Defense by Offense

  21. Heterogeneous Requests • Generalization of design • More realistic case with unequal requests • Attacker may request only “Hardest” requests • Assumptions • “hardness” is counted by how long it takes to compute • Server provides an interface to Thinner SUSPEND, RESUME, and ABORT requests DDoS Defense by Offense

  22. Time-sharing Mechanism Request 1 Request 3 Request 1 Request 2 Request 3 Request 1 Request 2 Request 3 Request 1 Request 2 Request 3 Request 1 Request 2 Request 3 Request 1 Request 2 Request 3 Request 1 Request 2 Request 3 Thinner SUSPEND request 2 SUSPEND request 1 SUSPENT request 3 SUSPEND request 1 RESUME request 1 RESUME request 2 RESUME request 1 RESUME request 1 RESUME request 3 ABORT request 3 Server Request 1 Done Request 2 Time-out Request 3 DDoS Defense by Offense

  23. Explicit Payment Channel IMPLEMENTATION DDoS Defense by Offense

  24. Specifications • Running on • Linux 2.6 kernel • Exporting well-known URL • Thinner • Prototype implemented in C++ • Requested from clients • Decide when to send requests to the server • Received responses from the server, and forward to clients • Classify each client by “id” field in HTTP request DDoS Defense by Offense

  25. Sequence • Thinner’s Decision • When to send request to server • Using “Explicit Payment Channel” • Server “processes” • With “Service Time” selected randomly between 0.9/c and 1.1/c • Respond to requests • Thinner’s Return • HTML to client with server’s response DDoS Defense by Offense

  26. In Case Of Busy Server • JavaScript sent from thinner (Encouragement) • Automatically issuing two requests • One for actual request • One for 1MB HTTP POSTs • Dynamic construction by browser • Dummy data inclusion • Payment channel • Client’s win • Termination of HTTP POST request • Submission of actual request to server • Client’s lose • JavaScript from thinner • Trigger process continuation DDoS Defense by Offense

  27. Explicit Payment Channel Experimental evaluation DDoS Defense by Offense

  28. Environment • On Emulabtestbed • Python Web clients connected to Python Thinner in various topology • Requests by Poisson process • Rate λ requests/sec • Server • Processing at rate c request/sec • 50 clients • With 2 Mbits/sec each • B + G = 100 Mbits/sec • Good client : λ = 2 w = 1 • Bad client : λ = 40 w = 20 • 600-second experiments • 1451 Mbps (stdev 38Mbps) for payment bytes • 379 Mbps (stdev 24Mbps) for regular requests(both from good and bad) DDoS Defense by Offense

  29. Validation of Thinner’s Allocation • Server allocation with c = 100 requests/sec DDoS Defense by Offense

  30. Validation of Thinner’s Allocation • In different “provisioning” regimes DDoS Defense by Offense

  31. Latency cost • Mean time to upload dummy bytes for good requests DDoS Defense by Offense

  32. Byte cost • Average number of bytes sent on the payment channel DDoS Defense by Offense

  33. Heterogeneous client network • Heterogeneous client bandwidth with 50 all good clients DDoS Defense by Offense

  34. Heterogeneous client network • Two sets of heterogeneous clients RTT DDoS Defense by Offense

  35. Experimental Topology • 50 Clients • 30 Clients behind bottleneck • 10 Good Clients connected to Thinner directly • 10 Bad Clients connected to Thinner directly 2Mbps/client 20Mbps 60Mbps 40Mbps 20Mbps 2Mbps/client DDoS Defense by Offense

  36. Good & Bad clients sharing bottleneck DDoS Defense by Offense

  37. Impact of Speak-up on other traffic DDoS Defense by Offense

  38. objections DDoS Defense by Offense

  39. Bandwidth envy • Under speak-up • More good clients “better off” • High-bandwidth good clients “more better off” • Unfairness with speak-up • Only under attack • Unfortunate, but not fatal • Possible solution for ISPs • Offering low-bandwidth customer to high-bandwidth proxythat “Pay bandwidth” to thinner DDoS Defense by Offense

  40. Variable bandwidth costs • In some countries • Payment for “per-bit” • Under speak-up, more actual payment • Possible solutions • Proxies provided by ISPs • Exposition of “going rate” in bytes by thinner • Translation of rate to money and report • Up to customer whether to pay DDoS Defense by Offense

  41. Incentives for ISPs • Incentive to encourage botnets • In many commercial relationships • Trust in • Regulation • Professional norms • Reputation to limit harmful conduct DDoS Defense by Offense

  42. Sloving the wrong problem • Problem caused by bots • Isn’t this approach too mess? • Encouraging more traffic ?! • Cannot clean up whole • Even if bots are reduced by order of magnitude • Bots can still do effective attack (smart bots) • Speak-up is still useful DDoS Defense by Offense

  43. Flash crowds • Overload from good clients alone • Treat like application-level DDoS • Not applicable case for low bandwidth service • Find another solution, please DDoS Defense by Offense

  44. conclusion DDoS Defense by Offense

  45. Speak-up summary • Who needs speak-up? • Survey to find out • But we can say that, it works. • Main advantages • No need to change network elements • Only need for server modification & Thinner addition • Client also should be modified little bit • Main disadvantages • Possibility of edge network hurt • Assumptions may not hold in many cases DDoS Defense by Offense

  46. Future Working • Distributed Thinner • Problem : Thinner should aggregate all “encouraged” traffic, may results in congestion • Solution : Distribute Thinner to regulate traffic step-by-step • One approach • Paper in ICC 2008[ Combining Speak-up with DefCOM for Improved DDoS Defense ] • DefCOM : Distributed DDoS Defense System • Combine speak-up as its rate-limiter • As a result, thinner is distributed DDoS Defense by Offense

  47. Any question? Thank you DDoS Defense by Offense

More Related