Crazy amount of guests

I managed to retrieve my full September access log, which gives me a much clearer picture of what happened before and after the crawler activity started.

I had AI analyse the complete log and break the traffic down by day, including the suspicious Chrome/macOS User-Agent I mentioned earlier.

The result is quite revealing:

Code:
Date       Total requests    Suspicious UA    Percentage
---------------------------------------------------------
Sep 1           8,632              113            1.3%
Sep 2           5,398               99            1.8%
Sep 3           6,928              147            2.1%

Sep 4          44,413           34,678           78.1%
Sep 5          65,536           48,666           74.3%
Sep 6          53,266           34,102           64.0%
Sep 7          50,972           43,724           85.8%

Sep 8*         27,121           24,387           89.9%
Sep 9**           877              111           12.7%

* September 8th was the day I progressively introduced the Cloudflare protections, so it isn't a clean before/after day.

** September 9th is only a partial day, approximately 00:02–07:26.



The change appears to have started very clearly on September 4th.

Before that, the forum was averaging approximately:

Code:
6,986 origin requests/day

Then suddenly:

Code:
Sep 3  →   6,928
Sep 4  →  44,413
Sep 5  →  65,536
Sep 6  →  53,266
Sep 7  →  50,972

What I find particularly interesting is what happens when the suspicious User-Agent is removed from the figures.

For September 4th:

Code:
44,413 total requests
-34,678 suspicious requests
------------------------------
 9,735 other requests

And for September 7th:

Code:
50,972 total requests
-43,724 suspicious requests
------------------------------
 7,248 other requests

That puts the remaining traffic almost exactly back into the normal range seen before September 4th.

So this gives me much more confidence that the huge increase wasn't simply legitimate visitors or normal search engine activity.


The number of IP addresses involved is also quite remarkable.

On September 7th:

Code:
43,724 suspicious requests
17,160 different IP addresses

And on September 5th:

Code:
48,666 suspicious requests
19,505 different IP addresses

So trying to deal with this by blocking individual IP addresses would have been almost pointless.


September 9th is where things become particularly interesting.

Between approximately 00:02 and 07:26, the origin log contains only:

Code:
877 total requests

The suspicious Chrome/macOS crawler was still present:

Code:
111 suspicious requests
111 different IP addresses
111 HTTP 403 responses

So every request carrying that particular signature during this period was rejected.

The crawler hasn't necessarily gone away. It is still trying, but those attempts are no longer successfully crawling the site in the same way.


There was another interesting surprise in the remaining traffic: Bingbot.

Of those 877 origin requests:

Code:
680  identifying as Bingbot       77.5%
111  suspicious Chrome/macOS      12.7%
 86  everything else               9.8%
---------------------------------------
877  total

The Bingbot traffic came from 89 different IP addresses.

Some of the most active addresses were in ranges such as:

Code:
40.77.167.x
52.167.144.x

These are consistent with Microsoft/Bing crawler infrastructure, so this appears to be genuine Bing crawling rather than simply another bot using a fake Bingbot User-Agent.

I haven't individually reverse-DNS/forward-DNS verified every one of the 89 addresses, so I'm not claiming absolute verification of every request, but the IP distribution is consistent with legitimate Bingbot traffic.

This changes the interpretation of the 877 requests quite significantly.

More than three quarters of the origin traffic this morning appears to be Bing crawling the forum, while the crawler that caused the original problem accounted for another 12.7% and all of those requests were rejected.

That leaves only:

Code:
86 other requests in approximately 7 hours 24 minutes

outside those two easily identifiable groups.


So the overall timeline now looks like this:

Code:
Sep 1 ──  8.6k ┐
Sep 2 ──  5.4k ├── Normal traffic
Sep 3 ──  6.9k ┘

Sep 4 ── 44.4k ┐
Sep 5 ── 65.5k │
Sep 6 ── 53.3k ├── Major crawler wave
Sep 7 ── 51.0k │
                 │
