The Cheapest Place to Drop a Packet Is the One You Already Own

Ask a security team where a malicious packet gets dropped and you will usually hear the name of a product. A FortiGate. A Palo Alto. A secure web gateway. An EDR agent. All correct, and all describing the same architectural choice: the packet is dropped after something has looked at it.

Looking at it is the expensive part.

Where the money actually goes

Every inspection control in the stack has the same cost structure, whatever the logo on the front:

• A throughput ceiling that collapses when you turn features on. A firewall's datasheet number is measured with nothing enabled. Turn on TLS inspection, IPS and application control and real-world throughput on the same box drops substantially — vendors publish the derated figures, and they are the ones that matter for sizing.
• A session table with a hard limit. Every flow the firewall sees consumes an entry whether that flow is legitimate or a botnet node knocking on a closed port for the ten-thousandth time today.
• An indicator list capped in the low thousands. External block lists in most NGFWs, SWGs and DNS filters are bounded — by entry count, by object count, or by how many you can push before policy compile time becomes a problem.
• Licensing tied to volume. Log ingestion, inspected bandwidth, seats, whichever meter the vendor chose. The meter runs on traffic you wish you had never received.

Now price the alternative. A router's forwarding plane drops a packet by consulting a route it already holds and sending it to a discard interface. That lookup is the same lookup it performs to forward the packet legitimately — an ASIC operation, at line rate, already paid for in the capital cost of the box. There is no per-packet marginal cost, no session-table entry, and no meter.

This is the whole argument. It is not that blackholing is better than inspection. It is that dropping is free in one place and expensive in every other place, and most networks do all of their dropping in the expensive place.

RTBH, briefly, for people who buy rather than configure

Remotely triggered blackhole routing is old, boring and standardized. A route is advertised for a destination prefix with a next-hop pointing at a discard interface. The router installs it like any other route. Traffic to that destination is thrown away in hardware.

The mechanism has carried RFC 7999's well-known community 65535:666 since 2016, and RFC 8092 large communities let a route server tag each prefix with what kind of threat it represents and let you decide, per class, what your router does about it.

Carriers have used this for DDoS mitigation for two decades — blackholing a customer's own attacked address to save the rest of the network. Pointing the same mechanism at outbound threat destinations is the same machinery aimed differently, and it is a much larger win, because the traffic you are discarding is the traffic that was going to cost you an incident.

What actually moves off the firewall

Be honest about the shape of the traffic, because this is where the savings are either real or imaginary.

Blackhole routing works on destinations you can name as IP prefixes. Command-and-control endpoints. Malware distribution hosts. Ransomware staging and exfiltration infrastructure. Botnet nodes. Bulletproof hosting ranges and hijacked address space. Entire autonomous systems whose business is abuse. Scanners. If you choose to, whole countries you have no business relationship with.

It does not work on URL paths, file hashes, CVE identifiers, or anything requiring a look inside the payload. A malicious document arriving over a legitimate CDN is a firewall's problem and always will be. So is a phishing page on a shared host you cannot afford to discard wholesale.

So the accounting question is not "can this replace inspection" — it cannot, and any vendor telling you otherwise is selling something. The question is narrower and more useful:

What fraction of the sessions my firewall inspects are headed somewhere no legitimate business process has ever needed to reach?

On most enterprise edges, that fraction is not small. Background scanning against public address space is continuous and machine-driven. Compromised hosts inside the estate beacon on fixed intervals, indefinitely, whether or not anyone is at the keyboard. None of that traffic was ever going to be allowed. All of it is currently being paid for twice: once in inspection capacity, and once in the log volume it generates.

Worked example — and read the assumptions

Numbers here depend entirely on your environment, so treat this as a method rather than a result. Take a firewall pair sized for 10 Gbps of inspected throughput and 2 million concurrent sessions, running at 60% of both at peak.

Suppose 15% of inspected sessions are headed to destinations that would be covered by a threat-prefix feed. Move those to the forwarding plane and you recover roughly 15% of session-table headroom and a similar share of inspection budget — without a hardware refresh, a licence upgrade, or a change to a single security policy. The firewall keeps doing exactly what it did before, on the traffic that actually needed judgment.

Run the same 15% through a log-volume-priced SIEM and the saving compounds, because those sessions stop generating deny events entirely. They never arrive.

