dwinden

@saconi

After I change de admin by configurations of this plugin …

Are you referring to the Change Admin User feature on the iTSec plugin Advanced page ?

If so I think there is some sort of conflict with your WordPress env.
Could be related to using an asterisk (*) in the user name which is normally not allowed in WordPress.

When I try to create a new user “sacon*” I get the following error:

ERROR: This username is invalid because it uses illegal characters. Please enter a valid username.

dwinden

@jontaarcs

Thank you for providing that info.

I’m taking a closer look into this. Would it be possible for you to email me at [ redacted, support is not offered via email, Skype, IM etc. only in the forums ]

Thanks,

dwinden

@matt Sweeney

It is possible to manually edit the .htaccess file and remove the entire iTSec security section. Or perhaps a previous .htaccess file was restored from a backup.
But as soon as you save settings in the iTSec plugin the Rewrite Rules should be present again in the .htaccess file.

You just changed the Front End SSL Mode setting back to its default value (Off) and saved … so I now expect the Rewrite Rules to be present in the .htaccess file.

Last thing you could try is to temporarily deactivate the iTSec plugin and see whether that resolves the issue. This will tell us whether using the iTSec plugin indeed causes the issue.

dwinden

@eic2010

Keep in mind there are 2 brute force attack vectors.

The most common one is wp-login.php. Enabling the Hide Backend feature will not only make your login slug a secret but it will also block wp-login.php login attempts.

The other one is xmlrpc.php. You can disable xmlrpc from the WordPress Tweaks section on the iTSec plugin Settings page.

Ideally you should have a look at the Apache web server error_log to determin which of the 2 above mentioned brute force attack methods is used to attack your site (perhaps even both).

If there are many many wp-login.php request entries in the error_log enabling the Hide Backend feature will protect you against the current brute force attack(s).

If there are many many xmlrpc.php request entries in the error_log disabling xmlrpc will protect you against the current brute force attack(s). Note there is also an advanced xmlrpc brute force attack where there is only one xmlrpc.php request logged while in fact that single request contains a multiple login attempts payload.

What I’m trying to say is that it is best to analyze how these brute force attacks are currently being executed upon your site. This will help in determining the best way to counteract the current brute force attacks.

Once you are back in control you can decide to further strengthen your site’s security.

dwinden

@matt Sweeney

Please post the content of your .htaccess file while obscuring any sensitive info.

dwinden

@jontaarcs

Ok, I see.

Once the 404 log record is created in the log table I think it makes no difference whether using the iTSec release 5.3.3 or 5.3.4.
Just wanted to make sure you are on a recent release.

What browser and what version of that browser are you using ?

dwinden

@mallory Destiny

All that the 404 Detection feature of the iTSec plugin does is log any 404s triggered in WordPress.
The reason why WordPress triggers a 404 has nothing to do with the iTSec plugin … In other words you are barking up the wrong tree …

So if you prefer to stay ignorant of what is happening to your site and don’t want to see all those 404 entries getting registered in the iTSec plugin log simply disable the iTSec plugin 404 Detection feature.

If you want to learn how to stop googlebot asap from crawling links that result in a 404 start Googling. The answer to your question is out there …

dwinden