Tolerating Denial of Service Attacks A System Approach

1
Tolerating Denial of Service Attacks A System
Approach

• Ju Wang
• CSAG UCSD

2
Outline

• Introduction
• Problem Description
• Current Approaches
• Proposed Solution
• Summary

3
Application Context

• Large scale Open model applications ? focus of
  this study
• Attributes
• Accessible to everyone in the Internet
• Weak user identity
• No strong user authentication
• Everyone has a fair chance of using the
  application service
• Fits well to a lot of applications and widely
  used today (many web applications follow this
  model)
• E-commence, search engines, news, digital
  libraries, stock report
• Applications not of our focus
• Require user identity (tied to pricing model for
  example)
• Only accessible to a group of users (others
  cannot access it)
• Only have a small number of users
• These applications share some common problems
  with the applications in study, so some of our
  solutions may apply. But they are not our focus.

4
Distributed Environment Context

• Internet infrastructure today
• Does not provide authenticated source address
• NAT addresses and firewalls widely used
• Does not universally support quality of service
  (network level and application level)
• Possible to compromise a number of hosts in the
  Internet in a short period of time (one day for
  example).
• software bugs, mis-configuration, and so on
• Role of IPv6
• Addresses the first issue
• May stop and deter some attacks.
• But DoS problem still exists with IPv6
• Not widely deployed today and it is not clear
  whether it will happen in the near future.

5
Problem Description

• Open applications are vulnerable to Denial of
  Service attacks
• Infrastructure level attacks
• Attacker abuses the hosting infrastructure of the
  application to cause DoS (flooding traffic,
  exploiting vulnerability and so on)
• Application level attacks
• Attacker abuses the application itself to cause
  DoS (sending excessive amount of requests at high
  rate)
• Problem to solve
• Tolerate Denial of Service attacks on large scale
  open applications

6
Importance of the problem

• Large application domain
• There are many open applications today and they
  are vulnerable to both types of DoS attacks
• There are many other applications vulnerable to
  infrastructure level DoS attacks sharing same
  properties.
• DoS attacks have been one of the major security
  threats
• Economic impact (DoS on E-commerce application)
• Political impact (DoS on government sites)
• Inconvenience to everyday life (unable to get
  important information)
• There have been no solutions for these DoS attacks

7
Solution Criteria Correctness

• Application correctness must be maintained
• Open model property must be maintained
• Both SCC1 and SCC2 must be met for any solution.

8
Solution Metrics Effectiveness

• For a given number of attackers (compromised
  hosts), and a given type of DoS attack
  (infrastructure or application level), at least
  one of the following criteria must be met.
• Containment
• Temporal attackers impact only last for a short
  interval
• Spatial only users near attackers may be
  affected
• Mitigation
• For any user, attackers impact is mitigated, so
  that users always have access to the application
• Elimination
• Reduce the possibility of DoS attacks
• Attackers do not have enough information required
  for attack.

9
How Distributed DoS Attacks Work?
Legitimate Users
Application
Attacker
compromise hosts in the Internet
DDoS Attack!!

• Attackers compromise hosts in the Internet and
  install zombies (for example, Code Red worm)
• Attackers control those zombies to DoS attack the
  victim
• Infrastructure level attack (UDP floods)
• Application level attack (floods of requests)

10
Current Approaches

• Reactive Schemes
• Detect and filter out attack traffic (Intrusion
  detection systems Axelsson00, Kumar94, Vigna99,
  Ferguson 98)
• Trace back to attackers or compromised hosts in
  order to stop them Savage01
• Punitive Schemes
• The ability to trace back to attackers may deter
  attacks Savage01
• Preventive Scheme
• Protect machines from being compromised
  Wagner01
• Problem remains unsolved
• Current schemes primarily focus on disrupting
  attack mechanisms rather than defeating the
  foundation of attacks

11
Proposed Solution (Overview)
Server side
Client side
Application Service
Application Client
Infrastructure
OS
OS
OS
OS
Host
Host
Host
Host
Network

