Forum Replies Created

Viewing 15 replies - 1 through 15 (of 493 total)
  • nlpro

    (@nlpro)

    If it exists try and manually delete the itsec_file_change_scan_destroyed option from the wp_options table in your database.

    To prevent any confusion, I’m not iThemes.

    • This reply was modified 1 day ago by nlpro.

    Looks like the data from the previous scan is not persisted in the database. Normally subsequent scans will compare with data collected during the previous scan.

    In other words any new scan is now comparing with the same stored file list/hashes over and over again … that may indicate a database issue.

    So check for any errors in the database log.

    • This reply was modified 1 day, 23 hours ago by nlpro.

    There is a difference in getting locked out (temporarily, expires by default after 15 minutes which is configurable) or getting banned (permanently).

    Likewise there are different places in the iTSec plugin UI where you can release/undo lockouts/bans.

    It seems you’ve already found where to undo permanent bans, but you haven’t yet figured out where to release lockouts.

    Lockouts can be released (before they auto expire) from the Active Lockouts side widget. Simply navigate to the Security/Settings page and notice the bunch of advertorial side widgets on the right of the page. Now scroll down and you’ll find the Active Lockouts widget somewhere buried among those advertorial widgets. Usually the widget is empty. If your site is as busy as you say it is there is a good chance your widget will show some lockouts. But remember lockouts do also auto expire …

    Also note there have been significant changes to the lockout API in a recent plugin release (for details read the Changelog). Usually new code also introduces new bugs.

    To prevent any confusion, I’m not iThemes.

    nlpro

    (@nlpro)

    FYI

    According to the iTSec Pro 6.3.3 Changelog:

    Bug Fix: Backup event was not added when the WP Cron Scheduler was reset manually.

    Note this bug fix is not yet implemented in the free plugin.

    To prevent any confusion, I’m not iThemes.

    Sounds like a PHP configuration issue. So perhaps an idea to provide some context like PHP version and PHP settings.

    Or even better, provide a reproducable testcase.

    To prevent any confusion, I’m not iThemes.

    If you have any questions or concerns over this Privacy Policy, or wish to exercise any of your statutory rights, please contact us at:

    iThemes Privacy Matters
    c/o Liquid Web, LLC
    Attn: Director of Security
    2703 Ena Drive
    Lansing, MI 48917
    USA
    Email – privacy@ithemes.com

    To prevent any confusion, I’m not iThemes.

    • This reply was modified 2 weeks, 1 day ago by nlpro.

    If no changes were made to resolve the issue, chances are the issue will return in the future. Anyway this topic should be marked as Resolved for now.

    • This reply was modified 2 weeks, 2 days ago by nlpro.

    For support about a feature (reCAPTCHA) from the Pro (premium) plugin you should contact iThemes here or log in to your iThemes Member Panel and click the “Support” tab.

    This Support Forum is only providing community support for the free plugin.

    That said, I noticed your site is using the iTSec Pro 5.5.8 release (2018-12-11).
    You seriously need to update the iTSec Pro plugin to the latest release. No guarantees it will solve your issue but it’s always best to run the latest plugin release…

    Ah, it seems it wasn’t about the WordPress register page after all.

    I just noticed your link seems to be working fine now. Apparently resolved by doing a HTTP redirect (302) to a “subscription” page.

    Thanks for sharing that solution with the community (not) 😉

    There have been a couple of changes in the latest iTSec plugin releases that may affect this (lockouts and IP detection).

    Not exactly sure what is happening. https://www.domain.com/register is usually not a default WP registration URL AFAIK. The default WP registration URL is https://www.domain.com/wp-login.url?action=register which seems to be working fine on your site.

    The default “ERROR” msg (which can be customized) indicates a HOST (IP) lockout. Usually a HOST lockout is triggered by too many invalid login attempts or too many 404’s within a certain time period.

    Is the iTSec plugin 404 Detection module enabled ?

    Anyway, without any further information it’s hard to figure this out.
    It could be a bug. It’s probably best to have a look at the iTSec plugin Logs page.

    To prevent any confusion, I’m not iThemes.

    • This reply was modified 3 weeks, 3 days ago by nlpro.

    Actually the File Change Detection module received some interesting updates in the past that addressed several issues.

    If you are running the Free version of this plugin then it is up to you to determin whether any reported file changes are malicious. The free plugin will not do this for you.

    However the Pro plugin includes an extra setting named Compare Files Online. Below the full description of that setting (copy/paste from the latest release of the Pro plugin):

    When any WordPress core file or file in an iThemes plugin or theme has been changed on your system, this feature will compare it with the version on WordPress.org or iThemes (as appropriate) to determine if the change was malicious. Currently this feature only works with WordPress core files and plugins and themes by iThemes (plugins and themes from other sources will be added as available).

    Turns out the description has not been updated in the past. According to the Pro 4.7.4 Changelog:

    New Feature: Online Files Comparison now supports WordPress.org plugins.

    So the Pro feature is doing more than the current setting description makes you think…

    The bottom line is that the Pro plugin will filter any file changes and only report the ones the plugin thinks are malicious. Pretty neat ! Less noise.

    I can access the login page fine now where I couldn’t earlier …

    So my suggestion certainly helped.

    To restore access, temporarily add the line below to the wp-config.php file:

    define('ITSEC_DISABLE_MODULES', true);

    Once logged in, disable the iTSec plugin Hide Backend module. Then undo the change in the wp-config.php file.

    To prevent any confusion, I’m not iThemes.

    That doesn’t make any sense. According to the 7.6.1 Changelog:

    Bug Fix: Properly notate that iThemes Security requires PHP 5.5 or greater.

    7.6.0 and 7.6.1 codebase is for 99.99999% identical …

    Have a look at the minimal changes yourself here.

    To prevent any confusion, I’m not iThemes.

    nlpro

    (@nlpro)

    Good to hear you were able to figure out the WSOD situation.

    IMHO (but I could certainly be wrong) locked files in this specific WordPress install may have been the root cause. You said yourself updating worked fine on other WordPress installs sharing the same server.

    It’s highly unlikely updating the iTSec plugin was the culprit. Based on the error you noticed during the iTSec plugin update it’s more likely that files were locked (maybe by the web server or something else). In fact I think the iTSec plugin (while updating) was the first to identify there was a file locking problem in this env …

    Just out of curiosity, was this on a Linux or Windows based server ?

    Anyway you should not blame a plugin without a thorough investigation and a solid and reproducible test case.

Viewing 15 replies - 1 through 15 (of 493 total)