Sep 8 ── 27.1k ┘  Protections progressively introduced

Sep 9 ── 877 requests (00:02–07:26)
          |
          +-- 680 Bingbot
          +-- 111 suspicious Chrome/macOS -> all HTTP 403
          +--  86 other requests

This also gives me something I didn't have before: a real baseline.

Before the crawler wave started, my forum was receiving roughly 5,000–9,000 origin requests per day.

The really striking part is that if I remove the suspicious crawler traffic from September 4th and September 7th, the numbers fall almost exactly back into that range.

I'll now leave the configuration unchanged and collect a complete 24-hour log for September 9th.

That should give me a much cleaner before/after comparison, but the first few hours are already looking very different from September 4th–8th.
 
Admin panel -> Users -> Banned IP addresses
Sure, but this is not a good option when dealing with distributed bot attacks: You can ban single IP addresses there as well as networks, but no ASNs or countries. So it does not scale very well and using this option would force you into game of "whack a mole". It was useful at times when unwanted traffic came from a certain fixed IP or a certain network - but those times are long gone and so this option is not fit for purpose for today's challenges.
 
@smallwheels could you explain to me how IP threat monitor works please, because I was concerned at doing anything that might increase requests to the server, at a time it was getting overloaded by the bot requests.

Did you read the add on description and the FAQ?


Those describe pretty exactly what it does and how. It was initially intended as a rate limiter against scraping with automated temporary blocking but can do much more: You can manually block IPs, ASNs and countries, auto-blacklist IPs that are considered malicious by proxycheck.io and you can also whitelist. So basically it is a kind of WAF.
It can let bypass logged in users (even if they come from a blocked network or country) and it can block or let pass VPN connections (configurable per VPN provider). It can let pass search engines and verifies the request is authentic via reverse DNS.
Overall, it is a very solid and easy to use tool. You probably will have to upgrade to a paid proxycheck account as the free 1000 requests per day do run out quickly, but this is not expensive. You can save a bit when using a free maxmind account for country identification.

Obviously, from an architectural and performance perspective, having the WAF as part of the application is not optimal and also your db will grow somewhat (depending from your log settings). But if you are on shared hosting your options are typically limited (as you yourself realized) and IP Threat monitor really comes to the rescue here.
 
Thank you. It sounds like a good addon - I'm still a bit concerned about the database aspect and extra load on the server as the bots are already causing a load on the database and server - and think I'll try the .htaccess option suggested by @badabugs1 earlier, with the cloudflare secret key. Not straight away as I'm still assessing the ones being blocked. It's down to about 3500 at night and 1500 during the day. Which is better than 5000. I think it's clear as well that a lot of them aren't deterred at all by managed or interactive challenges - they are too sophisticated. And rate limiting whats-new hasn't deterred them either.
 
I'm still a bit concerned about the database aspect and extra load on the server as the bots are already causing a load on the database and server
The load isn't an issue. Obviously it is higher than if you would do the filtering on a different host or a dedicated firewall (as then the load would be there) but it is not an issue and it is - also obviously - dramatically lower than your actual situation. The FAQ of the add on says:

Does the addon affect performance?
No, quite the opposite! The cache system improves performance by up to 80%. It reduces database load by 98%.

Database growth depends from how you set the logging. Obviously, if you keep the logs forever the db grows more than if you cut the logs regularly. It is all up to you.

- and think I'll try the .htaccess option suggested by @badabugs1 earlier, with the cloudflare secret key. Not straight away as I'm still assessing the ones being blocked. It's down to about 3500 at night and 1500 during the day. Which is better than 5000. I think it's clear as well that a lot of them aren't deterred at all by managed or interactive challenges - they are too sophisticated. And rate limiting whats-new hasn't deterred them either.
If you - as you said - cannot make sure that only connections via CF reach your forum this is a useless game and waste of effort. Obviously the choice is up to you, but optimizing a known non working solution intstead to choose a working one makes no sense at all.
 
