dwinden

@john

Could be a privileges issue.

Are there any error messages in the web server error_log ?

dwinden

@john

If the secret slug as specified for the Hide Backend module is still working even after deactivating the iTSec plugin then there is probably something wrong. If reproducable I’d say it is a bug or perhaps a caching issue.

The secret slug will primarily work because the iTSec plugin (normally) adds the following lines to the .htaccess (also referred to as Apache server config) file:

# Enable the hide backend feature – Security > Settings > Hide Login Area > Hide Backend
RewriteRule ^(/)?examplelogin/?$ /wp-login.php [QSA,L]

If for whatever reason these lines are not added to the .htaccess file the secret slug will still work because the slug is also recognized by a Hide Backend feature enabled snippet of iTSec plugin php code.

The 404 (not_found) on wp-login.php/wp-admin is also returned by a Hide Backend feature enabled snippet of iTSec plugin php code (but only if the Enable Redirection setting is enabled. Otherwise you’ll get the message “This has been disabled.”).

Disabling the Enable Redirection setting will help in determining whether a 404 response on wp-login.php/wp-admin after deactivating the iTSec plugin is caused by something else.

dwinden

@dvascheta

1. No, both will be blocked by the Hide Backend feature.
However the Away Mode feature will only block (actually redirect to the homepage) wp-login.php GET requests. So the Away Mode feature is useless for stopping (automated) brute force attacks.
And that is ok, because this feature was never designed to stop (automated) brute force attacks.

2. You will know when you identify which brute force method is being used from the logs. Simply identify which http request is logged by the webserver at the same timestamp that the invalid login attempt is registered in the iTSec plugin log.

The iTSec plugin includes another option to secure your site from those brute force attempts. I think I know which one but we need the confirmation from the web server log.

dwinden

@dvascheta

A default Apache install includes logging. Unless you have explicitly disabled it. So I don’t think you need to set up anything. Just look in the existing logs.

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

Goodluck !

dwinden

@dvascheta

Do anyone have an idea how robots detect login url?

You are assuming invalid login attempts are the result of bots performing wp-login.php POST requests while using your secret/hidden login slug.

Did you verify this in the web server logs ?

There are other ways of performing login attempts …

The web server logs will tell you.

dwinden

@garyweldy

Seems to be related to updating.
A stack trace of when the error occurs should tell us more.

dwinden

@mpesuit

Renaming the better-wp-security folder would probably have allowed you to get back in (workaround the WP user lockout).

Based on the lockout message you were getting, I think the WP user account got locked out. This is a direct consequence of your site leaking user accounts …

Botnets that perform automated brute force attacks prefer to do so on sites that leak user accounts. In such cases only the password needs to be brute forced.

Using the iTSec plugin you should perform the following steps:

• First of all permanently whitelist your IP in the Global Settings module. This will prevent you from getting locked out.
  Note this is only usefull when using a fixed client IP address.
• Ensure with the Security Check module that your site is using the recommended features and settings.
• Enable the Force Unique Nickname and Disable Extra User Archives settings (if not already enabled) in the WordPress Tweaks module.
  Note you will still need to add a unique Nickname (which is not equal to the user account) to all existing users.
  This will help in preventing your site leaking user accounts.
• Rename your ‘admin’ user in the (Advanced) Admin User module. Make a database backup before using this feature !
  NEVER EVER use an ‘admin’ user account.
  (This was probably the locked out user account).
• Enable the Hide Backend setting in the (Advanced) Hide Backend module. Specify a unique Login Slug.

Basically properly configure the iTSec plugin.

dwinden

@gadgetcoma

If you require no further assistance please mark this topic as ‘resolved’.

dwinden