Michael Walfish, Mythili Vutukuru, Hari Balakrishnan, David Karger, and Scott Shenker Presented by...
-
Upload
collin-price -
Category
Documents
-
view
215 -
download
0
Transcript of Michael Walfish, Mythili Vutukuru, Hari Balakrishnan, David Karger, and Scott Shenker Presented by...
DDoS Defense by Offense 1
DDoS Defense By Of-fense
Michael Walfish, Mythili Vutukuru, Hari Balakrishnan, David Karger, and Scott Shenker
Presented by Sunjun Kim, Donyoung Koo
DDoS Defense by Offense 2
• Introduction– Application-level DDoS Attack– Applicability of Speak-up
• Design of Speak-up– Design approaches– Two approaches
• Implementation
• Experimental Evaluation
• Objections
• Conclusion
Outline
DDoS Defense by Offense 3
INTRODUCTION
DDoS Defense by Offense 4
• 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
Overview
DDoS Defense by Offense 5
• Purpose– For exhaustion of server’s resources– No access, just for overwhelming
• Characteristics– Cheaper– Proper-looking– Hard to identify
Application-level DDoS
DDoS Defense by Offense 6
Example Of Application-level DDoS
Good
Good
Bad
B
server
c
g
DDoS Defense by Offense 7
• Over-provision– Additional resource purchase
• Detect and Block– Profiling by IP address– CAPTCHA-based– Capabilities
• Charge in a currency– No need for discremination
Defenses of DDoS
DDoS Defense by Offense 8
• 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
Speak-up : Intuition
DDoS Defense by Offense 9
• 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”
Speak-up
DDoS Defense by Offense 10
Speak-up
Good
Good
Bad
B
server
c
thinner
DDoS Defense by Offense 11
• 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
Applicability of Speak-up
DDoS Defense by Offense 12
• 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
Conditions for Speak-up
DDoS Defense by Offense
DESIGN OF SPEAK-UP
13
DDoS Defense by Offense 14
g B
c
• 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, )
Design Model
cBG
G
)(
gG B
thinner
c
g
g B
c
DDoS Defense by Offense 15
• 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
Design Goal
gcBG
G
idcGBgc )/1(
DDoS Defense by Offense 16
• 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
Required Mechanisms
DDoS Defense by Offense 17
• Random dropping of requests to 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,
Thinner Approach I
Random Drops And Aggressive Retries
pc
B G
r
B G
c
DDoS Defense by Offense 18
• 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 =
Thinner Approach II
Explicit Payment Channel
rB G
c
DDoS Defense by Offense 19
Comparison
• Approach I
Thinner should determine
(which means, expect B,G)
Pays in-band
• Approach II
Simply select winning bid-der
Pays on a separate channel- depends on application
pc
B G
DDoS Defense by Offense 20
• Approach II cannot claim that good clients get
• Theorem – If any client transmit ε fraction of average band-
widthit can get at least ε/2 fraction of service
– Key idea : one client should spend their bandwidth to de-feat other clients, so it’s hard to win forever.
• Over-provision by factor of 2– 100% more provision than
※ 15% in evaluation
Robustness To Cheating
cBG
G
Still propor-tional!
idc
DDoS Defense by Offense 21
• 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
Heterogeneous Requests
DDoS Defense by Offense 22
Time-sharing Mechanism
Request 1
Request 2
Request 3
Server
Thinner
Request 1
Request 1
Request 1
Request 1
Request 1
Request 1
Request 1
Request 2
Request 2
Request 2
Request 2
Request 2
Request 2
Request 3
Request 3
Request 3
Request 3
Request 3
Request 3
Request 3
RESUME request 1SUSPEND request 1 RESUME request 2SUSPEND request 2 RESUME request 1RESUME request 3SUSPEND request 1 ABORT request 3SUSPENT request 3 RESUME request 1
Time-outDone
DDoS Defense by Offense 23
IMPLEMENTATIONExplicit Payment Channel
DDoS Defense by Offense 24
• 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
Specifications
DDoS Defense by Offense 25
• 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
Sequence
DDoS Defense by Offense 26
• 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
In Case Of Busy Server
DDoS Defense by Offense 27
EXPERIMENTAL EVALUATIONExplicit Payment Channel
DDoS Defense by Offense 28
• On Emulab testbed– 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)
Environment
DDoS Defense by Offense 29
Validation of Thinner’s Allocation
• Server allocation with c = 100 requests/sec
DDoS Defense by Offense 30
• In different “provisioning” regimes
Validation of Thinner’s Allocation
DDoS Defense by Offense 31
• Mean time to upload dummy bytes for good re-quests
Latency cost
DDoS Defense by Offense 32
• Average number of bytes sent on the payment channel
Byte cost
DDoS Defense by Offense 33
• Heterogeneous client bandwidth with 50 all good clients
Heterogeneous client network
DDoS Defense by Offense 34
• Two sets of heterogeneous clients RTT
Heterogeneous client network
DDoS Defense by Offense 35
• 50 Clients– 30 Clients behind bottleneck– 10 Good Clients connected to Thinner directly– 10 Bad Clients connected to Thinner directly
Experimental Topology
60Mbps
20Mbps
20Mbps
40Mbps
clientMbpsMbps
MbpsMbps /
3
4
60
402
2Mbps/client
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
• 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 proxy that “Pay bandwidth” to thinner
Bandwidth envy
DDoS Defense by Offense 40
• 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
Variable bandwidth costs
DDoS Defense by Offense 41
• Incentive to encourage botnets– In many commercial relationships
• Trust in– Regulation– Professional norms– Reputation to limit harmful conduct
Incentives for ISPs
DDoS Defense by Offense 42
• 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
Sloving the wrong problem
DDoS Defense by Offense 43
• Overload from good clients alone– Treat like application-level DDoS
• Not applicable case for low bandwidth service– Find another solution, please
Flash crowds
DDoS Defense by Offense 44
CONCLUSION
DDoS Defense by Offense 45
• 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
Speak-up summary
DDoS Defense by Offense 46
• 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 De-fense ]
– DefCOM : Distributed DDoS Defense System Combine speak-up as its rate-limiter As a result, thinner is distributed
Future Working
DDoS Defense by Offense 47
THANK YOUAny question?