• Solution at two levels
• Part I Tolerate infrastructure level attacks
• The application has resource to operate
• Essential part of the solution
• Part II Tolerate application level attacks
• Fair distribution of application resource among
  users

12
Proposed Solution (Part I)

• Tolerate infrastructure level DoS attacks
• Location elusiveness defeats direct DoS attack on
  the application
• Location is secret, so attackers have no target
  to shoot at (SCM3)
• Location is changing, so attacks cannot last
  (SCM1A)
• Location Elusiveness capability is provided to
  the application transparently (SCC1)
• DoS tolerant proxy network as public access point
• Bridge between the users and the application
  (SCC12)
• Users can access the application without knowing
  the location of it.
• Highly distributed and redundant to tolerate
  infrastructure level attacks
• Goals are fundamentally different from proxies
  today

13
Proposed Solution (Part I)

• Shield against infrastructure level attacks

Distributed Location Elusive Application
Proxy
Proxy
User
User
User
User
Proxy
Proxy
User
Firewall
NAT Box
User
User
User
User
User
User
User
User
14
Proposed Solution (Part II)

• Tolerate application level DoS attacks
• Distributed fair scheduler gives users service
  guarantee
• Each user has a fair share of the application
  service, no other users (including attackers) can
  compromise that fair share. (SCM2)
• Use network topology information to overcome the
  problem of NAT addresses (addresses inside NAT
  box are indistinguishable from outside)
• Allocate fair share based on network capacity
• Guarantee fairness on aggregation of users
• Contain the impact of attackers to their own
  neighborhood (SCM1B)
• Hierarchical schedulers (SCM2)
• Fair schedulers inside firewalls (on NAT boxes)
• Protect users from attacks inside the same
  firewall

15
Proposed Solution (Part II)
Distributed Location Elusive Application
Proxy Scheduler
Proxy Scheduler
User
User
User
User
Proxy Scheduler
Proxy Scheduler
User
Firewall
NAT Box
User
User
User
User
User
User
User
User
16
Proposed Solution (Part II)

• Tolerate application level DoS attacks
• Distributed fair scheduler gives users service
  guarantee
• Each user has a fair share of the application
  service, no other users (including attackers) can
  compromise that fair share. (SCM2)
• Use network topology information to overcome the
  problem of NAT addresses (addresses inside NAT
  box are indistinguishable from outside)
• Allocate fair share based on network capacity
• Guarantee fairness on aggregation of users
• Contain the impact of attackers to their own
  neighborhood (SCM1B)
• Hierarchical schedulers (SCM2)
• Fair schedulers inside firewalls (on NAT boxes)
• Protect users from attacks inside the same
  firewall

17
Proposed Solution (Part II)
Amount of Fair Share
Small Corp A
Small Corp B
Big Corp C
Aggregation of fair share proportional to link
capacity
18
Proposed Solution (Part II)

• Tolerate application level DoS attacks
• Distributed fair scheduler gives users service
  guarantee
• Each user has a fair share of the application
  service, no other users (including attackers) can
  compromise that fair share. (SCM2)
• Use network topology information to overcome the
  problem of NAT addresses (addresses inside NAT
  box are indistinguishable from outside)
• Allocate fair share based on network capacity
• Guarantee fairness on aggregation of users
• Contain the impact of attackers to their own
  neighborhood (SCM1B)
• Hierarchical schedulers (SCM2)
• Fair schedulers inside firewalls (on NAT boxes)
• Protect users from attacks inside the same
  firewall

19
Proposed Solution- Put them together

• Shield against infrastructure level attacks
• Scheduler to defeat application level attacks

Distributed Location Elusive Application
Proxy Scheduler
Proxy Scheduler
User
User
User
User
Proxy Scheduler
Proxy Scheduler
User
Firewall
NAT Box
User
User
Scheduler
User
User
User
User
User
User
20
Validation Plan

