How resilient is your server to a DDoS — and how would you know?
Most sites find out during an attack. This checklist lets you find out in an afternoon — using only tests against infrastructure you own.
Bottom line: if your origin IP is exposed, one free tool floods it; if it's behind a real mitigation layer, the questions shift to L7 rate limits, state tables and your provider's thresholds. Work through the checklist below, then measure the two numbers that matter: your L4 ceiling (Gbps/Mpps) and your L7 ceiling (rps).
The 15-point DDoS resilience checklist
Is your real origin IP hidden?If a DNS record, certificate log or email header leaks the origin IP, attackers bypass whatever proxy sits in front. Check dig yourdomain history and crt.sh.
Does the origin only accept traffic from your proxy?Firewall the origin to your CDN/proxy IP ranges — otherwise hiding the IP is cosmetic.
Do you know your uplink capacity?1 Gbps? 10 Gbps? Your provider's DDoS terms? The answer is in your contract, not your hopes.
Have you measured your L4 floor?Where does packet loss first appear under iperf3-style pressure? That's your real bandwidth ceiling.
Have you measured your L7 floor?At what rps do expensive endpoints (search, login, cart) degrade? Often 10–100× lower than bandwidth.
Are state tables sized for floods?Conntrack/NAT tables fill before bandwidth on small routers — the classic 1 Mpps cliff.
Do per-IP rate limits exist?Requests/sec per IP on login/API endpoints — the cheapest L7 defense there is.
Is TLS handled at the edge?Handshake CPU exhaustion is a real vector; terminate at a layer you can scale.
Static assets cached?Every cache-miss is origin work an attacker can multiply.
Slow-client timeouts set?Slowloris-style attacks hold connections; sane timeouts release them.
Can you see it coming?Latency/error dashboards + alerts — attacks are noisy before they're fatal.
Do you have a response runbook?Who flips "under attack" mode, who calls the provider, what gets prioritized.
Have you tested failover?Origin down → cached/stale serving: does your site degrade gracefully or hard-fail?
Is your provider's abuse desk reachable?Know their flood threshold and null-route policy before you need it.
Have you rehearsed an incident?A 30-minute tabletop exercise beats discovering process gaps mid-flood.
Measuring your two ceilings — safely
Run these only against infrastructure you own, with a written scope if it's a client's:
L4 ceiling: push iperf3 traffic from an external host, ramping until packet loss exceeds ~2%. Note the number.
L7 ceiling: ramp wrk2/k6 against your most expensive endpoint; record the rps where p95 latency doubles or error rate moves.
Compare to threat size: commodity floods run 1–10 Gbps and ~50k–500k rps. If your ceilings are below that, you need upstream mitigation, not a bigger server.
Hide origin IP + proxy-front everything before anything else.
6–10
Fragile
Rate limits + timeouts + measured ceilings.
11–14
Resilient
Test against real load, write the runbook.
15
Hardened
Re-audit quarterly; threat sizes keep growing.
When self-help isn't enough
If your threat model includes sustained floods or motivated actors, the checklist's job is to tell you early. Serious mitigation is an upstream service problem: scrubbing centers, anycast absorption, and provider SLAs. It's also where documented, authorized load tests stop being optional — they become the acceptance test for whatever you buy.