Just "thinking out loud", per se.

Do the bot attacks fit into any "schedule"?
ie, if 80% of them (just to make up a number) all occur between the hours of X and Y, can Cloudflare be turned on only for those hours?
Then the "older browser" folks would just know to only use MSFN outside of those hours.

And again, just "thinking out loud", but do these bots GIVE UP and GO AWAY if we run Cloudflare for ONE MONTH?

Then return to without Cloudflare until they come back and do that again to get them to GIVE UP?

I additionally checked all MSFN accounts. At the moment, there are round about 4800 accounts with zero posts and no real activity. If I were the admin, I would delete them all. And 22 hours ago, a new account has been registered. I'm pretty sure it's also a bot account. Up until now, new ones have been created every 24 hours. So if another account is set up in a few hours’ time with no genuine activity, it is almost certainly another one. Such bot accounts are created as ‘sleeper’ accounts as a precaution for dubious activities later on.

And 22 hours ago, a new account has been registered. I'm pretty sure it's also a bot account.

Not bot.
Triple-checked and manually approved.

Ok. I am going to delete all members with 0 posts. I was planning on cleaning up the database anyway.

32 minutes ago, AstroSkipper said:

Here is a short catalogue of measures to tackle bot attacks, generated by AI:

Effective Anti-Bot Measures for Invision Community (IPS)

To effectively mitigate automated bot registrations and HTTP flooding without relying on aggressive Cloudflare JavaScript challenges (which disrupt older browsers and legitimate user sessions), the following server- and application-level strategies are recommended:

• 1. Custom Q&A Registration Verification Standard reCAPTCHA v2/v3 is routinely solved by modern bot frameworks. Replacing or supplementing it with custom, forum-specific logic questions (e.g., "Which Windows version was released after Windows 2000?" -> "Windows XP") stops automated registration scripts dead in their tracks.

• 2. Integration with StopForumSpam & Project Honey Pot APIs Enabling real-time API checks during registration cross-references incoming IPs, email addresses, and usernames against global spam databases. This silent check drops over 90% of known bot accounts before the registration form is even submitted.

• 3. Disposable Email Address Blocking Implement a dynamic domain blocklist for temporary/disposable email providers. Spambots rely heavily on these services to complete automated email verification loops.

• 4. Nginx / Apache Webserver Rate Limiting (limit_req) Configure rate limiting on critical endpoints such as /register/, /login/, and /search/. If an IP exceeds a reasonable threshold (e.g., more than 2–3 registration attempts per minute), the webserver returns an immediate HTTP 429 (Too Many Requests), preventing PHP and MySQL from being overwhelmed.

• 5. Fail2ban IP-Jailing at the Firewall Level Deploying Fail2ban to parse access logs allows the server to automatically block IPs via iptables if they attempt rapid-fire POST requests to sensitive endpoints.

• 6. Targeted Cloudflare Firewall Rules (WAF) instead of Global Rules If Cloudflare is utilized, avoid global "Under Attack" mode. Instead, set targeted Web Application Firewall (WAF) rules that specifically challenge or block traffic originating from known datacenter ASNs (AWS, DigitalOcean, Hetzner, etc.) or restrict access solely to the /register/ URI, leaving general browsing unaffected.

• 7. New Member Moderation Queue Require manual moderator approval for the first 1–2 posts of newly created accounts. Removing the immediate visibility of spam posts eliminates the incentive for spammers to target the platform.

All of that has already been implemented on the server and within Invision—except for Cloudflare. I don't mean to be rude, but what do you think I've been doing for the past 25 years? I was out of the game for 2 years and some things have changed quite a bit. But as always, I'll sort it out.

For now, I have blocked them using Nginx deny rules. It's temporary until the Vultr IP addresses clear up. Cloudflare uses Vultr.

2 minutes ago, xper said:

All of that has already been implemented on the server and within Invision—except for Cloudflare. I don't mean to be rude, but what do you think I've been doing for the past 25 years? I was out of the game for 2 years and some things have changed quite a bit. But as always, I'll sort it out.

For now, I have blocked them using Nginx deny rules. It's temporary until the Vultr IP addresses clear up. Cloudflare uses Vultr.

