DDoS mitigation is the practice of detecting, absorbing and filtering distributed denial-of-service traffic so that legitimate users can still reach a service while it is under attack. In infrastructure defense, it combines network capacity, traffic scrubbing, rate limiting and application-layer filtering across several points between the attacker and the protected system.
A distributed denial-of-service attack floods a target from many sources at once, often from a botnet of compromised devices or from abused reflectors. Because no single source looks extreme, mitigation depends less on blocking addresses and more on separating good traffic from bad traffic at scale, ideally before it reaches the origin network.
How DDoS mitigation works
DDoS mitigation follows a detect, divert, filter and return cycle. Detection compares current traffic with a learned baseline, using flow telemetry such as NetFlow or IPFIX, packet sampling and application metrics. When traffic exceeds thresholds or shows attack signatures, it is diverted to scrubbing capacity, cleaned, and forwarded to the origin.
Diversion happens in one of two main ways. BGP-based diversion announces the victim prefix, usually a /24 or larger, from the provider’s scrubbing centers and returns clean traffic over a GRE tunnel or direct interconnect. DNS or proxy-based diversion points the hostname to a reverse proxy or content delivery network, which terminates connections and forwards only valid requests. Anycast networks spread attack traffic across many locations so that no single site absorbs the full volume.
The following table summarizes the stages of the mitigation cycle and what each one depends on.
| Stage | Main technique | Key dependency |
|---|---|---|
| Detection | Baseline deviation, signature matching | Accurate traffic telemetry |
| Diversion | BGP announcement, DNS or anycast routing | Pre-arranged provider integration |
| Filtering | ACLs, rate limits, challenges, behavioral rules | Scrubbing capacity and rule quality |
| Return | Clean traffic via tunnel or proxy | Low added latency and correct routing |
Attack types and matching countermeasures
Effective DDoS mitigation starts by classifying the attack by layer, because each class exhausts a different resource. Volumetric attacks fill links, protocol attacks fill state tables, and application-layer attacks consume server processing with requests that look legitimate.
| Attack class | Typical examples | Resource exhausted | Main countermeasure |
|---|---|---|---|
| Volumetric | UDP floods, DNS and NTP amplification | Link bandwidth (Gbps) | Upstream scrubbing, anycast absorption |
| Reflection and amplification | Memcached, CLDAP, SSDP reflection | Bandwidth via spoofed requests | Port and protocol filtering, source validation |
| Protocol (state exhaustion) | SYN floods, ACK floods, fragmentation | Firewall and load balancer state tables | SYN cookies, stateless filtering |
| Application layer (L7) | HTTP floods, slow requests, cache busting | CPU, threads, database capacity | WAF rules, rate limiting, bot challenges |
Volumetric attacks are measured in gigabits or terabits per second, protocol attacks in packets per second, and application attacks in requests per second. A modest HTTP flood of tens of thousands of requests per second can take down an application that easily survives a far larger UDP flood, which is why layer 7 protection cannot be skipped.
Deployment models for DDoS protection
Organizations choose between on-premises appliances, cloud scrubbing services and hybrid designs. The decisive factor is that an on-premises device cannot help once the upstream link is saturated, so any attack larger than the internet connection must be stopped further upstream.
| Model | Strengths | Weaknesses | Best fit |
|---|---|---|---|
| On-premises appliance | Fast reaction, full visibility, low latency | Limited by link capacity | Protocol and small L7 attacks |
| Always-on cloud proxy | Continuous filtering, strong L7 controls | All traffic routed via provider | Public web applications and APIs |
| On-demand scrubbing | Large capacity only when needed | Minutes of exposure during diversion | Networks announcing own prefixes |
| Hybrid | Local speed plus upstream capacity | Higher cost and integration work | Data centers and service providers |
| ISP-based filtering | Stops floods before the access link | Coarse controls, provider dependent | Basic volumetric protection |
Remotely triggered black hole routing (RTBH) is a last-resort technique in which the provider drops all traffic to the attacked IP address. It protects the rest of the network but completes the denial of service for that address, so it suits only non-critical targets or extreme events.
DDoS mitigation compared with other infrastructure defenses
DDoS mitigation is about availability under load, while most neighboring controls in infrastructure defense focus on confidentiality and integrity. Firewalls, IPS devices and WAFs contribute filtering logic, but a stateful firewall can itself become the first component to fail during a SYN flood because its connection table fills up.
| Control | Primary goal | Role during a DDoS attack |
|---|---|---|
| DDoS mitigation service | Keep services reachable | Absorbs and scrubs attack traffic |
| Firewall | Enforce access policy | Drops unwanted ports but holds limited state |
| WAF | Block malicious web requests | Filters HTTP floods with rate and bot rules |
| IPS | Stop known exploits inline | Can be overwhelmed by high packet rates |
| SIEM | Correlate security events | Records the incident, does not filter traffic |
Planning, testing and common mistakes
Mitigation quality depends heavily on preparation before an attack. A runbook should name the provider contacts, the diversion procedure, the expected time to mitigate, and who decides on drastic steps such as geo-blocking or black holing. Many teams accept a target of mitigation within minutes for always-on services and plan for longer during on-demand diversion.
- Exposed origin addresses: if attackers learn the real server IP, they bypass the proxy entirely; restrict the origin to accept traffic only from the provider.
- Untested failover: diversion that has never been exercised often fails on routing or certificate details; run controlled DDoS simulations with the provider’s approval.
- Static thresholds: limits set too high miss slow L7 attacks, while limits set too low block real users during marketing peaks.
- Ignoring DNS: an unprotected authoritative DNS service is a single point of failure even when the website is protected.
- No autoscaling guard: elastic cloud scaling may absorb an HTTP flood but produce a large bill, sometimes called economic denial of sustainability.
In plain words
A DDoS attack is like thousands of fake customers crowding the entrance of a shop so that real customers cannot get in. DDoS mitigation is the crowd control: extra space far from the door to hold the crowd, staff who check who is genuine, and a quiet side entrance that only real customers are sent through.
The key point is that the crowd must be handled before it reaches the door. Once the entrance is blocked, nothing inside the shop can fix it.
A real-world example
An online ticket seller expects a busy morning when a popular concert goes on sale. Ten minutes after opening, traffic jumps to several times the normal level, and analysis shows two parts: a UDP reflection flood of tens of gigabits per second against the data center link and an HTTP flood hitting the search page with randomized query strings to bypass the cache.
Because the company had a hybrid setup, the on-premises appliance signals the cloud provider, which announces the network prefix and starts scrubbing the reflection traffic upstream. At the same time, the web application firewall applies a per-client rate limit and a JavaScript challenge on the search endpoint. Within a few minutes, error rates fall back to normal, and genuine buyers complete their purchases while the attack continues to be absorbed.