Taming IP Packet Flooding Attacks - PowerPoint PPT Presentation

1 / 22
About This Presentation
Title:

Taming IP Packet Flooding Attacks

Description:

– PowerPoint PPT presentation

Number of Views:59
Avg rating:3.0/5.0
Slides: 23
Provided by: dadk
Category:

less

Transcript and Presenter's Notes

Title: Taming IP Packet Flooding Attacks


1
Taming IP Packet Flooding Attacks
  • Karthik Lakshminarayanan, Daniel Adkins, Adrian
    Perrig and Ion Stoica

2
In a Nutshell
  • Problem Attacker floods a victims network link
  • Solution Stop attack traffic before it gets to
    the incoming link
  • Today call ISP to stop the traffic, and hope for
    the best!
  • Our approach Give end-hosts control over which
    packets they receive
  • E.g., enable end-hosts to stop attacks in the
    network

3
Why End-Hosts (and not Network)?
  • End-hosts can better react to an attack
  • Aware of semantics of traffic they receive
  • Know what traffic they want to protect
  • End-hosts may be in a better position to detect
    an attack

4
An Example
  • Under congestion, routers drop packets randomly
  • ? TCP congestion collapse
  • Given control, end-hosts can selectively drop
    traffic (e.g., TCP SYNs) to preserve throughput

5
Outline
  • Some DDoS Examples
  • Argument for End-Host Control
  • Possible Approaches

6
Recent DDoS Attacks
  • Slammer Worm 25 Jan 2003
  • Spread within minutes, saturating access
    bandwidth
  • Other unrelated services were affected
  • and that was just the infection phase

Operator response was ineffective
7
UWisc NTP flood
  • 800AM Packet flood starts
  • 940AM Intra-campus routing failures
  • 1100AM Blocked UDP traffic with source port
    23457 at WiscNets border routers

8
UWisc Analysis
  • Response time was 3 hours!
  • Wasnt even a malicious attack, just a bug in
    certain NetGear routers
  • They were luckythey could filter on source port
  • Otherwise, it might have been the perfect attack
  • Attack traffic comprised legitimate requests
  • Attackers were widely distributed

Response was slow
9
Doomsday Scenario
  • Some worm is going to get it right
  • Infect millions of hosts without being detected
  • Launch DDoS that is indistinguishable from
    legitimate traffic
  • Attack rate from each infected host is low enough
    that they wont be compelled to patch

Currently no good response
10
Current Approaches
  • Network Ingress Filtering RFC 2267
  • Stops spoofed addresses
  • Rate Limiting (a.k.a. traffic shaping)
  • Coarse grained, usually at the receiver
  • IP Traceback
  • Great if there are only a few attackers
  • Null Routing
  • Effective if the attack has a good signature
  • Anomaly Detection
  • Filter out the attack traffic while not affecting
    legitimate traffic

11
Give end-hosts fine-grained control over the
packets sent to them in the network
Our Approach
12
Why Give End-Hosts Control?
  • End-hosts know better (than network) which
    packets are important
  • Two different responses to same attack
  • Keep important service running
  • Drop service entirely (bandwidth costs)
  • The deeper a router is in the network, the less
    it knows about the hosts behind it (e.g. campus
    gateway router)

13
Some Useful Defenses
  • White-listing avoid receiving packets at
    arbitrary ports
  • Traffic isolation
  • Contain the traffic of an application under
    attack
  • Protect the traffic of established connections
  • Throttling new connections control the rate at
    which new connections are opened (per sender)

14
How Can We Give End-Hosts Control?
  • Using Internet Indirection Infrastructure (i3)
  • Filters at edge routers

15
Internet Indirection Infrastructure (i3)
  • Provides a rendezvous based communication
    abstraction (instead of point-to-point)
  • Each packet has an identifier id
  • To receive a packet with identifier id, receiver
    R maintains a trigger (id, R) in the network

Sender
Receiver (R)
16
1. White-listing
  • Packets not addressed to open ports are dropped
    in the network
  • Create a public trigger for each port in the
    white list
  • Allocate a private trigger for each new connection

H2
H1
17
2. Traffic Isolation
  • Drop triggers being flooded without affecting
    other triggers
  • Protect ongoing connections from new connection
    requests
  • Protect a service from an attack on another
    services

18
2. Traffic Isolation
  • Drop triggers being flooded without affecting
    other triggers
  • Protect ongoing connections from new connection
    requests
  • Protect a service from an attack on another
    services

Traffic of transaction server protected from
attack on web server
19
3. Throttling New Connections
  • Redirect new connection requests to a gatekeeper
  • Gatekeeper has more resources than victim
  • Can be provided as a 3rd party service

id
C
t
S
20
Edge Router Solution
  • Idea bottleneck is at the edge
  • End-hosts control filters at their edge router
  • End-hosts also get feedback from the router
  • Feasible with todays hardware

The Internet
Filters
21
i3 approach vs. Edge Router approach
  • Generality of i3-based approach
  • Protocol independence
  • Allows seamless redirection to gatekeeper servers
  • Deployability of edge-router approach
  • Requires change to only the edge routers
  • Incrementally deployable

22
Conclusion
  • End-hosts are in the best position to react to
    DDoS attacks
  • End-hosts know about the semantics of the traffic
    they receive
  • Our approach
  • Give end-hosts control over which packets they
    receive
  • Future work
  • What extent of control should be given to hosts?
  • How do we protect core of the network from
    attacks?
Write a Comment
User Comments (0)
About PowerShow.com