Question Google Cloud Abuse from their entire IP space and Fail2ban Unable block it

[nisamudeen97]

Server operating system version

Ubuntu 22

Plesk version and microupdate number

Plesk Obsidian 18.0.72 Update #3

For the past few days we are experiencing ddos like activity from Google Cloud (34.174.x.x) , (34.128.0.0/10). We've reported 100s of IPs to them, but no action. This is across thousands of sites we host in different plesk servers. Anyone else seeing this same behavior?
They are visitting different pages on the websites and those and successful visits with 200 code. It look like some kind of scrapping, I have already added the entire IP class to fail2ban blacklist, however I could still see access from those Ip addresses.

Is there any effective solution for this. Kindly note that all our websites are behind Cloud Flare proxy.

 

[Raul A.]

We also observed high traffic volumes from that huge subnet. The simplest approach is to block it since you don't expect traffic from a different hosting company.

In your case, firewall blocking won't help since your firewall will see only Cloudflare IP addresses. You can block in nginx but it has to be in each server block. You can include a conf file in Additional Nginx directives or write an extension that adds the desired Nginx rules or include statement.

Another approach is to deploy Anubis/BotStopper which will present all visitors with a generic User-Agent with a verification page. Once the verification is passed, future requests presenting a specific cookie will bypass the verification page.

 

[pleskpanel]

There threads about this here and there such this one but thus far as Google hasn't taken action, we've just blocked the entire 34.174.0.0/16 for now as the attacks were become relentless. If you're using CloudFlare, then you can do this via a rule in CloudFlare versus trying to block it in Nginx.

 

[nisamudeen97]

On June 25 2026 one of our magento production website was found having heavy load and website stopped working. I have checked the case and I could see it was heavy traffic to website and load has induced. Website is already behiend cloudflare proxy and we already have rate limitations via nginx for bots. When the issue happened, I initially enabled Nginx rate limiting and created a new Fail2Ban jail to automatically block abusive IPs. While monitoring the logs, I noticed the server was still under heavy load and PHP-FPM was repeatedly hitting its limits, eventually causing the website to return server errors.


After investigating further, it became clear that this wasn't a typical attack from a handful of IPs. It was a distributed scraping campaign where each IP was making only one or two requests, making traditional Nginx rate limiting and Fail2Ban largely ineffective since neither IP exceeded the configured thresholds.


Most of the requests were targeting Magento category and product pages with various filter combinations in the query string. These requests appeared to bypass Varnish caching, resulting in PHP generating the pages repeatedly, which explains why PHP-FPM became overloaded.


While analyzing the access logs more closely, I noticed another interesting pattern. A large number of these requests were using randomly generated, but consistently old, Windows and Chrome user agents. Based on that observation, I created a Cloudflare WAF custom rule to apply a Managed Challenge to requests matching those characteristics. Within just a few minutes, the rule had already triggered around 1,360 challenges, confirming that a significant amount of the traffic matched the pattern.


Since enabling the WAF rule, the server load has returned to normal, PHP-FPM is no longer being overwhelmed, and both the website and internal links are functioning normally again.


I'm still interested in understanding the root cause, though. Has anyone else encountered this type of distributed scraping against Magento, where thousands of IPs each make only a couple of requests specifically to filtered category/product pages? If so, how did you handle it without affecting legitimate users? I'm particularly interested in improving cache efficiency or identifying better ways to stop this type of traffic before it reaches the origin server. After the raise of AI, I am experiencing these kind of issues with random servers.