defending against ddos attacks using max-min fair server centric router throttles

1.1Operating System Concepts

Defending Against DDoS Attacks Using Max-min Fair Server Centric

Router Throttles

David K.Y. Yau John C.S. LuCS Dept, Purdue University CS&E Dept,CUHK


Motivations

Internet is an open and democratic environment increasingly used for mission-critical work

and commercial applications.

Many security threats are present or appearing Easy to launch, even for naïve users. need effective and flexible defenses to

detect/trace/counter attacks Goals:

protect innocent users; prosecute criminals

Ambitious goals


Network Denial-of-service Attacks

Some attacks quite subtle securing protocols and intrusion

detection (e.g., BGP, TCP-syn attack) at routing infrastructure, malicious

dropping of packets, etc (low-rate TCP) Others by brute force:

- flooding (e.g., UDP, valid Web Request)

Cripples victim: - precludes any sophisticated defense at

victim site Philosophical question: what is an “attacker”? Viewed as resource management problem


Flooding Attack

Server


Server-centric Router Throttle

Installed by server when under stress, at a set deployment routers can be sent by multicast

Specifies leaky bucket rate at which router can forward traffic to the server aggressive traffic for server dropped

before reaching server rate determined by a feedbak control

algorithm

Issues: (1) Which set of routers? (2) What is the “proper” dropping rate?


To S

Router Throttle

Aggressive flow

Throttlefor S’

To S’

Throttlefor S

Securely installed by S

Deployment router

C: Each victim has a leaky bucket for rate limit. Small memory and computationoverhead!


Key Design Problems

Resource allocation: who is entitled to what? need to keep server operating within load

limits notion of fairness, and how to achieve it?

Need global, rather than router-local, fairness

How to respond to network and user dynamics (e.g., fluctuation of traffic)? Feedback control strategy is needed


What is being fair?

Baseline approach of dropping a fraction “f”, say ½, of traffic for each flow won’t work well a flow can cause more damage to other flows

simply by being more aggressive!

Rather, no flow should get a higher rate than another flow that has unmet demands this way, we penalize “aggressive” flows only,

but protect the well-behaving ones


Level-k Deployment Points

Deployment points parameterized by an integer k

R(k) -- set of routers that are either k hops away from server S, or less than k hops away from S but are directly connected to a host

Fairness across global routing points R(k)


Level-3 Deployment

Server


Feedback Control Strategy

Hysteresis control high and low water marks for server load, to

strengthen or relax router throttle

Additive increase/multiplicative decrease rate adjustment increases when server load exceeds US, and

decreases when server load falls below LS

throttle removed when a relaxed rate does not result in significant server load increase


Fairness Definition

A resource control algorithm achieves level-k max-min fairness among the routers R(k) if the allowed forwarding rate of traffic for S at each router is the router’s max-min fair share of some rate r satisfying LS r US


Fair Throttle Algorithm


Example Max-min Rates (L=18, H=22)

Server

18.236.65

14.1

0.01

1.40

0.22

17.73

0.610.95

6.25

6.25

6.2520.53

24.88

15.51

17.73

0.22

0.61

0.95

59.9


Interesting Questions

Can we preferentially drop attacker traffic over good user traffic?

Can we successfully keep server operating within design limits, so that good user traffic that makes it gets acceptable service?

How stable is such a control algorithm? How does it converge?


Algorithm Evaluation

Control-theoretic analysis (fluid analysis) algorithm stability and convergence

under different system parameters Packet network simulations (packet

level analysis) Test under UDP and TCP traffic. Also test

with Web traces System implementation (the real

thing, baby !!!) deployment costs


Control-theoretic Model

Adjusted traffic from source i

Throttle signal from victim

Step size

When throttle signal is high, server is underloaded.When throttle signal is low, server is overloaded.

ANALOGY!!!


Feedback Control Model (Us=1750;Ls=1650)

Constant Source of 20






Output for good traffic (total from source 1)


Output for attack traffic (total from source 5)


Output for attack traffic (total from source 6)


Total traffic to server (Us=1750;Ls=1650)


Case 2: variable attack traffic (Us=1750,Ls=1650)

Square Pulse


Output of attack traffic 1


Output of attack traffic 2


Total traffic to server (Us=1750;Ls=1650)


Feedback Control Model(sources and server)


Feedback Control Model (server throttle signal)


Feedback Control Model (sources process throttle)


Throttle Rate (L=900; U=1100)


Server Load (L = 900; U = 1100)


Throttle Rate (U = 1100)


Server Load (U = 1100)


Throttle Rate (L=1050;U=1100)


Server Load (L=1050; U=1100)


NS2: UDP Simulation Experiments

Global network topology reconstructed from real traceroute data AT&T Internet mapping project: 709,310 traceroute

paths, single source to 103,402 other destinations randomly select 5,000 paths, with 135,821 nodes of

which 3879 are hosts

Randomly select x% of hosts to be attackers good users send at rate [0,r], attackers at rate [0,R]


20% Evenly Distributed Aggressive (10:1) Attackers


40% Evenly Distributed Aggressive (5:1) Attackers


Evenly Distributed “meek” Attackers


Deployment Extent


NS2: TCP Simulation Experiment

Clients access web server via HTTP 1.0 over TCP Reno

Simulated network subset of AT&T traceroute topology 85 hosts, 20% attackers

Web clients make request probabilistically with empirical document size and inter-request time distributions


Web Server Protection


Web Server Traffic Control


System Implementation

On Linux router loadable kernel moduleCPU resource reservation

Deployment platformPentium 4/2G Hz PCmultiple 10/100 Mb/s Ethernet

interfaces


System Implementation: cont

OPERA: An Open-Source Extensible Router Architecture

http://www.cse.cuhk.edu.hk/~cslui/ANSRlab/software/opera/ A Linux-based package for implementing a

software programmable router architecture with the aim to facilitate networking experiments for the research community. Using this architecture, one can dynamically load new extension and services into the programmable router. Some interesting extensions include QoS support and traceback of DDoS attacks.)

Dynamic module loading Resource reservation General extension framework Secured Communication


Future Work

Offered load-aware control algorithm for computing throttle rate impact on convergence and stability

Policy-based notion of fairness heterogeneous network regions, by size,

susceptibility to attacks, tariff payment

Selective deployment issues Impact on real user applications Defense for other forms of DDoS like

the reflector attack, BGP cascading failure..etc.


Conclusions

Extensible routers can help improve network health

Presented a server-centric router throttle mechanism for DDoS flooding attacks can better protect good user traffic from aggressive

attacker traffic can keep server operational under an ongoing

attack has efficient implementation

defending against ddos attacks using max-min fair server centric router throttles

Documents