This cheat sheet outlines how responders can prepare for and handle a distributed denial-of-service (DDoS) attack. It covers what to arrange with your DDoS protection provider and ISP before an attack. It also covers analyzing and mitigating the attack and handling extortion demands.
This cheat sheet outlines how responders can prepare for and handle a distributed denial-of-service (DDoS) attack. To print, use the one-page PDF version. You can also edit the Word version for your own needs. It grew out of the Network DDoS Incident Response Cheat Sheet from 2011 and now covers application-layer and DNS attacks as well. For other incidents, see the companion Initial Security Incident Questionnaire for Responders and the Security Incident Survey Cheat Sheet for System Administrators.
Prepare Before an Attack
- Put internet-facing services behind a DDoS protection provider, such as your CDN, so the provider can absorb and filter attack traffic.
- Find out whether the purchased DDoS protection is always-on or on-demand, what it covers, and how fast the mitigation can start.
- Keep DNS TTLs short to support quick DNS redirection if the original IPs get attacked.
- For self-hosted VPN, mail, or other non-web servers, consider arranging network-layer DDoS protection from your ISP or another provider.
- Given the importance of DNS, host authoritative DNS with an established, flood-resistant provider. Consider using two independent DNS providers.
- Configure servers behind the DDoS protection provider to accept traffic only from it, so attackers can’t access them directly.
- Make sure that servers that accept only the protection provider’s traffic still accept health checks, webhooks, and partner callbacks.
- Document the hosting and DDoS protection providers’ contact details and the steps you’ll need to take to activate the protection or get other help.
- Document which services are business-critical so you can prioritize them when dealing with a DDoS attack.
- Create a baseline of your normal traffic volume, request rates, and sources, so it’s easier to recognize an attack at its early stages.
- Set rate limits and bot rules on login, password reset, search, and APIs, since they’re often targeted, and test them against real traffic.
- Cap autoscaling and set billing alerts, since the cloud platform will likely charge you for the capacity it adds to handle the attack traffic.
- Designate people who’ll lead incident response, brief colleagues, and handle other incident tasks.
- Decide in advance who can approve drastic response steps, such as blocking a country’s traffic or taking a service offline temporarily.
- Conduct a tabletop exercise or a live drill of DDoS scenarios to test your plans and train your personnel.
Analyze the Attack
- Check with the provider and ISP first, since an outage on their side can appear like an attack on you.
- Determine the nature of the attack (e.g., does it fill your bandwidth, exhaust firewall connection tables, overload the application, etc.) to plan the response.
- Identify what distinguishes the attack traffic, such as source IPs, ports, URLs, or request patterns, so any filters you implement won’t block legitimate users.
- Pay close attention to other security signals, since the DDoS might conceal an intrusion attempt.
Mitigate the Attack
- Engage the DDoS protection provider first and ask it to tighten filtering for the targeted services.
- If you turn on a browser challenge (e.g., CAPTCHA) for all visitors, exempt API endpoints and mobile app traffic, which the challenge could block.
- Apply rate limits, browser challenges, or geographic blocks to the attacked URLs or endpoints, one change at a time, so you’ll know what worked.
- During the attack, have your CDN cache pages longer, serve expired copies rather than refetch them from your overloaded servers, and show a static placeholder for pages it can’t cache.
- Temporarily turn off features that put a heavy load on your servers, such as search, reports, and exports, to preserve capacity for essential functions.
- If the flood fills your internet connection, ask your ISP to blackhole the attacked IP address, sacrificing it so the rest of your network stays reachable.
- Share regular status updates with customers through channels that still work, such as a status page hosted on separate infrastructure.
Handle Extortion
- If you receive an extortion demand, check with your provider whether an attack is underway, and raise your protection in case one follows.
- Escalate the demand to executives and legal before anyone replies or pays, since it’s a business decision.
- Be mindful of the cyber insurance policy’s notice deadline and of which costs the insurer reimburses.
Wrap Up and Adjust
- Once traffic returns to normal, remove emergency filters one at a time, but keep the provider’s protection on, since attackers might come back.
- Save your logs before the retention period ends, get the provider’s attack summary, and keep any extortion message with its headers intact.
- Record the timeline and keep the evidence for the incident report, an insurance claim, or a law enforcement referral.
- Address what hindered your response to the attack, such as missing contacts, exposed servers, or a weak contract with the provider.
Other Incident Response Resources
- CISA, FBI, and MS-ISAC guide to DDoS attacks
- Companion Initial Security Incident Questionnaire, Security Incident Survey Cheat Sheet, and incident response report template
Post-Scriptum
Thanks to Daniel Fairchild, Chris Lemieux, Peter McLaughlin, Jose Nazario, Donald Smith, and Jim Tuttle for their insights on the 2011 version of this cheat sheet. If you have suggestions for improving it, please let me know. This cheat sheet is distributed under the Creative Commons Attribution 4.0 International License. Take a look at my other security cheat sheets.
