Distributed Denial of Service attacks aim to exhaust resources — bandwidth, CPU, connection tables, application threads — to prevent legitimate users from accessing a service. Understanding the attack category determines the correct mitigation approach. Volumetric attacks need bandwidth capacity; protocol attacks need stateful protection; application attacks need behavioral analysis.
Volumetric Attacks (Layer 3/4)
Overwhelm target bandwidth or edge capacity with massive traffic floods. Amplification attacks use third-party servers to multiply attack traffic — a small spoofed request triggers a large response directed at the victim.
- UDP flood: spoofed UDP packets saturate target link
- ICMP flood (Ping flood): overwhelm with echo requests
- DNS amplification: 40-byte ANY query → 4,000-byte response (100x)
- NTP amplification: monlist command returns 556x response
- Memcached amplification: up to 51,000x amplification factor
- CLDAP amplification: Windows LDAP over UDP, ~70x factor
Protocol Attacks (Layer 3/4)
Exploit weaknesses in network protocols to exhaust state tables in firewalls, load balancers, and servers rather than saturating bandwidth. A relatively small attack can take down equipment with limited connection table capacity.
- SYN flood: sends SYN without completing handshake; fills server SYN backlog
- ACK flood: forged ACK packets force stateless reply processing
- Smurf attack: ICMP to broadcast address with spoofed victim source
- Fragmentation attack: overlapping or incomplete IP fragments
- RST flood: forged RST packets terminate legitimate connections
Application-Layer Attacks (Layer 7)
Target specific application functions that are computationally expensive to process. Much harder to distinguish from legitimate traffic because each request is valid — the attack lies in the volume and distribution pattern.
- HTTP/HTTPS flood: thousands of GET/POST requests per second
- Slowloris: opens many connections, sends headers slowly — exhausts threads
- Slow POST (RUDY): sends POST body one byte at a time
- DNS query flood: overwhelm authoritative DNS server with queries
- SSL/TLS exhaustion: expensive handshake computations per connection
Record Attacks & DDoS-as-a-Service
Attack sizes have grown dramatically. Cloudflare mitigated a 5.6 Tbps UDP flood in October 2024 — the largest ever recorded — originating from a 13,000-device Mirai-based botnet. DDoS-as-a-service "booter" and "stresser" services lower the barrier to entry, with attacks available for as little as $10–$20.
- Cloudflare 2024: 5.6 Tbps (October), 3.8 Tbps (September) UDP floods
- Akamai 2023: 900 Gbps against financial services customer
- Mirai and its variants remain the dominant botnet family for volumetric DDoS
- IoT devices (cameras, routers) are primary botnet recruitment targets
| Attack Type | OSI Layer | Primary Target | Mitigation Approach |
|---|---|---|---|
| UDP/ICMP flood | L3 | Bandwidth / uplink | Upstream scrubbing, blackholing, anycast diffusion |
| Amplification (DNS/NTP) | L3 | Bandwidth / uplink | BCP38 ingress filtering; scrubbing; disable amplifiers |
| SYN flood | L4 | Server/firewall state tables | SYN cookies; rate limiting; stateless mitigation appliances |
| Slowloris / Slow POST | L7 | Web server threads/connections | Connection timeout tuning; reverse proxy buffering |
| HTTP flood | L7 | Application CPU / DB | WAF rate limiting; JS challenge; behavioral analysis |
| DNS query flood | L7 (DNS) | Authoritative DNS servers | Anycast DNS; rate limiting; Response Rate Limiting (RRL) |
BGP Blackholing & RTBH
Remotely Triggered Black Hole (RTBH) filtering allows an ISP or upstream provider to advertise a specific /32 victim IP to null route it at the network core. The attack traffic is discarded before reaching the customer's link — but so is all legitimate traffic to that IP.
- Destination RTBH: null-route attacked IP prefix (full blackout of target)
- Source RTBH: null-route attacker source prefixes (more surgical)
- FlowSpec: BGP community-based traffic policy for more targeted drops
- Best used as a last resort when attack exceeds mitigation capacity
Anycast Diffusion
Anycast routes traffic for a single IP address to the geographically nearest node in a distributed network. When a DDoS attack floods from globally distributed bots, the attack traffic is spread across all PoPs simultaneously, reducing the load any single location must absorb.
- Cloudflare's 300+ PoP anycast network can absorb tens of Tbps
- DNS anycast: Cloudflare 1.1.1.1, Google 8.8.8.8 use anycast for resilience
- Requires BGP anycast infrastructure; not feasible for most organizations directly
- Cloud DDoS services (Cloudflare, Akamai) provide anycast as a service
Ingress Filtering — BCP38
BCP38 (RFC 2827) recommends that ISPs filter outbound traffic to only allow source IPs from their own allocated prefixes. This prevents IP spoofing — if all ISPs implemented BCP38, volumetric amplification attacks would be impossible because spoofed source IPs would be dropped at the originating ISP.
- Many ISPs still don't implement BCP38 (especially in certain regions)
- MANRS (Mutually Agreed Norms for Routing Security) tracks adoption
- uRPF (Unicast Reverse Path Forwarding): strict or loose mode on routers
- Critical for eliminating amplification attack effectiveness globally
SYN Cookies & Rate Limiting
SYN cookies allow a server to handle SYN floods without maintaining per-connection state until the handshake completes. The server encodes connection parameters in the sequence number, eliminating the SYN backlog overflow condition.
- Linux:
net.ipv4.tcp_syncookies = 1(enabled by default) - Stateless firewall/router rate limiting: limit SYN packets per source IP
- TCP connection rate limiting at border routers reduces flood impact
- Hardware scrubbing appliances (Arbor, Radware) handle multi-Gbps floods
| Defense Mechanism | Layer | Effective Against | Limitations |
|---|---|---|---|
| BGP Blackhole (RTBH) | L3 | Any volumetric attack exceeding uplink | Also drops legitimate traffic to targeted IP |
| Anycast diffusion | L3 | Distributed volumetric floods | Requires large anycast infrastructure (or cloud service) |
| BCP38 ingress filter | L3 | Spoofed-source amplification attacks | Only works if widely adopted; ISP coordination required |
| SYN cookies | L4 | SYN flood (state exhaustion) | Doesn't help with bandwidth exhaustion attacks |
| Rate limiting (router) | L3/L4 | Moderate floods from limited sources | Ineffective against distributed botnets with many sources |
| Scrubbing center | L3–L7 | Volumetric + protocol attacks | Cost; latency introduced by traffic diversion |
For most organizations, on-premises DDoS mitigation is insufficient — a 100 Gbps attack will saturate a typical enterprise uplink before any filtering can occur. Cloud DDoS protection scrubs traffic upstream, delivering only clean traffic to the customer's network.
Cloudflare Magic Transit
Cloudflare's network-layer DDoS protection service for enterprises. Traffic is routed to Cloudflare's network via BGP announcement, scrubbed at Cloudflare's global edge, and delivered to the customer via GRE or Cloudflare Network Interconnect. Capacity: 321 Tbps global network.
- Always-on: traffic always flows through Cloudflare edge
- Sub-3-second mitigation detection and response time (announced)
- Magic Firewall: stateless L3/L4 rules applied at global edge
- Supports RFC 1918 private IP space for internal network protection
AWS Shield
AWS Shield Standard is free and automatically protects all AWS resources from common L3/L4 attacks. Shield Advanced provides enhanced protection, DDoS cost protection (billing credits during attacks), and access to the AWS DDoS Response Team (DRT).
- Shield Standard: free, automatic, protects EC2/ELB/CloudFront/Route53
- Shield Advanced: $3,000/month; SLA, cost protection, WAF included
- Route53 is highly resilient — Anycast DNS with automatic DDoS mitigation
- Best for organizations already running workloads on AWS
Azure DDoS Protection
Azure provides two tiers: Network Protection (per-VNet, $2,944/month) and IP Protection (per IP, $199/month). Both include adaptive tuning, real-time telemetry, and post-attack analysis reports. Microsoft's global network provides the scrubbing capacity.
- Network Protection: dedicated capacity, 24/7 DDoS rapid response team
- IP Protection: per-resource, cost-effective for smaller deployments
- Cost protection: credits for scaled-out resources during attacks
- Integration with Azure Monitor and Microsoft Sentinel for alerting
Akamai Prolexic
Akamai's Prolexic is the enterprise DDoS scrubbing service with the longest track record. Traffic is re-routed to Akamai scrubbing centers via BGP or DNS, cleaned, and forwarded via GRE tunnels. Prolexic On-Demand activates scrubbing only during attacks.
- 20+ global scrubbing centers; 20 Tbps+ scrubbing capacity
- Always-On vs. On-Demand deployment options
- SOCC (Security Operations Command Center) staffed 24/7
- Detailed post-attack reports and forensic evidence
| Provider | Free / Basic Tier | Enterprise Tier | Key Differentiator |
|---|---|---|---|
| Cloudflare | Free WAF + DDoS on Pro ($20/mo); Magic Transit enterprise pricing | Magic Transit; 321 Tbps network capacity | Largest network; sub-3s mitigation; unified platform |
| AWS Shield | Shield Standard — free for all AWS resources | Shield Advanced — $3,000/month + usage | Native AWS integration; DRT access; cost protection |
| Azure DDoS Protection | Basic (platform-level) — free | Network ($2,944/mo) or IP ($199/mo per IP) | Native Azure integration; adaptive tuning |
| Akamai Prolexic | No free tier | Custom enterprise pricing | 20+ years DDoS experience; 24/7 managed SOC |
| Radware Cloud DDoS | No free tier | Custom pricing | Behavioral-based; strong multi-vector detection |
L7 DDoS attacks are the hardest to mitigate because individual requests look legitimate. Mitigation requires distinguishing human users from automated attack traffic — a challenge that is fundamentally a bot detection problem.
Bot Detection Techniques
Effective L7 DDoS mitigation relies on layered bot detection signals rather than any single technique. Each signal contributes to a confidence score; high-confidence bots are challenged or blocked.
- TLS fingerprinting: JA3/JA4 hash identifies client libraries vs. browsers
- HTTP/2 fingerprinting: SETTINGS frame parameters identify automated clients
- JavaScript challenge: browser must execute JS and return computed value
- Canvas fingerprint: subtle rendering differences identify browser vs. headless
- Behavioral signals: mouse movement, keystroke patterns, navigation flow
Rate Limiting Strategies
Rate limiting by IP address alone is easily defeated by distributed botnets with many IPs. Effective rate limiting combines multiple dimensions to catch distributed attacks while avoiding false positives on shared IPs (corporate NAT, CDN egress).
- Per-IP: simple but bypassed by distributed botnets
- Per-session/cookie: more resilient; requires cookie support
- Per-endpoint: limit requests to expensive API endpoints specifically
- ASN-level: temporary blocks on entire autonomous systems during attacks
- Geo-blocking: block countries with no legitimate business presence
Credential Stuffing as L7 DDoS
Credential stuffing — automated login attempts using breached credential lists — functions as an L7 DDoS against authentication endpoints. Every failed attempt consumes server resources and database queries. Large-scale stuffing attacks (billions of requests) have taken down login systems.
- Rate limit login endpoints aggressively (5–10 attempts/minute/IP)
- CAPTCHA after N failed attempts from same IP
- Check passwords against HaveIBeenPwned (Pwned Passwords API)
- MFA eliminates stuffing risk even if credentials are compromised
Slowloris & Slow Attack Mitigations
Slow HTTP attacks (Slowloris, Slow POST) exploit web servers that allocate a thread per connection. Mitigations focus on aggressive timeouts and offloading connection handling to a reverse proxy or load balancer that can handle many more concurrent connections.
- Reverse proxy (Nginx, HAProxy, Caddy) handles slow connections before app server
- Reduce request timeout: 30s for headers, 60s for body
- Limit max concurrent connections per IP at load balancer
- Apache: mod_reqtimeout with short initial timeout
Architecture Is the Best DDoS Defense
The best DDoS defense is building systems that are inherently resilient to volumetric attacks — distributed by design, with excess capacity, multiple CDN providers, and no single points of failure. Reactive mitigation (blackholing, scrubbing) handles what you can't architect away. Design for resilience, not just protection.
DDoS Response Runbook
A documented DDoS response runbook ensures the team doesn't have to make decisions under pressure. Pre-authorization to activate paid scrubbing services, contact upstream providers, and implement emergency firewall rules speeds response time significantly.
- Detection: monitoring alert fires; confirm attack vs. legitimate traffic spike
- Characterization: source, volume, attack vector, targeted resource
- Mitigation: activate scrubbing / WAF rules / rate limits based on type
- Communication: internal status page; customer notification if SLA impacts
- Recovery: confirm traffic is clean before removing mitigations
- Post-incident: root cause analysis; update runbook; contact upstream ISP
Capacity Planning & Multi-CDN
Capacity planning for DDoS resilience means having significantly more bandwidth and compute than peak legitimate traffic requires. Multi-CDN strategies distribute traffic across two or more CDN providers, so a targeted attack against one CDN's network doesn't take down the service.
- Target 2–5x headroom above peak legitimate traffic
- Multi-CDN: Cloudflare + Fastly, or Akamai + Cloudflare
- DNS-based failover between CDN providers (TTL 60s or less)
- Out-of-band management network: manage infrastructure during attack
Post-Incident Analysis
Every DDoS incident provides intelligence. Attack vectors, source ASNs, timing patterns, and attack tool signatures help build better defenses and inform future mitigation decisions. Share intelligence with ISPs and industry peers.
- Document attack vectors and peak traffic volumes
- Identify source ASNs: notify upstream providers for persistent sources
- Evaluate mitigation effectiveness: time-to-mitigate, false positive rate
- Update runbook with lessons learned within 5 business days