If you - as you said - cannot make sure that only connections via CF reach your forum this is a useless game and waste of effort. Obviously the choice is up to you, but optimizing a known non working solution intstead to choose a working one makes no sense at all.
What that does is put a cloudflare secret header word onto every IP that hits the server via Cloudflare. As such it doesn't inject the secret header word into those that hit the server who have bypassed Cloudflare. The .htaccess code then blocks all those that don't have the Cloudflare secret header. So it's another way of only allowing Cloudflare IP's to access the forum. Although the server removes the cloudflare IP's to reveal the actual IP's the secret header word still remains.

What it should show is - if many of them are STILL in the guest list then they actually are going through Cloudflare but are just completing the challenges and captchas and evading blocks by re-routing. If some are in fact just hitting the origin IP and bypassing cloudflare they will be blocked at server level, before they even reach the forum and reduce the load on php and the database.
 
Last edited:
Thank you. It sounds like a good addon - I'm still a bit concerned about the database aspect and extra load on the server as the bots are already causing a load on the database and server - and think I'll try the .htaccess option suggested by @badabugs1 earlier, with the cloudflare secret key. Not straight away as I'm still assessing the ones being blocked. It's down to about 3500 at night and 1500 during the day. Which is better than 5000. I think it's clear as well that a lot of them aren't deterred at all by managed or interactive challenges - they are too sophisticated. And rate limiting whats-new hasn't deterred them either.
I think at this point it would be really important to analyse your raw server access logs before adding too many more rules.

With 1,500 to 3,500 guests still showing, you really need to identify exactly where that traffic is coming from and whether you're dealing with one dominant crawler pattern or several different ones.

That was the turning point for me. Looking at the complete logs made it possible to correlate User-Agents, IP addresses, ASNs, requested URLs, response codes and activity over time. In my case, one particular pattern accounted for the vast majority of the abnormal traffic, which wasn't obvious just from looking at the XenForo online list or Cloudflare statistics.

It would also be particularly interesting in your case because you say that Managed and Interactive Challenges don't seem to deter many of them. The logs should help establish whether those requests are actually reaching the origin, what they are requesting once they get there, and whether the thousands of "guests" are really part of the same crawling operation.

Otherwise there is a risk of blocking/challenging individual paths, ASNs or User-Agents without actually targeting the main source of the problem.

If you can get the original compressed .gz access log from your server, I'd be happy to run the same analysis on it that I did on mine. Ideally a complete 24-hour log from the current situation would be best.
 
I think at this point it would be really important to analyse your raw server access logs before adding too many more rules.

With 1,500 to 3,500 guests still showing, you really need to identify exactly where that traffic is coming from and whether you're dealing with one dominant crawler pattern or several different ones.

That was the turning point for me. Looking at the complete logs made it possible to correlate User-Agents, IP addresses, ASNs, requested URLs, response codes and activity over time. In my case, one particular pattern accounted for the vast majority of the abnormal traffic, which wasn't obvious just from looking at the XenForo online list or Cloudflare statistics.

It would also be particularly interesting in your case because you say that Managed and Interactive Challenges don't seem to deter many of them. The logs should help establish whether those requests are actually reaching the origin, what they are requesting once they get there, and whether the thousands of "guests" are really part of the same crawling operation.

Otherwise there is a risk of blocking/challenging individual paths, ASNs or User-Agents without actually targeting the main source of the problem.

If you can get the original compressed .gz access log from your server, I'd be happy to run the same analysis on it that I did on mine. Ideally a complete 24-hour log from the current situation would be best.
Thanks, yes I can download a 24 hour log - I'll try running it through Claude first :-) It kind of had been narrowed down to one or two bad actors. One was Alibaba but the bigger one seemed to be Chinanet. How to tackle something like Chinanet with 100 million IP's I'm not sure. I just blocked all their ASN's which didn't work.
 