• Analytical study
• Strength of location hiding scheme (SCM3)
• Probability of compromise (with given amount of
  resource and time)
• Theoretical bound of hierarchical scheduling
  schemes (SCM2)
• With perfect fair schedulers, what kind of
  fairness can be guaranteed for users (inside or
  outside firewalls).

21
Validation Plan

• Empirical study Simulation environment
• Cluster based network simulator with
  representative topology
• Firewalls of different sizes
• Hierarchy with large routers at higher level
• Application and proxy network run inside the
  simulated network
• Users and attackers are scattered inside the
  simulated network
• Simulate user access
• Simulate infrastructure level attack from
  attackers
• Simulate application level attack from attackers

22
Validation Plan

• Empirical study Experiments
• Effect of location changing (SCM1A)
• Simulate infrastructure attack on fixed locations
• User request delay distribution changes with time
  (attackers impact fades with time)
• Effect of topology guided scheduling scheme
  (SCM1B)
• Simulate application level attacks from attackers
  from various locations (inside and outside
  firewalls)
• Study geographic distribution of user request
  delay (attackers impact is contained locally)
• Effect of hierarchical scheduling scheme (SCM2)
• Simulate application level attacks from
  attackers from various locations (inside and
  outside firewalls) with different intensity
• Study how user request delay at various locations
  changes with attack intensity (attackers impact
  is bounded)

23
Summary

• With location hiding, the possibility of direct
  infrastructure level attacks on the application
  is mitigated.
• With location changing, can tolerate proxy
  compromises by containing the impact of attacks.
• Topology guided hierarchical scheduling scheme
  mitigate impact attackers can have. It also
  contain attackers impact locally.

24
Contributions

• It shows a system level approach (application
  generic) to effectively avoid infrastructure
  level DoS attacks.
• It demonstrates a way to mitigate application
  level DoS attacks at the system level without
  application specific information.
• It shows that all these schemes can be
  incrementally deployable in existing distributed
  environment and transparent to applications.

25
Impact and Benefit

• The whole solution has two folds of impacts
• Tolerate both types of DoS attacks
• Deter application level attacks (easier to locate
  attackers)
• Solution provided as a tier between the
  application and users. Transparent to all users.
• New applications can get full benefit from this
  solution.
• AO system provides location elusiveness
  transparently to the application.
• Designers only need to focus on application logic
  itself. DoS problem is solved at the system
  level.
• Many existing applications can also get full
  benefit with small changes.
• Stateless front-end, such as web servers. Easy to
  make location elusive.
• The rest can get partial benefit.
• With location hiding, without location changing.

26
Reference

• Intrusion Detection Systems A Survey and
  Taxonomy, Stefan Axelsson, Chalmers University
  of Technology, Goteborg and Sweden, 2000.
• A Pattern Matching Model For Misuse Intrusion
  Detection, Sandeep Kumar and Eugene H. Spafford,
  Proceedings of the 17th National Computer
  Security Conference, 1994
• NetSTAT A Network-based Intrusion Detection
  System, Giovanni Vigna, Journal of Computer
  Security, 1999
• Network Ingress Filtering Defeating Denial of
  Service Attacks which employ IP Source Address
  Spoofing, P. Ferguson and D. Senie, The
  Internet Society, 1998.
• Intrusion Detection via Static Analysis, David
  Wagner and Drew Dean, 2001 IEEE Symposium on
  Security and Privacy.
• Network Support for IP Traceback, Stefan
  Savage, David Wetherall, Anna Karlin and Tom
  Anderson, ACM/IEEE Transactions on Networking,
  2001

27
Caveats and Limitations

• Correlation among applications
• Flaws in the system may become common security
  hole for all applications running on it
• Attack on one application may affect other
  applications
• Bigger target for attackers
• Less effective if applications have flaws
• Implementation flaw possible compromise
• Design flow allow small number of requests
  consume huge amount of resource