404 lockouts does not work as intended

@robmuzo

404 Detection (and inherent host lockouts) works exactly as intended.

Best advise I can give you is to watch this iTSec plugin 404 Detection tutorial.

dwinden

I got locked out of a site when simply refreshing a page i was working on more than 20 times in 5 mins (The default setting for 404).

The lockout was down to excessive 404, though i was confused as I had not been served the 404 page once.

I released that the site i was working on had a reference in the header to a font file that was missing (Missing resources can be quite common)

So you are suggesting that I should be locked out of that site for simply visiting 20 pages within 5 mins (Default setting) because the site happens to have a link in a script or css somewhere causing a missing file resource?

In this case any site with any missing resources sitewide will lock out any user who browsers more than the threshold of pages and pretty much all search engines crawling the site.

In my opinion a missing resource being served in a header is not a 404 visit, just a missing resource and locking out users or crawlers sould only be counted when actually being served the 404 error page.

OK I see it cant tell the difference between an actual 404 or a missing resource 404 on a non 404 page, for me that makes the lockout feature on this way to dangerous to turn on as any plugin could cause this or a simple dev mistake and you could be locking most users out and search engines or yourself.

I’ll just leave it off, my point still stands about once you are locked out with such a sensitive feature you need to be able to get back in or release ips without core database mods.

A feature that would be better than blanket 404 lockout would be to be able to add specific requests as a blacklist, i.e if someone keeps trying to request timthumb.php

Whitelisting your IP address will prevent locking yourself out due to 404 Detection or Brute Force Protection.

Something else you can do is tweak the 404 Detection feature using its settings.

Lockouts are temporary and expire (default) after 15 minutes.
You could lower the threshold and simply wait a moment (getting tea or coffee) … and\or shorten\lower the Minutes to Remember 404 Error (Check Period) setting.
Having said that this is completely unacceptable for visitors of the site …

When your ip address gets locked out and you’ve had enough coffee or tea and don’t have the time to wait for the lockout to expire simply use another device to log into the WP Dashboard and then release the host lockout from the Active Lockouts metabox on the iTSec plugin Dashboard page.

The iTSec Pro plugin even includes a CLI feature that allows you to query the current lockouts from the command line and then also release any lockout.

Having said all this I agree this is a dangerous feature. That is probably why it’s disabled by default … so if enabled use it wisely.

dwinden

OK thanks for that ,my mistake I did not see that lockout meta box at the bottom of there, that solves that issue, I was still able to access the site via VPN, though the docs I read said you could only unlock via PHPMyAdmin or similar.

The 404 though might be suitable for some scenarios is not what I am looking for.

2 Features that would make this plugin unbeatable by other plugins:

1. The ability to add blacklist url locks for common bot targets such as timthumb etc.
2. The ability to be able to lock out any bot attempting to access the old wp-login after login url rewrite.

What I am trying to achieve safely is to stop brute force attempts fully, though the rewrite of login url does a good job of this the bots are still hitting the server and causing load, If we could have a feature to instantly lock out anyone attempting to access wp-login.php after rewrite this would do the job.

Thanks for your help, I’ll mark this issue as closed, sorry is I seemed a bit blunt in my replies just getting sick of these annoying brute force attempts all the time!

No need to apologize. Fully understand the frustration.

2. The ability to be able to lock out any bot attempting to access the old wp-login after login url rewrite.

Try and manually add the following lines to the .htaccess file when using Apache < 2.3.x:

<Files “wp-login.php”>
Order deny,allow
Deny from all
Allow from [IP]*
</Files>

Or try and add the following lines to the .htaccess file when using Apache > 2.2.x:

<Files “wp-login.php”>
Require ip [IP]*
</Files>

* Where [IP] should be substituted with your (fixed) IP address.

Unfortunately these lines are not included by the iTSec plugin.
Would definately be an improvement in a no public registrations website…

dwinden