ddos defense by offense

DDoS Defense by Offense 1

DDoS Defense By Of -fenseMichael Walfish, Mythili Vutukuru, Hari Balakrishnan,

David Karger, and Scott Shenker

Presented by Sunjun Kim, Donyoung Koo


• Introduction– Application-level DDoS Attack– Applicability of Speak-up

• Design of Speak-up– Design approaches– Two approaches

• Implementation

• Experimental Evaluation

• Objections

• Conclusion

Outline


INTRODUCTION


• 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


• Purpose– For exhaustion of server’s resources– No access, just for overwhelming

• Characteristics– Cheaper– Proper-looking– Hard to identify

Application-level DDoS


Example Of Application-level DDoS

Good

Good

Bad

B

server

c

g


• 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


• 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


• 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


Speak-up

Good

Good

Bad

B

server

c

thinner


• 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


• 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


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


• 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(


• 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


• 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 IRandom Drops And Aggressive Retries

p cB G

r B Gc


• 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 IIExplicit Payment Channel

r B Gc


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

p cB G


• 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


• 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


Time-sharing Mechanism

Request 1

Request 2

Request 3

Server

ThinnerRequest 1Request 1Request 1Request 1Request 1Request 1Request 1

Request 2Request 2Request 2Request 2Request 2Request 2

Request 3Request 3Request 3Request 3Request 3Request 3Request 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


IMPLEMENTATIONExplicit Payment Channel


• 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


• 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


• 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


EXPERIMENTAL EVALUATIONExplicit Payment Channel


• 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


Validation of Thinner’s Allocation

• Server allocation with c = 100 requests/sec


• In different “provisioning” regimes

Validation of Thinner’s Allocation


• Mean time to upload dummy bytes for good re-quests

Latency cost


• Average number of bytes sent on the payment channel

Byte cost


• Heterogeneous client bandwidth with 50 all good clients

Heterogeneous client network


• Two sets of heterogeneous clients RTT

Heterogeneous client network


• 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

clientMbpsMbpsMbpsMbps /

34

60402

2Mbps/client

2Mbps/client


Good & Bad clients sharing bottleneck


Impact of Speak-up on other traffic


OBJECTIONS


• 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


• 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


• Incentive to encourage botnets– In many commercial relationships

• Trust in– Regulation– Professional norms– Reputation to limit harmful conduct

Incentives for ISPs


• 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


• Overload from good clients alone– Treat like application-level DDoS

• Not applicable case for low bandwidth service– Find another solution, please

Flash crowds


CONCLUSION


• 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


• 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


THANK YOUAny question?

ddos defense by offense

Documents