A Middleware System to Protect Against Application Level DoS Attacks - PowerPoint PPT Presentation

1 / 28
About This Presentation
Title:

A Middleware System to Protect Against Application Level DoS Attacks

Description:

A Middleware System to Protect Against Application Level DoS Attacks ... Unless app logic is embedded in DoS filter. Complex, error prone filter ... – PowerPoint PPT presentation

Number of Views:179
Avg rating:3.0/5.0
Slides: 29
Provided by: ccGa
Category:

less

Transcript and Presenter's Notes

Title: A Middleware System to Protect Against Application Level DoS Attacks


1
A Middleware System to Protect Against
Application Level DoS Attacks
  • Mudhakar Srivatsa, Arun Iyengar, Jian Yin and
    Ling Liu
  • College of Computing, Georgia Tech
  • IBM T. J. Watson Research Center

7th ACM/IFIP/USENIX Middleware, 2006
2
Outline
  • Introduction
  • State of Art
  • Defending Application Level DoS attacks
  • Evaluation
  • Summary

3
Introduction
  • DoS attacks for extortion, disabling and
    impairing competition FBI Affidavit
  • 5,000 node zombie network
  • Weaknees.com SYN flood
  • Rackspace.com HTTP image flood
  • Two weeks downtime
  • 12 million revenue

4
Application Level DoS AttacksCharacteristics
  • Mimic flash crowds
  • Emulate request syntax
  • Network level traffic analysis fails
  • Target higher level server resources
  • Disk bandwidth, database, worker processes

5
Application Level DoS AttacksProblems
  • Zombie requests indistinguishable from legitimate
    requests
  • Weakness.com HTTP image flood
  • Same request rate
  • Similar IP, TCP and HTTP headers
  • Differences in HTTP request URLs

6
Application Level DoS Attacks Problems
  • Complex multi-tiered Web Apps
  • TPCW online book store
  • HTTP request ? app logic ? DB requests
  • Non-trivial HTTP request ? DB request
  • DB query cost
  • Complex function of query arguments
  • Exhaustive search, join large DB tables

7
Application Level DoS Attacks Problems
  • Indistinguishable request headers contents
  • Hard to predict, detect and enumerate all attacks
  • Unless app logic is embedded in DoS filter
  • Complex, error prone filter
  • DoS filter is as expensive as processing the
    request !!!

8
Outline
  • Introduction
  • State of Art
  • Defending Application Level DoS attacks
  • Evaluation
  • Summary

9
State of Art
  • Preauthorization
  • Infeasible to make exhaustive client list
  • Hard to ensure all authorized clients are benign
  • Challenge mechanism
  • Computation challenge drop in goodput
  • Image challenge legitimate automated scripts

10
State of Art
  • Network Level DoS Attacks
  • IP Trace back, Ingress filtering, SYN cookies,
    stateless TCP server, cryptographic capability
    based packet marking
  • Application Level DoS Attacks
  • Not handled by network level DoS filters
  • Lack of app level semantics

11
Outline
  • Introduction
  • State of Art
  • Defending Application Level DoS attacks
  • Evaluation
  • Summary

12
Our Approach Outline
  • App level DoS Attack Invariance resource
    intensive and low utility
  • Feed back loop
  • Examine a requests resource consumption
  • Compute a requests score using its utility and
    resource consumption
  • Update clients priority using its requests
    score
  • Rate limit clients requests using its priority

13
Our Approach Benefits
  • Independent of traffic characteristics, request
    headers and contents
  • Independent of attacks precise nature of
    operation
  • Handle a priori unknown attacks
  • Resilient to adapt and attack strategies
  • All attacks variants satisfy the invariance

14
Our Approach Benefits
  • No client preauthorization
  • Client transparency
  • No changes to client software
  • No superuser privileges
  • Asymmetric protocol
  • HTTP layer (browser) on the clients
  • IP layer (firewall) filtering on the server
  • App layer priority update on the server

15
Our Approach Software Contributions
  • API for app programmers
  • Request utility measure resource utilization
  • Implementation on Linux Kernel and Microsoft
    IE/Mozilla JavaScripts
  • HTTPD Apache HTTPD web server
  • TPCW Apache Tomcat server and IBM DB2 database
    server

16
Architecture
HTTP layer
Web Server
JavaScript
Cookie TT
Tomcat Filter
Update TT
FQ Filter TT filter IP Layer
IP layer
NetFilters
tt prio, tv, HMK(cip, sip, tv, prio) prio
priority, tv time stamp,
cip client IP address,
sip server IP address
H Pseudo-Random Function, MK master key
17
Updating Client Priority
  • Benefit from processing request rq B(rq)
  • Resource consumption rc(rq)
  • Utility ut(rq)
  • B(rq) ut(rq) ? rc(rq)
  • Additive-increase and multiplicative-decrease
    strategy
  • B(rq) 0 prio ? prio a B(rq)
  • B(rq) lt 0 prio ? prio / (ß (1 B(rq)))

18
Delayed Tokens
  • Adversary behaves well and then attacks
  • Older token with higher priority
  • eprio prio e-dmax(cur_time - tt.tv - 1/r, 0)
  • cur_time current time
  • tt.tv time stamp on TT
  • 1/r average request rate from client (computed
    by fair queuing filter)

19
Implementation
  • TT as HTTP cookies (Microsoft IE/Mozilla FireFox)
  • IP layer filtering on server using NetFilters
    (Linux kernel)
  • App layer priority update Apache Tomcat filters
  • Bootstrapping using challenge server

20
Outline
  • Introduction
  • State of Art
  • Defending App Level DoS Attacks
  • Evaluation
  • Summary

21
Evaluation
  • Two applications
  • bandwidth intensive Apache HTTPD
  • database intensive web transaction processing
    benchmark TPCW
  • Measurements
  • Operational overhead
  • Resilience to DoS attacks
  • Attacks on trust tokens

22
Overhead
  • TPCW benchmark three mixes
  • Overhead of TT filter is comparable to IPSec
  • IPSec requires pre-authorization

23
Resilience to DoS attacks
  • Strategy S
  • S1 always attack
  • S2 behave good (reach a high priority level) and
    then attack
  • Attack type T
  • T1 flooding attack
  • T2 low utility request attack
  • T3 Send old TT
  • T4 Send invalid TT

24
Resilience to DoS attacks
  • Applications A
  • A1 Apache HTTPD
  • A2 TPCW (Apache Tomcat IBM DB2)
  • Attack Scenario S x T x A
  • S1_T2_A1 always attack using low utility
    request attack on Apache HTTPD
  • 16 attacks

25
S1_T1_A1
  • Detailed results in paper

26
Summary
  • Defending app level DoS attacks
  • IP layer filtering
  • Client transparency
  • API for encoding application semantics
  • Experimental evaluation 1-2 overhead
  • Resilience to DoS attacks
  • Resilience to adapt attack strategies

27
Future Work Open Problems
  • Client side NAT routers
  • HTTP Proxies
  • Bandwidth exhaustion attacks

28
  • Questions ?
  • Further clarification mudhakar_at_cc.gatech.edu
Write a Comment
User Comments (0)
About PowerShow.com