Application-layer DDoS Attacks: Detection and Resiliency

grrrgrapeInternet and Web Development

Oct 31, 2013 (3 years and 7 months ago)

62 views

© 2005 Hewlett
-
Packard Development Company, L.P.

The information contained herein is subject to change without notice


Application
-
layer DDoS Attacks:

Detection and Resiliency

Supranamaya Ranjan, Narus Inc.

Ram Swaminathan, HP Labs

Mustafa Uysal, HP Labs

Edward Knightly, Rice University

Introduction


Denial of service attacks: prevent legitimate users of a
service from using that service


Malicious “blockade” of a legitimate service


Increasing attack sophistication and attack resources


Botnets: worm
-
infected machines organized into a pool


Geographically distributed


Behaves as legitimate clients when not attacking


Application
-
layer DoS attacks


Attacker’s goal: consume scarce system resources


Attackers pose as legitimate clients when attacking


Attack clients send valid application requests


Servers perform unnecessary operations

Application
-
layer attacks


Request flooding attack


Attackers send requests faster than normal clients

DDoS Clients

Web/Application
Servers

Proxy
Server

Dispatcher

Database
Servers

Legitimate
Clients

Server load:


Asymmetric workload attack


Attackers send requests that cause heavy server load


Repeated one
-
shot attack


Attackers send one heavy request per session


Attack load spread around multiple sessions

This talk


Study application
-
layer attacks


Potency of attacks


(Imperfect) attack detection mechanisms


Basic detection framework


Scheduling
-
based resiliency


Attack suspicion
-
aware scheduling policies


Attack Potency


Setup: E
-
commerce test
-
bed running bookstore application


Web
-
Tier: Apache and PHP scripting


Database Tier: MySQL server


Linux
-
based platform, 2 GHz Pentium IV servers

Number of attack sessions

Avg response time of normal sessions (sec)

Normal Clients

Inter
-
session time between attack sessions (sec)

Repeated One
-
Shot Attack

Defense Methodology


DDoS
-
Shield: generic protection mechanism


Decide ‘if’ and ‘when’ to process client requests


Separate perimeter around the application (e.g., reverse proxy)


Application workload anomaly detection


Assign suspicion values to all client sessions


DDoS
-
Resilient Scheduler


Map suspicion values into distinct service levels


End
-
System

Anomaly

Detector

DDoS

Scheduler

Workload Anomaly Detection


Application layer attacks are deviations from “expected
workload”


How do you create a profile of expected workload or behavior?


How do you detect deviations from the expected behavior?


Legitimate (or normal) client profiles


Basic approach: use service history


Characterize system “good
-
put” as a function of workload


The workload characterization for our e
-
commerce
application:


New session inter
-
arrival distribution


Request inter
-
arrival distribution within a session


Request “type” distribution of a session


Request type corresponds to an application task (e.g., a script, program)


Usually each type has varying resource consumption


Workload Anomaly Detection (2)


How do you detect deviations from the expected behavior?


Assign a suspicion value to each session based on the requests
seen


Suspicion value indicates deviation from normal behavior


Basic intuition for suspicion assignment:


Zero
-
distance
: session with expected workload


no suspicion


Distance
-
Proportionality
: more deviant sessions


higher suspicion


Length
-
Proportionality
: more requests seen


higher confidence in
suspicion


We used two suspicion measures:


Kullback Leibler distance metric


Residue Factor distance metric


Attack Detection Performance


Attack sessions quickly distinguishable after about 4
-
requests


Under a repeated one
-
shot attack:


Normal clients compete with attack sessions


Once admitted, they quickly lower their suspicion value

Number of requests (n)

Attack (B
-
N
-
H
-
P
-
S)

Workload Suspicion

Number of requests (n)

Aggregate Suspicion

Normal (0.2 sec)

One
-
shot Attack (0 sec)

One
-
Shot Attack (0.1 sec)

Attack (Bestsellers)

Asymmetric Attack

Repeated One
-
Shot Attack

DDoS
-
Resilient Scheduler


Basic defense mechanism:


Maximize system “good
-
put” given the suspicion assignment


Delay or drop sessions/requests with high suspicion


Suspicion
-
aware scheduling policies


Least Suspicion First (LSF)


Proportional
-
to
-
Suspicion Share (PSS)


Rate
-
limiting, non
-
work
-
conserving scheduling


Scheduler service
-
rate (
a

requests/sec)



Anomaly Detector

DDoS
-
Resilient Scheduler

Scheduling

Policy

End
-
System

a

DDoS
-
Shield Performance

100 legitimate, 300 request
-
flooding attackers

Suspicion aware scheduling effective against attacks


Very high scheduler service rate increase attack effectiveness


Very low scheduler service rate causes low system utilization


Scheduler service
-
rate (r req/sec)

Response time of normal clients (sec)

Lower baseline (no attack)

Higher baseline (no defense)

Conclusions


Application layer attacks are feasible and potent


Request
-
flooding attack (0.1 sec


3 secs)


Asymmetric workload attack (0.1 sec


10 secs)


Repeated one
-
shot attack (0.1 sec


40 secs)



Application layer attack detection possible


Workload profiles: expected behavior as a function of “good
-
put”


Anomaly Detector: Assigns continuous measure of suspicion



Attack resilient scheduling under imperfect detection


Suspicion
-
aware, non
-
work conserving request scheduler


Improves performance down to 0.5 sec and 1.5 sec under attack