DDoS Mitigation for ISPs: A Practical Baseline

For an ISP, distributed denial-of-service attacks are not an exotic threat — they are routine weather. A single targeted customer can pull enough hostile traffic to saturate a shared link and take service offline for everyone behind it, even though that customer was the only intended victim. That collateral blast radius is what makes DDoS an ISP problem rather than a customer problem: the damage is shared whether or not the target is.

You cannot prevent attacks from being launched, but you can build layers that detect them early, blunt the volumetric ones before they fill your links, and clean the traffic for the customers worth protecting. The right mental model is defence in depth, not a single magic box. This guide walks the layers in the order most ISPs should build them, explains how each works and where each fails in production, and ends with a runbook so the response is calm and consistent at three in the morning rather than improvised under pressure.

The defence layers at a glance

Each layer addresses a different part of the problem, and each has a cost and a limit. Build the always-on layers first; reach for the heavier ones as your scale and your attackers justify the investment.

See it first: flow-based detection

You cannot mitigate what you cannot see, so detection is the foundation everything else builds on. Flow telemetry — NetFlow, sFlow, or IPFIX exported from your routers — gives you a continuous view of traffic volumes and patterns across the network. An attack shows up as an anomaly against that baseline: a sudden surge of traffic aimed at a single customer IP, a flood of one specific protocol or port, or a spike of small packets from a scatter of sources. Good detection turns an attack from a vague why is everything slow into a precise, actionable alert within minutes.

The practical caveat is that flow on high-speed interfaces is usually sampled, which is excellent for spotting volumetric events and identifying top targets but less reliable for small, low-rate, application-layer attacks that hide inside normal traffic. Tune your detection thresholds against your own baseline rather than copying generic numbers, because an alert that fires constantly is one nobody acts on. Flow detection is the same layer that underpins capacity planning and abuse spotting more broadly — see monitoring an ISP network for how it fits the wider stack.

Filter the obvious: anti-spoofing hygiene

A large share of attack traffic, particularly the reflection and amplification attacks that produce the biggest floods, depends on spoofed source addresses. Source address validation — the principle codified as BCP 38 — means configuring your network so it only forwards traffic whose source address legitimately belongs to the customer or segment it came from. Implemented at the edge and on access aggregation, this stops your own subscribers, whether malicious or compromised, from being used to attack others.

There are two reasons to do this even though it protects others more than yourself. First, it is good citizenship that materially reduces the global pool of spoofable capacity, and the favour is reciprocal — networks that practise it are the ones the community helps when they are under attack. Second, being a known good neighbour earns real goodwill with upstreams and peers, which is exactly the currency you spend when you need them to blackhole or scrub for you in an emergency. Pair source validation with sensible edge filtering of plainly bogus traffic — packets from reserved ranges, obviously invalid combinations — to trim noise before it ever reaches the parts of your network that matter.

Steer and drop: remote-triggered blackhole

When a single target is under a flood large enough to threaten the links it shares, the fastest first response is to stop carrying that traffic at all. Remote-triggered blackhole (RTBH) uses BGP to signal — to your own edge routers or, more powerfully, to your upstream provider — that all traffic destined for the victim's address should be dropped. Done upstream, it discards the flood before it ever reaches your network, which is the only way to survive an attack that is bigger than your own links.

The trade-off is brutal and worth naming plainly: blackholing completes the attacker's goal for that one address by taking the victim entirely offline. You are sacrificing the single target to protect everyone else sharing the infrastructure. That is often the correct call when a link is seconds from drowning and thousands of other subscribers are at risk, but it is a blunt instrument. The prerequisites are arranged in advance — a blackhole community agreed with your upstream and tested before you need it — because the middle of an attack is the wrong time to discover the mechanism does not work. RTBH lives at the network edge alongside your other BGP policy; for the role of that edge, see what a BNG does.

Clean it: scrubbing, in-house versus upstream

Blackholing protects the network but finishes the job against the victim — unacceptable for a paying customer who expects you to keep them online, not take them down. The next level up is scrubbing: instead of dropping all traffic to the target, you divert it through a filtering system that strips out the attack traffic and forwards the legitimate traffic on to the customer. The customer stays online through the attack, which is the outcome they are actually paying for.

The real decision is build versus buy. In-house scrubbing gives you control and avoids per-incident fees, but it demands significant, expensive capacity that sits idle most of the time and only helps with attacks smaller than that capacity. Most ISPs, especially when starting out, lean on an upstream provider's scrubbing service or a specialist third party, paying for clean-pipe protection or on-demand mitigation rather than owning the hardware. This scales naturally: the very large volumetric attacks that exceed any single ISP's capacity are precisely the ones a dedicated provider with massive aggregate capacity is built to absorb. A common, pragmatic posture is to blackhole locally for floods that threaten your links and divert to scrubbing for attacks against customers important enough to keep online.

A runbook for the moment it matters

Layers only help if people use them correctly under pressure, and an attack is the worst possible time to be improvising. Write the runbook before you need it, keep it short, and make sure on-call has rehearsed it:

• Detect and confirm. Identify the target address and the attack characteristics from flow data; rule out a legitimate traffic spike.
• Assess the blast radius. Decide whether the threat is to one customer, a shared link, or the wider network — this drives every choice that follows.
• Contain. For a link-threatening volumetric flood, trigger the agreed upstream blackhole for the target. For an attack on a customer you must keep online, divert to scrubbing.
• Communicate. Notify the affected customer and, where relevant, your upstream; keep internal stakeholders informed with facts, not guesses.
• Recover and record. Withdraw mitigation once the attack subsides, confirm normal service, and write down what happened so the next response is faster.

How to choose and common mistakes

Build in order of always-on value: flow detection and anti-spoofing hygiene first, because they cost little and pay off constantly; then arrange upstream blackholing; then add scrubbing as your scale and your attackers justify it. The common mistakes are predictable. ISPs deploy flow for capacity planning but never wire it to security alerting. They skip source validation as low priority and end up sourcing attacks against others. They assume their upstream will blackhole on request without ever arranging or testing the community in advance. And they treat scrubbing as the first thing to buy rather than the last, over-investing in capacity before they have the cheap layers in place.

The takeaway

You do not need a carrier-grade scrubbing centre on day one, and trying to start there is the wrong order. Start with visibility and hygiene — flow-based detection and BCP 38 anti-spoofing — which are inexpensive and always working. Arrange upstream blackholing so you can survive a flood bigger than your links. Reach for scrubbing as you grow and as the attacks against your customers justify the cost. The ISPs that ride out attacks calmly are never the ones with the most equipment; they are the ones who built a layered plan, and rehearsed the runbook, before they needed either. To keep the detection layer connected to the rest of your operations, see how live network state ties into the wider picture.