From flow ingestion to BGP mitigation:
how Flowtriq detects and stops DDoS attacks

Back to Blog

The Problem with Traditional DDoS Pipelines

Most DDoS detection platforms work in one of two ways. Either they sit at the network edge and sample traffic using flow protocols, or they run on individual servers and monitor local metrics. The first approach gives you network-wide visibility but introduces sampling blind spots and detection latency measured in minutes. The second approach sees every packet on a given server but has no upstream visibility into what is heading toward your network before it arrives.

Flowtriq does both simultaneously. The agent runs a 1-second detection loop that reads kernel-level traffic counters on the server while also ingesting flow data from upstream routers and switches. When an attack is detected, the mitigation engine can respond at every layer: local firewall rules on the server, BGP FlowSpec announcements to drop specific traffic at the network edge, RTBH blackholing to stop volumetric floods at your upstream provider, and cloud scrubbing for attacks that exceed your local capacity.

This post walks through the entire pipeline, from the moment a flow packet arrives to the moment a BGP announcement drops attack traffic at the border.

Flow Ingestion: Four Protocols, Zero Dependencies

Flowtriq natively ingests four flow protocols without requiring any third-party collectors, aggregators, or middleware. The agent includes built-in binary parsers for each protocol and decodes flow records in real time as they arrive.

sFlow v5 (RFC 3176)

sFlow sends sampled packet headers from switches and routers to the agent over UDP port 6343. Rather than aggregating traffic into flow records on the device, sFlow exports the first 128 bytes of randomly sampled packets. The agent reconstructs flow statistics from these samples, giving you packet-level detail including protocol fields, TCP flags, and packet sizes. sFlow is the dominant flow protocol on Arista, Dell, HP/Aruba, and white-box switches running SONiC.

NetFlow v5 (Cisco legacy)

NetFlow v5 is the most widely deployed flow protocol in legacy Cisco infrastructure. It uses a fixed 48-byte record format and exports 5-tuple flow summaries (source IP, destination IP, source port, destination port, protocol) with byte and packet counts. The agent receives these records on UDP port 2055 and processes them with no template negotiation required. If you have Cisco routers that have been exporting NetFlow for years, you can point them at the Flowtriq agent and it works immediately.

NetFlow v9 (RFC 3954)

NetFlow v9 replaced the fixed record format with templates, allowing routers to define custom record structures. The agent handles template caching automatically: when it receives a template record, it stores the field definitions and uses them to decode all subsequent data records. This matters in practice because routers can restart or change templates, and the agent handles re-learning transparently. NetFlow v9 is the default export format on modern Cisco IOS-XE and MikroTik devices.

IPFIX (RFC 7011)

IPFIX is the IETF-standardized evolution of NetFlow v9. It adds support for variable-length fields, enterprise-specific information elements, and structured data types. The agent ingests IPFIX on UDP port 4739 and supports the full range of standard information elements. If your routers support IPFIX, it is generally the best choice for new deployments because of its vendor neutrality and richer field set.

The Merge: Flow Data Meets Kernel Metrics

Here is where Flowtriq's architecture diverges from every other flow-based detection tool. The agent does not rely solely on flow data for detection. Every second, it independently reads kernel-level traffic counters from /proc/net/dev and /proc/net/snmp, giving it exact byte counts, packet counts, and protocol breakdowns (TCP, UDP, ICMP) with zero sampling loss. Every packet that reaches the server's network interface is counted.

The agent then merges the two data sources within the same 1-second aggregation window. The merge strategy is simple and deliberate: for each metric (PPS, BPS, protocol ratio), the agent uses the higher reading between the flow data and the local kernel counters.

This merge strategy exists because each data source has a different blind spot:

• Flow data sees traffic before it reaches your server. If your upstream is dropping packets during an attack, the flow data from your border router still shows the full attack volume. The server's kernel counters only see what actually arrives.
• Kernel counters see every packet without sampling. Flow data is sampled (typically 1:1000 to 1:4096), which means small attacks, low-rate application-layer floods, and short bursts can fall below the sampling threshold. The kernel counters catch everything.

