Login Security Brute Force Attack

[Krzysztof]

I’m also using Wordfence and have decided to turn off login security there and check how BPS works in this matter. Puting various names and passwords didn’t lock me out as in wordfence so I tried to put a valid nam and wrong password and even after typing the password wrong for severall times (more than 3) I was not locked out. Is this normal?

[AITpro Admin]

BPS Pro only locks out valid user accounts.

Nope that is not normal.  Have you saved your Login Security options?  If you set the max attempts to 3 then you will be locked out after 3 failed login attempts.  For testing set the Automatic Lockout time to 1 minute or just use another login account so you don’t actually lock yourself out for the default 60 minutes.

If BPS Pro Login Security is not working then another plugin is overriding it.  You can only use 1 login security feature/plugin at a time otherwise they will conflict with each other.

[Krzysztof]

I had to refresh several times to see the locked out user.

So does this mean that someone can try to do a bruteforce and attack the login page with various invalid user names and passwords?  Like use admin as name and try hundreds of paswords for it? Will this be too uch for the server? Wouldnt it be better to lock out invalid user names right away as Wordfence is doeing? And if the name is valid lock out the user after 3 failed attempts?

[AITpro Admin]

I’m not sure what is wrong on your website.  3 failed login attempts with a setting of max 3 attempts locks a valid user account after 3 failed login attempts.  If this is not working on your website then something is wrong with your website.  ie another plugin is causing this problem or something else about your website or DB is fubar.

How do you lock out a username that does not exist?  The normal/standard way that WordPress Authentication processing code works is this.

If a username/user account does not exist then return an error and kill the script and do not proceed any further.  BPS Pro Login Security hooks into the WordPress Authentication process and also kills the script.

When a script is killed it does not consume any significant resources so let’s say someone was trying to run an automated login script on your site at a rate of 1,000 times per second.

Attempt 1 = script killed in less than 1 millisecond
Attempt 2 = script killed in less than 1 millisecond
…
…
…
Attempt 1,000 = script killed in less than 1 millisecond

I looked at adding a threshold, but I found this to be really stupid and a waste of time.  Most other Login security plugins are using a threshold – dumb.  😉

[AITpro Admin]

You can test BPS Pro Login Security on any of the AITpro websites by performing 3 bad login attempts to see how it is supposed to work.  If it is working differently on your website then something is not right and you will have to look at any other plugins that could be conflicting or interfering with BPS Pro Login Security.

[AITpro Admin]

Someone asked some similar questions and I answered them in the WordPress.org forum.

Source:  http://wordpress.org/support/topic/login-security-question?replies=5#post-4191648

100 to 1,000 times per second is the thing that is important to note. You would never want to log or process this type of malicious activity for 2 reasons. The goal of a DoS/DDoS attack is to overload your Server and crash your website.

1. If the hacker is NOT using a valid username then they will never be able to successfully log into the site.

2. WordPress handles this type of malicious authentication activity by returning an error instead of consuming unnecessary resources by continuing the authentication processing any further.

BPS Login Security is hooking into the WordPress authentication process and is also returning an error on this type of malicious activity.

Every time someone attempts to login to your website they are attempting to connect to your WordPress Database. This costs website resources so if someone is overloading your website resources by trying to login repetively then this will cause your website to run slower or probably just crash the site. So by ending the script with an error instead of continuing with script processing the resource cost is almost nil. If on the other hand you allowed the processing of this type of malicious activity to continue on in the script and be processed then this is unnecessary use of your Server resources and would have a negative impact on website performance. If handled completely wrong it could cause your Host to suspend your Hosting account. Therefore not allowing this type of malicious activity in the first place is the smart way to handle this.

Honestly why would you want to see or log login attempts for invalid usernames? I do not see any valid reason to do something like that. It is an unnecessary waste of your Server’s resources/website resources.

[Krzysztof]

Now this is interesting. Never thought that this works like this. Thank you for claryfying it. This means that Wordfence way is not so good. I will stick to BPS PRO 😉

[AITpro Admin]

The highest priority is security.  The next highest priority is website performance.  What good would security be if your site ran slow as molasses.  I hate having to log HTTP and Security Log errors, but that is a necessary evil.  With Login Security this is much simpler because you only need to keep track of/log valid login attempts and just ignore all the other attacks since they cannot hurt your website performance.  So yeah the last thing I would want to do would be to process/log/keep track of login attempts that do not matter anyway – waste of resources, DB space and time.

[Steve Lubetkin]

Is there a way to permanently block specific IP addresses from logging in? I’m getting hack attempts from one specific IP on several sites, all trying valid usernames but obviously not getting the password right. I want to block those IPs without blocking the usernames. Is that possible?

[AITpro Admin]

You can try, but IP addresses can be faked and changed very easily.  Most automated hacking and spamming scripts will automatically switch to a different IP address if you block the current IP address that they are using.

Here is IP address blocking .htaccess code if you want to give it a try.

http://forum.ait-pro.com/forums/topic/htaccess-block-ip-address-block-access-to-files-by-ip-address/

Or you could try something like this that is ONLY blocking IP addresses on your login page itself.

<FilesMatch "^(wp-login\.php)$">
Order Allow,Deny
Deny from 46.119.35.
Deny from 46.119.45.
Deny from 91.236.74.
Deny from 93.182.147.
Deny from 93.182.187.
Deny from 94.27.72.
Deny from 94.27.75.
Deny from 94.27.76.
Deny from 193.105.210.
Deny from 195.43.128.
Deny from 198.144.105.
Deny from 199.15.234.
Allow from all
</FilesMatch>

[Daniella Norwood]

What about only allowing from certain IPs?

[AITpro Admin]

Yes, that is always the much better aproach to use since you have full control over allowing IP addresses vs denying IP addresses.  Allowing IP addresses is a finite number.  Denying IP addresses is in infinite number (millions of possible IP addresses to block).  See this Topic link below that has Bonus Code that you can add to BPS Custom Code that uses an Allow vs Deny protection method/approach.

http://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/

[Daniella Norwood]

So this is what I placed in the Custom Code Brute Force Login….

# Protect wp-login.php from Brute Force Login Attacks based on IP Address
<FilesMatch "^(wp-login\.php)">
Order Allow,Deny
# Add your website/Server IP Address
Allow from xxx.xxx
Allow from xxx.xxx
Allow from xxx
</FilesMatch>

Do I need Deny from all at the end and do I need periods after the IPs?

[AITpro Admin]

No, you do not need to add a deny condition/rule it is implied.  Yes, you would need dots after each octet of the IP address.
3 octets:  Allow from 100.99.88.
2 octets:  Allow from 100.99.

# Allow,Deny
# First, all Allow directives are evaluated. At least one must match, or the request is rejected.
# Next, all Deny directives are evaluated. If any matches, the request is rejected.
# Last, any requests which do not match an Allow or a Deny directive are denied by default.
#
# Deny,Allow
# First, all Deny directives are evaluated. If any match, the request is denied unless
# it also matches an Allow directive. Any requests which do not match any Allow or Deny directives are permitted.
#
# *Match* -------------------- *Allow,Deny result* -------------------- *Deny,Allow result*
# Match Allow only ----------- Request allowed ------------------------ Request allowed
# Match Deny only ------------ Request denied ------------------------- Request denied
# No match ------------------- Default to second directive: Denied ---- Default to second directive: Allowed
# Match both Allow & Deny ---- Final match controls: Denied ----------- Final match controls: Allowed

[Alex Laxton]

Must be safe your security from Brute Force Attack because this attack is very harmful if your bots file allows everything then they will easily access your site and change anything.

[Author]

Posts