Tools · Incident response playbooks · 19 / 20
Playbook: responding to a distributed denial of service against your site
Identify whether an outage is a DDoS, engage your provider or CDN, apply rate limits and filtering, communicate status, and review capacity and protections afterward.
Is it really a DDoS?
Outages also come from deployments, expired certificates, and upstream failures. Signs of an attack include traffic volume far above normal from many sources, floods of a single request pattern, unusual protocols such as UDP amplification traffic, or connection exhaustion at the load balancer. Check dashboards from the CDN, load balancer, and network provider.
Mitigate
Volumetric network floods must be absorbed upstream, by the ISP, a scrubbing service, or a cloud DDoS protection service such as AWS Shield, Azure DDoS Protection, Cloudflare, or Akamai. Application-layer floods can be reduced with CDN caching, WAF rate-limiting rules, bot challenges for suspicious clients, and temporarily disabling expensive endpoints such as search.
- Contact the provider’s DDoS response team early
- Enable stricter WAF or bot rules
- Rate limit by IP, ASN, or path
- Serve cached or static pages
- Protect origin IPs from direct access
Lab: design rate limits
Using your own lab web server behind nginx, configure a rate limit for the login path and test it with a load tool from another lab VM at a modest rate. Observe 429 or 503 responses in the logs once the limit is exceeded, and tune the burst value so normal browsing is unaffected. Only generate load against systems you own.
# nginx.conf (http block)
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;
# server block
location /login {
limit_req zone=login burst=10 nodelay;
limit_req_status 429;
proxy_pass http://app;
}
# from a second lab VM
hey -z 20s -c 20 http://lab-web.internal/login
awk '$9==429' /var/log/nginx/access.log | wc -lAfterwards
Communicate status regularly through a status page hosted separately from the affected infrastructure. Review whether origin servers were reachable directly, whether autoscaling increased cost without helping, and whether your provider contract includes DDoS response. Some attacks are distractions, so check security logs for other activity during the same window.
Diagram
Volumetric versus application-layer
Different layers, different defenses.
Example. UDP amplification, SYN flood
Where to stop it. ISP, scrubbing, cloud DDoS service
Your server can. Do little alone
Example. Floods of HTTP requests to search or login
Where to stop it. CDN, WAF rate limits, bot challenges
Your server can. Rate limit, cache, disable expensive paths
Check yourself
1. Where must large volumetric floods be mitigated?
2. Which nginx directive limits request rate per client?
3. Why review security logs during a DDoS?