How do you put a DDoS mitigation strategy in place?

A DDoS mitigation strategy has four parts: knowing what normal traffic looks like, absorbing or filtering floods upstream of your servers, a written response plan, and monitoring for attacks that distract from something else. Most of the work happens before the attack, because during one there is little time to design anything.

What is a DDoS attack?

CISA describes a denial of service attack as flooding a target with traffic so legitimate users cannot reach systems, websites, email or accounts. In a distributed attack many machines, often hijacked internet connected devices in a botnet, attack one target together, which makes the source harder to trace. CISA notes that botnets may be rented through attack for hire services and that the owners of infected devices are victims too. It names two classic methods: smurf attacks, where spoofed broadcast requests make many hosts flood the victim, and SYN floods, which open many connections without finishing the handshake and tie up ports.

How do you recognize one?

CISA lists symptoms: unusually slow network performance, a particular website unavailable, or no websites accessible. These also come from maintenance and ordinary faults, so monitoring is needed to confirm. Compare against a baseline. If you have never measured normal request rates, you cannot say what a spike means.

What does CISA recommend?

The prevention list is practical:

• Subscribe to a protection service that detects abnormal traffic and filters it.
• Create a disaster recovery plan covering communication, mitigation and recovery.
• Use a firewall to restrict incoming and outgoing traffic.
• Keep antivirus software maintained, since compromised machines join botnets.
• Monitor traffic with a firewall or intrusion detection system and set alerts for unusual load.

For response, CISA says to contact your network administrator to rule out internal causes, contact your internet service provider to check whether they have an outage or are the target, and keep watching other hosts and services, since a flood may be a distraction for a second attack.

How does the strategy fit together?

Capacity upstream. A flood that exceeds your connection cannot be fixed at your firewall, because the link is already full. That is why a protection service or provider scrubbing sits upstream, where large volumes can be absorbed.

Edge filtering. Drop traffic you never expect, such as spoofed source addresses and unused protocols, with simple router rules.

Application layer. Floods of legitimate looking requests need rate limits, caching and challenges at the application or a web application firewall.

Resilience. Spread across more than one location or provider where you can, and make sure that expensive operations, such as search and login, are limited per client.

People and process. A plan with named contacts, decision rights and customer messaging.

Constructed example: the ticket sale

A ticketing site expects heavy demand on release day, and a competitor's disgruntled supporter starts a flood against the checkout page. The team had agreed in advance: traffic is routed through a protection service with rate limits on the checkout endpoint, a static waiting page can be switched on, and the on call lead has authority to enable stricter rules without approval. Normal sales slow but continue. Meanwhile one engineer keeps watching the admin portal logs for anything unusual, in line with CISA's warning about distraction attacks. The company is imagined, but the preparation reflects the guidance.

What do teams forget?

A runbook that nobody has read. Contact details for the provider. A baseline of normal traffic. A decision about what to degrade first. And testing: simulate load in a controlled way, with the provider's permission, so that you learn what breaks before an attacker shows you.

How to check or apply this

1. Measure normal traffic by hour and day, and set alerts for deviations.
2. List the services whose outage would hurt most, and their dependencies.
3. Put a protection service or upstream filtering in front of public services.
4. Add rate limits and caching on expensive endpoints.
5. Write a response runbook with contacts for your provider, host and leadership.
6. Decide in advance what to switch off or degrade under load.
7. Review logs of other systems during an attack in case it is a distraction.

Quick check

Sources

• CISA, Understanding Denial of Service Attacks

Last reviewed: 18 October 2026.