How DDoS Shield Mitigates Volumetric Infrastructure Attacks

Introduction

A Distributed Denial of Service (DDoS) attack floods a target with traffic to exhaust its bandwidth, CPU, or connection tables — making it unavailable to legitimate users. Volumetric attacks at Layer 3/4 (IP/TCP/UDP) can reach terabits per second using botnets or amplification techniques (DNS/NTP reflection). Defending against these requires infrastructure with massive scrubbing capacity positioned upstream of the victim, not at the victim’s servers themselves.

Step-by-Step: How DDoS Mitigation Works

flowchart TD
    A["1. Attack Detection"]
    B["2. BGP Blackholing (Last Resort)"]
    C["3. Traffic Scrubbing"]
    D["4. SYN Cookie Defense (TCP Layer)"]
    E["5. Rate Limiting and Challenge Pages"]
    A --> B
    B --> C
    C --> D
    D --> E

Step 1: Attack Detection

Detection systems analyze traffic flows in real time looking for anomalies:

Sudden 100× increase in packets-per-second to one destination
High ratio of UDP traffic to a non-UDP service
SYN flood indicators (high SYN, low ACK ratio)
Amplification signatures (DNS response > 512 bytes from unusual source ports)

AWS Shield Advanced uses flow logs from all AWS edge locations aggregated into a detection engine. Cloudflare uses Anycast network telemetry across 285+ cities.

Step 2: BGP Blackholing (Last Resort)

The fastest coarse defense: announce a BGP community to upstream transit providers to drop all traffic to the victim IP at the provider’s edge — before it reaches your infrastructure:

BGP Community: 65535:666  (BLACKHOLE community, RFC 7999)
Effect: All traffic to 203.0.113.42 is dropped at provider edges
Cost: Legitimate traffic is also dropped (target IP goes dark)
Use: Only when infrastructure survival > availability

Step 3: Traffic Scrubbing

More surgical defense: route all traffic through scrubbing centers that filter attack traffic and pass clean traffic to origin:

Attack traffic (100 Gbps)
  → BGP re-route to scrubbing center
  → Pattern matching strips attack packets (SYN floods, UDP amplification)
  → Clean traffic (2 Gbps legitimate) forwarded via GRE tunnel to origin

AWS Shield Advanced automatically reroutes suspect traffic through AWS scrubbing infrastructure. Cloudflare Magic Transit uses GRE tunnels to forward clean traffic back to on-premise data centers.

SYN flood attacks exhaust connection tables by sending millions of SYN packets without completing the handshake. SYN cookies move connection state into the initial sequence number:

Normal TCP:
  Client: SYN → Server stores half-open connection in table
  Client: SYN+ACK → Client: ACK → Connection established
  Problem: Table fills with millions of half-open connections

SYN Cookie:
  Client: SYN → Server sends SYN+ACK with ISN=hash(src,dst,port,time)
  No table entry stored
  Client: ACK → Server validates ACK number contains correct cookie
  Only then is connection accepted into table

Linux enables SYN cookies automatically under load: net.ipv4.tcp_syncookies = 1

Step 5: Rate Limiting and Challenge Pages

At Layer 7, Cloudflare and AWS WAF issue JS challenges or CAPTCHA for suspected bot traffic:

High request rate from single IP → Issue JavaScript proof-of-work challenge
Browser completes challenge → Receives clearance cookie → Requests pass
Bot cannot execute JS → Blocked at edge

Key Takeaways

Volumetric DDoS defense must occur upstream of the target — victim infrastructure cannot absorb terabit attacks regardless of configuration.
BGP blackholing (RFC 7999 community 65535:666) drops all traffic to a targeted IP at carrier edges — effective but trades availability for survival.
Scrubbing centers filter attack traffic and forward clean flows via GRE tunnels — enabling continued operation during an attack.
SYN cookies eliminate half-open connection table exhaustion by encoding state in the TCP sequence number.
AWS Shield Advanced provides automatic rerouting, DDoS cost protection, and 24/7 access to the AWS DDoS Response Team.