So yes, like the topic subject says, I tried a variety of firewall rules to try to stop brute force attacks to a specific domain and still I see more and more entries in my apache logs for wp-login.php accesses.
What I find more strange is that the same rules seems to had stop similar situations in other domains I manage. Any ideas?
I don’t know what your rules look like, but I use “Access” with two policies:
Since Access is free for 5 or fewer users, that only applies to email addresses which I rarely use unless I’m away from home.
This is my latest approach to the problem:
There’s always the chance they’re bypassing Cloudflare and directly attacking your server’s IP address.
What happens if you change that “Not Equal to” IP address to something else to see if it will block you?
I don’t think so because it’s a VPS, and only two domains out of 15 or so are being hit. By the way, instead of IP I used my country. It’s not common that we have domestic attacks.
Damn, I changed country to allow to Afghanistan and indeed I could access wp-login.php… no idea what’s going on.
So, now, just to test, I created a rule blocking all access to the site from my own country. And oddly I still can load the website.
You haven’t whitelisted your own address in Firewall Tools, have you?
I had indeed forgot to remove the country from White list. At least this bit is working. So I know Cloudflare is not deaf regarding this website 
Thanks!
But the original issue remains. wp-login.php keeps being hit 
This is crazy… I determined the offending IP, added it to the blacklist, block access to the website, and still, it keeps coming. From the same IP.
First I created a rule that allows my IP address.
Then I created a rule to block all php requests:
(http.request.uri.path contains “.php” and http.request.uri.path contains “/wp-content/”) or (http.request.uri.path contains “.php” and http.request.uri.path contains “/wp-admin/”) or (http.request.uri.path contains “.php” and http.request.uri.path contains “/wp-includes/”) or (http.request.uri.path contains “xmlrpc”) or (http.request.uri.path contains “login”)
It has pretty much shut down efforts to backdoor into the site.
Scott, thing is the rules I have added should be blocking this attack and they aren’t. that’s the intriguing thing, it’s like they are not active or something, but I can’t imagine how.
Scott, I adopted your rule but still the attack goes on. What is most bizarre above all is that I added the offending IP to the blacklist but still, it keeps hitting my wp-login.php
Where are you seeing the traffic logs? Within CloudFlare or from your server? It’s possible if these requests are not through CloudFlare it’s being sent to your server’s IP address directly.
Edit: I read where you said it wasn’t directly to your IP. You can try to block access all together but whitelist your IP when you need to access it. It’s also possible that other Firewall rules with a higher priority are allowing the traffic before the other firewall rule gets to drop it.
I am seeing the logs in my server. I did even block the attacker IP and even this is being ignored. If this won’t work, I can’t see what will.
I can’t work with IP’s blocks, I live in a world of dynamic IP’s (besides, this is not one of my own websites), but did block all countries but mine, to no avail. As I said, is like CF is not acting in this case, not so much a matter of tunning up rules.
Right now I have only one rule, the one the fellow of this community suggested above.
Yesterday I noticed attempted logins on a new site through xmlrpc, so I blocked that one as well. I don’t use anything that’s tied into xmlrpc, so that won’t break any of my access.
Sorry the approach I outlined didn’t help. Hopefully what you are doing now will do the trick. Good luck!
This topic was automatically closed after 30 days. New replies are no longer allowed.
