Keep receiving the same notification email over and over (Site Lockout)

Ok I’ve realised the 24 emails per hour thing is because Mandrill only sends 25 emails per hour and puts the rest in a backlog, which it has been slowly trying to clear since yesterday.

So it’s likely that iThemes tried to send all the emails at once.

The question remains why iThemes would send so many notification emails?

Hi, I’m having the same problem, iThemes is blocking the same IP thousands of times. I’ve received more than 5000 “too many bad login attempts” emails.

Something is wrong here, please help…

Thanks

I have had the same problem and have had no response from the developers to my post either.

@tissandier

The notification emails are the result of the Brute Force Protection feature reacting to a brute force attack.

What web server (and version) are you running on ?

dwinden

@dwinden

Thanks for your reply.

Server is running nginx 1.6.2

Yes I understand the notifications were in response to a brute force attack. The problem is that hundreds of notifications were sent at once.

@tissandier

A brute force attack typically does 100s or even 1000s of login attempts.
Every 5 invalid login attempts the host IP address is locked temporarily by the iTSec plugin (by default for 15 minutes). But as brute force attacks are distributed most of the times the attack continues from different hosts with different ip addresses …
For every locked out host the iTSec plugin sends an email.

When using Nginx web server there is a complication.
By default after 3 lockouts in 7 days a host IP will be banned permanently in the nginx.conf file located in the root of the WordPress install. However for Nginx you must stop/restart the web server in order for the permanent IP ban changes in the nginx.conf file to have any effect.

dwinden

@dwinden

Ok thanks for the nginx info, that makes sense. Does the 15 minute host lockout also work by changing nginx.conf, or just the bans?

In this case all the login attempts were from the same IP, trying to login with the same non-existent username (“Administrator”). All the emails had the same content and were sent in the same 15 minute period.

I guess ithemes couldn’t lock out the host because nginx wasn’t reloading the config file, but it kept trying and sent an email each time?

Is there a way to force nginx to reload conf files when they change?

@tissandier

Does the 15 minute host lockout also work by changing nginx.conf, or just the bans?

No, the temporary host lockouts are based on the results of database queries to the wp_itsec_temp table and purely php code.

Only the permanent bans are realized through adding lines to the nginx.conf file.

I guess ithemes couldn’t lock out the host because nginx wasn’t reloading the config file, but it kept trying and sent an email each time?

There is a difference between a lockout and a ban (temporary versus permanent). The iThemes plugin actually did what it is supposed to do.
But for any changes made by the iTSec plugin in the nginx.conf file to have any effect Nginx needs to be restarted.
So basically Nginx was not aware of the IP bans generated by the iTSec plugin in the nginx.conf file.

Is there a way to force nginx to reload conf files when they change?

In theory I think this should be possible.
Talk to a Unix\Linux system administrator (which I’m not)

Anyway I think this topic can be marked as ‘resolved’.

dwinden

The iThemes plugin actually did what it is supposed to do.

It’s supposed to send hundreds of identical emails in a 15 minute period?

If the host lockout was working properly then presumably the login attempts would have stopped for 15 minutes, and I should have only received another email if / when the host was unlocked and then locked out again.

@tissandier

tlo = temporary lockout

I would need to have a look around in your env to know exactly what happened. But based on the info provided so far I think below is the most likely scenario that happened:

5 invalid login attempts in 5 minutes from IP x -> tlo IP x for 15 mins -> send temporary lockout IP x email

5 invalid login attempts in 5 minutes from IP x -> tlo IP x for 15 mins -> send temporary lockout IP x email

5 invalid login attempts in 5 minutes from IP x -> 3 tlo IP x in 7 days -> ban IP x -> send permanent lockout IP x (=ban) email

+1(6) invalid login attempts in 5 minutes from IP x -> 3(4) tlo IP x in 7 days -> ban IP x -> send permanent lockout IP x (=ban) email

+1(7) invalid login attempts in 5 minutes from IP x -> 3(5) tlo IP x in 7 days -> ban IP x -> send permanent lockout IP x (=ban) email

etc etc

tlo = temporary lockout

There are 4 crucial factors that I think contributed to sending so many emails in such a short time:

• First of all there must have been a pretty serious brute force attack. With pretty serious I mean MANY invalid login attempts.
• When the 3rd (or fourth or fifth etc) tlo for the same IP is detected by the iTSec plugin there is no tlo executed. Instead a permanent ban is triggered … This is as designed.
• Nginx is not restarted and thus unaware of any IP bans.
• After the permanent ban is triggered (which Nginx is unaware of) the next invalid login attempt triggers another 3rd (or fourth or fifth etc) tlo which again is not executed but instead a permanent ban is triggered.

Again I can’t be sure without additional log details or access to the env but this is probably what happened.

dwinden

I’m also having a problem with one of my sites getting multiple emails about a couple of IP addresses.
I also enabled the “Hide Backend” feature yesterday and I’m still getting them from the same IPs.
Any way to stop them?
Thanks!

@khildreth

Unless your site is also running on the Nginx web server please open a seperate topic for your issue.
Try and provide as much details as possible. Start with providing the content of some of the emails received.

dwinden

Ok Thank you

@tissandier

I’ve done a quick Nginx test to see whether my theory is correct (or not).
And I can confirm it is exactly what happens when the Nginx config is not reloaded upon a conf file change (ban host IP).

I guess this topic can now be marked as ‘resolved’ ??

dwinden

@dwinden

Aha, yes you’re right. Thanks for taking the time to write that explanation.

In the logs I can see that there were two earlier temporary lockouts for the IP in question. So on the third time it tried a permanent ban (which didn’t work because of nginx) and then kept trying a permanent ban over and over again.

So ideally ithemes should have realised the ban wasn’t working and reverted to temporary lockouts, or at least stopped trying to ban the IP.

To stop this happening again I guess I have 3 options:
1) Figure out how to restart nginx every time ithemes makes a change

2) Switch to a different security plugin

3) Temporary solution: Set “Blacklist Threshold” to 999 so that ithemes just keeps using lockouts instead of trying to ban.

Any other options?