Practical approaches to dealing with ddos attacks
1 / 20

Practical Approaches to Dealing with DDoS Attacks - PowerPoint PPT Presentation

  • Uploaded on

Practical Approaches to Dealing with DDoS Attacks. Massimiliano Poletto Joint work with Andrew Gorelik and Robert Morris Mazu Networks | 125 CambridgePark Dr. | Cambridge MA 02140. AGENDA. This talk will try to address two questions of interest to people who need to manage DDoS attacks:

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Practical Approaches to Dealing with DDoS Attacks' - havyn

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Practical approaches to dealing with ddos attacks

Practical Approaches to Dealing with DDoS Attacks

Massimiliano Poletto

Joint work with Andrew Gorelik and Robert Morris

Mazu Networks | 125 CambridgePark Dr. | Cambridge MA 02140


This talk will try to address two questions of interest to people who need to manage DDoS attacks:

  • What are some useful ways of detecting and understanding the nature of DDoS attacks?

  • Given that it is desirable to deal with DDoS attacks in a distributed manner (e.g. find sources), is there a way to do this that is practical and incrementally deployable?

Why is ddos a difficult problem

  • Conceptual difficulties

    • Entire packet except destination address may be random

    • Filtering on destination address near victim may just reinforce DoS

    • Moving filtering upstream requires communication

  • Practical difficulties

    • Routers don’t have many spare cycles for analysis/filtering

    • Networks must remain stable—bias against infrastructure change

    • Attack tracking can cross administrative boundaries

    • End-users/victims often see attack differently (more urgently) than network operators (“T-3 vs. OC-48”)

  • Nonetheless, need to:

    • Maximize filtering of bad traffic

    • Minimize “collateral damage”

