Back to Blog

We build Flowtriq. This is not a general comparison of the two products (see the full comparison for that). This post focuses on one specific difference: what happens after an attack is detected.

FastNetMon Detects. Then What?

FastNetMon is a capable detection tool. It monitors traffic via sFlow, NetFlow, or mirror port. It identifies traffic anomalies against configured thresholds. It classifies attack types. When an attack crosses a threshold, it fires notifications and can execute scripts.

Its primary automated response mechanism is RTBH: announcing a blackhole route for the target IP via BGP. FastNetMon Advanced adds some additional response options through its scripting interface. FastNetMon Community is more limited, relying on notify.sh scripts that operators write themselves.

The detection works. FastNetMon identifies attacks and it identifies them correctly. The gap is not in the detection. The gap is in what happens after the alert fires. The available automated responses either take the server offline (RTBH) or require custom scripting to do anything else.

The RTBH Problem

When FastNetMon blackholes a /32, every user trying to reach that server gets nothing. The game server goes silent. The web application stops responding. API consumers get connection timeouts. From the perspective of anyone trying to use that service, it is indistinguishable from a successful attack.

The attacker wanted the server offline. The blackhole put the server offline. The attack traffic stopped, but so did everything else. The "mitigation" accomplished the attacker's goal through a different mechanism.

For a hosting provider, that is a customer outage. The customer is paying for a server, and their server is unreachable because the protection system took it offline. For a game server operator, that is a full player disconnect. The attack lasted 45 seconds; the blackhole lasted 5 minutes because of the withdrawal delay. For an e-commerce platform, that is 5 minutes of lost transactions and frustrated customers who may not come back.

RTBH is the right call when the attack is saturating a shared transit link and threatening collateral damage to other services. That is a genuine scenario where protecting the network takes priority over protecting the individual server. But when every attack triggers a blackhole regardless of size, RTBH stops being a last resort and becomes the only resort.

What Protection Actually Means

Protection means the server stays running during the attack. Legitimate users can still connect. Services remain available, potentially with some performance impact, but available.

Flowtriq's response targets the attack traffic specifically while leaving legitimate traffic alone:

  • SYN cookies for SYN floods. The kernel uses SYN cookies to validate TCP handshakes without allocating state for every incoming SYN. Legitimate connections complete normally. The server continues serving established sessions without interruption.
  • Source-based rate limiting for amplification attacks. Amplification traffic arrives from reflector IPs that are sending far more traffic than any legitimate source. Per-source rate limits cap reflector traffic while legitimate sources flow at full speed.
  • Port-specific drops for reflection. DNS amplification on port 53, NTP on port 123, memcached on port 11211. If the server does not need those ports open, drop the traffic at the kernel. Everything else is unaffected.
  • FlowSpec for upstream filtering. When local filtering is not enough, FlowSpec rules pushed upstream provide surgical filtering without blackholing. The upstream drops traffic matching the attack profile; everything else reaches the server normally.

The result: the server stays up. Users stay connected. The attack is handled by filtering, not by disconnecting the target from the internet.

Detection Speed

Detection speed matters because it determines how quickly any response can begin, whether automated or manual.

FastNetMon with sFlow/NetFlow: Detection speed depends on the flow export interval configured on your routers. Most deployments export flows every 10 to 60 seconds. FastNetMon cannot detect an attack until the flow data arrives, so detection latency is at minimum the export interval plus processing time. A 30-second export interval means the attack runs for at least 30 seconds before detection.

FastNetMon with mirror port: Faster than flow-based detection because FastNetMon sees packets directly. But mirror port requires dedicated hardware (a TAP or SPAN port), additional cabling, and a capture NIC on the FastNetMon server. This limits deployment to locations where you can install mirror infrastructure.

Flowtriq: The agent runs on each server and sees traffic directly. No flow export delay, no mirror port hardware, no sampling. Detection happens in 1-2 seconds on every server where the agent is installed. Deploying to a new server takes one command.

After Detection: Side by Side

Same scenario: a 500K PPS UDP flood targets a single server. The attack sustains for 3 minutes.

FastNetMon path:

  • Second 0: Attack begins.
  • Second ~30: sFlow data arrives at FastNetMon. Detection fires. Alert sent.
  • Second ~35: RTBH script triggers. Blackhole route announced for the target /32.
  • Second ~40: Upstream propagates the blackhole. Attack traffic stops reaching the network.
  • Second ~40: Legitimate traffic also stops reaching the server. Server is offline.
  • Minute 3: Attack ends. Blackhole remains active for the configured withdrawal timer (often 5 minutes).
  • Minute 8: Blackhole withdrawn. Server comes back online.

Flowtriq path:

  • Second 0: Attack begins.
  • Second 1: Agent detects UDP flood. Classification identifies source distribution and target ports.
  • Second 2: Kernel-level rules applied. Per-source UDP rate limiting and port-specific drops active. Server stays up for legitimate traffic.
  • Second 30: If local rules are not sufficient to handle the volume, FlowSpec pushed upstream automatically. Surgical upstream filtering active. Server still reachable.
  • Minute 3: Attack ends. Kernel rules remain active during cooldown period. FlowSpec withdrawn after configurable delay.
  • Throughout: Server remains online. Legitimate users experience no outage.

The difference is not just detection speed. It is response type. FastNetMon's automated response takes the server offline. Flowtriq's automated response keeps it running.

When FastNetMon Is the Right Choice

FastNetMon serves real use cases well:

  • Network-wide flow monitoring for ISPs. If you already have sFlow or NetFlow export from your routers, FastNetMon provides centralized visibility across your network without installing anything on individual servers.
  • Environments where RTBH is genuinely the preferred response. If your network carries traffic for services that can tolerate brief outages and your priority is protecting shared transit capacity, RTBH is a reasonable default.
  • Operators comfortable writing custom scripts. FastNetMon's notify.sh scripting interface is flexible. If your team has the expertise to build custom mitigation logic around FastNetMon's detection events, the scripting interface provides the hooks to do it.
  • Budget-conscious detection. FastNetMon Community Edition is free and provides solid detection. For operators who need detection and plan to build their own mitigation layer, that is a real value proposition.

When You Need More Than Detection

If your requirement is that the server stays running during an attack, detection alone is not sufficient. The response after detection is what determines whether the service survives. That means:

  • Per-server protection that maintains availability. Kernel-level filtering on each server, applied automatically, keeping the service up for legitimate users throughout the attack.
  • Automatic PCAP capture. Full packet capture during attacks for forensic analysis and post-incident review, without manual intervention to start the capture.
  • Attack classification with confidence scoring. Not just "this is a DDoS attack" but "this is a DNS amplification flood from 412 reflectors at 1.8 Gbps with 94% confidence," enabling the right mitigation for the specific attack type.
  • Multi-level escalation beyond RTBH. Kernel rules first, then FlowSpec, then scrubbing, then RTBH. Each level tried before escalating to the next. RTBH is the last resort, not the first.
  • Modern alerting without custom scripting. Webhooks, Slack, PagerDuty, and email notifications configured through a dashboard, not by editing shell scripts.

Detection and protection in one agent. Flowtriq detects DDoS attacks and keeps your server running during the attack. No RTBH unless nothing else works. $9.99/node/month with a 14-day free trial.