Item — HN Reader

My personal preference is to 'ip route add blackhole ${net}' as it has the lowest CPU overhead and I can add hundreds of thousands of CIDR blocks with no noticeable impact. The only downside is that it won't stop UDP packets from getting to a UDP listener. There will not be a response but the application will still see it. For my TCP daemons it's great.

    grep -m1 -E ^Tot /proc/net/fib_triestat ;ip route | grep -Fc blackhole
    Total size: 56735  kB
    426951

Those 426951 blackhole routes include data-centers, VPS providers, botnets, AI datacenters that ignore robots.txt, search engines, abused CDN's, known bad residential nodes and much more. I still see a few residential proxy bots that do a halfway decent job of pretending to be real people at times but the feds are playing whack-a-mole with them. The bots self report to my silly blog so I can block them elsewhere on systems I might care a little bit about. Happy to share them if anyone is remotely interested.

I also use a couple generalized rules in nftables raw table that keeps a lot of beyond poorly written bots away including hping3 tcp floods and masscan. My rules to port 443 are stateless. One must not taunt the state table.

5 comments

The problem is when you block those "residential proxy bots" you also block real people who just happen to have a dumb teenager on their network playing some free games that are monetized by proxies.

The only real solution to bots is making users log in. And even then you have to fight registration bots.

I get what you mean. It happens all the time when some clown trashes an IP's reputation and Cloudflare or Google will send the next lease of that IP into crosswalk fire-hydrant bus traffic light purgatory.

That's why I eventually let those go usually after a kernel update and the git repo for FireHOL gets updated often. The kernels get updated often. I only perma-ban the data-centers which is fine for my silly blog and probably for some peoples hobby sites. People can chose which methods to apply, how to apply them or which ones to skip entirely.

Excellent username btw. Those SNL Celebrity Jeopardy episodes are unforgettable. [1]

[1] - https://www.youtube.com/watch?v=bEghu90QJH4

I would like to learn more how you maintain your table of IP ranges (or CIDR block). How do you decide when to add/remove a range?

I'm most concerned about blocking innocent users, currently I use Cloudflare to block known bad ASNs using a list I found on GitHub.

How do you decide when to add/remove a range?

The only IP's that come and go are the Tor 30 day blocklist and a couple FireHOL attackers from a repo though I will sometimes leave the last entries live until reboot. I do not really need to block tor but I use this silly blog as a testing ground. Tor and some known abusers come from a git repo I refresh periodically.

The data-centers, VPS providers, CDNs, known botnets are perma-banned. For my hobby nodes I personally find this acceptable. I would not do this in a professionally managed data-center. There are better methods for those cases especially for B2B corporate arrangements. Regardless of what daemons I run I never have external dependencies that need to be accessed from my node or from the client with exception of stratum-1 time servers.

I do have to periodically update the CIDR blocks for given ASN's. I have not automated this but I probably should some day. It's not hard to automate, I am just excessively "efficient". I was told to stop calling myself lazy, but I am.

Methods 2, 3 and 5 are the ones I talk about here. [1]

[1] - https://nochan.net/b/Internet-Crap/20260606-How-To-Block-Som...

Thank you for including a link to your blog, very useful read.

What does all of this give you? For a static(?) site burning a few cycles unnecessarily, saving what, 30 cents of power per year?

Peace of mind? Fair enough but I'd be more wary about blocking legitimate users. VPS providers are often used for VPNs etc.

What does all of this give you?

Good question. A playground to test things. A place for bots and their kin to report themselves to me so that I can use this information for sites I actually want to protect a little bit. A place to share some ideas with a small handful of like minded people. I do not consider power savings for a device unless I have it running on one of my inverters or if I am doing that to constrain a potentially malicious node.

Blogs are throw away for me. After some time I delete the VM and edit articles offline for 6 to 18 months and then put them back up on another domain when there may be a need to share some old articles. This method disjoints the archive sites and breaks any filters botters have set up to ignore me. That also allows me to change the CSS. I try to make it smaller each time.

I also find it easier to put long form content on a blog of sorts instead of HN comments in the unlikely chance that YC removes HN due to future ID/Age verification constrains or other unforeseen reasons that we hope never happens.

> The only downside is that it won't stop UDP packets from getting to a UDP listener. There will not be a response but the application will still see it.

Try:

  ip route add src ${net} blackhole

You could configure reaction to add and remove `ip route` commands in that format.