Thanks, yes I can download a 24 hour log - I'll try running it through Claude first :-) It kind of had been narrowed down to one or two bad actors. One was Alibaba but the bigger one seemed to be Chinanet. How to tackle something like Chinanet with 100 million IP's I'm not sure. I just blocked all their ASN's which didn't work.
Yes, that's exactly why I think analysing the complete .gz log could be useful.

In my case, looking at the ASN initially pointed towards Alibaba, but the really useful discovery came from correlating the complete log rather than concentrating on the IP addresses alone.

The same suspicious User-Agent was appearing across thousands of different IP addresses. Once that pattern was isolated, it became much easier to understand what was actually generating most of the abnormal traffic.

So with ChinaNet, rather than trying to deal with potentially millions of IP addresses or blocking huge networks, I'd be curious to see whether the requests actually share something else in common: User-Agent, URLs being requested, request frequency, response codes, timing, etc.

Claude may well spot it from the .gz file. If you want a second analysis afterwards, feel free to send me the same file and I'll run it through the analysis I used on mine. It could also be interesting to compare what the two analyses find. :-)
 
Main issue is I'm trying to work out how to upgload a .gz file to Claude! Last time I could only paste a chunk of entries.
 
Last edited:
Edit - sorted - I had to upload the zipped file - the unzipped one was too big to upload. It covers the last 9 days.
 
Claude is getting quite excited :ROFLMAO:

"The top six user-agents alone account for roughly 8.5 million of your 9.5 million total requests (about 90% of ALL your site's traffic over 9 days), and they're suspiciously uniform in volume (all between 1.37M–1.48M each)

That's the scale of it right there: 129,786 unique IP addresses, all using that exact same single user-agent string, over just 9 days. That's not a botnet of a few servers — that's a massive, distributed proxy/botnet operation.

That number is staggering: 619,119 unique IP addresses, generating 8.53 million requests over 9 days, all using just those 6 disguised browser signatures. This is an enormous, professionally-run distributed scraping operation — not a handful of servers, a genuine botnet-scale or residential-proxy-network operation."

"China is only 21% of this swarm. The rest is spread across the entire world: US (16.8%), Brazil (8.7%), India (6.8%), UK (3.6%), Pakistan, Philippines, Bangladesh, Saudi Arabia, Turkey, Iraq, Indonesia, Argentina, Malaysia, Colombia, Canada, Kazakhstan, Vietnam, Thailand, Chile — over 100 countries represented in total.


What this means: this isn't primarily a "Chinese bot problem" at all — it's a massive, globally-distributed residential proxy or botnet network, using 619,000+ unique IP addresses from ordinary residential/mobile ISPs worldwide (not datacenters), all rotating through the same 6 disguised browser signatures. Each IP is only used briefly (roughly 14 requests per IP on average across 9 days) before being dropped and replaced — classic behavior of a residential proxy service or malware-infected-device botnet, the kind used by professional scraping operations specifically to evade exactly the kind of country/ASN blocking you've been doing."
 
Last edited:
Wow. :ROFLMAO:

That is on a completely different scale to what I found on my forum.

The really interesting part to me isn't even the 9.5 million requests, but the combination of:

  • 8.53 million requests from only six User-Agent signatures
  • roughly 90% of all traffic
  • 619,119 unique IP addresses
  • very similar request volumes for each of the six User-Agents

That last point in particular makes me wonder whether the six browser signatures are being deliberately rotated by the same scraping infrastructure.

I would be slightly cautious about Claude's conclusion that this proves a genuine botnet, though. The logs can clearly show that it is massively distributed, but I don't think the IP count alone can tell us whether those are compromised machines, residential/mobile proxies, commercial proxy networks, or some combination of them.

I'd be really interested in the next level of the analysis now.

Could you ask Claude to break those six User-Agents down by ASN, country, requested path and HTTP status, and also check whether their behaviour and timing correlate with each other?

In particular, I'd be interested to know whether ChinaNet is genuinely responsible for most of those 8.53 million requests, or whether ChinaNet is simply the most visible part of a much wider distributed network.
 
