DoS: Fighting Fire with Fire Michael Walfish, Hari Balakrishnan, - - PowerPoint PPT Presentation

▶
dos fighting fire with fire
SMART_READER_LITE
LIVE PREVIEW

DoS: Fighting Fire with Fire Michael Walfish, Hari Balakrishnan, - - PowerPoint PPT Presentation

Jan 23, 2024 216 likes •491 views

DoS: Fighting Fire with Fire Michael Walfish, Hari Balakrishnan, David Karger, and Scott Shenker * MIT Computer Science and AI Lab * UC Berkeley and ICSI 15 November 2005 The Scenario and the Problem Server with scarce computational

slide-1
SLIDE 1

Michael Walfish, Hari Balakrishnan, David Karger, and Scott Shenker*

15 November 2005 MIT Computer Science and AI Lab

*UC Berkeley and ICSI

DoS: Fighting Fire with Fire

slide-2
SLIDE 2

The Scenario and the Problem

good good bot server (Web, DB, etc.)

  • DDoS: many legitimate-looking requests from bots
  • Hard to differentiate bots and good clients
  • Bots not anomalous, just heavy users
  • Proofs-of-humanity (CAPTCHAs) not ideal
  • Server with scarce computational resources:
  • CPU, memory, expensive DB software, etc.

. . .

slide-3
SLIDE 3

Goal: Bots Behaving Like Good Clients

One Possibility (e.g., IP throttling, proof of work)

good good bot

Our Approach “Speed up the good clients”

. . . . . .

“Slow down the bots” For now, assume more good clients than bots

slide-4
SLIDE 4

I. Mechanism

  • II. When useful?
  • III. Compare to other defenses

Rest of the Talk

slide-5
SLIDE 5

Assumptions and Status Quo

cap. server

Assumptions

  • Each bot sends at high rate
  • More goods than bots
  • Will revisit
  • Server capacity is known
  • All requests cost server same
  • Paper relaxes this

Status Quo

slide-6
SLIDE 6

Approach in a Nutshell

cap. request

(1) Thinner (server front-end) randomly drops excess

X

thinner server server

Status Quo

slide-7
SLIDE 7

Approach in a Nutshell

cap. thinner server server

(1) Thinner (server front-end) randomly drops excess (2) Thinner asks clients to retry

request “please retry”

  • War of attrition

Status Quo

slide-8
SLIDE 8
  • War of attrition
  • Pay bandwidth to reach server: proof of net-work

Approach in a Nutshell

cap. thinner

(1) Thinner (server front-end) randomly drops excess (2) Thinner asks clients to retry

server request “please retry” server

Status Quo

slide-9
SLIDE 9
  • Thinner is HTTP front-end
  • “please retry” is automatic, zero-delay HTML refresh

Web server GET / HTTP/1.0

Net-work for Web; No Client Changes

thinner <head> <meta http-equiv=“refresh” content=0></head> GET / HTTP/1.0

slide-10
SLIDE 10

We Think This Won’t Harm the Network

  • Standpoint of total capacity:
  • Core is over-provisioned (by rumor)
  • Inflation only in traffic to attacked sites
  • Standpoint of transient congestion:
  • Application does consume more bandwidth …
  • … but controls congestion with packet conservation:

request client “please retry” thinner

X

backoff

slide-11
SLIDE 11

I. Mechanism

  • II. When useful?
  • III. Compare to other defenses

Outline

slide-12
SLIDE 12

When is Net-work Useful?

  • You might think: goods need much more b/w than bots
  • Not true!
slide-13
SLIDE 13

Net-work Levels the Playing Field

  • Net-work lets good clients capture up to
  • Is a level playing field enough?
  • To satisfy good clients, need ≥ g
  • Translates to provisioning reqt: C ≥ g(1 + B/G)

C B (attacker b/w) G (good b/w) g (legit. demand) server’s resources server’s resources Status Quo With Net-work g

( )

g + B C G

( )

G + B C G

( )C

G + B G

( )C

G + B

slide-14
SLIDE 14

