dwinden
Forum Replies Created
-
Are you a long time iTSec plugin user or did you recently download and install the latest iTSec plugin release ? (This is a very relevant question!).
Anyway, make sure the Enable local brute force protection setting is enabled on the settings page.
In the same Brute Force Protection section make sure the Immediately ban a host that attempts to login using the “admin” username. setting is enabled.Also make sure the Enable ban users setting is enabled in the Banned Users section of the Settings page.
dwinden
What Apache Web Server version are you using ? (1.3.x, 2.2.x or 2.4.x).
Try and disable the HackRepair.com blacklist feature and see whether that makes any difference.
If it does I’ll refer you to another topic that will probably help you resolve the issue.
dwinden
You might find an answers to your question in this topic.
Note as of the 5.2.0 release memory is set to 256 MB by the backup feature. The 5.2.0 changelog mentions this:
Enhancement: Updated the Database Backup feature to attempt a max memory limit of 256M rather than 128M as some users experience out of memory issues which could be fixed with the higher memory limit.
dwinden
There is a big misunderstanding among WordPress website owners where they think their website is 100% protected when using a security plugin like the iTSec plugin.
In reality such security plugins (if properly configured) only make it harder for hackers/botnets to hack WordPress sites. It’s basically risk management. So 100% protection simply does not exist.For example if there is a core vulnerability in WordPress and you haven’t updated it to the latest release, a security plugin (like the iTSec plugin or any other plugin) won’t prevent your site from getting hacked.
There are some WordPress security guidelines to follow that will minimize the risk of getting hacked. A lot depends on YOU following those guidelines.
And then still you’ll never reach 100% protection.
So ALWAYS have a recent backup!dwinden
Weird, the reset should work.
Tested it to be sure and yep reset definately still works.Well anyway, thought to spare you deleting and reinstalling the plugin.
Kept that as a last resort. But you figured that out on your own.Well done 😉
Please take a moment to mark this topic as ‘resolved’.
dwinden
The reset should work.
Don’t use the info from the email that you received.Use the info from my post in this topic on the forum.
My initial post contained an error which I corrected.
Unfortunately corrections to a post don’t get emailed again.dwinden
Expires in 19 years !! The default is 15 minutes !
How is that possible ?
Please make sure you have the right Time Zone set in WordPress.Anyway it seems the host lockouts are caused by too many 404s.
Disable 404 Detection to prevent the host lockouts.To reset the iTSec plugin add the following line to the wp-config.php file:
define(‘ITSEC_DEVELOPMENT’, true);
Add this line right after: define(‘WP_DEBUG’, false);
Then deactivate the iTSec plugin and reactivate it.
This will delete and then recreate the 3 iTSec plugin tables in the database.IMPORTANT: REMOVE the ITSEC_DEVELOPMENT line from wp-config.php afterwards !!
dwinden
I think a post like this belongs in the forum. This is no review.
Anyway there are several things you can do.
To disable (deactivate) the plugin simply rename the better-wp-security folder.
Can you be more specific in regard to “server 500 error with a misconfiguration message” ?
The Internal server error 500 msg is often caused by something in the .htaccess file. First create a copy of the .htaccess file. Then remove everything between these lines:
# BEGIN iThemes Security – Do not modify or remove this line
…
# END iThemes Security – Do not modify or remove this lineAnd then see whether that allows you to access the website again.
If so you could start adding iTSec .htaccess conf lines back per feature to figure out which one breaks your site.
dwinden
Never mind. It seems Gerroald has already taken care of marking this topic as ‘resolved’.
dwinden
I’m not even going to respond to your interpretation of certain parts in my previous post. It’s that ridiculous … By the way I think you should realize I’m not iThemes …
So don’t confuse my opinion as being the opinion from the plugin authors … Or to put it otherwise, using my opinion as an extra argument to stop using this plugin is not a very intelligent thing to do …
I’m just a fellow trying to help out others who have troubles using this plugin.
I do believe your opinion as expressed in your initial post is mainly the result of your emotion. And I fully understand that. However by now I expected less emotional content in your second post. But it seems you’re still so upset that using common sense is too much asked for.I think I confirmed in my previous post there may be problems happening when running this plugin. I don’t recall denying your issue …
What do you want me to say ? Yeah this plugin is a piece of junk ! Don’t use it. That would not be very constructive …Anyway this plugin only writes to the wp-config.php and\or .htaccess (or nginx.conf) files because YOU configured it that way. Also as far as I know it doesn’t write to any other config files … So what “and some other files” did the iTSec plugin overwrite ?
Try and provide the info we need to get to the bottom of this. Just stating it zerod out “some other files” is not very constructive.
I think there are probably very specific circumstances that caused the issue. Let’s take emotion out of the equation and get to the bottom of it.
If a proper investigation reveals the plugin did something stupid I’ll be the first to shout: What a piece of junk ! 😉
And after all the emotion is over we’ll report what’s wrong to the plugin authors so that they can fix it.Does that sound like a solid plan to you ?
dwinden
Nice to hear this mystery finally got resolved.
I feel the responsibility for this “vulnerability” lies more at the hosting provider (web server configuration) than at the web application layer (WordPress\iTSec plugin).
The Apache Multiviews option is not enabled by default. So it needs to be explicitly enabled by the hosting provider. This indicates that it is not an option without risks.
From what I’ve read on the internet Multiviews seems to have a HUGE performance impact. And it seems websites are also not properly indexed by Google.
So it seems to me that for a proper hosting provider it would make much more sense to not enable the Apache Multiviews option by default. If you do need it you can always enable it per directory in the .htaccess file (provided the AllowOverride is set properly).
dwinden
@falk Wussow
Ok, I see.
It looks like the temporarily whitelisted IP address is completely ignored when a lockout is triggered.
The is_ip_whitelisted() function has been rewritten as well as moved from the ITSEC_Lockout (class-itsec-lockout.php) class to the ITSEC_Lib (class-itsec-lib.php) class. This was probably part of the changes made to include support for IPv6. So I guess this got broken (or perhaps better: forgotten) in the 5.3.0 and higher releases.
As a workaround whitelist your IP address permanently in the Global Settings section on the Settings page. Untested (yet) but I expect it to work.
dwinden
@falk Wussow
Ok, that makes it sound like some sort of Web Server configuration issue.
I think you are right. http://www.100son.net/wp-signup also works (Though it currently redirects to the login screen as registration is disabled).
Normally this url would result in a 404.@css1
Ask your hosting provider.dwinden
Is this issue present on multiple WP websites hosted at the same hosting provider ?
Or does the issue occur across multiple hosting providers ?
You may have to post a new topic in the WordPress forum.
The question is: where does the wp-login slug come from on some WP envs ?
It’s basically not related to the iTSec plugin.dwinden