120 likes | 277 Views
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
E N D
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 Server load: Web/Application Servers • Request flooding attack • Attackers send requests faster than normal clients Legitimate Clients Database Servers Proxy Server Dispatcher DDoS Clients • 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
Repeated One-Shot Attack Asymmetric Request Flooding Attack Avg response time of normal sessions (sec) Request Flooding Attack Normal Clients Number of attack sessions Inter-session time between attack sessions (sec) 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
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
Asymmetric Attack Repeated One-Shot Attack Attack (Bestsellers) One-shot Attack (0 sec) Attack (B-N-H-P-S) One-Shot Attack (0.1 sec) Workload Suspicion Aggregate Suspicion Normal Normal (0.2 sec) Number of requests (n) Number of requests (n) 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
DDoS-Resilient Scheduler a Scheduling Policy End-System DDoS-Resilient Scheduler Anomaly Detector • 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 (arequests/sec)
DDoS-Shield Performance 100 legitimate, 300 request-flooding attackers Higher baseline (no defense) Response time of normal clients (sec) Fair policy: PSS LSF policy Suspicion aware scheduling effective against attacks • Very high scheduler service rate increase attack effectiveness • Very low scheduler service rate causes low system utilization Lower baseline (no attack) Scheduler service-rate (r req/sec)
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