Going to give this a try here. I have had flooding issues on my cloud server so many times now that my provider is going to terminate me if this doesn’t get fixed. This has happened at least 10 times in 3 months and it is SO FRUSTRATING. I am panicking because my host will terminate me if this does not get fixed already. Here I will attach a log for the latest issue:
Could you go back to your original post, edit it and mark the log section as code? Just highlight the log part and click on the </> icon. This will make it easier to read.
First, apply a “I’m Under Attack” setting to the whole site.
Then you should try to find patterns and block visitors accordingly. Try to figure if there’s a country or a few countries where the hits are originating from. Create a Firewall Rule to block Challenge (Captcha) visitors from those countries. Or you may prefer to Challenge all visitors NOT coming from the countries most of your legit visitors come from.
Then try identifying User Agents and IPs that are being used. Firewall > Tools > IP Access Rules / User Agent Block.
I hope these actions help you mitigate this attack. Good luck!
I’m so scared to request reactivation now because they will terminate 10 years of work. I just asked them to provide me with a new server IP… I hope they agree to. And I had my web site all set up on the attack part and all these features, somehow it keeps flooding anyway and I cannot fix this on my own.
You should try to keep calm, avoid giving in to panic.
If you provide more details on your setup, other people in this community with similar config can perhaps help you with tips from their past experience or expertise.
Is your site running in Apache? Nginx?
What’s the CMS?
What rules do you have in place already, both in Cloudflare and on your origin server? Though you said you’ve tried “all these features”, perhaps if you provide some details others may help you fine tune your rules to more effective results.
It would be good if you posted the actual Firewall Rule. Challenge Captcha is better then JS Challenge here, and you may even elevate it to Block until the attack is controlled.
Add more to the list as you identify more IPs. Don’t worry about the list getting big, the performance impact should be negligible.
Ideally, you should get help from your host to only allow connections from Cloudflare servers. You can try adding something like this to your htaccess, to check for a CF header before allowing anyone in.
Also, make sure the WordPress block on .htaccess is at the bottom of the .htaccess file.
That means they are being blocked by Cloudflare before they reach your origin server. It also means these hits are not bypassing Cloudflare as you feared.
So with the proper set of rules in place you should be able to ask your hosting to reactivate your site. If you are afraid this may cause them to permanently close your account, you should try talking to them to reestablish your site for, say, half an hour, then check the logs and see if the attack was in fact completely blocked by Cloudflare.
Also, the page rule you posted above, these settings should be set at the different tabs of the Dashboard. Only one page rule is triggered by a URL, so if you have another page rule placed above it, it may render that one ineffective.
I changed Challenge now to Block - as you said, until it gets under control. However, how do I know by looking at this chart that these functions are actually working? Is there any way to measure before/now GETs?
These hits were blocked. Whether or not there are other hits getting to your website needs to be checked at your origin server logs, like the one in the original post. That’s why I suggested you reenable it for a short period, look at the logs, then hopefully put the site back on.
Also, you may want to check Analytics on the Cloudflare Dashboard.
You should make sure you have a backup (multiples preferably) of your content stored offsite. This is true regardless of your current situation with the provider. Accidents/ disasters/ bad things happen.
If this content is mostly static you could also consider turning on a cache everything page rule. This would cache the HTML content as well and reduce requests to origin.
Depending on the requirements of your site, most traffic use GET and POST if you have forms. You could use a Cloudflare Firewall Rules to temporarily block all requests that are not GET
Not sure if you have mod_Cloudflare installed or you are getting direct hits on the origin but your logs above show the actual IP’s.
A Firewall Rule like this would block traffic from reaching the origin that isn’t from your country and methods that are not GET or POST(if you have forms) (ip.geoip.country ne "YOUR_COUNTRY") or (http.request.method ne "GET") or (http.request.method ne "POST")
The following would help with direct traffic by blocking unwanted methods and require visitors to arrive with Cloudflare’s headers.
If you know you don’t have mod_Cloudflare you can also add this
#REQUIRE Cloudflare IPs
order deny,allow
deny from all
#(IPv4)
Allow from 173.245.48.0/20
Allow from 103.21.244.0/22
Allow from 103.22.200.0/22
Allow from 103.31.4.0/22
Allow from 141.101.64.0/18
Allow from 108.162.192.0/18
Allow from 190.93.240.0/20
Allow from 188.114.96.0/20
Allow from 197.234.240.0/22
Allow from 198.41.128.0/17
Allow from 162.158.0.0/15
Allow from 104.16.0.0/12
Allow from 172.64.0.0/13
#(IPv6)
Allow from 2400:cb00::/32
Allow from 2405:8100::/32
Allow from 2405:b500::/32
Allow from 2606:4700::/32
Allow from 2803:f800::/32
Allow from 2c0f:f248::/32
Allow from 2a06:98c0::/29
Lastly, IMO, maybe they are now, but the Hosting company should have been a lot more helpful with this matter.
This won’t affect bots in any way, as they won’t cache anything from your site no matter what setting you have here.
You should have this setting at the smaller value available to your plan, smaller relative to the normal cycle of your site dynamic content generation. If your pages have no dynamic content, you can safely set this to 1 day. If you add content every hour, set the smaller amount possible, or Respect Origin Headers.
You should have a Edge Cache TTL, which is the amount of time the cached file stays at a CF datacenter, set at a much larger period if your content is not dynamic. You can always purge this cache when you update your content. This setting must be included in the same page rule that sets “cache everything” for many WordPress installations.
Guys - the problem is still there. Now I am starting to think that this is a ROOT issue. I don’t use it for any purpuses but it seems the attack goes up that far. The subdomains automatically started getting flooding as soon as they unsuspended my account just now.
What am I missing? Is the flooding focused on my root (and going from there into the subdomains) or?
BUT I CAN’T add “my” root because it is a subdomain to my hosting provider.
That really shouldn’t matter AFAIK. As long as your domain and subdomain DNS records are being proxied by Cloudflare ( in their DNS records on Cloudflare Dashboard > DNS), all rules you created should apply to them as well.
After blocking CN, have you identified any other countries? Also, is there any pattern such as the same URLs being requested over and over? You can try a Firewall Rule to block requests to non existing URI paths, to avoid the origin server having to process these 404s.
In a WorldPress site, the server won’t know it is a 404 until WP returns a 404, which is un unnecessary burden you can avoid by identifying and blocking such requests before they even hit your origin.
in their DNS records on Cloudflare Dashboard > DNS), all rules you created should apply to them as well.