Same type of harmful requests slow the server


We have a PRO plan, WAF enabled. However, there is a weird type of requests to the wp-login.php
They are coming from Romania (IP is changing) , but as a global site, I’m sure CloudFlare WAF must know how to identify such bad requests and block them. Can anyone please help? this is from the logs: - - [08/Jul/2020:06:39:28 +0000] “POST /wp-login.php HTTP/1.0” 200 3545 “” “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.90 Safari/537.36 2345Explorer/” - - [08/Jul/2020:06:39:34 +0000] “POST /wp-login.php HTTP/1.0” 200 3547 “” “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.90 Safari/537.36 2345Explorer/” - - [08/Jul/2020:06:39:36 +0000] “POST /wp-login.php HTTP/1.0” 200 3545 “” “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.90 Safari/537.36 2345Explorer/”

I’m not sure if I’m missing something obvious. What’s weird about that request? It looks like any other Login attempt. Is it the User Agent String that’s suspicious?

Hi and thanks for the reply.
If you look that the timeframe - it’s a login attempt every 2 seconds, it’s not a user, it’s a bot behaviour.

Isn’t there a rule to lmit number of requests from wp-admin.php ? let’s say one IP cant send X requests in X minutes?

Or somehow else to handle it. like if it identifies a bot pattern it will block. thanks

adding to the above, another example from now:


These are BOTS! look how often they make the requests. how to make cloudflare block them?

1 Like

I didn’t say it was a human login attempt. So it’s just a brute force attack. There’s nothing at all “weird” about those. Use Rate Limiting for the Login.

yeah I think that will be it!

I created a rule to block /wp-login.php after 5 tryouts in 1 minute

do you recommend also adding something for the whole website?

You could also use Zone Lockdown if you know the IPs for the actual admins who should be accessing that page. Alternatively a FW rule for that path could be created that makes sense.

thanks, the thing is that the admin users are from 20 countries

Ya, but if you Challenge the traffic to that path, it will still weed out the bots. The rate limiting becomes a backup plan then.

I agree about the challenge.
we set page-rules for the login pages , is that what you meant? or do you have another idea for that?

we set the wp-login.php page rule : security level - under attack, cache level - bypass and browser integrity check - ON

Ya, that’s a good general idea and the settings you have sound good. That should create a challenge for new visitors to that url and filter out most of the problems. The rate limiting should serve a good fallback. If you notice the rate limiting being hit, it’s worth checking configurations and traffic again. Also, consider the timeout period. In this instance, you may want to make it a longer timeout.

As far as the rest of the site, I wouldn’t recommend Rate Limiting the site, as a whole. I’d make sure my WAF rules match up to my site and the underlying tech I’m using and then I usually take some time to figure out what my normal traffic should look like versus what the malicious/bot traffic looks like and then I add controls to mitigate the most prevalent threats. You’ll see trends if you keep an eye on things.

If you haven’t already, I’d make sure I have my firewall set to only allow traffic that comes through Cloudflare and make sure I was proxying all traffic, wherever possible.

thanks for the detailed reply!

I did Rate Limiting only for wp-login.php and xmlprc and so far seems like it blocked several attacks, seems like it works.

can you please explain how to check this part: “If you haven’t already, I’d make sure I have my firewall set to only allow traffic that comes through Cloudflare and make sure I was proxying all traffic, wherever possible.”

Thanks again!

Since Cloudflare proxies traffic, your FW will see Cloudflare IPs hitting it when the traffic routes through Cloudflare’s network. Direct traffic to your IP could still occur that bypasses Cloudflare, however. As a best practice, you want to whitelist Cloudflare IPs and drop all other traffic that attempts to reach your site directly. The CF IPs are listed here:

That way, a request is forced to come through Cloudflare. It’s not always 100% possible, but if it is, it is definitely the way to go.

This isn’t a step to take to resolve your current issue, per se, but it is a good general rule for your site.

this is done via the server itself? or htaccess?

I would generally say your firewall…This community question talks about it in a little more detail: Why to whitelist cloudflare ip ranges?

There are a lot of variations of a firewall so I can’t directly answer that question though.

You probably need something like fail2ban and rate limiting on your origin server which links in and communicates with Cloudflare Firewall.

I wrote

in your case you’d configure rate limiting on wp-login.php at your origin web server which gets logged and fail2ban reads that log to ban the IP doing the excessive requests and passes to CF Firewall API the block action.

Of course you need to have sufficient admin/root access to origin server to configure this.

Or you can do rate limiting on origin web server without the CF Firewall/fail2ban and just let the bad excessive requests hit a Cloudflare 5xx error page as it sees a 503 unavailable message returned (or for nginx you can configure rate limited requests to return a 444 HTTP status code) from your origin when such excessive requests are rate limited at origin server level. The goal here is to prevent requests hitting the slowest part of your origin server which would be php requests and offload it to the origin server which in theory can handle higher amounts of traffic i.e. apache/nginx to serve the rate limited response i.e. 503 HTTP status code.

Of course you can do rate limiting at Cloudflare Edge just you will incur variable costs for all good requests.

Hi @sdayman and @dmcclure -

Following the original question,

I see on my firewall log the following event from a malicious IP “12 Jul, 2020 01:00:49
JS Challenge
Security level”

in the details I see “Path /xmlrpc.php”
and the action taken “JS Challenge”

I see like 15K requests from one IP. This is despite I defined a rate limited for xmlprc to block after 5 attempts in 10 minutes.

I know see that I also have in the page rules a rule about xmlprc which says the following: “Browser Integrity Check: On, Security Level: I’m Under Attack”

My question is, what causes the action taken to be JS Challenge for xmlprc instead of a Rate limiting block? are the page rules coming up first?
and if so, what should I do which will be the best response to xmlrpc attacks following the above?


It looks like Under Attack triggers before Rate Limiting. I know the Rate Limiting works, though. I hit it a bunch of times in a row with ‘curl’. As for which to use, that’s up to you. Is there any reason for anybody to hit your xmlrpc? I have that in a Firewall Block rule along with a handful of other URLs that should never be hit.

Screen Shot 2020-07-11 at 4.48.56 PM

thanks for the reply, so the bottom line is, does it make sense to leave it only as Rate Limiting , and just remove the Page Rule (that’s probably hitting it before) ?