Drop the threat
before it reaches
your firewall.
BlackHawk is a BGP blackhole route server. Bring up one eBGP session and your routers start discarding traffic to command-and-control servers, malware hosts, ransomware infrastructure, aggressive scanners and entire hostile networks — in hardware, at line rate, before any of it touches a firewall rule or an IDS.
Live from the routing table, refreshed every 5 minutes. Per-country blocking adds a further 333,381 prefixes of registry data — off by default, and enabled one country at a time.
See the infections you already have
Most blocking tools throw the packet away and tell you nothing. Point the blackhole next-hop at a sinkhole collector instead and every blocked attempt names the internal host that made it — turning your perimeter into a detection surface for machines that are already compromised.
Infected host beacons out
A workstation on the corporate LAN is already compromised. Its implant opens a session to a known C2 server at 198.51.100.44. Nothing on the endpoint reports this.
Enforcement where you already have capacity
Your routers can already discard millions of packets per second without breaking a sweat. BlackHawk simply tells them what to discard.
Enforcement in silicon, not software
Forwarding-plane drops cost you nothing. No firewall state table, no IDS inspection budget, no proxy licence tier scaling with the size of your threat list.
Find hosts that are already infected
Sinkhole the blackhole next-hop and every blocked beacon identifies the internal machine that sent it. Detection without deploying an agent on the endpoint.
Policy changes without a session flap
Toggling a category rewrites your export filter and issues a route refresh. The session stays up; the routes change underneath it.
We never accept a route from you
Inbound is rejected at policy for every peer, unconditionally. BlackHawk cannot be used to leak or hijack a prefix through your session.
Per-category, per-country control
Block C2 and ransomware but keep research scanners. Drop three countries and nothing else. Your policy, changed whenever you like.
IPv4 and IPv6, equally
Both families are carried on the same session with correct MP-BGP next-hops. IPv6 threats are not an afterthought.
Plain BGP your gear already speaks
RFC 7999 blackhole community, RFC 8092 large communities for classification, optional MD5 and RFC 5082 GTSM. No agent, no appliance, no tunnel.
Counts, trends and session state
See exactly how many prefixes you are receiving, broken down by category, with 30-day history and live session status.
Operator injection when it matters
When something is actively burning, our operators can push a prefix to every subscriber immediately rather than waiting on the next feed cycle.
Subscribe to exactly what you want dropped
Every category is a switch in your dashboard. Flip one and the change reaches your router in seconds over the existing session — no reconnect, no flap, no ticket.
GeoIP ranges are derived from the five regional internet registries and are opt-in per country. Benign research scanners (Shodan, Censys, Shadowserver) are a separate, off-by-default category — plenty of teams want their exposure measured.
Two sessions. Your vendor, your syntax.
Sign up, tell us your peer address and ASN, and paste the config we generate. You peer with every BlackHawk node, so losing one costs you nothing. Both sessions are egress-only: BlackHawk advertises to you and rejects every route you send.
! BlackHawk AS401573 - RTBH feed
! Discard interfaces: everything black-holed lands here.
ip route 192.0.2.1 255.255.255.255 Null0
ipv6 route 100::1/128 Null0
!
! Advertise nothing back.
ip prefix-list BH-NO-EXPORT seq 5 deny 0.0.0.0/0 le 32
ipv6 prefix-list BH-NO-EXPORT-V6 seq 5 deny ::/0 le 128
!
route-map BLACKHAWK-IN permit 10
set ip next-hop 192.0.2.1
set ipv6 next-hop 100::1
!
router bgp 65001
bgp log-neighbor-changes
neighbor 68.183.61.178 remote-as 401573
neighbor 68.183.61.178 description BlackHawk threat route server (nyc3)
neighbor 68.183.61.178 password <generate-your-md5-key-first>
neighbor 68.183.61.178 ebgp-multihop 64
!
neighbor 144.126.216.83 remote-as 401573
neighbor 144.126.216.83 description BlackHawk threat route server (sfo3)
neighbor 144.126.216.83 password <generate-your-md5-key-first>
neighbor 144.126.216.83 ebgp-multihop 64
!
address-family ipv4
neighbor 68.183.61.178 activate
neighbor 68.183.61.178 send-community both
neighbor 68.183.61.178 route-map BLACKHAWK-IN in
neighbor 68.183.61.178 prefix-list BH-NO-EXPORT out
neighbor 68.183.61.178 maximum-prefix 500000 90
!
neighbor 144.126.216.83 activate
neighbor 144.126.216.83 send-community both
neighbor 144.126.216.83 route-map BLACKHAWK-IN in
neighbor 144.126.216.83 prefix-list BH-NO-EXPORT out
neighbor 144.126.216.83 maximum-prefix 500000 90
exit-address-family
!
address-family ipv6
neighbor 68.183.61.178 activate
neighbor 68.183.61.178 send-community both
neighbor 68.183.61.178 route-map BLACKHAWK-IN in
neighbor 68.183.61.178 prefix-list BH-NO-EXPORT-V6 out
neighbor 68.183.61.178 maximum-prefix 500000 90
!
neighbor 144.126.216.83 activate
neighbor 144.126.216.83 send-community both
neighbor 144.126.216.83 route-map BLACKHAWK-IN in
neighbor 144.126.216.83 prefix-list BH-NO-EXPORT-V6 out
neighbor 144.126.216.83 maximum-prefix 500000 90
exit-address-familyName the machine, not just the packet
Blackholing tells you traffic stopped. It does not tell you which of your machines was sending it — and on an incident call that is the only fact anything turns on. Point the blackhole next-hop at a collector inside your own network and every blocked beacon becomes a named host, a named user, and the category that put the route there.
41,209 packets discarded
Something inside your network is compromised and calling home. The traffic is stopped. You cannot send anybody to fix it, because nothing here says which machine it was.
beaconing to a Feodo C2 every 90s since Tuesday
C2 · critical · 2,317 attempts
Same route, same drop, different next-hop. Now it is a ticket with a hostname on it — and detection on a device you were never going to get an endpoint agent onto.
The collector is the next-hop
Your blackhole routes point straight at it. Highest fidelity — every attempt, with ports, at packet granularity. It reads headers only and never stores payload. Linux only.
Nothing is redirected at all
The router that discards the traffic exports NetFlow v5/v9, IPFIX or sFlow and the collector matches it against the routes you receive. The data path does not change — frequently the only proposal that survives a change board. Both sensors can run at once.
An address becomes a host, a person and a department by asking systems you already run. All three lookups happen on your side of the wire.
Your resolvers
Reverse DNS against your internal servers, not the system stub, so the names are the ones your team already uses. Rate-limited on purpose — a burst of PTR queries at a domain controller serving logons is how a monitoring box gets blamed for a slow morning.
Active Directory
Two read-only LDAPS searches per host yield the OU, operating system, last logon and the assigned user's name, mail and department. The bind account needs nothing beyond the read every domain already grants. Plain ldap:// is refused at startup.
Who was actually at the keyboard
AD records who a machine is assigned to. Only the domain controller that authenticated the session knows who signed in — and with shared workstations or VDI those differ. Forward logon events and the dashboard says which source answered.
Destination addresses — the ones we already told you to blackhole — and a heartbeat every five minutes carrying six fields: the appliance’s own version, hostname and platform, its sensor mode, and two counters.
No internal addresses. No hostnames of your machines. No usernames. No flow records. Those exist only on your appliance, and there is a test in our build that fails if a seventh field is ever added to that heartbeat.
{
"version": "1.0.0",
"hostname": "bhc1",
"platform": "linux/amd64",
"sensor_mode": "netflow",
"hosts_seen": 412,
"events_seen": 88123
}Set offline: true and it makes no outbound calls at all — the dashboard keeps working and classifies from the last route snapshot. An air-gapped site is a day behind, not unsupported.
The same routes, working inbound
A blackhole route is a route to a destination. It stops your hosts reaching a bad address, and on its own it does nothing about that same address connecting to you. Loose uRPF turns the routes you already receive into an inbound filter — no new feed, no second session, one line per interface.
Matches on the destination address
The discard route the generated configuration already sets up. Your host sends to a blackholed address; the FIB drops it.
Matches on the source address
Loose uRPF asks where a reply to this source would go, lands on the discard route you already hold, and drops the packet — in hardware, before any ACL.
Your BlackHawk routes make the question answer itself. A blackholed prefix sits in your FIB pointing at a discard next-hop, so when a packet arrives from an address inside that prefix the reverse lookup fails and the packet is gone at line rate — before an ACL, before the firewall, before anything allocates state for it.
Cisco IOS / IOS-XE — internet-facing interface
interface GigabitEthernet0/0/0 ip verify unicast source reachable-via any allow-default ipv6 verify unicast source reachable-via any allow-default
IOS-XR, NX-OS, Arista, Junos and Linux stanzas are in the documentation.
Read the default-route caveat first
If your edge carries a full BGP table this is safe as written. If it carries only a default route, uRPF without allow-default will drop essentially all inbound traffic. Use strict mode on a multihomed edge and it will drop legitimate asymmetric traffic. Getting this wrong takes your edge off the internet.
Nothing new to maintain
No extra feed, no second session, no ACL that drifts out of date. The routes you already receive start working in both directions the moment the interface command is applied.
It fails open, not closed
If the BGP session drops, the routes withdraw, the discard entries leave the FIB and uRPF stops matching them. Losing BlackHawk costs you the filtering — it does not black-hole your network.
A blackhole feed is dangerous. This one is built like it.
Handing another network authority over your routing table deserves scrutiny. Here is exactly what stops BlackHawk from breaking your estate.
An immutable never-blackhole safelist
RFC 1918 space, loopback, link-local, the public resolvers, the DNS root servers and the documentation ranges can never enter the table. Matching is by overlap in both directions, so announcing a supernet of a protected address is refused just as firmly as the address itself.
Breadth limits that stop the obvious catastrophe
Nothing broader than a /8 (IPv4) or /19 (IPv6) is accepted from any source, so a malformed feed cannot advertise a default route and black-hole the internet for every subscriber at once.
Feeds that shrink or explode are refused
A source returning far fewer prefixes than last time, more than its configured ceiling, or nothing at all is rejected outright and the previous data is retained. Silent truncation upstream does not become a silent gap in your protection.
You choose the next-hop, so you choose the behaviour
Discard to null0, or divert to a collector and keep the telemetry. BlackHawk advertises the prefix; what your router does with it stays entirely your decision.
Free while we build
the community.
No cost, no card, no prefix cap. Sign in with your Google Workspace or Microsoft Entra account, or verify a business email address.