BGP blackhole cuts SSH brute force in minutes
The service pitches a BGP community that anyone can peer with over GRE to automatically drop routes identified as malicious. You start by signing up on the website, where you can register with an email address, a PeeringDB profile, or a Thoughtwave account. After registration the system assigns you a private ASN and generates a router configuration snippet that you can apply on your edge device. Once the GRE tunnel is up and the BGP session is established, your router begins receiving routes tagged with a special community; those routes are installed as discard paths, effectively blackholing the source IPs without needing any local script or cron job.
The external network that feeds the community operates under AS23026. According to the author, the feed is built from a combination of public threat intel sources such as Spamhaus, various abuse feeds, and fail2ban reports contributed by other participants. In addition, the operator runs its own attack intelligence pipeline that enriches the data before it is advertised via BGP. The result is a constantly updating list of addresses linked to brute force attempts, credential stuffing, and similar low‑volume attacks. Importantly, the service does not claim to mitigate volumetric DDoS floods; its strength lies in stopping repetitive connection attempts that would otherwise fill log files and consume CPU cycles on authentication daemons.
From an operational standpoint, the setup is advertised as “minutes” because the only manual steps are account creation, downloading the config, and applying it to your router. The author reports running the feed on his own edge router, identified as AS54380, and observing a noticeable reduction in SSH login failures over several months of use. While the original post does not provide an exact percentage drop, the description emphasizes that the change was “drastic” enough to merit sharing the project publicly.
Pricing is straightforward: a two‑week trial period is offered at no cost, after which the subscription is $59 per month. The plan can be cancelled at any time, and a ticket‑based support system is available for troubleshooting peering or configuration issues. There is no mention of long‑term contracts or hidden fees, which makes the recurring cost easy to predict for budgeting purposes.
When compared to more traditional methods of blocking abusive IPs—such as maintaining static access‑control lists, running local fail2ban jails, or subscribing to commercial IP reputation services—the BGP approach offers a few distinct advantages. First, the distribution mechanism is protocol‑native; updates propagate instantly to all peers without requiring a pull‑based script. Second, because the blackholed routes are installed at the routing table level, they consume negligible processing power on the router itself, unlike software‑based solutions that inspect every packet. Third, the multi‑tenant nature of the feed means you benefit from the observations of other participants without having to run your own honeypots or sensor network.
On the downside, the reliance on BGP may be a barrier for operators who do not control their own ASN or who lack GRE tunneling capabilities on their edge hardware. Additionally, because the service focuses on low‑volume, repeated‑attempt patterns, it does not replace dedicated scrubbing capacity for large‑scale UDP or SYN floods. Users seeking comprehensive protection would likely need to layer this solution with upstream DDoS mitigation or cloud‑based protections.
Overall, the project presents a concrete example of how BGP communities can be repurposed for threat intelligence distribution in a way that is lightweight to deploy and easy to consume. If you manage a router that can speak BGP over GRE and are looking for an automated way to trim SSH brute force traffic without investing in a full‑blown IDS, the described mechanism is worth a closer look. The combination of a clear ASN, a defined price point, and a specific use case (brute force SSH reduction) gives enough tangible information to decide whether a trial fits your environment.
In my lab, I’d use email signup and test the generated private-ASN config before allowing GRE-fed malicious routes.