10 000ft outline

  • Define attack as activation of one or more “triggers”

    • E.g.: congestion (drops on a router queue, high traffic rates on a link), unusual traffic mixes, or other metrics of interest

  • Try to identify DoS traffic (question #1)

    • Find aggregates [Bellovin et al.] and look at distributions of various packet metrics

    • Use history to help decrease collateral damage

  • Where possible, notify other (upstream) network devices (question #2)

Aggregates and traffic statistics

  • Bellovin et al.:

    • “Aggregate” is a collection of packets that share some property

    • Focus on destination address because it won’t be spoofed

    • Rate-limit high-volume dest addr aggregates during an attack

  • Good idea, but filtering by destination address is punitive unless done far from victim

  • Proposal

    • Look at other parameters (source addr, ports, other IP fields, hashes of part of payload, packet length) for candidate aggregates

    • Combine with distributions of parameter values and history information to help decrease collateral damage

Example source ip address

  • Top: source address distribution of normal incoming traffic for large (400+Kpps) web site

  • Bottom: source address distribution of incoming traffic during randomly spoofed SYN flood

  • Normal traffic distributions vary a little from site to site, but consistent per site across time periods at scales >1 minute

Detecting randomness

  • Useful, e.g., for detecting spoofing

  • One way is to compute ratio stddev/mean of histogram bucket values (not of histogram itself)

  • Intuition (for source address example):

    • Lots of traffic from one source, or clumped as on last slide, has high stddev

    • Randomly spoofed traffic has low stddev

    • Divide by mean to normalize for traffic volume

    • So, lower values mean more randomness

  • Plots are stddev/mean of source addr histogram bucket values vs. time.

    • Top: large web site normal traffic

    • Bottom: randomly spoofed SYN flood

    • Note Y-axis values: ~20 vs. <1.

Using traffic history

  • Problem:

    • Distribution of a given parameter (e.g. source address) in normal traffic may not be random (there may be large “spikes”)…

    • But attack packets may have randomized parameter values…

    • So biggest aggregates based on that parameter may include a lot of legitimate traffic

  • Solution:

    • Many parameter distributions change little over time

    • Use past distributions of normal traffic for reference

    • Rate-limit biggest outliers (or values that are historically low) first

Traffic history example

  • Source address is a suitable parameter because distributions appear to be consistent across time periods

  • Top: outside address distribution for 2 months on a corporate T-1 line

  • Bottom: outside address distribution for 1 day on a corporate T-1 line

  • If incoming source addresses are random (as determined by observing histogram or computing stddev/mean), first rate-limit biggest outliers or addresses that historically send no traffic

Example ip protocol

  • Most traffic is TCP; UDP is often limited to specific services; ICMP is often unimportant

  • So, traditional smurf/fraggle floods are often the easiest to identify and filter with minimal collateral damage

  • Top: distribution of different IP protocols at large web site (TCP dominates; some UDP and ICMP)

  • Bottom: stdev/mean of bucket values changes little over course of a month

Example ttl

  • TTL distribution has large, predictable spikes below powers of 2 (depends on specific IP implementations)

  • Stable across time periods; relatively similar for different sites

  • A crafty attacker may not want to randomize TTLs (improbable TTLs easily identifiable)

  • Big spikes in TTL distribution are also detectable (increase in stddev/mean at right is due to large file transfers from a small number of hosts)

Example packet length

  • Top: packet length distribution across a day, large web site

  • Bottom: stddev/mean of bucket values for minute-length buckets at same site

  • Packets come primarily in a few lengths (small, ~500 bytes, ~1500 bytes)

  • Stddev/mean relatively constant

  • Randomizing packet length or using just one (or few) lengths can be detected relatively easily

Distributing ddos defense

  • Now assume you have an answer to question #1: a combination of aggregates computed on different parameters, historical analysis, etc.

  • But large floods often cannot be solved by a single downstream filter—need to move closer to attackers, filter away from victim

  • How to do this in a practical, incremental way?

  • Remember constraints:

    • Limited router computation budget

    • Bias against network change (both hardware and software/config)

    • Multiple administrative domains

Existing methods proposals

  • Input debugging

    • Victim identifies attack signature and notifies upstream ISP

    • Manual egress filtering and interface testing

  • (ICMP) Traceback [Savage et al. 2000, Bellovin 2000]

    • Routers probabilistically annotate packets (or send ICMP packets) with their identity and other information

    • Destination can reconstruct path of large volumes of traffic

  • Pushback [Bellovin et al. 2001]

    • Routers identify aggregates and send rate-limit requests upstream

    • Status messages about ongoing traffic rates flow downstream

  • CenterTrack [Stone 2000]

    • Edge routers reroute traffic via IP overlay network to tracking router(s)

    • Tracking routers diagnose attack and optionally filter traffic

Potential problems

  • Input debugging is used today but is slow and coarse; requires extensive human intervention

  • Traceback and (especially) pushback require considerable changes to large fraction of router installed base

  • Traceback effectiveness decreases with increasing fan-out and hop count; it has authentication/spoofing problems

  • Pushback combines source identification with filtering, which raises difficult inter-domain adminstration issues

  • As currently defined, pushback stops at the first router that does not implement it

  • CenterTrack has a potential bottleneck (tracking routers) and may be detectable by attackers

A complementary near term approach

“Distributed monitoring”

  • Monitor key links using taps and dedicated monitor devices

  • Store traffic state (logs) on monitors: enable historical analysis with no central repository

  • Implement hierarchical communication between monitors

  • Encourage open standards for communication between monitors

  • Separate filtering from monitoring

  • Possibly separate filtering from routing and routers (employ dedicated filtering device)

  • Ensure human in loop during filtering to decrease risk of inadvertent DoS

Relation to existing schemes

  • Pragmatic, incrementally deployable improvement to input debugging

    • Effectively a separate network for fast, precise monitoring

    • Filtering can be implemented via routers (like manual input debugging today) or via dedicated (“firewall-like”) filtering devices

  • Complements ambitious designs like pushback/traceback

    • Emphasis on near-term feasibility

    • Could benefit from traceback information


  • Dedicated passive monitors with taps

    • Add no latency or load on routers

    • Increase visibility into traffic (vs. what is available from routers)

    • Require no change to deployed devices

    • Allow incremental deployment with minimal change to infrastructure

    • Are invisible to attackers

  • Hierarchy and point-to-point communication among monitors

    • Remove need for physical adjacency as in pushback

    • Simplify problem of inter-domain authentication

  • Filtering via routers: can work today

  • Filtering via dedicated devices: is fast, fine-grained; allows routers to focus on routing


  • Requires investment in devices beyond current infrastructure

  • Filtering via routers is

    • Slow as always

    • Limited by expressiveness of ACL languages

  • Filtering via dedicated filter device introduces new network element and point of failure

  • Need to define open standards for inter-monitor communication


  • Computing aggregates for many parameters and using historical information are promising methods of identifying DDoS traffic and decreasing collateral damage

  • Tracking DDoS attacks towards their sources is difficult and time-consuming

  • Distributed monitoring is a more efficient and accurate form of input debugging while we wait out the deployment issues and technical challenges of other proposed solutions

  • Interoperability between different devices that detect/track DDoS traffic is fundamentally important