Hello,
What’s the security plugin you used? I have had issues in the past where even deactivating a plugin leaves this kind of setting in place, it may for example have edited your .htaccess file and added a rule in there.
Question though – do you know what you changed the login URL to? And if so can you try restoring the plugin folder name and logging in with that initially?
Cheers,
Also, if you’re looking at security you will really want to get SSL / https set up for your site.
This is easily achievable for free now and two good options are:
Hi @dominic_ks the plugin is iThemes Security; If I try to enable again the plugin and to visit the custom login page, the web site give me the same 404 error 🙁
Hi,
Please check this.
They have mentioned a way to disable all the features.
I hope this will help you.
Hmm OK, I just tested this and noted two things:
- When iThemes redirects to a 404 / 403 you normally specify a url to forward to, the default is /not_found, your site isn’t doing this
- When I rename the iThemes plugin folder, the hidden backend setting is ignored and I can login is normal with /wp-admin or /wp-login.php, as you expected yours to do
I then noticed that when trying to visit:
I am redirected here:
And this seems to generate a genuine 404. If I navigate to:
I get an infinite redirect error, which also looks genuine.
So… my feeling right now is that the current issue is probably not caused by the iThemes plugin or your attempt to hide the login area. Though, you can add this to your config.php to ensure that iThemes is definitely disabled:
define( 'ITSEC_DISABLE_MODULES', true );
First off, I would double check that the /wp-login.php file is in fact there and in tact, I suspect it is, but good to check.
You can have a look at something like this to help here:
Hi, thank you for your support @dominic_ks @prashantvatsh !!
I followed the istructions in the link of @dominic_ks and I found that was a problem of .htaccess
Now it does seems everything ok 🙂
Thanks a lot!
Awesome. Seems to have been a bit of a spike in hacked sites recently, glad you’re back up and running!
Side note, I’ve been an iThemes user for a long time and it is definitely a great plugin. Using the hide your back end features in combo with locking people out for things like too many 404s is a great set as it can lock out offending bots quite quickly for typical brute force login events.
Also keeping an eye on your server logs for any user agents you don’t care to support is also a good one, can save you a fair bit of bandwidth as well.
Also keeping an eye on your server logs for any user agents you don’t care to support is also a good one, can save you a fair bit of bandwidth as well.
Good advice @dominic_ks ; how can I do that? 🙂
Exactly how you would do it will depend on your hosting. I use Plesk as a web server panel and one of the good things about it is the logs are really easy to use. Check this image example out, there should be SOMETHING similar on any host IF you have access to the logs, on shared hosting for example, you might not.
Here you can see a couple of example user agents, these two, from Bing and Yandex, you may well choose to allow because they’re probably keeping their search engine results up to date.
You can then block these in iThemes settings in the Banned Users section. For example, here is a list I choose to block because I happen to have been alerted to them after receiving alerts that my server had high resource usage and found these to be crawling sites on the server.
Some people may well have reason to say don’t block these, so I suggest researching any and deciding for yourself what action to take:
- MJ12bot
- AhrefsBot
- dotbot
- BUbiNG
- Baiduspider
- VelenPublicWebCrawler
As an example, I block AhrefsBot because I don’t use ahrefs and I don’t particularly feel like providing bandwidth to have my site crawled only to potentially make that data available to assist a competitor in doing better against me. As an example!