Now run the sensitivity. At 3% instead of 15%, the capacity argument mostly evaporates and you are buying this for the detection value rather than the economics. That is still a reasonable purchase — see below — but it is a different business case, and you should know which one you are making before you write it down. Measure your own share first. Pull a week of deny logs, extract destination addresses, and check them against a threat-prefix feed. That number is the entire business case and it takes an afternoon.

The part that is genuinely free: inbound

Here is the detail most teams miss. Once a threat prefix sits in your FIB pointing at a discard next-hop, you have also, incidentally, built an inbound filter.

Loose unicast Reverse Path Forwarding drops a packet whose source address has no usable return path. A packet arrives sourced from inside a blackholed prefix, the reverse lookup lands on a discard route, uRPF fails, and the packet dies in hardware — before an ACL, before the firewall, at line rate.

One line per interface. No second feed, no second session, no ACL to maintain and re-audit every quarter:

interface GigabitEthernet0/0/1
 ip verify unicast source reachable-via any
 ipv6 verify unicast source reachable-via any

Use loose mode. Strict uRPF will break any multihomed network with asymmetric routing, which is most of the networks worth protecting. This warning belongs next to the feature everywhere it is described, including here.

The savings nobody puts in the spreadsheet

Capacity is the easy argument. Two others matter more in practice.

Indicator scale. A routing table holding hundreds of thousands of prefixes is an ordinary Tuesday. An NGFW external block list capped at a few thousand entries forces someone to curate — to decide which threats are worth the slots. That curation is unpaid, invisible, and the first thing to lapse when the person who did it leaves.

Time to protection. Adding a prefix to a route server and having it programmed into every subscriber's forwarding plane is seconds of work. Getting a new indicator through a firewall change process is a change ticket, a review board and a maintenance window. During a live campaign that difference is the whole engagement.

Where the real value shows up

If blackholing only saved inspection capacity it would be a decent infrastructure optimization and a boring blog post.

What makes it interesting is the direction of the traffic. Most of what a threat-prefix feed discards is outbound — something inside your network trying to reach something outside it. That is not an attack arriving. That is a machine you own, already compromised, calling home.

A firewall deny log records that the packet was dropped. It does not tell you which laptop sent it, and that is the only fact an incident actually turns on.

Point the blackhole next-hop at a collector inside your own network instead of at null0, and every blocked beacon becomes a named internal host — and, if you enrich against your own directory and logon events, a named user. "Your router discarded 41,000 packets" becomes "the workstation in Finance used by a named employee has been beaconing to a known C2 every ninety seconds since Tuesday."

That is detection on devices you cannot put an agent on. OT controllers. Medical equipment. Printers. Building management. Contractor laptops. Anything embedded. For a large part of most estates it is the only way that machine's compromise will ever surface.

The risk, stated plainly

A blackhole feed can take a network off the air. If a bad prefix enters the table, traffic to it stops — and if the prefix is broad enough or important enough, that is an outage you caused to yourself.

Anyone selling you this who does not lead with that is not someone to buy it from. The questions to ask:

1. What can never be blackholed, and is the safelist matched by overlap in both directions? Refusing 8.8.8.8/32 is easy. A feed that accepts 8.8.0.0/16 breaks the same resolver and is the failure that actually happens.
2. What is the minimum prefix length accepted from any source? Without a breadth floor, one malformed feed can advertise something close to a default route.
3. What happens when an upstream feed silently truncates? Half a list is a silent gap in protection. It should be rejected and the previous data retained, not accepted quietly.
4. Can the service accept a route from me? The answer should be a flat no, enforced globally rather than per peer. Anything else is a route-hijack path through your own session.
5. Can I run it in observe mode first? You choose the next-hop. Point it at a collector before you point it at null0 and watch what would be dropped for a fortnight. If a vendor cannot support that, they are asking you to take the risk on faith.

Start by measuring

You do not need to buy anything to find out whether this is worth it.

Pull a week of outbound deny logs. Extract the destination addresses. Check what share of them fall inside known threat prefixes, and — more revealing — how many distinct internal hosts are generating them. The first number tells you what you would save. The second tells you how many machines you own are already talking to someone else's infrastructure, which is usually the number that changes the conversation.

Then decide whether that work belongs in a device sized and licensed for inspection, or in the forwarding plane you have already bought.

BlackHawk Data operates BlackHawk BlackHole, a BGP blackhole route server on AS401573, with a free tier that is a working session rather than a trial. Our network engineers will sit on the call while you bring the session up.