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:
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?
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.
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.
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.
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.”
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: IP Ranges
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.
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.
I see on my firewall log the following event from a malicious IP “12 Jul, 2020 01:00:49
JS Challenge
France
XX.XX.XXX.XX (the IP)
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.
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) ?
