DDoS Attack Prevention by Rate Limiting and Filtering

1
DDoS Attack PreventionbyRate Limiting and
Filtering

• dArtagnan de Anda
• dartdart_at_cs.ucla.edu
• CS239 Network Security
• 26 Apr 04

2
Overview

• Pushback Paper
• NetBouncer
• D-WARD Paper
• Questions for Discussion

3
Overview

• Filtering requires real time algorithms, and
  most likely pre-deployment of resources for trust
• Rate Limiting Hard to prevent collateral damage
  to good and poor traffic v. just bad traffic

4
Pushback

• Ioannidis and Bellovin attempt to implement
  Pushback
• Problem We cant tell legitimate traffic from
  illegitimate traffic
• Goal Develop heuristics that try to identify
  most bad packets while not disturbing most good
  packets.
• Aggregate-based Congestion Control
• A subset of the traffic with an identifiable
  property, e.g.
• Packets to destination D
• TCP SYN packets
• IP packets with a bad checksum
• Identify attack signature -gt congestion
  signature
• Sort of recursive It tells the next level of
  routers to back off, as it is backing off.
• Rationale The packets will be dropped at the
  destination anyway, so why not just drop them at
  the routers above too?

5
Pushback

• Good architecting by allowing the pushback daemon
  to exist out of band.
• Router must have some sort of inherent traffic
  shaping capability to take advantage of this
• Only logs packets dropped for queue discipline
  reasons
• pushbackd processes the saved drop-set to try to
  detect congestion.
• The exact algorithm(s) to run will be an
  important research topic for some time to come.
• The algorithm detects aggregates based only on IP
  destination address the simplest implementation

6
Pushback

• The pushback daemon listens for requests from its
  downstream routers. gt Necessitates greater
  deployment
• Probability of keeping a packet is inversely
  proportional to its size smart!
• In a real router with hardware-assisted fast
  switching paths for the common cases, the
  overhead of imposing a number of rate limiting
  sessions may be much higher.

7
Pushback

• Even though the prefix garnered from the routing
  table will be shorter than 32 bits, the address
  of the selected aggregate will be the full 32
  bits. Why? Because a specific machine is
  targeted.
• It is likely that more than one attack is
  happening at the same time. Why? More than one
  attack does happen at the same time and one
  should design a system that works for the real
  world.
• The algorithm should run in less time than it
  takes to collect the packets. Why? Queuing
  system theory You want the server to operate
  faster than the queue can fill up.
• Pushback is most effective when the attack is
  non-isotropic. (most attack traffic close to
  victim and from a subset of the in-links) Why?
  Smaller area to graph. More likely to have a
  complete deployment of Pushback in that area.

8
NetBouncer

• Claim NetBouncer can tell the difference
  between legitimate and illegitimate traffic in a
  hardware implementation of a router.
• End-point-based solution to DDoS protection
• Goals
• No changes in current network protocols
• No administrator intervention for legitimacy
  tests
• State safety legitimacy tests do not become
  vulnerabilities
• A NetBouncer device maintains a large legitimacy
  list of clients that have been proven to be
  legitimate
• Not on the legitimacy list? Administer tests to
  prove legitimacy.

9
NetBouncer

• Use of TCP SYN cookies was a good idea
• Interception of SYN packets
• Handles TCP connection in a stateless manner
• Good job addressing Application and
  Session-oriented legitimacy tests (structured-
  and ad hoc- composite services i.e., SCS and
  ACS). But
• The ACS subcategory is currently a topic if
  intense research and will be reported in the
  future.

10
NetBouncer

• NetBouncer should be placed upstream of
  potential chokepoints How is this location
  determined? There really arent great places to
  deploy NetBouncer. Must be placed where it can
  handle all of the attack traffic. Otherwise,
  rate limiting before NetBouncer will reduce the
  good and bad traffic it sees.
• Use of ICMP echo messages touted, and then
  acknowledged as not likely to be effective
• How does the list of legitimate sources get
  instantiated? This is hard to do.
• We are currently exploring how ICWFQ can be
  supported within the IXP-1200 based hardware
  prototype of NetBouncer.

11
D-WARD

• DDoS defense mechanism intended to be deployed at
  the source to detect and stop attacks by
  evaluating traffic signatures
• Problems
• Attack traffic is too aggregated at the victim so
  it makes on-the-fly packet dropping difficult.
• Core routers cannot spare enough resources to do
  a good job so much collateral damage is suffered
  from implementation there.
• Solution Stop attacks at the source

12
D-WARD

• Configure outgoing addresses to be policed
• Monitor traffic between these addresses and the
  rest of the internet.
• Compare traffic against historical data and
  curtail deviating behavior. Autonomous
  adjustment.
• Addresses TCP, ICMP, and UDP
• Definitions provided for normal, suspicious, or
  attack
• of machines attacking is transparent to the
  system

13
D-WARD

• We assume that D-WARD is able to identify the
  police address set. Probably not a simple task.
  Fairly easy to identify what machines are in
  your own network.
• We assume that all machines from the police
  address set use the source router as the exit
  router (i.e., Asymmetric routes you have to
  check between every possible pair, with secure
  communication and clock synchronization, exposing
  more points to be attacked.)
• What would be the maintenance cost of keeping the
  police address set up to date? Not much.
• Most networks DO have more than one border
  router. D-WARD would be most effective if
  deployed on each border router.
• Possibly, the correct assumption is that if an
  ISP chooses to implement this system on one
  border router, they would do so for all

14
D-WARD

• Hardware vs. Software Router
• and enable us to test whether D-WARD can
  handle traffic at high speeds. Implemented on
  IXP-1200
• Legitimate flows that start during the attack
• Hash table size limitation
• Detection of UDP packets
• Cannot detect the shrew attack from non-spoofed
  sources. Can now detect some UDP traffic flows
  too.

15
Questions for Discussion

• Will any of these DDoS prevention schemes be
  deployed?
• Of the three papers, which is the most scalable?
• Is it better to filter at the source or at the
  destination
• How do we expose the benefits of every one
  filtering at the source?
• Are we stuck with DDoS attacks forever?