The Detection-Only Trap: Why Knowing You're Under Attack Isn't Enough

Back to Blog

We build Flowtriq, a DDoS detection and mitigation agent. This post examines the gap between detection and mitigation, why RTBH is not mitigation, and what a real response looks like when the goal is keeping your server running.

The Gap Between Seeing and Stopping

Most DDoS tools stop at detection. They tell you an attack is happening. Your services are degrading. Your customers are timing out. And you know about it.

But knowing is not the same as stopping.

The detection fires. A Slack notification appears. An email arrives. Maybe a PagerDuty alert wakes someone up. The tool did its job: it saw the attack and told you about it. Now what? Someone has to log in, evaluate the attack, decide on a response, and execute that response manually. The gap between detection and mitigation is where downtime accumulates.

Detection at second 1 is meaningless if mitigation does not start until minute 8. Your customers do not care that your tool identified the attack quickly. They care that the service was down for 8 minutes.

RTBH Is Not Mitigation

This is the core of the problem. When a DDoS tool detects an attack and responds by blackholing the target /32, the server goes offline. All traffic, legitimate and malicious, is dropped at the upstream edge. The "mitigation" achieves exactly what the attacker intended: the target is unreachable.

Your customers cannot connect. Your game server is offline. Your web application returns nothing. The attack traffic is gone, but so is everything else.

RTBH protects your transit links from congestion. It prevents a flood targeting one IP from saturating a shared uplink and causing collateral damage to other services on the same network. That is a real and valid use case. But it does not protect the server under attack, and it does not protect the users trying to reach that server.

For link-saturating volumetric attacks, RTBH is sometimes the only option. When a 200 Gbps flood is hitting your 10 Gbps transit link, there is no local filtering that will help. The packets have already consumed the link before they reach your router. In that scenario, RTBH is the correct response to protect everything else on the link.

The problem is when tools default to RTBH as the primary response for every attack. A 500 Mbps SYN flood does not saturate a 10 Gbps link. A 200K PPS UDP reflection attack does not overwhelm a modern server's packet processing capacity. These attacks can be filtered locally or surgically at the upstream without taking the server offline. When the only response in the toolbox is RTBH, every attack gets treated like a link-saturating emergency. The tool becomes a detection engine with a self-destruct button.

What Real Mitigation Looks Like

Real mitigation keeps the server running. The attack traffic is filtered or rate-limited. Legitimate traffic continues to flow. The service stays available for users throughout the attack.

What that looks like in practice:

• SYN cookies for SYN floods. The kernel handles the SYN flood using SYN cookies instead of allocating connection state for every incoming SYN. Legitimate TCP handshakes complete normally. The server stays responsive. No traffic is dropped indiscriminately.
• Source-based rate limiting for amplification attacks. Amplification traffic comes from a predictable set of reflectors. Rate limiting per-source reduces the attack volume to manageable levels while allowing legitimate sources through at full speed.
• Port-specific filtering for reflection attacks. DNS amplification targets UDP port 53 from open resolvers. NTP amplification hits UDP port 123. If your server does not run those services on those ports, drop the traffic at the kernel level. Legitimate traffic on other ports is unaffected.
• ConnTrack tuning for UDP floods. Adjusting connection tracking timeouts and table sizes lets the server handle elevated UDP volumes without exhausting kernel state tables. The server processes legitimate UDP traffic normally.
• FlowSpec rules pushed upstream. BGP FlowSpec tells your upstream router to drop traffic matching specific criteria: source IP ranges, protocols, ports, packet sizes. Unlike RTBH, FlowSpec is surgical. It filters attack traffic at the upstream edge while allowing everything else through. The server stays reachable.

The common thread: legitimate traffic continues to flow. The server stays up. The service stays available. The attack is handled, not by taking the target offline, but by filtering out the malicious traffic while preserving the good.

The Four-Level Response

