DDoS attacks have become more accessible and more damaging than ever. Booter services let anyone launch volumetric attacks for a few dollars. Application-layer attacks that mimic legitimate traffic are increasingly common. And the financial impact — downtime, emergency mitigation costs, reputational damage — is significant for any organisation with internet-facing services.
A DDoS protection strategy isn’t about preventing every attack. It’s about ensuring that attacks don’t translate into meaningful downtime. This guide covers the attack landscape, the defence architecture, and how to select and implement appropriate protection.
Understanding DDoS Attack Types
Volumetric Attacks (Layer 3/4)
Volumetric attacks overwhelm your network bandwidth or infrastructure with raw traffic volume.
UDP Flood: Send massive volumes of UDP packets to random ports. The target generates ICMP “destination unreachable” responses until bandwidth is exhausted. Easy to generate, hard to filter without DDoS infrastructure.
DNS Amplification: Attacker sends DNS queries with a spoofed source IP (your IP). DNS resolvers respond to you with responses much larger than the query (amplification factor of 28–54x). Multi-gigabit attacks with minimal attacker bandwidth.
ICMP Flood / Ping Flood: Flood the target with ICMP echo requests. Classic, less common now, but still used.
SYN Flood (Layer 4): Flood the target with TCP SYN packets but never complete the handshake. Exhausts connection state tables on servers and firewalls.
Measured in: Gbps (gigabits per second) or Mpps (millions of packets per second)
Notable scale: Attacks exceeding 1 Tbps are documented (Mirai botnet attacks in 2016 reached 1.1 Tbps against Dyn DNS). Cloudflare mitigated a 5.6 Tbps attack in 2024.
Protocol Attacks (Layer 4)
Exploit weaknesses in Layer 3 and 4 protocols to exhaust server resources:
Smurf Attack: ICMP flood using broadcast amplification. Fragmentation Attack: Malformed IP fragments that consume processing resources. BGP Hijacking: Rare but devastating — attackers reroute your traffic.
Application Layer Attacks (Layer 7)
The most sophisticated and hardest to defend against because they look like legitimate traffic:
HTTP Flood: Send millions of seemingly legitimate HTTP GET or POST requests to resource-intensive endpoints. A request to generate a PDF or run a complex report can consume 1000x more resources than a simple page load.
Slowloris: Open many HTTP connections and send headers very slowly, tying up web server connection threads without completing requests. Effective against Apache, less so against nginx or CDNs.
DNS Query Flood: Flood your DNS servers with queries for your own domains. Response rate limiting (RRL) on DNS servers mitigates this.
Credential Stuffing / Login Floods: Disguised as an application-layer DDoS — many IP addresses attempting authentication. Exhausts authentication server resources while also attempting account takeover.
SSL/TLS Negotiation Attacks: Flood with SSL handshake initiation requests. TLS negotiation is computationally expensive — an attacker can exhaust server CPU with a fraction of the bandwidth.
Measured in: Requests per second (RPS) — attacks commonly reach 1-10 million RPS.
The Layered Defence Model
No single control stops all DDoS attack types. Effective protection is layered:
Attacker Traffic
↓
[Layer 1] CDN / DDoS Scrubbing Centre
- Network-layer attack absorption (volumetric, SYN flood)
- BGP anycast routing, globally distributed capacity
↓
[Layer 2] WAF / Application Firewall
- HTTP flood rate limiting
- Reputation-based blocking
- Bot detection and challenge
↓
[Layer 3] Load Balancer / API Gateway
- Connection limiting
- Request routing
↓
[Layer 4] Application / OS Level
- Rate limiting in application code
- Connection timeout tuning
- Resource limits
↓
[Layer 5] Monitoring and Response
- Traffic anomaly detection
- Alerting and [incident response](/services/managed-soc)
Each layer handles a different attack type. Together, they provide resilience that no single layer can deliver.
Layer 1: CDN and DDoS Scrubbing
The first and most important layer. For internet-facing web applications, this means routing all traffic through a DDoS-capable CDN or dedicated scrubbing service.
CDN-Based Protection
Cloudflare:
- Unmetered DDoS protection at all plan levels (including free)
- 300+ PoPs globally — volumetric attacks are absorbed across the entire network
- Network capacity of 296 Tbps — can absorb the largest known attacks
- L3/L4 DDoS protection automatic; L7 via WAF rules and rate limiting
- Best for: Web applications and APIs of any size
Fastly:
- Enterprise CDN with DDoS capabilities
- More customisable than Cloudflare but fewer automatic protections
- Best for: Large media and content platforms
AWS CloudFront + AWS Shield:
- CloudFront provides global CDN; Shield adds DDoS protection
- Shield Standard (free): L3/L4 protection automatically
- Shield Advanced ($3,000/month): L7 protection, DRT (DDoS Response Team) access, cost protection
- Best for: AWS-native architectures already using CloudFront — pair with a cloud security assessment to identify your full exposure
Azure Front Door + DDoS Protection:
- Global front door with integrated WAF and DDoS
- DDoS Protection Standard ($2,944/month/VNet) provides L3/L4 + adaptive L7 tuning
- Best for: Azure-native architectures
Dedicated Scrubbing Services
For non-HTTP traffic or IP-level protection (gaming servers, VoIP, financial APIs):
- Cloudflare Magic Transit: Routes IP traffic through Cloudflare via BGP, scrubbing before delivery
- Radware Cloud DDoS Protection: Dedicated scrubbing with behavioural analysis
- Imperva DDoS Protection: Industry-leading time-to-mitigate (< 3 seconds SLA)
- Akamai Prolexic: High-bandwidth scrubbing for enterprises
On-Premise DDoS Appliances
For organisations that need to handle traffic before it leaves their data centre or reaches cloud services:
- Arbor Networks (NETSCOUT): Market leader in carrier-grade DDoS protection appliances
- Fortinet FortiDDoS: Hardware appliances for on-prem protection
- A10 Thunder TPS: Purpose-built DDoS protection
When to use on-premise: Latency-sensitive applications (financial trading, gaming), regulatory requirements to keep traffic on-premises, environments not suitable for CDN fronting.
Layer 2: WAF and Application-Layer Controls
The CDN absorbs volumetric attacks. Application-layer attacks (HTTP floods) require the WAF.
Rate Limiting
Rate limiting is the primary control for HTTP-layer DDoS:
Rule: High-volume requests from single IP
Expression: More than 1,000 requests per minute from one IP
Action: Challenge (CAPTCHA) → Block if challenge fails
Rule: Endpoint-specific protection
Expression: More than 100 POST /api/search requests per minute from one IP
Action: Block for 10 minutes
Rule: Login endpoint protection (also stops credential stuffing)
Expression: More than 10 POST /auth/login per minute from one IP
Action: Block for 1 hour
Bot Management
Sophisticated HTTP floods use distributed botnets with legitimate-looking user agents. Bot management:
- Analyses request patterns, headers, timing, and JavaScript execution
- Assigns a bot score to each request
- Challenges or blocks requests below a confidence threshold
Geographic Restrictions
If your application only serves certain regions, block traffic from others:
Rule: Only allow traffic from target regions
Expression: IP country not in {IN, US, GB, AU, SG}
Action: Block (or challenge)
Use carefully for B2B/B2C applications where you genuinely don’t serve other regions. Never use this as the only DDoS mitigation — bots use VPNs and residential proxies.
Layer 3: Infrastructure-Level Controls
Anycast Routing
CDNs use anycast — the same IP announced from hundreds of PoPs globally. When an attacker floods an anycast IP, traffic is distributed across all PoPs. A 500 Gbps attack against Cloudflare’s anycast network reaches 500 Gbps across 300+ PoPs — each absorbs 1.7 Gbps. Manageable.
Origin IP Concealment
If attackers discover your origin server’s IP, they can bypass your CDN entirely:
- Never expose your origin IP in DNS — all records should point to CDN
- Rotate origin IP periodically (once per year minimum)
- Firewall origin server to only accept traffic from CDN IP ranges
- Check historical DNS records — attackers use Shodan, SecurityTrails, and Wayback Machine to find your pre-CDN IP
# Lock origin to Cloudflare IPs only (AWS security group)
# Get current Cloudflare IPs
curl -s https://www.cloudflare.com/ips-v4
# Revoke all non-Cloudflare inbound HTTP/HTTPS rules
# Add each Cloudflare CIDR as allowed
Connection Limits and Timeouts
On your web server, tune connection handling:
Nginx:
# Limit connections per IP
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
limit_conn conn_limit 20; # Max 20 simultaneous connections per IP
# Limit request rate
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=30r/s;
limit_req zone=req_limit burst=50 nodelay;
# Timeout configuration (defend against Slowloris)
client_body_timeout 10s;
client_header_timeout 10s;
keepalive_timeout 5s 5s;
send_timeout 10s;
Application-level:
# Rate limiting in FastAPI
from slowapi import Limiter, _rate_limit_exceeded_handler
from slowapi.util import get_remote_address
limiter = Limiter(key_func=get_remote_address)
@app.get("/search")
@limiter.limit("20/minute")
async def search(request: Request, query: str):
# Expensive search operation
...
Layer 4: DNS Protection
DNS is frequently targeted — a successful attack on your DNS takes down your entire internet presence:
Use a DDoS-hardened DNS provider:
- Cloudflare DNS (free) — protected by the same anycast infrastructure
- Amazon Route 53 — AWS-scale protection
- NS1 — enterprise-grade with DDoS protection
Configure DNS properly:
- Enable DNSSEC to prevent cache poisoning
- Set appropriate TTLs — low TTLs make failover faster; high TTLs reduce query volume
- Use multiple DNS providers for redundancy (failover if primary DNS is attacked)
DDoS Incident Response
When you’re under attack (having 24/7 security monitoring in place dramatically reduces response time):
Immediate Response (first 15 minutes)
- Confirm it’s DDoS — distinguish from traffic spike, infrastructure failure, or misconfiguration
- Characterise the attack — volumetric or application-layer? Which endpoints? What’s the source pattern?
- Enable “under attack” mode — Cloudflare and others have emergency modes that add challenges to all visitors
- Communicate internally — notify engineering, on-call, and leadership
- Engage DDoS response team — if you have Shield Advanced (AWS) or an enterprise CDN contract, call the DRT/support
Mitigation (first hour)
- Implement emergency rules — block attacking IPs/ASNs/countries at WAF if pattern is identifiable
- Rate limit aggressively — temporarily reduce thresholds on affected endpoints
- Scale infrastructure — auto-scaling helps for application-layer attacks that bypass CDN; doesn’t help for volumetric attacks hitting CDN
- Reroute traffic — if under BGP-level attack, work with upstream provider
Recovery
- Gradually lift emergency controls as attack subsides — monitor traffic patterns
- Document the attack — timeline, attack characteristics, mitigation steps
- Post-incident review — what worked, what failed, what permanent improvements to make
Choosing the Right Level of Protection
| Profile | Recommended Protection |
|---|---|
| Small website, WordPress/CMS | Cloudflare Free/Pro — sufficient for most attacks |
| SaaS application | Cloudflare Business or Enterprise + WAF + rate limiting |
| Fintech / financial services | Cloudflare Enterprise or Akamai Prolexic + dedicated DRT access |
| Gaming / latency-sensitive | Magic Transit (Cloudflare) or Radware for IP-level protection |
| Enterprise with on-prem | Arbor/Netscout on-prem + cloud scrubbing hybrid |
| Healthcare / critical infrastructure | Multi-vendor redundancy + dedicated scrubbing + 24/7 DRT |
Testing Your DDoS Protection
Don’t wait for an attack to find out if your protection works:
Penetration testing with DDoS testing:
- Engage a third-party to conduct controlled DDoS testing in agreement with your CDN provider
- Test specific attack types (HTTP flood, SYN flood, Slowloris) against your environment
- Verify that alerting fires, response procedures activate, and mitigation is effective
Tabletop exercise:
- Without any actual attack, walk through your DDoS incident response procedure
- Identify gaps in communication, tooling, or escalation paths
Load testing (not DDoS testing):
- Load testing tools (Locust, k6, Artillery) can test how your application handles high request volumes
- Not the same as DDoS testing, but validates infrastructure scaling
CyberneticsPlus designs and implements DDoS protection architecture for clients across financial services, SaaS, and e-commerce. We’ve helped organisations survive multi-gigabit attacks with zero downtime. Contact us to assess your current DDoS posture.