dwinden
Forum Replies Created
-
@rush Hour Marketing Technology
Uhmm, restore the .htaccess and wp-config.php files and the database from a backup.
If that is not an option you can manually remove anything between these lines in .htaccess:
# BEGIN iThemes Security – Do not modify or remove this line
…
# END iThemes Security – Do not modify or remove this lineSimilarly there could also be entries added to the wp-config.php file which can also be removed manually.
After this you might be able to deactivate and delete the iTSec plugin from WP Dashboard. This will remove any settings in the database.
Untested so try it at your own risk.
dwinden
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, well done. Thanks for your feedback.
As the issue seems to be solved please take a moment to mark this topic as ‘resolved’.
dwinden
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
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
Did you use the Change Content Directory feature from the Advanced page ?
Please provide us with a link to your website.
dwinden
Well the temporary IP lockouts do counteract the brute force attack to some degree. But because the IPs are not automatically & permanently banned on IIS the Brute Force Protection feature is not fully effective as it should be.
So no I would not disable the Brute Force Protection. But you could disable the Blacklist Repeat Offender setting in the Global Settings. This is the setting that governs the automatic & permanent IP bans.
Also take a look at the list of IP addresses in the Banned Users section, Enable ban users, Ban Hosts. I’m not 100% sure (for IIS) but I think there should be a list of bad IPs here. You can remove them all and then disable the Enable ban users setting (unless you have also blacklisted User Agents).You could use the list of bad IPs to manually block them some way in IIS.
Alternatively you could fully disable Brute Force Protection and Blacklist Repeat Offender and then replace this functionality with another brute force defensive plugin that does fully support/function on IIS.
dwinden
It wasn’t a glitch. The iTSec plugin automatic permanently ban IP functionality does not get effectuated on IIS web server.
Only temporary IP lockouts will function.Please be so kind to mark this topic as ‘resolved’.
dwinden
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
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
Would it be possible to share some more details about the server config problem with the community ? It may help others.
Anyway please mark this topic as ‘resolved’.
dwinden
Ah right. Thats probably why it keeps locking out the same IP address over and over again …
The IP address is never banned while using IIS web server.Please note the iTSec plugin does not support the IIS web server.
Though you could manually add for IIS modified IP ban entries to the web.config file I guess …The only supported web servers are:
– Apache
– Nginx
– LiteSpeedSo I think this puppy can be marked as ‘resolved’.
dwinden
Ok, I see.
Anyway these lockout emails are the result of a brute force attack.
Basically the iTSec plugin Brute Force Protection feature is doing its work.Since the email mentions that:
The host has been locked out permanently.
You should see a list of IP addresses in the Ban Hosts setting under the Banned Users section of the settings page. Note it will only show up if the Enable ban users setting is enabled.
For every IP address listed you should see a similar section as below in the .htaccess file:
# Ban Hosts - Security > Settings > Banned Users SetEnvIF REMOTE_ADDR "^192\.99\.36\.79$" DenyAccess SetEnvIF X-FORWARDED-FOR "^192\.99\.36\.79$" DenyAccess SetEnvIF X-CLUSTER-CLIENT-IP "^192\.99\.36\.79$" DenyAccess <IfModule mod_authz_core.c> <RequireAll> Require all granted Require not env DenyAccess Require not ip 192.99.36.79 </RequireAll> </IfModule> <IfModule !mod_authz_core.c> Order allow,deny Allow from all Deny from env=DenyAccess Deny from 192.99.36.79 </IfModule>If all of the above checks out you should be ok.
dwinden
Are the websites which are exhibiting this lockout behavior, websites where you have just newly installed and configured the iTSec plugin or has the iTSec plugin been running for a while on those websites ?
dwinden