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


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

Random Drops And Aggressive Retries

pc

B G

r

B G

c


• 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


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


• 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

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


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

clientMbpsMbps

MbpsMbps /

3

4

60

402

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?

michael walfish, mythili vutukuru, hari balakrishnan, david karger, and scott shenker presented by...

Documents

offense slide

ddos attack ddos defense

discremination ddos

overprovision ddos defense

smart bots ddos defense

expensive cost ddos

server protection of

good bad b server c