The Firewall Was the Wrong Layer: Automating Threat Response with BGP

A LinkedIn post I wrote about this covers the story: a daily infosec email, a firewall policy cycle, and the decision to stop doing the same fix by hand. This post goes deeper into the mechanics behind Remote Triggered Black Hole (RTBH) routing. Specifically, it covers why the firewall was structurally the wrong enforcement point, and how RTBH uses BGP signaling to solve the same problem at the layer built to handle it at wire speed.

The problem with enforcing at the firewall

A stateful firewall evaluates every packet against a policy table. That’s the right tool for permit/deny decisions that need context — zones, application awareness, session state. However, it’s the wrong tool for “drop everything from this /32, no exceptions, no state to track.” Every firewall policy change on a production edge device carries change-management weight: a request, an approval, a push, a verification pass. For a single bad-actor IP that infosec has already identified with certainty, none of that overhead buys anything. Instead, it just adds latency between detection and enforcement.

Remote Triggered Black Hole: Moving Enforcement to the Data Plane

Remote Triggered Black Hole routing solves this by using BGP itself as the signaling mechanism. Instead of a policy engine, it uses the router’s forwarding plane as the enforcement point.

The design centers on a route reflector — in this case, a RHEL VM running Quagga/BGPD — sitting in an iBGP relationship with both edge border routers. When a bad-actor /32 needs blocking, that host route enters BGP with a specific next-hop: a documentation-range address (192.0.2.1) that stays non-routable except through a static route on each border router. That static route points 192.0.2.1 at Null0.

The effect follows directly. The static route resolves any prefix using that next-hop to a discard action in the router’s FIB. There’s no ACL entry, no firewall rule, and no per-packet policy evaluation involved. The router simply has no forwarding path for that destination, so it drops the traffic in hardware.

Why the return path also gets handled — uRPF loose mode

Blocking inbound traffic to a victim IP only solves half the problem for a volumetric threat. Source-based blackholing also needs the reverse direction covered.

Unicast Reverse Path Forwarding in loose mode, defined in RFC 3704, checks whether the router holds any FIB entry for a packet’s source address. If that entry’s next-hop is Null0, the router drops the packet on ingress, before it reaches the rest of the forwarding pipeline.

This is the mechanism that makes RTBH bidirectional without touching two separate features. Blackhole a source /32 via iBGP, and uRPF loose mode drops that source’s traffic on ingress at every enabled interface — no separate configuration step per interface, per threat.

Verification is straightforward. The command show cef <prefix> detail confirms the Null0 forwarding entry. Drop-counter increments on the ISP-facing interface then confirm uRPF is actually firing, rather than the route simply sitting unused.

Closing the loop from email to enforcement

The remaining piece was operational, not architectural. Infosec’s daily report arrived as a list of IPs in an email body, and Quagga needed BGP network statements instead.

A script built around Expect parsed the email, translated each IP into the corresponding vtysh command, and injected it into the running BGP process. The workflow stayed human-in-the-loop by design: infosec originates the list, and a single operator executes it. However, the execution step itself changed — from a multi-system approval chain down to one paste.

What Remote Triggered Black Hole Changed

Remote Triggered Black Hole enforcement moved threat response permanently off the firewall policy cycle and onto the data plane. Every border-host enforcement decision infosec made for the remainder of the engagement ran through this path instead of the firewall. Thirty minutes a day, indefinitely, or roughly six hours to build once. The math wasn’t close.

This is a different failure mode than the BGP prefix leak that took down campus-wide CDN access. There, the routing system itself was the problem; here, it becomes part of the fix.