wp-login.php brute force attacks

qba82

Verified User
Joined
Jun 26, 2018
Messages
65
Hi,
I have some bigger wp-login.php brute force attacks from many different IPs, for many wordpress installations,
of course I have enabled "Directadmin's BFM compatible with CSF" from this topic:

but there is too many IP and even when they are blocked every minute there is more then 1000 new IPs and system is overloaded all the time.

Is there any others options to secure wp-login.php for wordpress?
I saw good solution on some websites: javascript cookie only for wp-login.php page, if You have javascript enabled in website browser, then You are allowed to see wp-login.php, if You don't have javascript, which most attacks doesn't use, You are blocked,
does anybody know where I can find that solution for server side?
 
In website source it looks like that:

Code:
<script>document.cookie = "humans_21909=1"; document.location.reload(true)</script>
 
That's why I've offered: or build your own solution based on this

You take the idea on how it is integrated in Apache and do your own validation check with JS or Cookies.
 
Ha, Wordpress.... My enemy... I just ignore brute-force attacks, as a host, not my problem......

Host job = Making the site/email/etc run and back-end software updated.....
Client job = Keep their software updated (< lol?) and secure it........
 
Ha, Wordpress.... My enemy... I just ignore brute-force attacks, as a host, not my problem......
What about Joomla? It's my enemy even more. Way overkill for a simple user site. I rather have Wordpress than Joomla on my servers.
We use Softaculous and regularly we check this. Users get automated messages to update their stuff. If they don't, they have the risk that we update it for them via Softaculous in case an update is needed to prevent hacks. If that breaks things, that's their problem. We do warn them thouroughly when they start using Wordpress (or Joomla if any) they have to keep it up to date and are responsible themselves if things go wrong because they don't and we have to do it externally.
I must say most of our users keep their installations reasonable up to date. But we're not having hundreds of users using Wordpress, we're not that big.

But what else is there for users (most of them) which can't really create a website? CMSimple is an option, but sometimes a bit too simple and not a lot of options either.

They dont know what this is...
Unfortunately not. That's why I'm happy Maldetect is installed on all servers. And other security measures to prevent spam as much as possible via leak scripts and themes or hacks.
 
Why not block the wp-admin with a simple htaccess request, that is the easiest thing and helps 100%.

I had also that kind of problems before, after i protected it with a simple htaccess request, i never had that problems ;-)

If you need more infos to it, i can help.

BTW: Blocking IPs helps nothing in that kind of problems, this hammers only down your server and you have no chance. The only one and simplest solution is the htaccess ;-) from my own experience on several hundred domains!

Greets
 
They dont know what this is...
Exactly, they just see a website as a website, nothing more. But, to run a website, even a little blog, you must know a bit about how it is run and how sites are prone to attacks...... It's no different from protecting yourself from fraud, news outlets go on about being cautious, but still, people get victimised.
 
It's no different from protecting yourself from fraud, news outlets go on about being cautious, but still, people get victimised.
Right, and how many Windows users still don't know anything else but to click on things only, how many people still fall even for the easiest and most well known whatsapp and email fraud tricks and so called telephone calls from Microsoft.... You can't change what isn't there.
Users will be users. Some who have a bit of affinity or are eager to learn something will improve, most won't.

On the other hand, it's also because we know lots about internet stuff. I don't know scooters and don't want to know, I want them to work and to ride them. So we might be as ignorant or unknowing with other things. It's just part of life and will never change.
 
Hi, DA Brute Force not block this? i use CSF and Comodo WAF

176.31.105.112 - - [05/Jun/2020:21:45:37 -0400] "POST /wp-login.php HTTP/1.1" 200 4737 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36"
176.31.105.112 - - [05/Jun/2020:21:45:37 -0400] "POST /wp-login.php HTTP/1.1" 200 4737 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36"
176.31.105.112 - - [05/Jun/2020:21:45:38 -0400] "POST /wp-login.php HTTP/1.1" 200 4737 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36"

i have more 10000 request...
 
My technicians had no chance to block this with the CSF firewall, because of the massive entrys it will also slow down your server.
Why are you not easily block it with a htaccess which protects the wp-login.php with a password and the problem is gone?

Or do you need this on thousands of customer domains?

I use the htaccess method on hundreds of domains and never had that kind of issue anymore again.
One time work, freedom for the next years.

Greets
 
My technicians had no chance to block this with the CSF firewall, because of the massive entrys it will also slow down your server.
configure CSF to use IPSET, in my case some servers has 25000-40000 denied IPs and all works fine.
 
Thanks for the info. Maybe i try it out in future, but at moment i am quite happy with the htaccess and i dont like to change a running system ;-)
 
I get ten of thousand brute force also last month, and also every day some people do that it showing in server log!
If you only have one user login account. U can change go to "file manager" and set wp-login.php's permission to 600
Also, you should change another files:
wp-config.php
xmlrpc.php

my experience, when change wp-login.php to 600, the attacker will go to xmlrpc.php

when you login, just change wp-login to 644, after that, change again to 600..

But if you have some user i think change wp-login.php to another URL... the attacker will hard to find that
 
Last edited:
Back
Top