By taking the higher value, the agent gets the best of both worlds: upstream visibility from flow data and per-packet accuracy from kernel inspection. A 10,000 PPS attack that the 1:4096 sFlow sampling reduces to 2.4 sampled packets per second is still detected instantly by the kernel counters. A 50 Gbps volumetric flood that saturates your transit link before it reaches your server is still visible in the flow data from the border router.

Sample rate configuration

The agent needs to know the sampling rate of your flow sources to properly scale sampled data. You configure this per-node in the dashboard. Typical values:

• 1 Gbps links: 1:500 or 1:1000
• 10 Gbps links: 1:1000 or 1:2048
• 40/100 Gbps links: 1:4096 or higher

You can also configure allowed source IPs per node to restrict which devices are permitted to send flow data to the agent, preventing spoofed flow injection.

Detection: One-Second Loop, Dynamic Baselines

The merged traffic data feeds into the detection engine, which runs a continuous 1-second loop. Every second, the engine compares current metrics against dynamic baselines to determine whether an anomaly is occurring.

How baselines work

Flowtriq uses exponentially weighted moving averages (EWMA) with two windows: a fast window that adapts within minutes and a slow window that represents longer-term traffic norms. An anomaly fires when current traffic exceeds the fast baseline by 3x and the slow baseline by 5x (both multipliers are configurable per node). This dual-window approach means legitimate traffic spikes shift the fast baseline upward and avoid false alerts, while sudden attacks exceed both baselines simultaneously.

The fast baseline converges within 5 minutes of agent startup, at which point it is typically within 15% of the true traffic mean. The slow baseline converges after roughly 30 minutes. During the initial bootstrap phase, detection falls back to conservative static thresholds based on the interface line rate.

What gets measured

The detection engine computes baselines for multiple metrics independently:

• Packets per second (PPS) for volumetric floods
• Bytes per second (BPS) for amplification attacks with large packets
• New connections per second derived from SYN rates for connection-state attacks
• Protocol ratio (TCP/UDP/ICMP) to catch protocol-shift attacks that evade single-metric detectors

An alert fires when any single metric crosses its threshold. The alert includes which metrics deviated and by how much, giving you immediate context about the attack type without manual traffic analysis.

Attack classification and severity

When a threshold is crossed, the detection engine classifies the attack into one of seven families: UDP Flood, SYN Flood, HTTP Flood, ICMP Flood, DNS Flood, Multi-Vector, or Unknown. Application-layer attacks (L7) are classified under the HTTP Flood family. Each classification includes a confidence score from 0 to 100%.

Severity is calculated from the ratio of peak traffic to baseline:

Critical:  ratio > 10  OR  peak PPS > 500,000
High:      ratio > 5   OR  peak PPS > 100,000
Medium:    ratio > 2   OR  peak PPS > 20,000
Low:       default

The engine also performs IP spoofing detection by analyzing TTL distribution patterns across source addresses, and flags botnet involvement when more than 300 distinct source IPs are observed in an attack.

End-to-end detection latency is under 1 second. From the moment attack traffic crosses the baseline threshold to the moment the incident opens and alerts fire, the entire pipeline completes within a single tick of the 1-second loop.

Mitigation: 4-Level Auto-Escalation

Detection without mitigation is just an expensive alert. Flowtriq's mitigation engine implements a 4-level auto-escalation chain that matches the response to the severity of the attack. Each level uses a different mechanism with increasing blast radius and effectiveness.

Level 1: Local rate-limiting (FlowSpec)

When inbound traffic exceeds 100 Mbps (configurable), the engine announces BGP FlowSpec rules to rate-limit specific traffic at your border routers. FlowSpec rules are surgical: they can match on destination and source prefix, IP protocol, source and destination port, packet length, TCP flags, ICMP type/code, and DSCP value. This lets you throttle attack traffic while leaving legitimate traffic untouched.

For example, during a UDP amplification flood from port 53 with oversized packets, the FlowSpec rule can match protocol UDP, source port 53, packet length > 512 and rate-limit it to 10 Mbps. DNS responses from your legitimate resolver still flow normally because they are smaller than 512 bytes.

Level 2: FlowSpec drop