Answering “When is Net-work Useful?”

  • Provisioning reqt. now g(1 + B/G); was g(1 + B/g)
  • If G >> B or G ≈ B, provisioning reqt. not terrible
  • If G << B? Likely, C < g(1 + B/G). (eg, tiny flower shop)
  • Good clients still get better ratio
  • Global abilities of bots decrease
  • These are weak answers. Is there hope?
  • Anecdotally: DDoS victims are popular sites and services
  • Not small flower shop
slide-15
SLIDE 15

I. Mechanism

  • II. When useful?
  • III. Compare to other defenses

Outline

slide-16
SLIDE 16

Net-work Uses Bandwidth as a Currency

  • Other currencies: CPU cycles, mem cycles, money
  • Price under net-work: # of retries (calc’d in paper)
  • All currency schemes: attackers still get service
  • C ≥ g(1 + B/G) applies to all
  • To do better: must tell apart legit. and bot
  • Not always feasible, as discussed on slide 1

We now compare bandwidth to other currencies . . .

slide-17
SLIDE 17

Advantages of Bandwidth as Currency

  • Price (# of retries) emerges “naturally”
  • Clients aren’t told price
  • They need not guess; just keep retrying
  • Payment is observable (puzzles can be broken)
  • Bandwidth plays a role in other currencies anyway:

client p u z z l e s

  • l

u t i

  • n

busy server “solve harder puzzle”

slide-18
SLIDE 18

Disadvantages of Bandwidth as Currency

  • Possibly undemocratic: low bandwidth clients
  • Good point
  • Some customers pay per-byte
  • But most servers aren’t attacked most of the time
slide-19
SLIDE 19

At the End of the Day

  • Is this Internet vigilantism?
  • Net-work treats bots and legitimates equally
  • Is a level playing field enough?
  • Depends
  • Is bandwidth the right way to level the playing field?
  • Possibly more undemocratic
  • More natural than other currencies
slide-20
SLIDE 20

Appendix Slides

slide-21
SLIDE 21

Thinner Needs Lots of Bandwidth

  • So much bandwidth may be expensive. Solutions?
  • Co-locate thinner?
  • Service provider or overlay? (i3, Mayday, SOS…)
  • Thinner must be uncongested

X

r e q u e s t thinner backoff client

slide-22
SLIDE 22

Why not . . .

  • . . . Proof-of-humanity (CAPTCHA)?
  • Assumes human clientele
  • Not all humans want to answer CAPTCHA [Killbots]
  • . . . IP throttling?
  • Source address spoofing for UDP requests
  • Attackers hijack IP space with bogus BGP advts.
  • NAT (many clients, lots of bandwidth; one IP addr)
  • . . . Capabilities?
  • Good point
  • These aren’t exclusive; combine them?
slide-23
SLIDE 23

How Many Retries?

  • Recall provisioning requirement: C ≥ g(1 + B/G)
  • If provisioning requirement satisfied:
  • Average number of retries is B/(C – g)
  • See paper for simple derivation
  • If provisioning requirement not satisfied:
  • Good clients spend everything, G
  • Allow probability is C/(B + G)
  • Average number of retries is (B + G)/C
slide-24
SLIDE 24

Extension

  • If request-retry loop brings unacceptable latency…
  • … thinner can explicitly calculate price, r retries
  • Price is ratio of inbound request rate to capacity
  • Thinner communicates price, r, to clients
  • Clients send r-1 retries over cong.-controlled stream
  • Still “natural”?
  • Yes.
  • Easy for thinner to calculate price
slide-25
SLIDE 25

Is Upload Bandwidth the Right Constraint?

  • What if constraint is clients’ download bandwidth?
  • Much of net-work still applies
  • Why think server’s computational resources more

expensive than its bandwidth?

  • Enterprise application licenses are expensive
  • Requests can be tiny yet cause much work (e.g.,

travel sites)

slide-26
SLIDE 26

“But Bots Won’t Control Congestion . . .”

  • Bots won’t be so polite in their malfeasance
  • True
  • But failing to back off is a link attack; exists today

request client “please retry” thinner

X

backoff

  • Recall picture: