title: How to respond to a DDoS attack description: A defensive DDoS runbook: confirm it's really an attack, engage upstream mitigation, tune your CDN and WAF, and communicate while you recover. heroImageAlt: "Green line-art umbrella shielding a database from falling dots, above a spiking traffic line, on a dark grid" date: 2026-06-10 tags: [security, ddos, incident-response] author: Trace Warrior Team
Your site is down or crawling, traffic is 50x normal, and the on-call channel is lighting up. This is the runbook for the next hour: confirm it's an attack, push mitigation to the layers that can absorb it, and keep people informed.
One framing note first: DDoS response is entirely defensive. You absorb, filter, and outlast. There is no useful "counterattack" - the traffic comes from compromised machines and spoofed sources, not the attacker, and retaliating is illegal in most jurisdictions anyway. The goal is service restoration, full stop.
Step 0. Prepare before it happens
Everything below is ten times harder if you're doing it for the first time mid-incident. The preparation list is short:
- Know your baseline. You can't spot abnormal traffic without knowing normal. Keep a website uptime monitor running so you have response-time history and get paged the moment availability degrades, rather than when a customer tweets.
- Front your origin with a CDN/proxy (Cloudflare, Fastly, CloudFront) before you need it. Emergency onboarding mid-attack is possible but miserable.
- Keep your origin IP secret. If attackers can hit the origin directly, the CDN is decoration. Firewall the origin to accept traffic only from your CDN's published ranges.
- Have your provider's emergency contacts written down - hosting support, CDN account team, ISP NOC. Not "findable," written down in the runbook.
Reading this mid-attack? Skip ahead; come back to step 0 afterwards.
Step 1. Confirm it's actually an attack
Not every spike is hostile. A product launch, a viral post, or a misconfigured client retry loop can all look like a DDoS from the inside. Check:
- Does the traffic correlate with anything legitimate? Marketing email, press coverage, app release?
- What does the request pattern look like? Legitimate surges spread across many pages with normal user behaviour. Attack traffic tends to hammer one or a few endpoints (often the homepage, login, search, or anything expensive like a report generator) with abnormal uniformity - identical user agents, no referrers, requests at machine-perfect intervals.
- Where is it coming from? Pull the top source IPs from your access logs and spot-check a handful through the IP Geolocation tool. A sudden flood from hundreds of hosting-provider ASNs across thirty countries, against a product sold in one country, is a strong attack signal. WHOIS on the top netblocks tells you whether you're looking at residential botnet traffic or rented servers.
- Which layer is being hit? Volumetric floods (UDP, SYN) saturate bandwidth and show up as packet loss network-wide - an external ping test confirms reachability. Application-layer (L7) attacks look like valid HTTP and exhaust CPU, database connections, or worker pools instead.
Note the confirmation time and the traffic signature - your provider and your post-incident review both need them.
Step 2. Engage upstream mitigation immediately
The most important fact in this runbook: you cannot absorb a serious DDoS at your own server. If the attack saturates your inbound link, iptables rules are irrelevant - the packets consumed the bandwidth before your kernel dropped them. Mitigation must happen upstream, at someone with more capacity than the attack.
In parallel:
- Contact your hosting provider / ISP. Most have DDoS mitigation (scrubbing, upstream filtering, null-routing specific targets) they can enable on request. Give them the start time, target IPs/ports, and traffic signature from step 1.
- Escalate at your CDN. If you're behind Cloudflare, enable Under Attack mode; equivalents exist at other providers. This inserts challenge pages that cost bots more than they cost real users.
- If you have no CDN, onboard one now. Emergency onboarding means changing DNS to route through the provider - painful mid-incident because of DNS TTLs, but it's the path that ends most L7 attacks.
Be aware of the blunt instruments: a provider may null-route your IP entirely if the attack threatens their other customers, which completes the attacker's job for them. Another reason to get scrubbing in place early.
Step 3. Filter at the CDN/WAF layer
Once traffic flows through a layer with capacity, start carving the attack out of it. Work from cheapest, safest rules to most aggressive:
- Rate limiting on the hammered endpoints - per-IP and per-session limits on login, search, and API routes. This caps damage even from sources you haven't identified.
- Block the obvious signature. If 90% of attack requests share a user agent, an ASN, or a malformed header, write a WAF rule for it. Attack tools are often lazy and uniform.
- Geo-restrictions, carefully. If you serve one region and the flood comes from elsewhere, a temporary geo-block is effective. It will also block legitimate travellers and VPN users - acceptable during an incident, but revert it afterwards.
- Challenge before block. JavaScript or managed challenges filter dumb bots without hard-blocking shared IPs (corporate NAT, carrier-grade NAT) where one address represents thousands of real users.
- Cache aggressively. Anything that can be served static during the incident, should be. A cached homepage costs the attacker the same to request and costs you nearly nothing to serve.
Avoid per-IP blocking as a primary strategy. Botnets rotate sources faster than you can list them; signatures and rate limits scale, IP lists don't.
Step 4. Protect the origin
While the edge absorbs the flood:
- Verify the origin only accepts CDN traffic. Attackers who know your origin IP will go around the CDN.
- Shed load deliberately. Disable expensive features (search, exports, report generation) temporarily rather than letting them take down everything. A degraded site beats a dead one.
- Watch the secondary failure modes. Connection-pool exhaustion, disks filled by 50x log volume, and runaway auto-scaling bills are all real DDoS damage.
Step 5. Communicate
Silence during an outage costs more trust than the outage itself.
- Internally - one incident channel, one coordinator, timestamps on every action. You will not remember the sequence afterwards.
- Externally - a status page update within 30 minutes: "We're experiencing a denial-of-service attack affecting availability; mitigation is in progress." You need acknowledgement and a cadence ("next update in 60 minutes") that you actually keep, not detail.
- Don't speculate publicly about who's attacking or why. Attribution is genuinely hard and public guesses age badly.
If the attack comes with an extortion demand, don't pay and don't reply - payment marks you as a payer. Report it to law enforcement or your national CERT.
Step 6. Stand down and review
Attacks end, often abruptly. Before relaxing:
- Keep heightened protections (rate limits, challenge mode) up for 24-48 hours; re-tests after a stand-down are common.
- Roll back the blunt rules (geo-blocks, feature disables) one at a time, watching the uptime monitor as you go.
- Preserve logs from the attack window before rotation eats them.
- Run a post-incident review: time to detection, time to mitigation, what worked, and which parts of step 0 were missing. Fix those.
Common mistakes
Fighting a volumetric flood at your own server. If the pipe is full, host-level filtering is too late. Escalate upstream first, tune locally second.
Blocking IPs one at a time. Rotating botnets make manual IP lists a treadmill. Rate limits and signature rules scale; lists don't.
Leaving the origin exposed behind the CDN. Lock origin ingress to CDN ranges or the attacker simply goes around.
Going silent. A 30-minute status update cadence costs nothing and preserves customer trust.
Mistaking success for the end. Attackers re-test. Keep defences elevated for a day or two after traffic normalises.
TL;DR
- Confirm it's an attack: compare against baseline, inspect the request signature, spot-check sources via IP geolocation and WHOIS.
- Escalate upstream immediately - hosting provider mitigation and CDN attack mode. You can't absorb it locally.
- Filter at the edge: rate limits, signature-based WAF rules, challenges, aggressive caching.
- Lock the origin to CDN traffic only and shed expensive features.
- Communicate on a fixed cadence, internally and on your status page.
- Keep defences up 24-48 hours after it stops, run the review, and set up uptime monitoring so detection is never the slow part again.
Related
- Website uptime monitoring - get paged at minute one, not when customers notice
- IP Geolocation tool - characterise attack sources during triage
- Ping Test - external reachability check when you suspect link saturation
- How to trace an IP address location - deeper source investigation after the fire is out