If the attack volume exceeds 500 Mbps or continues to escalate despite rate-limiting, the engine upgrades to targeted drop rules. These are still FlowSpec announcements, but instead of rate-limiting, they instruct the router to discard matching traffic entirely. The match criteria remain specific to the attack vector, so only attack traffic is dropped.

Level 3: RTBH blackhole

When volumetric attacks exceed 2 Gbps and threaten to saturate your transit links, the engine escalates to Remote Triggered Black Hole routing. RTBH announces the victim IP as a /32 with the well-known blackhole community (RFC 7999: 65535:666), causing upstream routers to drop all traffic destined for that IP at the network edge before it consumes your bandwidth.

RTBH is a blunt instrument: it drops all traffic to the target, not just attack traffic. That is exactly why it is Level 3 and not Level 1. The engine only escalates to RTBH when the attack volume is large enough that the collateral damage of blackholing one IP is less than the collateral damage of a saturated transit link affecting your entire network.

Flowtriq supports both standard destination-based RTBH and source-based RTBH (where supported by your upstream). Common blackhole communities for major transit providers are pre-configured:

RFC 7999 (standard):     65535:666
Cogent:                  174:997
Lumen/Level3:            3356:9999
NTT/Verio:               2914:666
Telia:                   1299:9999
Hurricane Electric:      6939:666
OVH:                     16276:666

Level 4: Cloud scrubbing

For attacks exceeding 5 Gbps or when local network capacity cannot absorb the volume, the engine diverts traffic to an upstream scrubbing service. Flowtriq integrates directly with Cloudflare Magic Transit, Radware DefenseFlow, and F5 BIG-IP via their APIs, as well as any custom scrubbing provider via a configurable webhook adapter. The scrubbing service absorbs and filters the attack traffic, returning only clean traffic to your infrastructure.

BGP Adapters: How Rules Reach Your Routers

The mitigation engine does not speak BGP itself. Instead, it pushes rules to a BGP adapter that maintains the actual BGP sessions with your routers. This separation is deliberate: it means the agent does not need to be a BGP peer, and you can use whichever BGP daemon your infrastructure already runs.

Flowtriq supports eight adapter types:

• ExaBGP: JSON API over HTTP. The most common choice for teams that want a lightweight, purpose-built BGP daemon. Supports FlowSpec rate-limiting, protocol/port-specific drops, and RTBH with community tagging.
• GoBGP: gRPC and REST API for low-latency announcements. Built for high-throughput environments where millisecond rule propagation matters.
• BIRD 2: Native FlowSpec syntax with BGP Large Community support (RFC 8092). The dominant BGP daemon in European ISPs and IXPs. Supports both IPv4 and IPv6 FlowSpec alongside unicast blackhole routes.
• FRRouting (FRR): vtysh command proxy for real-time control. Static blackhole routes with tag-based communities and policy-based routing for FlowSpec-like filtering. The natural choice for whitebox switches and SONiC deployments.
• Cloudflare Magic Transit: Direct API integration for on-demand scrubbing with BGP prefix advertisement and global anycast.
• Radware DefenseFlow: Enterprise appliance integration via REST API with policy management for divert/drop actions.
• F5 BIG-IP: REST API integration for enterprise environments with existing F5 infrastructure.
• Webhook: Generic HTTP endpoint for custom integrations. Full attack context in JSON payload with configurable headers and timeout.

The adapter selection is automatic. The engine scores available adapters by capability (does it support the required action?) and health (when was the last successful test?), then selects the best available adapter for each rule. If an adapter fails, the engine retries with exponential backoff and can fall back to an alternative adapter.

The Mitigation Pipeline: 6 Stages in Under 2 Seconds

Between detection and the BGP announcement reaching your router, the mitigation engine processes each event through a 6-stage pipeline. The full pipeline completes in under 2 seconds.

