BGP Flowspec False Positives: When DDoS Filters Block Legitimate Traffic

Your ISP deploys BGP Flowspec to mitigate volumetric attacks. Rules are pushed to your edge routers. Automatic. Real-time. Traffic from known attack sources gets rate-limited or dropped. Except yesterday, your nightly backup script timed out mid-transfer. Today, your monitoring vendor’s API calls are returning 503. Neither are attacks. Both hit Flowspec rules.

Flowspec is powerful—it lets upstream providers push filtering rules to your border routers without manual configuration. But it’s blunt. It matches on 5-tuple (source IP, destination IP, protocol, source port, destination port) and can apply rate limits or discard actions. The problem: legitimate traffic with the same tuple as attack traffic gets caught in the same net.

Myth: Flowspec Filters Only Attack Traffic

The ideal Flowspec rule is specific: “Drop all packets from 192.0.2.0/24 to 203.0.113.1 on port 53 with packet size >1000 bytes.” That’s precise. Only oversized DNS queries from one subnet to one target get blocked. Legitimate small DNS queries pass. Legitimate large queries from other sources pass. It’s surgical.

But in practice, Flowspec rules come from upstream providers (your ISP, your DDoS mitigation service). They’re aggregated across thousands of customers. The rules are broad because they’re meant to stop traffic *before* it reaches your network. A typical rule: “Drop packets from AS64512 with destination port 53 and packet size >512 bytes.” This catches the UDP amplification attack. It also catches your bulk DNS zone transfer, your secondary nameserver sync, your monitoring tool’s DNS performance tests, and any legitimate application doing DNS-over-TCP.

Why the false positives? Because attackers don’t have unique fingerprints. They use the same protocols, same destination ports, same packet sizes as legitimate services. An HTTP flood looks like an iperf bandwidth test. A SYN flood looks like a load test. A DNS amplification attack looks like a legitimate recursive query from a proxy server.

Reality: Flowspec Rules Are Too Coarse-Grained

Here’s a real scenario. Your ISP observes a UDP flood toward port 53 from a botnet in AS64512. Packet size: 60 bytes (small DNS queries trying to trigger large responses). The ISP creates a Flowspec rule: “Drop UDP packets from AS64512 to any destination on port 53 with size <100 bytes.” The rule propagates to your border router within seconds.

Sounds defensive. But your secondary nameserver receives zone transfers from your primary (also UDP, port 53) with small packets (SOA queries, IXFR requests). Your rule now blocks zone transfers. Your secondary falls out of sync. Your DNS responses become stale. Queries for domains you host start failing.

Another case: your DDoS mitigation vendor pushes a Flowspec rule: “Rate-limit packets from sources outside your AS to your web servers on port 80/443 if packet rate exceeds 10,000 pps.” This protects you from a botnet. But it also rate-limits your legitimate CDN provider whose single presence generates 50,000 pps during a traffic spike. The Flowspec rule doesn’t distinguish between attack traffic and legitimate traffic—it just sees high rate and acts. Your website slows down during peak hours.

The deeper problem: Flowspec operates at the BGP level. It has no application context. It sees IP addresses, ports, and packet characteristics. It doesn’t see that 203.0.113.50 is your monitoring platform. It doesn’t see that 192.0.2.10 is your backup server. It only sees tuples. If an attacker source happens to be in the same AS or has the same characteristics as your trusted partner, you get collateral damage.

Flowspec is a firewall at the ISP level with no knowledge of your traffic patterns. Every rule is a guess about what’s legitimate.

How to Protect Against Flowspec Collateral Damage

1. Get visibility into active Flowspec rules. Your ISP or DDoS provider should expose this. If they don’t, ask. You need to know what’s being filtered:

# Most ISPs push Flowspec via BGP NLRI AFI 1 SAFI 133
# Check your router's Flowspec routes with:

# Cisco IOS XE / Juniper
show bgp flowspec

# Juniper (detailed)
show route table inetflow.0 extensive

