Automating BGP FlowSpec for DDoS
mitigation

Back to Blog

Why FlowSpec Over RTBH

When a DDoS attack hits, the traditional response is RTBH (Remotely Triggered Black Hole): announce a /32 route for the target IP with a blackhole community, and your upstream drops all traffic to that IP. The attack stops. So does all legitimate traffic. The server is offline.

BGP FlowSpec (RFC 5575) is the surgical alternative. Instead of blackholing the entire IP, you advertise filtering rules via BGP that match specific traffic patterns. Drop UDP packets from port 53 destined to 10.0.0.5. Drop TCP SYN packets above a certain rate. Drop ICMP from these source prefixes. The attack traffic gets filtered at the router. Legitimate traffic passes through. The server stays online.

The challenge is automation. Manually crafting and injecting FlowSpec rules during an attack is too slow. By the time you've analyzed the traffic, written the rule, and pushed it to the router, the attack has either ended or already caused damage. The entire pipeline needs to be automated: detection, rule generation, injection, and withdrawal.

The Automation Pipeline

An automated FlowSpec pipeline has four stages:

1. Detection: Identify that an attack is happening and classify the vector (DNS amplification, SYN flood, UDP flood, etc.)
2. Rule generation: Based on the attack classification, build a FlowSpec NLRI (Network Layer Reachability Information) that matches the attack traffic without matching legitimate traffic
3. Injection: Advertise the FlowSpec rule to the router via a BGP session (typically using ExaBGP)
4. Withdrawal: When the attack subsides, withdraw the FlowSpec route so the filter is removed

Let's walk through each stage.

Stage 1: Detection and Classification

FlowSpec rules are only as good as the classification that generates them. A rule that drops "all UDP to port 53" will also drop legitimate DNS traffic. A rule that drops "UDP from source port 53 with packet size above 512 bytes to destination 10.0.0.5" surgically targets DNS amplification responses without affecting normal DNS queries.

The detection system needs to provide:

• The target IP (destination of attack traffic)
• The attack protocol (UDP, TCP, ICMP)
• Source port (for amplification attacks: 53, 123, 11211, 1900, etc.)
• Destination port (if the attack targets a specific service)
• Packet size range (amplification responses are typically large)
• Source prefixes (if the attack comes from identifiable sources)

Agent-based detection on the target server provides the most accurate classification because it sees every packet. Flow-based detection from the router gives you broader visibility but with sampling limitations (see our IPFIX detection guide).

Stage 2: Rule Generation

FlowSpec rules are expressed as BGP NLRI with match criteria and actions. The match criteria specify which traffic to filter. The action (encoded as extended communities) specifies what to do: drop, rate-limit, redirect, or mark.

Here are FlowSpec rules for common attack vectors:

DNS Amplification

# Match: UDP, source port 53, destination 10.0.0.5, packet length > 512
flow {
  match {
    destination 10.0.0.5/32;
    protocol udp;
    source-port 53;
    packet-length >512;
  }
  then {
    discard;
  }
}

This drops large DNS responses (amplification traffic) while allowing normal small DNS replies through.

NTP Amplification

# Match: UDP, source port 123, destination 10.0.0.5
flow {
  match {
    destination 10.0.0.5/32;
    protocol udp;
    source-port 123;
    packet-length >468;
  }
  then {
    discard;
  }
}

SYN Flood

# Match: TCP SYN, destination 10.0.0.5, rate-limit instead of drop
flow {
  match {
    destination 10.0.0.5/32;
    protocol tcp;
    tcp-flags syn !ack;
  }
  then {
    rate-limit 10000;
  }
}

For SYN floods, rate-limiting is often better than dropping. You want to allow legitimate TCP connections while capping the SYN rate to something the server can handle.

Generic UDP Flood

# Match: UDP to specific port on 10.0.0.5
flow {
  match {
    destination 10.0.0.5/32;
    protocol udp;
    destination-port 27015;
  }
  then {
    rate-limit 50000;
  }
}

Stage 3: Injection via ExaBGP

ExaBGP is the standard tool for programmatic BGP route injection. It establishes a BGP session with your router and allows you to announce and withdraw routes (including FlowSpec routes) via its API.

ExaBGP Configuration

# /etc/exabgp/exabgp.conf
process announce-routes {
    run /usr/bin/socat stdout pipe:/var/run/exabgp.sock;
    encoder json;
}

