Detection Tells You. Mitigation Stops It.
Detection is the process of identifying that an attack is happening. It means recognizing abnormal traffic patterns, classifying the attack vector, and generating an alert. Detection answers the question: is this server under attack right now?
Mitigation is the process of reducing or stopping the impact of that attack. It means applying firewall rules, pushing FlowSpec routes, diverting traffic to scrubbing, or announcing RTBH. Mitigation answers the question: what are we doing about it?
Most tools do one of these well. The operational problem is the gap between them. A detection tool fires an alert. Someone reads the alert, logs in, assesses the situation, and manually triggers a mitigation action. That process takes minutes, sometimes longer. The damage happens in those minutes.
Detection-Only Tools
Tools like ntopng, Kentik (without scrubbing), Arbor Sightline (without TMS), and FastNetMon Community Edition are detection platforms. They monitor traffic, identify anomalies, classify attack vectors, and send alerts. They are good at telling you what is happening.
The response, however, requires a separate step. An operator receives the alert, evaluates the situation, and then takes action: manually applying firewall rules, triggering a BGP announcement, or activating a scrubbing service. Each of those steps takes time. During a volumetric attack, time is the resource you have least of.
Detection-only tools give you visibility. They do not give you response. For networks where an on-call engineer can respond within minutes, this may be acceptable. For networks where downtime is measured in dollars per second, the gap between detection and response is the problem.
Mitigation-Only Tools
Cloud scrubbing services like Cloudflare and Akamai Prolexic mitigate effectively once activated. Traffic is diverted through their scrubbing infrastructure, attack traffic is filtered, and clean traffic is forwarded to the origin. The scrubbing itself works well.
But activation requires a trigger. Someone or something must detect the attack first and then divert traffic to the scrubbing service. With always-on scrubbing, this latency is reduced, but many deployments use on-demand activation where a BGP announcement or DNS change triggers the diversion. That detection-to-activation gap can be minutes.
Mitigation-only services depend on detection happening elsewhere. If your detection is slow (flow-based with 30-60 second latency) or manual (someone notices the alert), your mitigation is slow regardless of how capable the scrubbing infrastructure is.
The Integrated Approach
When detection and mitigation live in the same system, the gap between them disappears. The agent on the server detects an attack at second 1 and applies kernel-level firewall rules at second 2. No alert is generated for a human to read. No separate system is triggered. No orchestration delay.
An integrated system can escalate through multiple mitigation levels automatically:
- On-server rules: iptables/nftables rate limiting and blocking, applied in 1-2 seconds. Handles the majority of attacks that do not saturate the inbound link.
- BGP FlowSpec: Surgical upstream filtering that drops specific traffic patterns while allowing legitimate traffic through. Applied when on-server rules are insufficient.
- Cloud scrubbing: Traffic diversion through a scrubbing provider for large volumetric attacks. Services stay online during the diversion.
- RTBH: Last resort. Blackhole the target at the upstream edge when nothing else can keep up with the volume.
Each level is triggered automatically based on whether the previous level is containing the attack. De-escalation is also automatic: when the attack subsides, mitigation rules are withdrawn in reverse order. No stale firewall rules, no lingering BGP announcements, no traffic still routing through scrubbing after the attack ended hours ago.
RTBH Is Not Mitigation
This distinction matters. When your "mitigation" response is to blackhole the target IP, the attacker achieved their goal. The target server is unreachable. Legitimate users cannot connect. The service is down.
RTBH protects your network links from congestion. It prevents a volumetric attack from consuming all your transit bandwidth and affecting other services. That is a valid and important function. But calling it mitigation implies the target service was preserved, and it was not.
Real mitigation maintains service availability during the attack. On-server filtering, FlowSpec, and scrubbing all accomplish this. RTBH does not. When evaluating tools, ask whether "mitigation" means the service stays online or just that the transit link is preserved.
What to Look For
When evaluating DDoS protection tools, these are the questions that separate detection-only, mitigation-only, and integrated systems:
- Does it detect AND respond automatically? Detection without automated response means manual intervention during attacks.
- How fast from detection to response? An integrated system responds in seconds. A detection tool plus a separate mitigation tool responds in minutes at best.
- What response options beyond RTBH? If the only automated response is blackholing, the tool is completing the attacker's objective for them.
- Does it maintain service availability during response? On-server rules and FlowSpec keep services online. RTBH does not.
- Does it escalate automatically? Starting with the least disruptive response and escalating only when needed minimizes collateral impact.
- Does it de-escalate when the attack ends? Automatic withdrawal of mitigation rules prevents stale configurations.
- Does it provide forensic evidence? Server-side PCAP capture during the attack gives you the data needed for post-incident analysis, abuse reporting, and upstream coordination.
Detection and mitigation in one agent. Flowtriq detects attacks in 1-2 seconds and applies mitigation automatically, with four escalation levels. $9.99/node/month, 14-day free trial.