Cloudflare DDoS readiness checklist
Use this checklist to prepare Cloudflare DDoS protection before an incident. It covers public hostnames, DNS, origin exposure, SSL/TLS, critical paths, APIs, WAF and HTTP DDoS events, bot signals, rate limits, logs, alerts, emergency rules, rollback, and response ownership.
Use this checklist to prepare Cloudflare DDoS protection before an incident. It covers public hostnames, DNS, origin exposure, SSL/TLS, critical paths, APIs, WAF and HTTP DDoS events, bot signals, rate limits, logs, alerts, emergency rules, rollback, and response ownership.
Topics: cloudflare, resource, cloudflare, ddos, readiness, checklist
Machine-readable context: /ai-index.json
Step by step
Step-by-step checklist
- 1
Inventory public hostnames, IPs, and critical paths (login, checkout, APIs) and confirm which are proxied through Cloudflare.
- 2
Close direct-to-origin exposure: restrict origin firewalls to Cloudflare IP ranges and enable Authenticated Origin Pulls.
- 3
Baseline DNS, SSL/TLS mode, and origin reachability so failover and rate controls behave predictably under load.
- 4
Review HTTP DDoS managed-rule sensitivity and custom thresholds; confirm L3/4 protection for any non-HTTP services.
- 5
Design rate limiting and WAF rules for high-risk endpoints, starting in log/simulate mode.
- 6
Configure attack alerting (notifications, Logpush, dashboards) and define who responds.
- 7
Prepare an under-attack playbook: emergency rules, Under Attack Mode, escalation owners, and rollback criteria.
Risk register
Risks to control
Attackers bypass Cloudflare by hitting the origin IP directly.
Allowlist only Cloudflare IPs at the origin firewall, rotate exposed origin IPs, and enable Authenticated Origin Pulls.
Over-aggressive emergency rules block legitimate users.
Stage rate limits and WAF rules in log/simulate mode, review traffic, and keep rollback steps ready.
No clear ownership when an attack starts.
Define an escalation chain, on-call owners, and a written playbook before an incident.
Non-HTTP services (DNS, TCP/UDP apps) are left unprotected.
Use Spectrum or Magic Transit for L3/4 protection on services that are not plain HTTP(S).
Missing visibility during an attack.
Enable Logpush, dashboards, and alerting in advance so events are observable in real time.
Output
Useful deliverables
- Public attack-surface inventory (hostnames, IPs, critical paths).
- Origin-protection plan (Cloudflare IP allowlisting, Authenticated Origin Pulls).
- DDoS and rate-limiting configuration with staged enforcement.
- Alerting, Logpush, and dashboard setup.
- Under-attack playbook with owners and escalation.
- Rollback criteria for emergency rules.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
Does Cloudflare stop DDoS automatically?
Cloudflare's network mitigates many volumetric and HTTP attacks automatically, but readiness still matters: origin exposure, rate limits on sensitive endpoints, alerting, and a response playbook determine how well you handle a targeted attack.
Why protect the origin IP if Cloudflare is in front?
If the origin IP is reachable directly, attackers can bypass Cloudflare entirely. Allowlisting Cloudflare IPs and enabling Authenticated Origin Pulls forces traffic through the edge.
Should rate-limiting rules be enabled immediately?
Start them in log or simulate mode to observe real traffic and avoid blocking legitimate users, then promote to enforcement with rollback steps documented.
What about non-web services?
HTTP DDoS protection covers web traffic; TCP/UDP or DNS services need L3/4 options such as Spectrum or Magic Transit. Inventory these separately.
Nanosek
Assess DDoS readiness
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.