dwinden

Goodafternoon rdekruijf 😉

Ok, I now fully understand what is happening.

On second thought I don’t think the captcha is an active plugin in the WordPress env.

It looks like this is either part of the Softaculous install or an extra feature for WordPress sites which is included in the hosting providers package/service (which basically boils down to same thing).

You can probably find out exactly what it is by clicking on the link underneath the captcha form:

Informatie over deze beveiliging

Perhaps logging into the account management system also allows you to disable/enable or tweak the captcha feature.

In any case entering the captcha correctly once initially returns a 404. But a subsequent second attempt to access the same secret login url will provide immediate access to the WordPress Dashboard login screen (the captcha form is skipped).

So I’m pretty sure the action behind the captcha form tries to redirect to the wp-login.php script. Since the iTSec plugin Hide Backend feature also blocks (actually responds with a 404 to) wp-login.php requests a 404 is returned upon a correct captcha submit.

Basically the captcha form is unaware of the iTSec plugin Hide Backend feature responding to wp-login.php requests with a 404.
If you could somehow tweak the captcha form to redirect to the secret login slug as set by the iTSec plugin Hide Backend feature the problem would be solved.

Another option would be to disable the captcha form.

dwinden

@rdekruijf

Screenshots are always welcome.

At what hosting provider is the site hosted? Wondering whether this is a WordPress specialized hosting company. I’m Dutch so I will be able to find out.
Did you install/configure the WordPress env yourself or did the hosting provider do it for you ?

Also provide a list of plugins installed. I may be able to determin which plugin includes the reCaptcha functionality.

Anyway if the reCaptcha functionality tries to redirect to the wp-login.php script while the iTSec plugin Hide Backend feature is enabled then a 404 is the expected result.
Enabling the iTSec plugin Hide Backend feature also blocks direct access to the wp-login.php script …
(What’s the point of hiding the wp-admin slug when the wp-login.php script can still be accessed directly ?)

If you provide the site URL I can even have a look at this myself.

dwinden

Just to let you I submitted my post without noticing your last post.
So I only responded to your previous post.
Complicated … 😉

dwinden

@mike Matenkosky

I think you will need to add the entire path relative to the WordPress root in the “404 File/Folder White List”.

Try it and let me know the result …

dwinden

@poopypants

Ok, that fits the picture.

I think it is a file/folder permission issue.

Before the lockout is actually executed the plugin tries to create a file lock. If the file lock fails to be created the lockout code is not executed …

It looks like this:

if ( $itsec_files->get_file_lock( 'lockout_' . $host . $user . $username ) ) {

	//do lockout code

}

$itsec_files->release_file_lock( 'lockout_' . $host . $user . $username );

I’ve seen your issue in a previous topic and I can confirm it was resolved by setting proper folder permissions.
The temporary lock file/folder is normally created in the wp-content/uploads/ithemes-security folder.

The above info should allow you to fix the issue.

dwinden

@poopypants

Ok, so if I understand correctly we should see this as an isolated issue on a single site.

Permanent bans are triggered by a certain number of (host) lockouts (by default 3) within a predefined timeframe (by default 7 days). No temporary lockouts means no (automatic) permanent bans written to the .htaccess file.

Are there any errors in the web server error_log ?

Did you try deactivating&deleting the plugin and then reinstalling&reactivating the plugin ?

dwinden

@tungstene2

No, restore from (database) backup is the easiest/fastest solution.

dwinden