neighbor 10.0.0.1 {
    router-id 10.0.0.2;
    local-address 10.0.0.2;
    local-as 65001;
    peer-as 65000;
    family {
        ipv4 flow;
        ipv6 flow;
    }
}

Injecting a Rule

Once ExaBGP is running and the BGP session is established, you inject FlowSpec rules by writing commands to ExaBGP's API socket:

# Announce a FlowSpec rule to drop DNS amplification traffic
echo "announce flow route { match { destination 10.0.0.5/32; source-port =53; protocol udp; packet-length >512<4096; } then { discard; } }" | socat - /var/run/exabgp.sock

Withdrawing a Rule

# Withdraw the rule when attack ends
echo "withdraw flow route { match { destination 10.0.0.5/32; source-port =53; protocol udp; packet-length >512<4096; } then { discard; } }" | socat - /var/run/exabgp.sock

The router receives the BGP update, installs the FlowSpec filter in its forwarding plane, and starts dropping matching traffic. When you withdraw the route, the filter is removed. The entire process takes seconds.

Stage 4: Automated Withdrawal

Injecting a FlowSpec rule without automated withdrawal is dangerous. If the rule is never removed, it permanently filters traffic to that IP. If the detection system crashes, the rules stay in place indefinitely.

Good automation includes:

• TTL-based expiry. Every injected rule has a maximum lifetime (e.g., 30 minutes). If the detection system doesn't renew it, the rule expires and is withdrawn automatically.
• Traffic-based withdrawal. The detection system monitors whether the attack is still active. When traffic returns to baseline, it withdraws the rule. This is the primary mechanism.
• Watchdog process. A separate process monitors ExaBGP and the detection system. If either crashes, the watchdog withdraws all active FlowSpec rules as a safety measure.

Escalation: When FlowSpec Isn't Enough

FlowSpec works when the attack doesn't saturate the upstream link. If your transit link is 10 Gbps and the attack is 50 Gbps, the packets are already filling the pipe before they reach your router. FlowSpec rules on your router can't help because the damage is done upstream.

A complete automation pipeline includes escalation tiers:

1. Local firewall rules (iptables/nftables on the server). For small attacks that don't saturate the server's link. Deployed in milliseconds.
2. FlowSpec at the edge router. For medium attacks that the router can absorb. Deployed in seconds via ExaBGP.
3. RTBH as last resort. For attacks that saturate the transit link. Blackhole the IP to save the rest of the network. Deployed in seconds.
4. Upstream scrubbing. Signal your upstream provider or cloud scrubbing service to take over filtering. Response time depends on the provider.

Each tier handles a different attack magnitude. The detection system should automatically escalate based on attack size and whether the current mitigation tier is effective.

Safety Considerations

Automated FlowSpec injection is powerful and dangerous. A bug in the rule generation logic can filter legitimate traffic. A runaway automation loop can inject hundreds of rules that overwhelm the router's TCAM. Here are guardrails every production deployment needs:

• Maximum rule count. Cap the total number of active FlowSpec rules. If the automation tries to inject rule #51 and the limit is 50, reject it and alert. Router TCAM is finite.
• Prefix whitelist. Never inject FlowSpec rules that match your own infrastructure IPs, management subnets, or critical services. Maintain an explicit whitelist that the automation checks before every injection.
• Rate limiting rule changes. Cap the number of rule changes per minute. A detection system that rapidly oscillates between "attack" and "normal" will flap FlowSpec rules, which destabilizes the router's forwarding table.
• Dry-run mode. Run the full pipeline in dry-run mode for at least a week before enabling real injection. Log every rule that would have been injected and review them manually.
• Audit trail. Log every rule injection and withdrawal with timestamps, the detection event that triggered it, and the rule content. You need this for post-mortem analysis and debugging.

Doing This with Flowtriq

Flowtriq implements this entire pipeline out of the box. The agent detects and classifies attacks. The mitigation engine generates FlowSpec rules based on the classification. The ExaBGP adapter injects rules into your router. Automated withdrawal removes rules when the attack ends. All the safety guardrails (rule limits, prefix whitelisting, rate limiting, audit logging) are built in.

Setup is: install ExaBGP, establish a BGP session with your router, configure the ExaBGP adapter in Flowtriq's dashboard, and enable auto-mitigation. From that point on, FlowSpec rules are deployed automatically when attacks are detected.

In our EU Network Operator case study, the full pipeline from first attack packet to FlowSpec rule active on the router took 9 seconds. The attack peaked at 159 Gbps. Zero customer tickets.

Back to Blog

Related Articles