How to Test Your DDoS Protection Before Attackers Do

You wouldn't deploy untested code to production. So why are you trusting untested DDoS protection?

Most organizations spend significant budgets on DDoS mitigation - CDNs, WAFs, scrubbing services - yet have never actually validated whether these defenses work. When the real attack comes, they discover gaps the hard way.

This guide provides a practical methodology for security engineers and DevOps teams to test DDoS resilience before attackers do.

The Testing Pyramid

Effective DDoS testing follows a pyramid approach, starting with the safest and most informative tests:

1. Configuration Audit - Review settings without sending traffic
2. Discovery Testing - Identify what's exposed (passive recon)
3. Synthetic Validation - Controlled, low-volume tests
4. Load Testing - Graduated stress testing
5. Red Team Simulation - Full adversary emulation (with authorization)

Level 1: Configuration Audit

Before sending any traffic, audit your existing configuration. Many vulnerabilities are visible in settings alone.

CDN Configuration Checklist

WAF Configuration Checklist

DNS Configuration

# Check for exposed origin records
dig +short ANY yourdomain.com
dig +short direct.yourdomain.com
dig +short origin.yourdomain.com
dig +short mail.yourdomain.com

# Check historical DNS records
# Services like SecurityTrails, DNSHistory, or Censys

Level 2: Discovery Testing

Passive reconnaissance reveals what attackers can see without triggering alerts. This is how attackers begin - and you should too.

Origin IP Discovery

Can attackers find your origin IP? Check these sources:

• Certificate Transparency Logs: crt.sh reveals all issued certificates
• Historical DNS: Old A records may point to origin
• Email Headers: SPF, DKIM, and email server IPs
• Subdomains: Often point directly to origin
• Shodan/Censys: Indexed servers matching your SSL cert

# Check certificate transparency for all subdomains
curl -s "https://crt.sh/?q=%.yourdomain.com&output=json" | jq '.[].name_value'

# Check if origin IP responds directly
curl -I --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com

Attack Surface Mapping

Map every endpoint that accepts traffic:

• Web servers (ports 80, 443)
• API endpoints (including versioned paths)
• WebSocket connections
• Administrative interfaces
• Health check endpoints
• Legacy systems still running

Level 3: Synthetic Validation

Now we send controlled traffic to validate protection is working. Start small.

Rate Limit Testing

# Test rate limiting (adjust numbers based on your limits)
for i in {1..100}; do
  curl -s -o /dev/null -w "%{http_code}\n" https://yourdomain.com/api/endpoint
  sleep 0.1
done | sort | uniq -c

# Expected: After threshold, you should see 429 or challenge responses

WAF Rule Validation

# Test if WAF blocks common attack patterns
# SQLi test (should be blocked)
curl "https://yourdomain.com/?id=1' OR '1'='1"

# XSS test (should be blocked)
curl "https://yourdomain.com/?q="

# Path traversal test (should be blocked)
curl "https://yourdomain.com/../../../etc/passwd"

# Large payload test
dd if=/dev/zero bs=1M count=10 | curl -X POST -d @- https://yourdomain.com/api/upload

Protocol Validation

# Test HTTP/2 handling
curl --http2 -I https://yourdomain.com

# Test with unusual headers
curl -H "X-Forwarded-For: 1.2.3.4" \
     -H "X-Real-IP: 5.6.7.8" \
     https://yourdomain.com

# Test slow client handling (slowloris-style)
# Use only on your own systems!
timeout 30 bash -c 'exec 3<>/dev/tcp/yourdomain.com/443; echo -e "GET / HTTP/1.1\r\nHost: yourdomain.com\r\n" >&3; sleep 25; cat <&3'

Level 4: Load Testing

Graduated load testing reveals capacity limits before attackers find them.

Tools for Load Testing

• k6: Modern load testing with JavaScript scripting
• Locust: Python-based, distributed testing
• wrk: High-performance HTTP benchmarking
• Artillery: Cloud-native load testing
• Gatling: Scala-based, detailed reporting

Graduated Load Test Plan

# Example k6 script with graduated load
import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
  stages: [
    { duration: '2m', target: 100 },   // Ramp up
    { duration: '5m', target: 100 },   // Steady state
    { duration: '2m', target: 500 },   // Push higher
    { duration: '5m', target: 500 },   // Observe
    { duration: '2m', target: 1000 },  // Stress test
    { duration: '3m', target: 1000 },  // Observe degradation
    { duration: '2m', target: 0 },     // Ramp down
  ],
};

export default function() {
  let res = http.get('https://yourdomain.com/api/test');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

Metrics to Monitor

• Response time: P50, P95, P99 latencies
• Error rate: 5xx responses, timeouts
• Throughput: Requests per second
• Origin health: CPU, memory, connections
• CDN metrics: Cache hit ratio, bandwidth
• Cost: Bandwidth charges, compute scaling

Level 5: Adversary Simulation

The most comprehensive test: simulate real attack patterns. This requires explicit authorization and should be performed by experienced professionals.

Attack Patterns to Simulate

1. Volumetric: High bandwidth, simple requests
2. Protocol: TCP/UDP exhaustion, SYN floods
3. Application: Expensive queries, regex DoS
4. Multi-vector: Combined approaches
5. Low-and-slow: Slowloris, R.U.D.Y.

Questions to Answer

• At what traffic level do defenses engage?
• How long until mitigation kicks in?
• What's the customer impact during mitigation?
• Do alerts fire correctly?
• Can the team execute runbooks effectively?
• What's the cost of mitigation?

Common Gaps We See

After testing hundreds of organizations, these are the most common findings:

1. Origin Exposure (73% of sites): CDN can be bypassed entirely
2. Rate Limits Too High: Set at 10,000 req/min when 100/min is normal
3. API Unprotected: CDN only covers web, not api.domain.com
4. No Challenge for Bots: No CAPTCHA or JavaScript challenge
5. Logging Gaps: Can't forensically analyze attack patterns
6. No Runbook: Team doesn't know escalation procedures

Building a Testing Program

DDoS testing shouldn't be a one-time event. Build it into your security program:

• Monthly: Configuration audits (Level 1)
• Quarterly: Discovery testing (Level 2)
• Semi-annually: Synthetic validation (Level 3)
• Annually: Full load testing (Level 4)
• As needed: Red team exercises (Level 5)

What to Do With Findings

Testing is only valuable if you act on results:

1. Document everything: Screenshots, logs, metrics
2. Prioritize by risk: Origin exposure > rate limits > logging
3. Fix and verify: Retest after remediation
4. Update runbooks: Reflect what you learned
5. Brief stakeholders: Share findings with leadership