Wow. :ROFLMAO:

That is on a completely different scale to what I found on my forum.

The really interesting part to me isn't even the 9.5 million requests, but the combination of:

  • 8.53 million requests from only six User-Agent signatures
  • roughly 90% of all traffic
  • 619,119 unique IP addresses
  • very similar request volumes for each of the six User-Agents

That last point in particular makes me wonder whether the six browser signatures are being deliberately rotated by the same scraping infrastructure.

I would be slightly cautious about Claude's conclusion that this proves a genuine botnet, though. The logs can clearly show that it is massively distributed, but I don't think the IP count alone can tell us whether those are compromised machines, residential/mobile proxies, commercial proxy networks, or some combination of them.

I'd be really interested in the next level of the analysis now.

Could you ask Claude to break those six User-Agents down by ASN, country, requested path and HTTP status, and also check whether their behaviour and timing correlate with each other?

In particular, I'd be interested to know whether ChinaNet is genuinely responsible for most of those 8.53 million requests, or whether ChinaNet is simply the most visible part of a much wider distributed network.
I updated the post a bit more above ...... haven't finished reading the rest of the analysis yet :-)
 
I think you're actually getting very close to identifying the culprit now — not who is operating it, obviously, but the traffic responsible for the problem.

If those six User-Agents account for around 90% of all requests and show the same kind of behaviour across 600,000+ rotating IP addresses, I think I'd stop concentrating on individual IPs, countries and ASNs at this point.

If it were my forum, my next steps would probably be:

  1. Close direct access to the origin using the Cloudflare secret-header + .htaccess method we discussed earlier. That makes sure the bots can't simply bypass Cloudflare.
  2. Ask Claude to compare the six User-Agents by requested paths, hourly activity, HTTP status codes and navigation patterns. If all six behave similarly, that would be very strong evidence that they're different disguises used by the same scraping system.
  3. Create a Cloudflare Managed Challenge for those six signatures, initially rather than blocking them outright. They could all potentially be included in a single rule.
  4. Watch the Challenge Solve Rate and the origin access logs. If huge numbers are being challenged and virtually none successfully pass, that would give much more confidence that legitimate visitors aren't being caught.
  5. Protect the expensive XenForo endpoints separately if the logs show they're being heavily targeted — particularly things such as /search/ and /whats-new/ — rather than putting aggressive protection on normal /threads/ pages.
  6. Then compare a fresh 24-hour origin log with the current one to see how much traffic is actually still reaching XenForo/PHP/MySQL.

The interesting thing is that although you apparently have 619,000 IP addresses to deal with, you may not really have a 619,000-IP problem.

You may have a six-signature problem. :-)

And if those six signatures turn out to have the same behaviour, it might even effectively be one scraping operation rotating both IP addresses and browser identities.

I wouldn't delete all your existing ASN rules immediately, but I certainly wouldn't spend much more time chasing individual networks until you've tested this approach.
 
Claude

"Why this is such a resilient, hard-to-block operation — you cannot country-block or ASN-block your way out of 100+ countries' worth of residential IPs."

"
Here's the complete breakdown, per user-agent, covering country, path, and status code as requested. (I'll explain the ASN gap below — it needs a different tool than what's built into my analysis here.)