1. Event queue. Detection events enter a priority queue scored by severity: critical (90), high (70), medium (50), low (30). Higher-priority events are processed first.
2. Aggregation. Events within a 5-second window targeting the same IP, protocol, port, and attack family are collapsed into a single mitigation rule. This prevents rule storms when multiple nodes detect the same distributed attack.
3. Validation and intent. The engine validates that the target is a public IPv4 address (no private or reserved ranges) with at least a /24 prefix, then determines the appropriate action: rate-limit, drop, blackhole, or VRF redirect.
4. Escalation. The engine evaluates the attack volume against the configured escalation thresholds and determines which level to apply. If an existing rule is already active at a lower level and the volume has increased, the rule is automatically upgraded.
5. Rate limiting. A sliding window (default 30 rules per minute per tenant) prevents excessive rule generation during large-scale distributed attacks. This protects both the BGP daemon and the routers from being overwhelmed with updates.
6. Announce. The rule is pushed to the selected adapter. The full payload is logged for audit. The engine confirms the announcement was accepted and records the rule's TTL for automatic expiry.

Rule lifecycle

Every mitigation rule has a configurable TTL (default 5 minutes). When the TTL expires, the rule is automatically withdrawn and the BGP announcement is removed. If the attack is still active when the rule expires, the detection engine will fire a new event and the rule will be re-announced. This prevents stale rules from accumulating indefinitely.

Rules can also be manually withdrawn from the dashboard. If the engine detects that a rule is causing collateral damage (legitimate traffic dropping after a rule announcement), it can automatically withdraw the rule and deploy a more targeted replacement with narrower match criteria.

What This Looks Like in Practice

To make this concrete, here is what happens during a real attack scenario:

T+0s: A UDP amplification flood begins hitting your server at 800 Mbps via DNS responses from spoofed source addresses. The border router's sFlow export sends sampled packet headers to the Flowtriq agent. Simultaneously, the agent reads a spike in UDP PPS from /proc/net/dev.

T+1s: The detection loop fires. The merged data (flow + kernel) shows UDP PPS at 12x the dynamic baseline and BPS at 8x. The engine classifies the attack as a DNS amplification flood with 94% confidence based on source port 53, packet sizes above 512 bytes, and TTL distribution indicating spoofed sources. Severity is calculated as High. Alerts fire to Discord, Slack, and PagerDuty. A 1,000-packet PCAP capture starts from the pre-attack ring buffer.

T+1.5s: The mitigation engine processes the event. At 800 Mbps it triggers Level 2 (FlowSpec drop). The engine generates a FlowSpec rule: match destination {your IP}/32, protocol UDP, source port 53, packet length > 512, action drop. The rule is pushed to the ExaBGP adapter via its JSON API.

T+2s: ExaBGP announces the FlowSpec rule to your border router. The router installs the filter in its forwarding plane. DNS amplification packets are dropped at the network edge before consuming transit bandwidth. Legitimate traffic to the same IP continues unaffected.

T+5m: The rule's TTL expires. The engine checks whether the attack is still active. If traffic has returned to baseline, the rule is withdrawn and the incident closes. If the attack is ongoing, a new rule is announced for another 5 minutes.

Per-Host Thresholds and Geo Lockdown

Not every IP on your network has the same risk profile. A payment gateway handling credit card transactions needs tighter thresholds than a CDN origin serving static assets. Flowtriq supports per-host threshold overrides that let you configure custom escalation thresholds for individual IPs or critical infrastructure.

For each target IP, you can override the default escalation thresholds at every level: the local rate-limit threshold, FlowSpec threshold, RTBH threshold, and cloud scrubbing threshold. This means your payment gateway might escalate to FlowSpec at 50 Mbps while your CDN origin tolerates 2 Gbps before any mitigation kicks in.

Per-host overrides also support geo lockdown. You can specify a list of allowed countries (ISO 3166 codes) per IP. During an attack, the engine automatically generates FlowSpec rules that drop traffic from countries outside the allowed list. If your SaaS platform only serves North American customers, geo lockdown can filter 80% of botnet traffic before any volumetric threshold is even reached.

RPKI Validation: Don't Announce What You Don't Own

Before the mitigation engine announces any BGP route, it validates the prefix against RPKI (Resource Public Key Infrastructure). This prevents a misconfigured escalation policy from accidentally announcing a prefix you do not own, which would be a BGP hijack.

The engine queries the RPKI validation status using either the Cloudflare RPKI API or a custom Routinator/rpki-client endpoint that you configure. Validation results are cached locally to avoid adding latency to the mitigation pipeline. If a prefix fails RPKI validation, the announcement is blocked and an alert is fired so you can investigate.