Ok. It was just meant as alternative options to get rid of or curb bot attacks. No more, no less. If you already performed such measures, then it is of course fine and purposeful. 👍

57 minutes ago, xper said:

Bot attack. There is no way to stop it without Cloudflare, but CF is out of the question, right? So be it.

My stance on CloudFlare has been made known, i.e. it creates several serious issues client-side/user-side for legitimate members not having the most-up-to-date Chromium/(mainline) Firefox code snapshot, NOT using the latest version of Win11, not having a recent, powerful, multi-core CPU to solve challenges or coming from "smaller" countries (like Greece) with IP pools having lower scores by the web powers that be 😠 ...

I also understand it's the ultimate counter-measure when the "bots hit the fan" 😜 , so a server owner might really need to deploy it at such occasions...

18 minutes ago, xper said:

Ok. I am going to delete all members with 0 posts. I was planning on cleaning up the database anyway.

Probably a wise thing to do, too; I'd suggest, if I might, that a disclaimer be posted in the registration page/form, that "0 post accounts" would be routinely purged for security and database performance reasons, so real humans intending to register know beforehand what to expect 😄 ...

All in all, during the last two hours or so, things look to have settled down without CloudFlare ON ; the board is responsive, functional in somewhat older browsers too (fx-115esr-based), sign-in works, "502 BR" very rare now; not to jinx it, of course 😜 ...

Edited 18 hours ago18 hr by VistaLover

Zero-post accounts might have been created by guests just to download post attachments or view profiles. No real content lost; easy to recreate if they return.

Currently working okay in Chrome 103 and Chrome Beta 138. No 502's here in Western US.

Zero-post accounts might have been created by guests just to download post attachments or view profiles. No real content lost; easy to recreate if they return.

You are absolutely right.

We used to get hit with a sh#t-ton of INTUIT (Turbotax, Quicken) spam.
Like a HUNDRED all in a matter of MINUTES.

Did these spam-poster accounts get deleted when the posts were deleted?
Or are they still counted as "members" that won't be deleted because they don't have a zero-count?

And the same question applies to spam-posters that successfully posted one or two posts.
Were they deleted at the time of the spam-post offense?
'cause if not, this zero-count cleanup won't catch them.

The posts have been deleted, but the banned users have not. Deleting them would allow them to register again with the same email address.

24 minutes ago, xper said:

The posts have been deleted, but the banned users have not. Deleting them would allow them to register again with the same email address.

Excellent. That makes sense.
The email address these use is not used over and over again, but there is only so much we can do / safeguard against.

18 hours ago, VistaLover said:

"502 BR" very rare now; not to jinx it, of course 😜 ...

... I'm again very sorry to report that the 502s have come back with a vengeance 😭 for me; this again started since ca. 02:30 EEST (20260901 23:30 UTC) today, my timezone; my Greek ISP is now in the 46.12.11.xxx range, but I can't connect in a variety of browsers (R3dfox-several versions, Supermium-Chromium based, New Moon 28); I've disabled everything Cloudflare-related on my side (DNS servers, r3dfox DoH feature), but I still can't connect; the tricks I used yesterday evening don't work now (clearing MSFN cookies, clearing browser cache, restarting browser, reloading MSFN tab repeatedly); I'm now connected via the Austrian Singapore node of a browser proxy extension, and even that didn't work from the first attempt 😞 ; the error is always a 502 Bad Request on the site's server (openresty - Powered by APISIX.). We were told that this issue is CF-related and that it will remedy itself as the hours go by; I had my chances high yesterday evening, but now gloom again...

I trust xper has done everything on their side, but so have I; I've even contacted my own ISP for this problem, and they responded they're unable to do something more on their end; their IP pools for web connections from (Northern) Greece are specific, those I communicated to xper on an earlier exchange (which they had whitelisted in their server); this has started getting on to my nerves at this point, because it's adding to extremely serious and unpleasant real life issues, that are to stay for at least the next couple of months (not health related, thankfully, but who knows?) ...

Accessing the board via someone else's machine (the people running the proxy server(s)) isn't a viable solution in the long run, and I don't have to list the reasons for that 😉 ...

Thanks and regards.

Edited 3 hours ago3 hr by VistaLover
change of proxy node