# OpenBSD bgpd / Linux bird
show route table flowspec

# If your ISP doesn't expose this, ask for a Flowspec rule summary
# and request they be shared with you for auditing

2. Monitor Flowspec hits and misses. Know when rules are triggering. Most modern routers log Flowspec actions. Parse them to catch false positives early:

# Cisco: collect Flowspec action logs
show access-list flowspec-drop
# Shows matched and dropped packets per rule

# Juniper: enable logging for Flowspec actions
set firewall filter flowspec term match-attack then log

# Parse logs to identify high-volume legitimate sources
# If you see port 53 traffic from your secondary nameserver, that's a false positive

# Real-time with tcpdump on the border
tcpdump -i border-interface 'dst port 53' | head -100
# Inspect source IPs. If you recognize them (your DC, your partners), investigate Flowspec rules

3. Maintain a whitelist of known-good sources. Coordinate with your ISP to exempt internal traffic, partner traffic, and monitoring sources from Flowspec rules:

# Request ISP add exceptions to their Flowspec rules
# Example: "Drop UDP/53 from AS64512 EXCEPT from our secondary nameserver 203.0.113.50"
# Flowspec supports this with more specific rules

# On your router, you can also override Flowspec behavior per rule:
# (Juniper example)
set firewall filter local-override term allow-dns-zone-transfer from source-address 203.0.113.0/24
set firewall filter local-override term allow-dns-zone-transfer then accept

# Apply local-override with higher priority than Flowspec

4. Test Flowspec rules in staging before production rollout. If your ISP or vendor is pushing a new rule, request a staged deployment or a preview window:

# Simulate the rule on your lab router or a test interface
# Send traffic matching the rule signature and verify:

# Example rule: "Drop UDP packets from external AS to port 53 >1000 bytes"
# Test with:
iperf3 -c nameserver.example.com -u -l 1200 -b 0 -t 5
# Monitor the lab interface to confirm packets are dropped

# Check your monitoring during the test
# Expected result: DNS queries should fail or be rate-limited during the test window

# If no anomalies, request the ISP roll out the rule
# If anomalies appear, request refinement (whitelist your secondary, adjust packet size threshold, etc.)

5. Establish incident response for Flowspec false positives. When a critical service goes down and you suspect Flowspec, you need a playbook:

# Quick diagnosis:
# 1. Check if traffic reached your router
tcpdump -i border-interface 'dst host critical-service' | head -20

# 2. If traffic is present, check for Flowspec rule matches
show access-list flowspec-* | grep hit
# High hit count + your service down = Flowspec collateral

# 3. Contact ISP immediately and request rule suspension or refinement
# Example: "Rule 'Drop UDP/53 >512 bytes' is blocking our zone transfers. Please add exception for 203.0.113.50 or rollback."

# 4. As temporary mitigation, filter ingress traffic through your own rules
# Accept traffic from known-good sources even if Flowspec drops it
set firewall filter local-override term allow-partner-dns from source-address 192.0.2.0/24
set firewall filter local-override then accept

6. Request granular Flowspec rules from your provider. Push back on overly broad rules. Specific is better:

# Instead of: "Drop UDP/53 from AS64512"
# Request: "Drop UDP/53 from AS64512 with packet size <100 and rate >10,000 pps EXCEPT 203.0.113.50"

# Instead of: "Rate-limit HTTP traffic above 50,000 pps"
# Request: "Rate-limit HTTP traffic from sources outside your AS above 50,000 pps, EXCEPT partner-cdn-as"

# Flowspec supports complex rules. Use them.

Flowspec is a powerful tool for upstream mitigation. But it operates blind to your network’s topology and legitimate traffic patterns. The rules come from the ISP’s detection systems, not from knowledge of your business. Treat every Flowspec rule as a hypothesis, not a guarantee. Monitor, whitelist, test, and maintain incident response. The alternative is discovering that your backups failed or your DNS went stale only when users complain.