This is a guardrail that matters most in ISP and multi-tenant environments where a single misconfigured origin ASN could cause a route leak affecting upstream peers.

Automated Rollback and Collateral Detection

Every mitigation action carries a risk of collateral damage. A FlowSpec rule that is too broad can drop legitimate traffic. An RTBH blackhole affects everything destined for the target IP, including real users. The mitigation engine continuously monitors for collateral damage and can automatically roll back rules that cause more harm than they prevent.

The detection is straightforward: if legitimate traffic to a target drops by more than 90% after a rule is deployed, the engine flags it as collateral damage. It then withdraws the offending rule and deploys a replacement with narrower match criteria. The original rule, the replacement, and the reasoning are all logged in the rollback history for post-incident review.

The collateral check runs every minute via a dedicated cron job. You can also trigger a manual rollback check from the dashboard.

XDP/eBPF: Kernel-Bypass Local Filtering

For attacks that need to be stopped at the server itself (not at the network edge), the mitigation engine can deploy XDP (eXpress Data Path) filters directly on the target node. XDP filters run in the Linux kernel's network stack before the packet reaches the normal processing pipeline, giving you near-line-rate filtering with minimal CPU overhead.

XDP filters are deployed via the agent's command queue. The engine pushes a filter specification (protocol, port, rate limit) to the node, and the agent installs the corresponding XDP program. When the attack subsides or the rule expires, the filter is automatically removed.

This is particularly useful for game servers and bare-metal infrastructure where you do not have a BGP-capable upstream but need to survive high-PPS attacks locally. XDP can drop millions of packets per second per core without consuming the CPU cycles that iptables or nftables would require.

IPv6 FlowSpec, Large Communities, and Flow Mirroring

Dual-stack FlowSpec

Flowtriq supports both IPv4 FlowSpec (AFI 1, SAFI 133) and IPv6 FlowSpec (AFI 2, SAFI 133). The mitigation engine generates rules for whichever address family the attack targets. If you are running dual-stack infrastructure, both address families are protected with the same escalation logic and adapter integration.

BGP Large Communities (RFC 8092)

Large Communities extend the standard 16-bit community format to 32-bit ASN-aware communities. This matters for networks with 4-byte ASNs and for operators who need per-peer community tagging. Flowtriq supports configuring Large Communities per adapter and per peer, giving you fine-grained control over how your upstream providers handle announced routes.

Flow mirroring

If you need to send flow data to multiple destinations (for example, to Flowtriq for detection and to a separate collector for capacity planning), the agent supports flow mirroring. You configure additional export targets per node, and the agent duplicates the decoded flow data to each destination. This avoids the need to configure multiple export targets on your router, which is not always supported.

BGP Session Health Monitoring

A mitigation rule is useless if the BGP session to your router is down. The engine runs automatic health checks against every configured adapter every 5 minutes, tracking latency, connection status, and response codes. Each adapter is scored as healthy, degraded, or down.

If the primary adapter goes down during an active incident, the engine automatically fails over to a backup adapter. The failover, the reason, and the adapter switch are all logged and trigger a notification to your configured Slack or Telegram channels.

Mitigation-specific alerts are separate from your incident notification channels. You can configure Slack webhooks and Telegram bots that receive only mitigation lifecycle events: rule deployments, withdrawals, escalations, rollbacks, and adapter failovers. This lets your NOC team monitor the mitigation pipeline without being buried in detection alerts.

Transit Analytics and Traffic Intelligence

The same flow data that powers detection also feeds Flowtriq's analytics engine. Transit Analytics computes 95th percentile bandwidth measurements per node and across your workspace, giving you the standard billing metric that transit providers use. You can export per-node billing tables to CSV for reconciliation against your provider invoices.

Traffic Intelligence provides top talker analysis (source and destination IPs by volume), protocol distribution trends (TCP/UDP/ICMP breakdown over time), and anomaly detection in historical traffic patterns. The analytics dashboard supports time windows from 15 minutes to 24 hours with auto-scaling charts, threshold line overlays, incident annotations, and rolling averages.

Threat Intelligence Feeds

Flowtriq correlates detected attack sources against multiple threat intelligence feeds to enrich incident data. The platform ingests five feeds at configurable intervals:

• CISA Known Exploited Vulnerabilities (KEV): Network-facing CVEs filtered to infrastructure vendors (Fortinet, Cisco, Palo Alto, Juniper, Citrix) with CWE-based confidence scoring.
• Emerging Threats Compromised IPs: Known compromised IP addresses actively participating in attacks.
• URLhaus Active C2: Active malware command-and-control infrastructure.
• CERT.PL Network Threats: Polish CERT threat intelligence on network-level indicators.
• Trickest CVE PoC: CVE proof-of-concept database for known exploitable vulnerabilities.

In addition to these feeds, the detection engine matches traffic against 38 IOC (Indicator of Compromise) patterns covering 28 CVE exploit signatures (FortiOS, PAN-OS, Cisco IOS XE, Citrix Bleed, Log4Shell, OpenSSH regreSSHion, HTTP/2 Rapid Reset, and more) and 10 network protocol exploit patterns (SIP, MGCP, SSLv3 POODLE, Shellshock, JNDI injection, and path traversal probes).

Observability: Prometheus, Kafka, and Terraform

Prometheus metrics

Flowtriq exposes a /api/metrics endpoint in standard Prometheus exposition format. You can scrape it with any Prometheus-compatible collector and build Grafana dashboards on top. The endpoint exports node health status, per-node PPS/BPS, protocol breakdown percentages, baseline statistics (average, p95, p99), active incident counts, active mitigation rules, pending and failed rules, adapter health status, and adapter latency. Authentication supports both Bearer tokens and session cookies.

Kafka export

For teams that run a data pipeline, Flowtriq can stream flow data and mitigation events to Kafka topics in real time. The integration supports both the native php-rdkafka extension (for high-throughput environments) and a REST proxy fallback. SASL authentication (PLAIN, SCRAM-SHA-256, SCRAM-SHA-512) and TLS are supported. Default topics are flowtriq.flows and flowtriq.mitigation.events.

Terraform provider

Flowtriq ships a Terraform provider for infrastructure-as-code workflows. The provider supports full CRUD for nodes and alert channels, plus data sources for querying node lists and workspace configuration. If your infrastructure is managed through Terraform, you can add Flowtriq nodes and configure alerting alongside your compute and networking resources.

Why Not Just Use a Flow Collector?

If you are already running a flow collector like Kentik, FastNetMon, or Arbor Sightline, you might be wondering what Flowtriq adds. The fundamental difference is the detection model.

A standalone flow collector depends entirely on sampled data. At 1:4096 sampling with a 60-second export interval, an attack needs to generate roughly 50,000 PPS sustained for at least one minute before it produces enough sampled packets to reliably trigger detection. Attacks shorter than 60 seconds or below 50,000 PPS are systematically missed.

Flowtriq does not replace your flow data. It augments it with kernel-level counters that have zero sampling loss and 1-second granularity. The flow data gives you upstream visibility into what your border router sees. The kernel data gives you ground truth about what actually reaches each server. The merge gives you both.

For ISPs and hosting providers that already have flow infrastructure, this means you do not need to rip out your existing setup. Point your existing flow exports at the Flowtriq agent alongside your current collector. You get the same network-wide flow visibility you have today, plus sub-second per-server detection, attack classification, PCAP forensics, and automated BGP mitigation.

Flowtriq replaces two tools with one: your flow collector for traffic visibility and your DDoS detection platform for attack response. One agent, one dashboard, one escalation policy.

Audit and Compliance

Every step of the pipeline is logged in a hash-chained audit trail. Each log entry contains a SHA-256 hash of the previous entry, making the audit log tamper-evident. You can prove that a specific detection event led to a specific mitigation action at a specific time, with cryptographic integrity guarantees.

Every BGP adapter payload (the exact rule announced and withdrawn) is recorded. Every escalation decision, threshold crossing, and severity calculation is preserved. This matters for PCI DSS 4.0, SOC 2, HIPAA, and DORA compliance, where you need to demonstrate that DDoS incidents were detected and responded to within defined timeframes.

Flowtriq is available starting at $9.99/mo per node with flow ingestion, dynamic baselines, and auto-escalation included. Start your free trial to see the full pipeline running on your infrastructure.

Back to Blog

Related Articles