User-Agent​
Total Requests​
Unique IPs​
Top Countries​
Top Paths​
Top Status Codes​
Mac/Chrome1481,479,799129,786CN 21.2%, US 16.4%, BR 7.5%, IN 6.5%/index.php & /whats-new/posts/N/ (~723K each), /css.php, /job.php200 (75%), 303 (24%)
Mac/Chrome1501,454,009142,199US 19.6%, CN 18.8%, BR 8.1%, IN 6.2%same pattern200 (75%), 303 (24%)
Win/Chrome1481,445,799125,527CN 21.6%, US 16.1%, BR 7.5%, IN 6.5%same pattern200 (75%), 303 (24%)
Mac/Chrome1491,391,620121,574CN 21.5%, US 16.3%, BR 7.5%, IN 6.5%same pattern200 (75%), 303 (24%)
Win/Chrome1501,388,263121,451CN 21.9%, US 16.2%, BR 7.5%, IN 6.4%same pattern200 (75%), 303 (24%)
Win/Chrome1491,371,370119,599CN 21.5%, US 16.2%, BR 7.5%, IN 6.5%same pattern200 (75%), 303 (24%)
The remarkable thing here — every single one of these six supposedly-independent UAs shows almost identical country percentages (China always ~21%, US always ~16%, Brazil always ~7.5%, India always ~6.5%, Singapore, UK, Pakistan, Bangladesh all consistently in the same order). Real, organic traffic from unrelated populations would never split this evenly and consistently — this is further proof of one centrally-managed pool of proxy IPs being randomly assigned a UA string per request, not six independent operations.

On ASN specifically: the free offline database I used only provides country-level data, not ASN/organization names — that would need a paid lookup service or a different database to do properly across 619,000 IPs (individually querying each one isn't practical). What I can tell you is that the country distribution being so evenly spread across 100+ nations, combined with the extreme per-IP-brevity (~14 requests per IP before rotating away), is itself the signature of a commercial residential-proxy-network product — the kind of service explicitly sold to scrapers precisely to evade country/ASN blocking."
 
  1. Ask Claude to compare the six User-Agents by requested paths, hourly activity, HTTP status codes and navigation patterns. If all six behave similarly, that would be very strong evidence that they're different disguises used by the same scraping system.
  2. Create a Cloudflare Managed Challenge for those six signatures, initially rather than blocking them outright. They could all potentially be included in a single rule.
I put that to Claude:

The distribution of requests-per-IP within just this one UA (Mac/Chrome148) is very telling:

  • 86% of all 129,786 IPs made only 2–5 requests total, ever (across the whole 9-day period)
  • Median: just 4 requests per IP
  • A small tail (about 9,500 IPs) made 21+ requests, with one extreme outlier hitting 2,391 requests from a single IP
Why this matters: a genuine human visitor browsing an active hamster forum would typically generate far more than 2–5 requests per visit — loading a thread pulls in the page itself, images, CSS, JS, maybe several thread pages if they're engaged. A cluster this concentrated at "2–5 requests then gone forever" is a classic signature of short-lived proxy rotation — each IP used just long enough for one scrape pass (hit the target page, load the service_worker check, then discarded).

The important caveat for your suggestion: these 6 UA strings themselves are just completely standard, ubiquitous Chrome-on-Windows/Mac signatures — genuinely ordinary browsers that plenty of your real forum members almost certainly use too. So a Cloudflare rule that challenges purely "does the UA match one of these 6 exact strings" risks challenging a meaningful chunk of your genuine readers as well, since Chrome 148/149/150 on Windows/Mac are some of the most common browser configurations on the entire internet right now — not a rare or unusual fingerprint on their own.

What actually distinguishes the bots isn't the UA alone — it's the UA combined with the narrow, short-burst request pattern. So the more precise, safer version would be a compound rule:

Challenge if: (User-Agent matches one of the 6 strings) AND (URI path matches /whats-new/* or /index.php?sw/*)

This narrows the net to exactly the pages being hammered, rather than challenging someone innocently reading a completely different thread who happens to use Chrome 149. Cloudflare's custom rules support combining conditions with AND like this in a single rule."

However I still think that could challenge a lot of regular guests.

Plus sorting the origin IP .htaccess might solve a lot of it maybe.
 
/whats-new/posts/N/ (~723K each)
If you have ~4.200.000 requests by bots to "what's new" and still do not adjust permissions for guests for this page despite being told countless times you deliberately want to suffer. This along with a working country block for CN, IN, BR and a bunch of other countries and an ASN block for the usual suspects would lower your issue dramatically and some fine adjustment with countries and ASNs would probably solve it. Your choice.

What timeframe do those logs cover?
 
Back
Top Bottom