Download
1 / 25
250 likes | 456 Views
DDos Defense by Offense. Michael Walfish , Mythili Vutukuru , Hari Balakrishanan , David Karger , Scott Shankar. Introduction.
E N D
DDos Defense by Offense Michael Walfish, MythiliVutukuru, HariBalakrishanan, David Karger, Scott Shankar
Introduction • A distributed denial-of-service (DDoS) attack is one in which a multitude of compromised systems attack a single target, thereby causing denial of service for users of the targeted system. • Goal is to defend servers against application level DDos , a noxious attack in which criminals mimic legitimate client behavior by sending proper looking requests via compromised and commandeered hosts. • The attacker forces to spend much of its resources on spurious requests. • Examples of such attacks include using bots to attack website by : requesting large files ,making queries of search engines and issuing computationally expensive requests.
Taxonomy of defenses • Over-provision massively • Detect and block • Charge all clients in currency • Speak up is a currency approach with bandwidth as the currency
Applicability of speak up • 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? • Small websites, if defended by speak up, still be harmed? • Because bandwidth is in part a communal resource ,doesn’t the encouragement to send more traffic damage the network?
Applicability of speak up For the speak up to defend against the threat model , the following two conditions must hold: • Adequate link bandwidth • Adequate client bandwidth
Design of speak up • Motivated by simple observation about bad clients : they send requests to victimized servers at much higher rates than legitimate clients do.
Illustration • Imagine a request response server ,where each request is cheap for clients to issue , is expensive to serve , and consumes same quantity of server resources. • Suppose that every server has the capacity to handle c requests per second and that the aggregate demand from good clients is g requests per second , g<c • If the attackers consume all of their aggregate upload band width B and if B + g > c, then the good clients will receive only a fraction g/( g + B) of the server’s resources. • Assuming B>>g ,the bulk of the server goes to attacking clients.
Design goal and required mechanism • Design goal : with our view of bandwidth as currency , our principle goal is to allocate resources to competing clients in proportion to their bandwidths. • If the good clients make g requests per second in aggregate and have an aggregate band width of G requests per second to the server , and if the bad clients have a bandwidth of B requests per second , then the server should process good requests at a rate of min(g,G/(G+B)c)
Required mechanisms • Practical realization of speak up needs three mechanisms. • Limit requests to the server c per second. • Speak up must perform encouragement. • Given the incoming bandwidths , speak up needs a proportional allocation mechanism to admit clients at rates proportional to their delivered band width
Required Mechanisms • Encouragement can take several forms • Random drops and Aggressive retries • Explicit payment channel
Robustness to cheating • Theorem : In a system with regular service intervals , any client that continuously transmits an ε fraction of the average band width received by the thinner gets at least an ε/2 fraction of the service ,regard less of how the bad clients time or divide up their band width. • This claim remains true regard less of the service rate c, which need not be known to carry out the auction.
Revisiting assumptions • Speak up’s effect on network : Speak up would not much increase total traffic . • Inflating upload traffic to the level of download traffic would cause an inflation factor of at most two. • Only a small fraction of Internet servers is attacked at any one time.
Revisiting assumptions • Shared links • Provisioning the thinner • Attacker’s constraint
Heterogeneous requests • Generalize the design to handle the more realistic case when requests are unequal. • If a client’s request is made of x chunks , the client must win x auctions for its request to be fully served.
Experimental Evaluation • Validating the thinner’s allocation:
Conclusion • This study has sought an answer to two high level questions : • Which conditions call for speak up’s peculiar brand of protection ? • Does speak up admit a practical design ?
