We build Flowtriq, which handles both detection and mitigation triggering. This post examines why many tools stop at detection, what that gap costs operators, and how automated mitigation escalation closes it.
The detection-only trap
Many DDoS detection tools are exactly that: detection tools. They monitor traffic, identify anomalies, classify attack vectors, and send alerts. When the alert arrives, the tool's job is done. What happens next is your problem.
"Your problem" typically means: log into the detection dashboard, confirm the attack classification, decide on a mitigation strategy, log into your router or firewall, manually configure a filter or blackhole route, verify the mitigation is working, and then monitor to ensure legitimate traffic is not affected. This process takes 5-15 minutes in the best case, longer if the on-call engineer is not immediately available or unfamiliar with the mitigation workflow.
During those 5-15 minutes, the attack is hitting your infrastructure at full volume. Your customers are experiencing degraded service or complete outages. Your support queue is filling up with tickets. And your engineer is typing BGP commands into a router CLI, trying to remember the correct community string for their upstream provider's blackhole service.
"We had detection. What we needed was for the detection to actually do something. By the time I SSHed into the router and pushed a blackhole route, the attack had been running for eight minutes and my phone was blowing up with customer complaints."
Why tools stop at detection
There are legitimate reasons why many DDoS tools do not include mitigation:
Mitigation is network-specific. Detection is relatively universal: analyze traffic, find anomalies, classify attacks. Mitigation depends on your specific network architecture. Your router vendor, your BGP configuration, your upstream provider's capabilities, your firewall rules, your scrubbing service contracts. A detection tool that works the same way everywhere cannot also mitigate everywhere without extensive per-deployment customization.
Mitigation carries risk. A false detection that sends an alert is annoying. A false detection that pushes a BGP blackhole for a /24 containing 200 customer IPs is an outage. Vendors who include automated mitigation accept liability for the consequences of false positives, which is why many choose to stop at detection and let the operator make the mitigation decision.
Mitigation requires infrastructure access. To push BGP routes, a tool needs BGP peering with your router. To modify firewall rules, it needs API access to your firewall. To trigger cloud scrubbing, it needs API credentials for your scrubbing provider. Each of these integrations is a security surface that operators are understandably cautious about exposing to a third-party tool.
These are real concerns, not excuses. But they explain why the market ended up with a detection/mitigation split that forces operators to buy two tools, or buy one tool and build the mitigation layer themselves.
The alert fatigue to action gap
Detection-only tools create a specific operational failure mode: alert fatigue that leads to slow response.
The pattern is predictable. The tool generates alerts. At first, the team investigates every alert promptly. Then they realize that many alerts are minor (port scans, small anomalies, short-lived spikes) and do not require action. They start triaging alerts, checking severity before responding. Over time, alert response becomes routine, then slow, then sporadic. When a real 50 Gbps volumetric attack arrives, it sits in the alert queue alongside the port scans and anomalies, waiting for someone to decide it is worth acting on.
The fundamental problem is that detection without mitigation puts humans in the critical path of every incident. Humans are slow, inconsistent, and unavailable at 3 AM on a Saturday. An automated system that can distinguish between "send a Slack notification" and "push a BGP blackhole immediately" removes humans from the time-critical path while keeping them in the decision-making loop for edge cases.
"Our detection tool sent 47 alerts last month. We investigated 12 of them. Three were real attacks. We need detection that makes it actionable, not detection that adds to our alert backlog."
How mitigation escalation works
The solution is not to either detect-only or auto-mitigate-everything. It is a graduated escalation chain where the response matches the severity:
Local kernel-level mitigation
For small attacks (under your server's capacity), drop malicious traffic at the kernel level using iptables/nftables rules or XDP filters. This stops the attack without involving any external systems. The server stays online, legitimate traffic flows normally, and no BGP changes are needed. This handles the majority of attacks that target individual servers.
BGP FlowSpec to upstream
When the attack exceeds local capacity, push BGP FlowSpec rules to your upstream provider. FlowSpec is surgical: it can drop traffic matching specific source IPs, protocols, ports, or packet sizes while allowing everything else through. The attack traffic gets dropped at the upstream edge before it reaches your network. Legitimate traffic is unaffected.
RTBH (Remote Triggered Black Hole)
For large volumetric attacks that exceed FlowSpec capacity or when FlowSpec is not supported by your upstream, RTBH drops all traffic to the targeted IP. This is a blunt instrument, since it drops both attack and legitimate traffic, but it protects the rest of your network from collateral damage. RTBH is the last resort before cloud scrubbing.
Cloud scrubbing diversion
For sustained, high-volume attacks, divert traffic through a cloud scrubbing service (Cloudflare Magic Transit, Akamai Prolexic, etc.). The scrubbing service absorbs the attack volume and forwards clean traffic back to your network. This is the most expensive option but handles attacks that exceed your upstream's filtering capacity.
The key insight is that each escalation level is appropriate for a different attack size and type. A 500 Mbps SYN flood does not need cloud scrubbing. A 200 Gbps UDP amplification attack does not need local iptables rules. The escalation chain matches the response to the threat, minimizing both the impact on legitimate traffic and the cost of mitigation.
Why detection-only tools require buying a second tool
Operators who deploy a detection-only tool eventually face a choice: build custom mitigation automation or buy a second tool that handles mitigation.
Building custom mitigation typically means writing scripts that take detection alerts as input and push BGP routes, firewall rules, or API calls as output. This works, but it creates a custom integration layer that must be maintained, tested, and updated whenever either the detection tool or the mitigation infrastructure changes. Most teams underestimate the ongoing maintenance cost of this approach.
Buying a separate mitigation tool means another vendor relationship, another budget line, another interface to learn, and another integration to maintain. The detection tool sends alerts to the mitigation tool, which takes action. The gap between them is a latency penalty (seconds to minutes depending on the integration) and a reliability risk (if the integration breaks during an attack, you are back to manual mitigation).
In either case, the operator is paying for the detection/mitigation gap with time, money, or both. A tool that handles the full chain, from packet inspection to attack classification to mitigation action, eliminates this gap.
Detection that actually does something
Flowtriq detects attacks in 1-2 seconds and triggers mitigation automatically: local firewall rules, BGP FlowSpec, RTBH, or cloud scrubbing diversion. The escalation chain matches the response to the threat.
Start Free Trial →How Flowtriq handles the full chain
Flowtriq combines detection and mitigation triggering in a single agent. When an attack is detected, the mitigation response is determined by the attack size, type, and your configured escalation policy:
- Small attacks (below local capacity): The agent applies local firewall rules immediately. No external systems involved. Attack traffic is dropped at the kernel level within seconds of detection.
- Medium attacks (exceeding local capacity): The agent pushes BGP FlowSpec rules to your configured upstream peers via the ExaBGP adapter. Attack traffic is filtered at the upstream edge within seconds.
- Large attacks (exceeding upstream filtering): The agent triggers RTBH to protect the rest of your network, and can simultaneously trigger cloud scrubbing diversion via webhook or API integration.
Each escalation level can be configured independently. You can set the thresholds for when local mitigation escalates to FlowSpec, when FlowSpec escalates to RTBH, and when to trigger cloud scrubbing. You can also override the automation at any point: the dashboard shows what mitigation is active and lets you modify or withdraw it in real time.
The escalation is not fire-and-forget. The agent continuously monitors the attack and adjusts mitigation as the attack changes. If a 1 Gbps attack escalates to 50 Gbps, the mitigation escalates with it. If the attack stops, mitigation rules are withdrawn automatically after a configurable cooldown period, so you are not left with stale blackhole routes after the attack ends.
The honest trade-offs
Automated mitigation is not without risk. Here is what operators should consider:
False positive impact. When mitigation is automated, a false positive does not just generate an unnecessary alert. It triggers an unnecessary mitigation action. If that action is a local firewall rule, the impact is limited to one server. If it is a BGP blackhole, the impact is broader. This is why confidence scoring and escalation thresholds matter: they determine how aggressive the system is at each level.
BGP integration complexity. Automated FlowSpec and RTBH require BGP peering between the agent and your router. This is a real configuration step that requires coordination with your network team. It is not a "click a button and it works" setup. We provide detailed guides for ExaBGP, BIRD, and common router configurations, but the initial setup requires network engineering knowledge.
Upstream provider support. Not all upstream providers support FlowSpec. Some only support RTBH with specific community strings. The effectiveness of automated mitigation depends on what your upstream provider can accept. Flowtriq can push the routes, but your provider needs to honor them.
We think the trade-off is overwhelmingly positive. Automated mitigation with proper safeguards (confidence scoring, escalation thresholds, hysteresis, cooldown periods) is safer than manual mitigation performed by a tired engineer at 3 AM. But we are transparent about the configuration and coordination required to make it work.
Detection without mitigation is half a product
The DDoS tool market has spent two decades building excellent detection engines. The classification accuracy of modern tools is genuinely impressive: sub-second identification of multi-vector attacks across dozens of attack types. But detection accuracy means nothing if the operator cannot act on it quickly enough to matter.
Bridging the gap between "we know what is happening" and "we stopped it" is what separates monitoring from protection. A tool that detects an attack in 0.5 seconds but requires 8 minutes of manual intervention to mitigate has a response time of 8 minutes and 0.5 seconds. The detection speed is irrelevant when the mitigation is manual.
The industry is moving toward integrated detection and mitigation, but many operators are still running split architectures: one tool for detection, one tool (or a set of scripts) for mitigation, and a prayer that the integration between them holds during the next attack. If that describes your setup, it is worth asking whether the gap is a feature of your architecture or a liability.