pronl
Forum Replies Created
-
Irregardless who the hosting company is, this is clearly a false positive.
Open the file and all you’ll see is 30000 ranked plain text passwords …
Even better, read the wp-content/plugins/better-wp-security/core/lib/itsec-zxcvbn-php/readme.md file and learn what zxcvbn uses it for …
System Files protection doesn’t work if WordPress is installed to sub directory.
Actually it works when WordPress is initially installed in a subdirectory.
What you are saying is that it doesn’t work when WordPress is initially installed in the root AND then moved to it’s own sub directory as described in Method II of
https://codex.www.ads-software.com/Giving_WordPress_Its_Own_DirectoryWhat happens when you temporarily change the line below in .htaccess file:
RewriteRule ^wp-admin/includes/ - [F]to:
RewriteRule ^(wp/)?wp-admin/includes/ - [F]- This reply was modified 7 years, 7 months ago by pronl.
Issue 1
Ok, so you have manually added an exception for plugin file signaturesave.php in the .htaccess file.
This basically means anyone can access that file with a direct http request:
https://www.example.com/wp-content/plugins/pluginname/contracts/signaturesave.php
YOU MUST BE 100% SURE THIS PHP FILE DOES NOT CONTAIN ANY EXPLOITABLE VULNERABILITIES !
Secondly: Since you manually added an exception to the .htaccess file, as soon as the iTSec plugin regenerates the content of the .htaccess file your edit will be lost. This will happen for sure when you decide to change a setting (which writes to the .htaccess file) in the iTSec plugin and save. Depending on your plugins settings the iTSec plugin might even regenerate the content of the .htaccess file without you ever touching anything…(this happens when an IP is fully automatically banned).
In such cases, in order to keep the edit you’ll need to add the extra .htaccess rule to the plugin code. So that requires a code change in the plugin. Not very complicated but that code change will also be lost when updating the plugin …
Hard coding an exception is not a flexible solution anyway …The simplest solution is to disable the plugin feature in the System Tweaks module.
Disadvantage is that your site is a little bit less secure. Not a big deal if you are using well written/secure and reputable plugins …Another route is to request a feature at iThemes.
It’s basically an enhancement request that offers anyone the flexibility to add/remove exceptions to the System Tweaks module PHP in Plugins feature from the iTSec plugin Dashboard UI. And/or provide a filter that other plugin developers can hook into.
Before doing so note that the System Tweaks module PHP in Plugins feature is a fallback security mechanism.
If you are using well written/secure and reputable plugins there is no need to block direct access to PHP files from the plugins folder.Issue 2
To be continued should you be interested ??Ah right, I assumed you were already on the latest release.
Never mind how the link is being generated. The format confirms it’s probably done by a call to the get_edit_post_post() function.
So indeed test after updating the plugin.
The Hide Backend feature has totally been refactored ??
List all servers with:
- OS
- PHP version
- Web Server (version)
- PHP directive open_basedir set or not.
Particularly interested in the info from the newest production server.
The one generating the 500 internal server error.If it does it will probably fail on the next similar require_once() command …
So I figured to instead make a modification in the get_core_dir() method:
return self::get_plugin_dir() . 'core/';to:
return self::get_plugin_dir() . 'core';Turns out the result of the get_core_dir() method is concatenated with strings starting with a slash as well as with strings NOT starting with a slash … (what a mess).
Still a better option to test this new modification since the get_core_dir() method concatenates with strings starting with a slash (far) more often. So even with this new modification it will still fail somewhere further down the stack …
Anyway perhaps we should focus on why this is failing in your env while it works fine in other envs. Could be Windows specific … Perhaps related to the PHP/Web Server version being used …
Oh I should mention that mixing the directory separator (\ and /) in a path is no problem. PHP can deal with that on a Windows platform. It’s the // I’m focusing on.
Make a backup copy of the core.php file.
Then remove the leading ‘/’ from ‘/lib/class-itsec-lib-directory.php’ so it looks like this:
require_once( self::get_core_dir() . ‘lib/class-itsec-lib-directory.php’ );Does that make any difference ?
Ok, I see. Probably the 404 Detection module that triggered 2 temporary lockouts on the CDN IP and on third banned the IP permanently.
Simply add the CDN IP(s) to the Lockout White List setting in the Global Settings module.
Please ignore the following part of the descriptive text underneath the Lockout White List box:
… and will only prevent a temporary ban. Should a permanent ban be triggered you will still be added to the “Ban Users” list unless the IP address is also white listed in that section.
It’s bulls*t ??
The whitelist prevents temporary lockouts for the whitelisted IPs. No (temporary) lockouts means no (permanent) ban.
There is probably something in the .htaccess file that is blocking those images.
In order to find out which plugin feature writes the rule(s) that causes the issue you could try and disable the plugin features that add rules to the .htaccess file.
In the 6.1.1 plugin release there are 4 modules that write to the .htaccess file.
Start by disabling (if not already) the Default Blacklist (HackRepair.com’s blacklist) setting in the Banned Users module.
Next if the Ban Lists setting is enabled temporarily save any banned IP addresses listed in the Ban Hosts box. This will allow you to add the IPs back later on in case removing them makes no difference.
Do the same for any User Agents listed in the Ban User Agents box.If that doesn’t help move on to the next module: Hide Backend
Disable this module.If that doesn’t help move on to the next module: System Tweaks
Disable all the settings one by one. You could disable the module but if the culprit is in this module you still don’t know which setting is causing havoc.Still no luck, move on to the next module: WordPress Tweaks
Only the Comment Spam and XML-RPC settings write to the .htaccess file. So disable those 2.If done properly, by this time the plugin will not write any rules into the .htaccess file. You can doublecheck by navigating to the Advanced page and then clickin on the Show Details button of the Server Config Rules module. There should be no rules visible there.
- This reply was modified 7 years, 8 months ago by pronl.
I’m a bit puzzled by this.
/wp-admin/my-post doesn’t look like a proper link for editing a post.
(I would expect something like wp-admin/post.php?post=1&action=edit).Is the user supposed to enter the Admin Dashboard to edit the (edited) post ?
Or is the user supposed to simply read the (edited) post in the frontend ?
(Probably not).Also: how does the plugin generate the post link URL in the email ? What WordPress function is used by the other plugin to generate the post link URL ? get_edit_post_link() ? Or perhaps it’s hard coded …
Assuming wp-admin/post.php?post=1&action=edit is the correct link URL format for editing a post, adding &itsec-hb-token=[slug] as an extra parameter to the URL (where [slug] should be substituted with the Hide Backend login slug) would probably make the link work (in a non logged in situation). That is it would redirect to the login screen and add a redirect_to URL parameter …
After logging in the user is then auto redirected to the edit post screen within the Admin Dashboard.
You can actually test this. Simply copy/paste the URL from the email link into the browser address bar and then manually add the extra URL parameter. Just to see what happens. Make sure the user is not already logged in AND the Hide Backend cookie (itsec-hb-login-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) is not set in the browser …Not offering this as a solution, but trying to understand what’s happening and thinking towards a solution ??
- This reply was modified 7 years, 8 months ago by pronl.
Assuming this is about adding a blocking rule to the The HackRepair.com’s blacklist, the HackRepair.com’s blacklist is supposed to be a starting point … Bots come and go, the list cannot include every bot all the time …
Try and contact the author of the HackRepair.com’s blacklist (Jim Walker).
Once you succeed in getting it in his master list iThemes will probably follow.
spbot doesn’t look like a bad bot. It respects the robots.txt file … so it may not qualify for inclusion.Anyway you can block any additional bot(s) in the Ban User Agents field.
Something else: Are you sure it’s the official spbot crawling your site ? Got this from their site:
How can I verify spbot is really spbot?
Other web crawlers can spoof the spbot user agent to make them seem legitimate. They seem to be coming from us but they don’t. You can verify the IP addresses to make sure that the spbot that visits your site is actually from OpenLinkProfiler.org. We’re currently using the hosting company Digital Ocean for our crawlers.
A list of IP addresses is included on their site.
- This reply was modified 7 years, 8 months ago by pronl.
You may not be experiencing the issue at this moment but as you are using 6.2.1 the issue may return any moment.
The only way to fix this issue permanently is to update the plugin to 6.3.0.
Update the plugin to 6.3.0, test the Hide Backend feature in Chrome and if the issue does not reappear please mark this topic as resolved ??
My understanding is that the 6.3.0 plugin update which was released last week includes a totally refactored Hide Backend feature.
As a result one of the old Hide Backend hooks/functions (auth_cookie_expired) which probably caused the ERR_RESPONSE_HEADERS_TOO_BIG error (due to an infinite loop) is no longer present.
You’ll find the following related entry in the 6.3.0 changelog:
Bug Fix: Fixed an infinite loop that could occur when expiring a cookie and Hide Backend is enabled.
Not sure why this only seemed to affect Chrome …
Anyway I guess you’ll need to check whether the issue vanished after applying the lastest plugin update (6.3.0) …
- This reply was modified 7 years, 8 months ago by pronl.
Just wanted to add that the 6.3.0 update released yesterday introduces the ITSEC_DISABLE_MODULES constant. As per the ChangeLog:
New Feature: Added support for the ITSEC_DISABLE_MODULES define.
And filtered this text snippet from inside the code (core.php):
* Check to see if the define to disable all active modules is set.
*
* Note that the ITSEC_DISABLE_MODULES should only be used to gain access to a site that you are locked out of.
* Once logged in, you should remove the define to re-enable the protections offered by iThemes Security.Adding it to the wp-config.php file like so:
define('ITSEC_DISABLE_MODULES', true);is just another way to deal with accidental lockouts.
Do note the plugin will add the following warning on top of ALL pages once logged into the Admin Dashboard:
The ITSEC_DISABLE_MODULES define is set. All iThemes Security protections are disabled. Please make the necessary settings changes and remove the define as quickly as possible.
- This reply was modified 7 years, 8 months ago by pronl.
Let’s just say I’m a knowledgeable person heavily interested in WordPress security.
iThemes has fixed other bugs in the lockout code in the past, so I’m sure they’ll fix any of the ones that still exist as well as soon as they pop up on their radar.
Do lockouts still expire and get purged if the “Permanent ban” option is set?
Yes, they do.
Allthough, once IPs are banned (in the .htaccess file) they are banned forever unless you decide to remove them from the Ban Hosts setting.
Removing a banned IP from the Ban Hosts setting will remove the banned IP entry in the .htaccess file.So basically lockouts are temporary and bans are (sort of) permanent.
If you whitelist your IP no lockouts will occur and no ban can happen on your IP.
(Or at least thats how it is supposed to work).
In fact the plugin automatically whitelists anyones IP that successfully logs into the WordPress Dashboard as an administrator. The only difference is that it’s a temporary whitelist that is set to expire in 24 hours.The plugin creates 3 tables in your database:
[prefix_]itsec_log
[prefix_]itsec_lockouts
[prefix_]itsec_tempWhere [prefix_] should be substituted with your database table prefix.
So when you manually clear the [prefix_]itsec_lockouts table, make sure to clear the [prefix_]itsec_temp as well.
That way your manual action is similar to what the itsec_purge_lockouts cron job does.