A proper mitigation system operates in escalation levels, not binary states. Each level is appropriate for a different attack size, and the system should move through them automatically as conditions change.

Level 1: Kernel-level rules on the server. iptables, nftables, or XDP filters applied directly on the attacked server. This is the fastest response: rules take effect in milliseconds. It is also the most surgical, since rules target specific traffic patterns and only affect the single server. For attacks below the server's packet processing capacity, this is all you need. The server stays fully reachable for legitimate traffic.

Level 2: FlowSpec pushed to upstream routers. When the attack volume exceeds what the server can filter locally, BGP FlowSpec rules are pushed to the upstream. The upstream router drops matching traffic at its edge before it reaches your network. FlowSpec can match on source/destination IPs, protocols, ports, and packet characteristics. The server stays reachable for everything that does not match the filter.

Level 3: Cloud scrubbing center diversion. For sustained high-volume attacks that exceed your upstream's FlowSpec capacity, traffic is diverted through a cloud scrubbing center (Cloudflare Magic Transit, Akamai Prolexic, or similar). The scrubbing center absorbs the attack volume and forwards clean traffic back to you. This handles the largest attacks but adds latency and cost.

Level 4: RTBH. Last resort. When the link is saturated, nothing else has worked, and the priority shifts from protecting this server to protecting every other server sharing the same link. RTBH takes the attacked IP offline but saves the rest of the network from collateral congestion.

Most detection-only tools skip straight to Level 4 because they do not have Levels 1 through 3. They detect the attack, and the only automated action available is a blackhole. The server goes offline regardless of whether the attack warranted that extreme a response.

The Cost of Detection-Only

Walk through a typical detection-only response:

Minute 0: The tool detects a UDP flood. An alert fires to Slack and PagerDuty.

Minute 1: The on-call engineer sees the notification. They open the detection dashboard to confirm the alert.

Minute 3: The engineer has confirmed the attack. It is a 2 Gbps DNS amplification flood targeting a single IP. They evaluate their options.

Minute 5: The engineer decides to blackhole the target. They open a terminal, SSH into the edge router, and start typing the route command.

Minute 8: The blackhole route is committed. Attack traffic stops reaching the network. Legitimate traffic also stops reaching the server. The server is offline.

Minute 12: The attack subsides. The engineer removes the blackhole. The server comes back online.

Total impact: 8 minutes of service degradation under attack, followed by 4 minutes of total outage from the blackhole itself. Detection happened at second 0. The operator's response made things worse before making them better, and the server was affected for the entire 12-minute window.

A 2 Gbps DNS amplification flood against a single server is well within the capacity of kernel-level filtering on the target. The attack could have been mitigated at the server in under 2 seconds with port-specific drops and source rate limiting. The server would have stayed up for every legitimate user for the entire duration. No blackhole needed.

Automated Response Changes the Equation

When detection and mitigation run in the same system on the same server, the response timeline changes completely.

Second 1: Agent detects a UDP flood. Attack classification identifies DNS amplification from ~400 reflector sources.

Second 2: Kernel-level rules applied automatically. Source-based rate limiting caps each reflector IP. Port-specific drops filter unsolicited DNS responses. Legitimate traffic on all other ports flows normally.

Second 2 onward: Server stays up. Legitimate users experience no interruption. The agent monitors the attack for changes in volume or vector.

Second 30: If attack volume exceeds local filtering capacity, FlowSpec rules are pushed upstream automatically. The upstream drops the amplification traffic at its edge. Still no blackhole. Still no server outage.

If the attack escalates further and the upstream cannot handle it, scrubbing is activated. RTBH is the last resort, triggered only when nothing else is sufficient.

No human was required for the initial response. No 8-minute gap between detection and action. No server taken offline for a sub-capacity attack. The system matched the response to the threat, starting with the least disruptive option and escalating only when necessary.

The on-call engineer still gets the Slack notification. They still review what happened. But they review it after the system already responded, not while the attack is running and the clock is ticking.