Locked out even after whitelisting IP

Hi, this is still happening and it’s a HUGE problem for my client.

So, what lockout message(s) is(are) displayed ?

A. error
B. You have been locked out due to too many invalid login attempts.
C. Your IP address has been flagged as a threat by the iThemes Security network.

Or perhaps a combination of these.

dwinden

It’s B.

Ok, so it’s probably a user lockout.

There are 2 methods to find out what username is locked out.
(Well actually, it’s probably the username the client is using to login but get’s repeatedly locked out).

Method 1
If possible, log into WP Dashboard and goto the iTSec plugin Logs page.
Select “Invalid Login Attempts” from the Select Filter: dropdown listbox.
If multiple entries are displayed, all within short time of each other they are probably the result of a brute force attack. Take note of the Username(s) listed.

Method 2
If the “Enable Email Lockout Notifications” setting is enabled in the Global Settings section of the Settings page, the iTSec plugin sends an email for every lockout to the email address as specified in the “Notification Email” setting.
Find that(those) email(s) and it will contain the host(s) and\or username(s) locked out and when the lockout is expected to expire.

Is the username identified different than “admin” ?
Is there just 1 username associated with the bad login attempts or multiple ?

Please note whitelisting the client’s ip address will prevent a host lockout but not a user lockout. Well actually it will prevent triggering a user lockout due to bad login attempts from the whitelisted ip address but NOT FROM ANY OTHER IP ADDRESS.
Someone else (or a bot) is generating bad logins which results in user lockouts on the username found.

Normally user lockouts are regulated by Brute Force Protection settings Max Login Attempts Per User and Minutes to Remember Bad Login (check period). However due to a known bug user lockouts ignore the latter. All bad login attempts are remembered …
Once a user lockout has occurred on a username any subsequent bad login attempt with that username will trigger an immediate user lockout …
This bug basically makes user lockouts trigger faster …
Faster than expected based on the values of the Max Login Attempts Per User and Minutes to Remember Bad Login (check period) settings.
By default a user lockout is temporary and expires after 15 minutes but you can imagine that when user lockouts get triggered faster the temporary nature of a user lockout can easily transform into a permanent one … certainly under a brute force attack.

By this time you are probably thinking bla bla bla, but the point of all this is that you need to understand the whole process behind Brute Force Protection in order to be able to deal with lockouts effectively.

So how can we prevent the user lockouts from happening ?

If the bad login attempts are using the admin username you could enable the Brute Force Protection “Immediately ban a host that attempts to login using the “admin” username.” setting.

Or even better use the “Change Admin User” feature from the Advanced page.

If the bad login attempts are using a different username the best strategy would be to create a new username and then delete the old one.
But changing any username is only effective when you also take measures to prevent bots from harvesting usernames from your WordPress env.

You could enable the Blacklist Repeat Offender setting and the Ban Users setting (if not already enabled) so that the attackers ip address is automatically added to the Ban Hosts box
after 3 lockouts.

Using the Hide Backend feature is also a good option.

iThemes fixing the user lockout bug would also be a start … not a total solution.

A combination of the options mentioned above would probably be best …

dwinden

I wasn’t sure about one thing so I decided to test it.

I know whitelisting prevents any type of lockout from being triggered while doing bad login attempts from the whitelisted ip address(es).
But does whitelisting also allow you to login with a certain user account while a user lockout has already been triggered on it and still active?

I thought the answer to this question was no but that turns out not to be true.

Whitelisting your ip still allows you to login while using an actively locked out user account.

So why is this not working with your client ?

Perhaps an incorrect ip address is being whitelisted.
Or your client’s ip address is changing\reset all the time …
Or the iTSec plugin is not detecting the correct ip address …
(Is this website accessed through a proxy ?)

Anyway whitelisting the ip address should prevent any lockouts from occurring from the whitelisted ip address.

dwinden