Thought the real-time threat map by spamhaus was interesting https://www.spamhaus.com/threat-map/
Pretty much tallies with all the botnets I have posted about recently as well..
Can all registered uses please login, even just for a few minutes..
It helps build a picture where our "good traffic" is coming from..
Thanks :)
It helps build a picture where our "good traffic" is coming from..
Thanks :)
Server updates
Re: Server updates
A quick note on the meta-externalagent blocks that went in today.
This is Meta's own AI/indexing crawler, separate from the one that generates Facebook link previews (facebookexternalhit), which is untouched and still works fine, so sharing links to the forum on Facebook is unaffected.
What's blocked: that specific crawler, identified by its user agent, hitting our download links. Each individual IP address was sticking close to a respectable 2 requests a second, roughly what a robots.txt-abiding crawler should do. The problem was the number of IP addresses doing it simultaneously, dozens of them all at once, adding up to combined traffic in the region of 1,000 requests a second, enough to start slowing the server down. Some of these are also caught and banned outright once they repeat.
What's not blocked: real visitors, including anyone arriving via a Facebook link, and any other legitimate search or AI crawler (Google, Bing, etc.) are untouched.
Some history on this one. Meta's crawler was banned outright a few months ago because the sheer volume was taking the server down. I lifted that ban to see if things had improved this time round, they had not, so clearly they are still sending far more traffic than any server should reasonably have to absorb. A couple of weeks ago I switched from an outright ban to just serving them 403s instead, but that only filled up the logs while still leaving several thousand connections a minute landing on the server, which is just noise for no benefit.
So meta AI bot is permanently banned again now, because it simply will not behave. For what it's worth I'm generally against banning AI crawlers on principle, I think they should have as much right to read public content as anyone else. But that only holds while they behave themselves, and Meta clearly is not going to.
This is Meta's own AI/indexing crawler, separate from the one that generates Facebook link previews (facebookexternalhit), which is untouched and still works fine, so sharing links to the forum on Facebook is unaffected.
What's blocked: that specific crawler, identified by its user agent, hitting our download links. Each individual IP address was sticking close to a respectable 2 requests a second, roughly what a robots.txt-abiding crawler should do. The problem was the number of IP addresses doing it simultaneously, dozens of them all at once, adding up to combined traffic in the region of 1,000 requests a second, enough to start slowing the server down. Some of these are also caught and banned outright once they repeat.
What's not blocked: real visitors, including anyone arriving via a Facebook link, and any other legitimate search or AI crawler (Google, Bing, etc.) are untouched.
Some history on this one. Meta's crawler was banned outright a few months ago because the sheer volume was taking the server down. I lifted that ban to see if things had improved this time round, they had not, so clearly they are still sending far more traffic than any server should reasonably have to absorb. A couple of weeks ago I switched from an outright ban to just serving them 403s instead, but that only filled up the logs while still leaving several thousand connections a minute landing on the server, which is just noise for no benefit.
So meta AI bot is permanently banned again now, because it simply will not behave. For what it's worth I'm generally against banning AI crawlers on principle, I think they should have as much right to read public content as anyone else. But that only holds while they behave themselves, and Meta clearly is not going to.
Re: Server updates
Some of you will have noticed intermittent connection trouble to the forum over the past few days rather than just general slowness.
A couple of weeks back I retired a few of the fail2ban jails watching for certain floods, they'd gone quiet for a while and didn't seem to be catching anything worth keeping running. Typical timing, the same threats have started back up again since, so today involved putting a few of those jails back to work and adapting nginx directly to drop that traffic at the door rather than let it through.
Two separate floods were making things worse together. One was random probes hammering files and folders that don't exist on this server, hunting for exposed config and credential files. Every one of those still mints its own short-lived cache entry, so thousands of them in a row just fills the cache up with junk that nobody will ever ask for twice.
The other was the cache's own two hour refresh only running once a day rather than little and often, meaning a big pile of pages would go stale before the next top up. When a flood then lands on a stack of pages that have all quietly expired around the same time, every single one of those hits the backend directly to be rebuilt instead of being served instantly from cache, which is exactly the sort of pile up that causes the connection trouble some of you saw.
Both are sorted now, the junk probes get dropped immediately rather than reaching the cache at all, and the refresh runs every five minutes instead of once a day so far fewer pages are ever sat there stale waiting to be hit all at once.
A couple of weeks back I retired a few of the fail2ban jails watching for certain floods, they'd gone quiet for a while and didn't seem to be catching anything worth keeping running. Typical timing, the same threats have started back up again since, so today involved putting a few of those jails back to work and adapting nginx directly to drop that traffic at the door rather than let it through.
Two separate floods were making things worse together. One was random probes hammering files and folders that don't exist on this server, hunting for exposed config and credential files. Every one of those still mints its own short-lived cache entry, so thousands of them in a row just fills the cache up with junk that nobody will ever ask for twice.
The other was the cache's own two hour refresh only running once a day rather than little and often, meaning a big pile of pages would go stale before the next top up. When a flood then lands on a stack of pages that have all quietly expired around the same time, every single one of those hits the backend directly to be rebuilt instead of being served instantly from cache, which is exactly the sort of pile up that causes the connection trouble some of you saw.
Both are sorted now, the junk probes get dropped immediately rather than reaching the cache at all, and the refresh runs every five minutes instead of once a day so far fewer pages are ever sat there stale waiting to be hit all at once.
Re: Server updates
Spent today hunting down a caching gremlin that let a few pages serve stale content well past when they should have refreshed. Turned out a caching header wasn't being handled quite right, which meant duplicate copies of the same page were quietly stacking up under different names, and the system got confused about which one was actually live. All fixed now (hopefully), and while I was in there I also rebuilt the background refresher so it only bothers pages that genuinely need it instead of hammering thousands every few minutes regardless. Should mean snappier pages and one less mystery for me to trip over at 3am.
Re: Server updates
Just found some more issues which I had not taken into account 
The basic floor is that the cache only helps on second hits. In the worst case when the cache is empty, a bot comes along and requests all pages all at once on the server goes down half an hour. Once the cache is built, everything after that is easy to keep up with. But then eventually the cached pages have to expire, in the 100's, and the flood comes back and takes us down again due to all the backend hits.
To prevent that, I rebuild the cache at a controlled rate instead of letting it expire naturally. The challenge is that you can’t refresh a cached page until it actually expires, so all expired pages still need to be rebuilt in one go. Doing that too fast creates an “internal flood” that overloads the server, and doing it too slowly causes timing drift where refreshes fall behind. It's a balancing act cannot be won !
The new system which is WIP currently, will fix this by continuously cycling the cache at a gentle, rate‑limited pace of only a few pages per second,so everything stays fresh without ever overwhelming the backend. It’s basically a way of keeping the cache updated on our own terms rather than letting it explode all at once.
Basically annoying as it looks like will have to pay for another month of AI's subscription to work through all these problems
EDIT:
I had a "bug" with cleantalks extension which was causing huge cache problems as well. I did a "hack" to get around the problem a couple weeks ago as a workaround. I used AI to write a MD file on the problem and sent it to Cleantalk. They got back to me today and fixed the problem ! Not often I give praise to a company, but they deserve it considering I was likely their only customer who will run into that particular problem ! Their support has been pretty good overall, its why I stick with them. I've reported all sorts of weird bugs and even gave my own fixes to problems in the past. So I guess they feel more inclined to take my bug reports seriously
The basic floor is that the cache only helps on second hits. In the worst case when the cache is empty, a bot comes along and requests all pages all at once on the server goes down half an hour. Once the cache is built, everything after that is easy to keep up with. But then eventually the cached pages have to expire, in the 100's, and the flood comes back and takes us down again due to all the backend hits. To prevent that, I rebuild the cache at a controlled rate instead of letting it expire naturally. The challenge is that you can’t refresh a cached page until it actually expires, so all expired pages still need to be rebuilt in one go. Doing that too fast creates an “internal flood” that overloads the server, and doing it too slowly causes timing drift where refreshes fall behind. It's a balancing act cannot be won !
The new system which is WIP currently, will fix this by continuously cycling the cache at a gentle, rate‑limited pace of only a few pages per second,so everything stays fresh without ever overwhelming the backend. It’s basically a way of keeping the cache updated on our own terms rather than letting it explode all at once.
Basically annoying as it looks like will have to pay for another month of AI's subscription to work through all these problems
EDIT:
I had a "bug" with cleantalks extension which was causing huge cache problems as well. I did a "hack" to get around the problem a couple weeks ago as a workaround. I used AI to write a MD file on the problem and sent it to Cleantalk. They got back to me today and fixed the problem ! Not often I give praise to a company, but they deserve it considering I was likely their only customer who will run into that particular problem ! Their support has been pretty good overall, its why I stick with them. I've reported all sorts of weird bugs and even gave my own fixes to problems in the past. So I guess they feel more inclined to take my bug reports seriously
Re: Server updates
Why JavaScript is now required to log in and post
Bit of housekeeping. The forum now needs JavaScript switched on to log in and post properly.
Guests can still browse fine with JavaScript off, but be aware a fair few bits of the site quietly rely on it. The search box is the obvious one, it'll sit in its default spot just under the banner instead of tucking itself neatly up near the board index bar like it normally does. Other features, like image search, need JavaScript and being logged in to work at all.
This is part of tightening up against bots and the growing pile of AI-generated posts turning up on forums everywhere. Real browsers run JavaScript without even thinking about it, bots generally don't bother, so it's a handy way of telling the two apart without making anyone jump through hoops.
If you're one of the rare souls who switches JavaScript off out of principle, first of all, respect, and secondly, sorry, you'll need to turn it back on for the full experience. It won't bite. Probably.
We don't know how many of you are running without it, but unfortunately this is just where forums are in 2026. Any issues logging in or posting, give us a shout.
Bit of housekeeping. The forum now needs JavaScript switched on to log in and post properly.
Guests can still browse fine with JavaScript off, but be aware a fair few bits of the site quietly rely on it. The search box is the obvious one, it'll sit in its default spot just under the banner instead of tucking itself neatly up near the board index bar like it normally does. Other features, like image search, need JavaScript and being logged in to work at all.
This is part of tightening up against bots and the growing pile of AI-generated posts turning up on forums everywhere. Real browsers run JavaScript without even thinking about it, bots generally don't bother, so it's a handy way of telling the two apart without making anyone jump through hoops.
If you're one of the rare souls who switches JavaScript off out of principle, first of all, respect, and secondly, sorry, you'll need to turn it back on for the full experience. It won't bite. Probably.
We don't know how many of you are running without it, but unfortunately this is just where forums are in 2026. Any issues logging in or posting, give us a shout.
Re: Server updates
Small changes when posting
Just a heads up, some of you may notice the odd small change here and there when posting over the coming days. Some things might seem a bit pointless or look slightly odd, but rest assured everything happens for a reason.
It's all part of the ongoing effort to keep bots and AI junk off the forum. I won't be going into detail about how any of it works, for obvious reasons, the less the bots know the better.
For the vast majority of you, you shouldn't notice anything different at all. If something genuinely seems broken though, give me a shout.
Why we ditched the mainstream IP blocklists
For years the go-to advice for server security was "just use a blocklist" - Spamhaus, AbuseIPDB, and the lot. Sounds sensible. In practice it wasn't.
A couple of years back we tested over 200 combined blocklists against real attack traffic hitting this server. At best they caught around half of it, and that figure rapidly fell to only about 3% of active attack traffic. Not exactly confidence inspiring.
The core issue is these lists are reactive by nature. An IP often needs thousands of reports before it builds enough confidence to actually get added, and by that point weeks or months can have passed. You could argue the lists still have value for IPs that aren't hitting you yet but might later, but that's cold comfort when the server's already on its knees from IPs that are attacking right now and simply aren't on any list.
On top of that, some of these lists happily block traffic we'd rather let through, including AI crawlers that do respect robots.txt, like Claude and GPT. Meanwhile the ones that don't obey it, like Meta's, just get blocked outright and carry on regardless from somewhere else anyway.
So for this server, blocklists have gone from "essential first line of defence" to "mostly pointless, occasionally actively unhelpful". Turns out fighting modern botnets with a static list is a bit like trying to catch smoke with a net.
Just a heads up, some of you may notice the odd small change here and there when posting over the coming days. Some things might seem a bit pointless or look slightly odd, but rest assured everything happens for a reason.
It's all part of the ongoing effort to keep bots and AI junk off the forum. I won't be going into detail about how any of it works, for obvious reasons, the less the bots know the better.
For the vast majority of you, you shouldn't notice anything different at all. If something genuinely seems broken though, give me a shout.
Why we ditched the mainstream IP blocklists
For years the go-to advice for server security was "just use a blocklist" - Spamhaus, AbuseIPDB, and the lot. Sounds sensible. In practice it wasn't.
A couple of years back we tested over 200 combined blocklists against real attack traffic hitting this server. At best they caught around half of it, and that figure rapidly fell to only about 3% of active attack traffic. Not exactly confidence inspiring.
The core issue is these lists are reactive by nature. An IP often needs thousands of reports before it builds enough confidence to actually get added, and by that point weeks or months can have passed. You could argue the lists still have value for IPs that aren't hitting you yet but might later, but that's cold comfort when the server's already on its knees from IPs that are attacking right now and simply aren't on any list.
On top of that, some of these lists happily block traffic we'd rather let through, including AI crawlers that do respect robots.txt, like Claude and GPT. Meanwhile the ones that don't obey it, like Meta's, just get blocked outright and carry on regardless from somewhere else anyway.
So for this server, blocklists have gone from "essential first line of defence" to "mostly pointless, occasionally actively unhelpful". Turns out fighting modern botnets with a static list is a bit like trying to catch smoke with a net.
Re: Server updates
Holy crap the spam attacks jumped up significantly lately...
- Capture.PNG (32.7 KiB) Viewed 14 times
Re: Server updates
Bit of housekeeping on the server today. Over the past few months the firewall had built up a "known good" list of addresses that were exempt from automatic blocking. The idea was to stop members getting caught by the anti-bot systems by accident, and it did work as intended. The problem was that nothing ever removed anything from it, so over time it filled up with addresses that were no longer needed, and that is where it started causing more harm than good.
The list had grown to nearly 7,000 entries, and only about 100 of them could be traced back to a current member. Most of the rest were stale addresses belonging to people whose IP had changed months ago, so they were exempting nobody useful. Mixed in with those was a load of VPN and cloud provider ranges that got added whenever someone browsed through one, and that is the part that actually matters, because exempting a VPN exit address exempts everyone else using that same VPN too. Earlier today a WordPress scanner walked straight past every one of the blocking rules for exactly that reason.
So the list has been cleared and replaced with something smarter. Instead of remembering individual addresses, which change constantly, the system now keeps track of which internet providers our members actually use, and treats those networks with extra caution before blocking anything. BT, Virgin, Sky, TalkTalk, Vodafone and the rest are all recognised, along with the European, American and Australian providers our members are on.
What this means for you: almost certainly nothing. If you are on a normal home or mobile connection you should never notice a difference. If you use a VPN there is a slightly higher chance of being caught by the automatic blocking, because the system cannot tell your VPN traffic apart from anyone else using the same VPN. If you do get blocked, switching to a different connection and using the unban request page still works exactly as before, and I will sort it out.
I would rather hear about one person being wrongly blocked than leave a hole open that lets scanners hammer the site unchecked. If anything looks off, let me know.
The list had grown to nearly 7,000 entries, and only about 100 of them could be traced back to a current member. Most of the rest were stale addresses belonging to people whose IP had changed months ago, so they were exempting nobody useful. Mixed in with those was a load of VPN and cloud provider ranges that got added whenever someone browsed through one, and that is the part that actually matters, because exempting a VPN exit address exempts everyone else using that same VPN too. Earlier today a WordPress scanner walked straight past every one of the blocking rules for exactly that reason.
So the list has been cleared and replaced with something smarter. Instead of remembering individual addresses, which change constantly, the system now keeps track of which internet providers our members actually use, and treats those networks with extra caution before blocking anything. BT, Virgin, Sky, TalkTalk, Vodafone and the rest are all recognised, along with the European, American and Australian providers our members are on.
What this means for you: almost certainly nothing. If you are on a normal home or mobile connection you should never notice a difference. If you use a VPN there is a slightly higher chance of being caught by the automatic blocking, because the system cannot tell your VPN traffic apart from anyone else using the same VPN. If you do get blocked, switching to a different connection and using the unban request page still works exactly as before, and I will sort it out.
I would rather hear about one person being wrongly blocked than leave a hole open that lets scanners hammer the site unchecked. If anything looks off, let me know.