DDoS Defense by OffenseMichael Walfish∗, Mythili Vutukuru∗, Hari Balakrishnan∗, David Karger∗, and Scott Shenker†∗MIT, {mwalfish,mythili,hari,karger}@csail.mit.edu†UC Berkeley and ICSI, [email protected] paper presents the design, implementation, analysis, and ex-perimental evaluation of speak-up, a defense against application-level distributed denial-of-service (DDoS), in which attackers crip-ple a server by sending legitimate-looking requests that consumecomputational resources (e.g., CPU cycles, disk). With speak-up,a victimized server encourages all clients, resources permitting, toautomatically send higher volumes of traffic. We suppose that at-tackers are already using most of their upload bandwidth so cannotreact to the encouragement. Good clients, however, have spare up-load bandwidth and will react to the encouragement with drasticallyhigher volumes of traffic. The intended outcome of this traffic infla-tion is that the good clients crowd out the bad ones, thereby captur-ing a much larger fraction of the server’s resources than before. Weexperiment under various conditions and find that speak-up causesthe server to spend resources on a group of clients in rough pro-portion to their aggregate upload bandwidth. This result makes thedefense viable and effective for a class of real attacks.Categories and Subject Descriptors: C.2.0 [Computer-Communication Networks]: Security and protectionGeneral Terms: Design, Experimentation, SecurityKeyw ords: DoS attack, bandwidth, currency1 INTRODUCTIONOur goal is to defend servers against application-level DistributedDenial of Service (DDoS), a particularly noxious attack in whichcomputer criminals mimic legitimate client behavior by send-ing proper-looking requests via compromised and commandeeredhosts [10, 18, 36, 37]. By exploiting the fact that many Internetservers have “open clientele” (i.e., they cannot tell a good clientfrom the request alone), the attacker forces the victim server tospend much of its resources on spurious requests. For the savvyattacker, the appeal of this attack over a classic ICMP link floodis two-fold. First, it requires far less bandwidth: the victim’s com-putational resources—disks, CPUs, memory, application server li-censes, etc.—can often be depleted by proper-looking requests longbefore its access link is saturated. Second, because the attack trafficis “in-band”, it is harder to identify and thus more potent. Examplesof such (often extortionist [30,44]) attacks include using bots to at-tack Web sites by: requesting large files [36, 37], making queriesof search engines [10], and issuing computationally expensive re-quests (e.g., database queries or transactions) [21].Current DDoS defenses try to slow down the bad clients. Thoughwe stand in solidarity with these defenses in the goal of limitingPermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SIGCOMM ’06, September 11–15, 2006, Pisa, Italy.Copyright 2006 ACM 1-59593-308-5/06/0009 . . . $5.00.the service that attackers get, our approach is different. We relyon encouragement (a term made precise in §3), whereby the servercauses a client, resources permitting, to automatically send a highervolume of traffic. Our approach is to encourage all clients to speakup, rather than sit idly by while attackers drown them out. For if,as we suppose, bad clients are already using most of their uploadbandwidth, then encouragement will not change their traffic vol-ume. However, the good clients typically use only a small fractionof their available bandwidth to send requests, so they will react toencouragement by drastically increasing their traffic volume. Asgood clients send more traffic, the traffic into the server inflates,but the good clients will be much better represented in the mix andthereby capture a much larger portion of the server than before.Of course, this caricature of our approach leaves many mech-anisms unmentioned and myriad issues unaddressed. The purposeof this paper is to bring the preceding high-level description to lifewith a viable and effective system. To that end, we describe thedesign, prototype implementation, and evaluation of speak-up,adefense against application-level DDoS attacks in which clients areencouraged to send more traffic to an attacked server.We put our approach in context with the following taxonomy ofdefenses:Over-provision massively. In theory, one could purchaseenough computational resources to serve attackers and goodclients. However, anecdotal evidence suggests that while sites pro-vision additional link capacity during attacks [33], even the largestWeb sites try to conserve computation by detecting and denyingaccess to bots [30, 42] using the methods in the next category.Detect and block. These approaches try to distinguish betweengood and bad clients. Examples are profiling by IP address [5,9,27](a box in front of the server or the server itself admits requests ac-cording to a learned demand profile); rate-limiting alone (a specialcase of profiling in which the acceptable request rate is the same forall clients); CAPTCHA-based defenses [16,21,29,42,47] that pref-erentially admit humans; and capabilities [4, 50, 51] (the networkallows only traffic that the recipient has authorized). These tech-niques are powerful because they seek to block or explicitly limitunauthorized users, but their discriminations can err (see §8.1).Moreover, they cannot easily handle heterogeneous requests (i.e.,those that cause the server to do different amounts of work). Thenext category addresses these limitations.Charge all clients in a currency. Here, an attacked server givesa client service only after it pays in some currency. Examples areCPU or memory cycles (evidence of payment is the solution to acomputational puzzle) [1, 6, 7, 11, 12, 20, 25, 49] and money [25].With these defenses, there is no need to discriminate between goodand bad clients, and the server can require a client to pay morefor “hard” requests. However, for the legitimate users to capturethe bulk of the service, they must in aggregate have more of thecurrency than the