DDoS Protection
A Distributed Denial of Service (DDoS) attack overwhelms a target with traffic from many sources, making it unavailable to legitimate users. DDoS attacks do not steal data -- they disrupt service. The challenge is distinguishing between a DDoS attack and a legitimate traffic spike, because the wrong response to either can take down your service. Mitigation requires defense at multiple layers, from network infrastructure to application logic.
Types of DDoS Attacks
Volumetric Attacks
Volumetric attacks flood the target's bandwidth with massive amounts of traffic. The goal is to saturate the network link so legitimate traffic cannot get through.
Attack Type How It Works Typical Volume
──────────────────────────────────────────────────────────────────────────
UDP flood Send massive UDP packets to 10-500+ Gbps
random ports
DNS amplification Spoof source IP, send small Up to 70x
DNS query, large response amplification
sent to victim
NTP amplification Spoof source IP, send monlist Up to 556x
command to NTP server amplification
Memcached Spoof source IP, send request Up to 51,000x
amplification to open memcached server amplification
Amplification attacks exploit protocols that return responses much larger than the request. The attacker sends small requests with a spoofed source IP (the victim's IP), and the response server sends the large response to the victim.
In February 2018, GitHub was hit with 1.35 Tbps of traffic from a memcached amplification attack -- the largest DDoS attack recorded at the time. GitHub's traffic went from normal to 1.35 Tbps in under 10 minutes. Akamai Prolexic mitigated the attack within 20 minutes by rerouting traffic through their scrubbing centers.
Protocol Attacks
Protocol attacks exploit weaknesses in network protocols to exhaust server resources (connection tables, firewall state).
Attack Type How It Works
──────────────────────────────────────────────────────
SYN flood Send SYN packets with spoofed IPs. Server
allocates resources for half-open connections
that never complete the handshake.
Slowloris Open many connections, send partial HTTP
headers very slowly. Server holds connections
open waiting for the rest of the request.
RUDY (R-U-Dead-Yet) Send POST requests with very long
Content-Length headers, then send the
body one byte at a time.
Application Layer Attacks
Application layer attacks target specific application functionality with requests that are expensive to process. They use less bandwidth than volumetric attacks but can be more effective because they target business logic.
Attack Type How It Works
──────────────────────────────────────────────────────────────
HTTP flood Send legitimate-looking HTTP requests
at high volume. Hard to distinguish
from real traffic.
Expensive queries Target search endpoints, report
generation, or any endpoint that
triggers heavy database queries.
Login brute force Flood authentication endpoints,
triggering expensive password hashing
(bcrypt/Argon2 is intentionally slow).
API abuse Call API endpoints at rates far beyond
normal usage. Each call may trigger
downstream service calls.
In 2023, Cloudflare reported mitigating an HTTP/2 Rapid Reset attack that peaked at 201 million requests per second. The attack exploited a vulnerability in the HTTP/2 protocol where the client opens streams and immediately resets them, forcing the server to do work for each stream while the client does very little.
Rate Limiting
Rate limiting is the first line of defense against application layer attacks. Implement it at multiple layers.
Application-Level Rate Limiting
# Rate limiting strategies
Strategy Description Use Case
─────────────────────────────────────────────────────────────────
Fixed window N requests per time window Simple, but allows
(e.g., 100/minute) burst at window edges
Sliding window N requests in rolling window Smoother rate limiting
than fixed window
Token bucket Tokens refill at steady rate. Allows controlled bursts
Each request costs a token. while enforcing average rate
Leaky bucket Requests queue and process Constant output rate,
at a fixed rate smooths bursts
# Nginx rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
# Allows 10 requests/second per IP
# Burst of 20 requests allowed without delay
# Excess requests return 503
}
}
Rate limit by multiple dimensions:
- Per IP address (basic, can be bypassed with distributed attacks)
- Per authenticated user (prevents abuse from compromised accounts)
- Per API key (for API services)
- Per endpoint (protect expensive endpoints more aggressively)
Infrastructure-Level Rate Limiting
Cloud load balancers and CDNs provide rate limiting before traffic reaches your application servers.
# AWS WAF rate-based rule
{
"Name": "RateLimit",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} }
}
CDN as DDoS Shield
A Content Delivery Network (CDN) absorbs DDoS traffic by distributing it across a global network of edge servers. The attacker must overwhelm the CDN's entire capacity, not just your origin server.
How CDN Protection Works
Normal traffic flow:
Client → Origin Server
With CDN:
Client → CDN Edge (absorbs attack) → Origin Server (protected)
CDN providers with DDoS protection:
Provider DDoS Capacity Notable Features
──────────────────────────────────────────────────────────────
Cloudflare 296+ Tbps network Free tier includes DDoS,
automatic mitigation
AWS CloudFront Integrated with AWS Shield Standard (free)
+ AWS Shield AWS infrastructure AWS Shield Advanced (paid,
with DDoS response team)
Akamai Prolexic Dedicated scrubbing Enterprise-focused,
centers BGP-based rerouting
Google Cloud Google's network Cloud Armor for WAF and
Armor infrastructure DDoS rules
Origin Protection
A CDN only helps if attackers cannot bypass it. If your origin server's IP address is known, attackers can target it directly.
# Protect your origin
1. Do not expose the origin server's IP address
2. Restrict origin to accept traffic only from CDN IP ranges
3. Use CDN-provided origin certificates for mutual authentication
4. Change your origin IP if it was ever publicly exposed
# Nginx: allow only Cloudflare IPs
# (Cloudflare publishes their IP ranges)
allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
# ... (full list at cloudflare.com/ips)
deny all;
Web Application Firewalls (WAF)
A WAF inspects HTTP traffic at the application layer. It can block requests based on patterns, rate, geography, and reputation.
WAF capabilities:
- Block known attack patterns (SQLi, XSS payloads)
- Rate limiting by IP, URI, header, or cookie
- Geo-blocking (block traffic from specific countries)
- IP reputation lists (block known malicious IPs)
- Bot detection (CAPTCHA challenges for suspicious clients)
- Custom rules based on request attributes
WAFs are not a substitute for secure code. They are a defense-in-depth layer that catches common attacks and provides time to patch vulnerabilities. False positives are the main operational challenge -- legitimate requests blocked by overly aggressive rules.
Auto-Scaling
Sometimes absorbing an attack is cheaper and faster than blocking it. If your infrastructure can scale horizontally, auto-scaling can maintain availability during an attack while mitigation rules are tuned.
# AWS Auto Scaling policy for DDoS absorption
# Scale out when CPU exceeds 70% or request count spikes
{
"TargetTrackingScalingPolicy": {
"TargetValue": 70.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
},
"ScaleOutCooldown": 60,
"ScaleInCooldown": 300
}
}
Auto-scaling considerations:
- Set maximum instance limits to control costs. An attacker can drive your cloud bill to extreme levels (economic denial of service).
- Scale out quickly (short cooldown) but scale in slowly to avoid oscillation.
- Alert on unusual scaling events. A sudden scale-out may indicate an attack, not organic growth.
- Combine with rate limiting. Scaling without rate limiting just gives the attacker more resources to consume.
DDoS vs. Legitimate Traffic Spike
The hardest part of DDoS mitigation is distinguishing attacks from legitimate traffic. A product launch, viral social media post, or news event can produce traffic patterns identical to an application layer DDoS.
Signal DDoS Attack Legitimate Spike
────────────────────────────────────────────────────────────────────
Traffic sources Many IPs, similar Diverse IPs, organic
patterns, same region geographic distribution
Request patterns Same endpoint hit Varied endpoints,
repeatedly, no session normal user journeys,
progression session cookies
User agents Identical or missing Diverse, real browsers
user agents and devices
Conversion/engagement Zero engagement, no Normal engagement
clicks, no purchases patterns
Timing Sudden spike with Correlates with a
no external trigger known event
When in doubt, use progressive mitigation: start with rate limiting and CAPTCHA challenges rather than blocking. Monitor the effect and tighten rules incrementally.
Real-World DDoS Incidents
Dyn DNS Attack (2016)
The Mirai botnet, composed of approximately 100,000 compromised IoT devices (cameras, routers, DVRs), attacked Dyn, a major DNS provider. The attack took down DNS resolution for Twitter, Reddit, Netflix, GitHub, and dozens of other major services. The attack peaked at approximately 1.2 Tbps. This incident demonstrated that attacking shared infrastructure (DNS) has a cascading effect far beyond the direct target.
AWS (2020)
AWS disclosed mitigating a 2.3 Tbps DDoS attack, the largest volumetric attack publicly reported at that time. It was a CLDAP reflection attack. AWS Shield Advanced absorbed the traffic without customer impact. The incident highlighted that at massive scale, only large infrastructure providers can absorb volumetric attacks.
Common Pitfalls
- No DDoS plan until you are under attack. Define your response plan before an attack. Know who to contact, what tools to use, and how to activate mitigation.
- Relying only on application-level defenses. Application servers cannot handle volumetric attacks. You need infrastructure-level protection (CDN, cloud provider DDoS service) for network-layer attacks.
- Rate limiting only by IP. Distributed attacks use thousands of IPs. Rate limit by multiple dimensions: IP, user, API key, endpoint, and request fingerprint.
- Exposing origin server IPs. If attackers know your origin IP, they bypass your CDN. Restrict origin access to CDN IP ranges and do not expose the origin address in DNS history, email headers, or error pages.
- No cost controls on auto-scaling. An attacker can trigger massive auto-scaling and run up your cloud bill. Set maximum instance limits and budget alerts.
- Blocking legitimate users during mitigation. Overly aggressive blocking during a DDoS attack can cause more damage than the attack itself. Use progressive mitigation and monitor for false positives.
- Treating every traffic spike as an attack. A viral post or product launch looks like a DDoS. Verify with business context before activating aggressive mitigation.
Key Takeaways
- DDoS attacks operate at three layers: volumetric (flood bandwidth), protocol (exhaust connection state), and application (expensive requests). Each requires different defenses.
- Rate limiting should operate at multiple layers and multiple dimensions. IP-only rate limiting is insufficient against distributed attacks.
- A CDN is your first line of defense for volumetric attacks. Protect your origin server IP so attackers cannot bypass the CDN.
- WAFs provide application-layer protection against known attack patterns but require tuning to avoid false positives.
- Auto-scaling can absorb attacks but must have cost controls. Unlimited scaling means unlimited bills.
- Have a DDoS response plan before you need one. Know your escalation path, your provider's mitigation tools, and your communication plan.
- Distinguish DDoS from legitimate traffic spikes by analyzing traffic patterns, user agents, engagement metrics, and business context.