• Prior to today iThemes reported no changed files except those due to plugin updates. This reflected that of another security plugin.
    Today though I got the following error:
    id => 21107
    module => file_change
    type => fatal
    code => file-scan-aborted
    timestamp => 2019-01-29 01:40:32
    init_timestamp => 2019-01-29 01:40:31
    remote_ip => x.x.x.x.
    user_id => [empty string]
    url => https://www.sitename_here.com/
    memory_current => 48702456
    memory_peak => 48848352
    data => Array
    id => file-change
    step => get-files
    chunk => plugins

    {NOTE: I have removed the site name and IP address from above]
    The next attempted scan resulted in
    0 Added, 2123 Removed, 2 Changed

    The files that iThemes said are removed are still on the site. In otherwords this is a totally bogus report.

    Prior to today the scan showed
    0 Added, 0 Removed, 2 Changed

Viewing 15 replies - 1 through 15 (of 19 total)
  • You may find my last post in this topic interesting.

    The iTSec plugin handles scheduled tasks using WP Cron (default and preferred) or on any page request to the site (frontend or backend).

    Since the plugin by default runs tasks (like file change detection) using WP Cron, the url => https://www.sitename_here.com/ part may be an indication of “inconsistant cron scheduling”. It indicates the failed task was actually run on a page request…(and not WP Cron).

    Once a scan fails the result of the next scan is incorrect.

    I suspect the bug causing the issue is fixed in the Pro plugin. Unfortunately that fix has not yet been incorporated into the Free 7.2.0 release.

    So it looks like we will have to wait for the next free plugin update.

    Thread Starter frustrated999

    (@frustrated999)

    Yes thankfully I do not rely solely on only on iThemes for security reporting since I saw this exact behavior months ago. The first time I wasted time thinking it was a valid alert.

    Thread Starter frustrated999

    (@frustrated999)

    Just like the last time this happened with this extension today I got an email indicating several thousand files were added to the site. Sigh,

    Thread Starter frustrated999

    (@frustrated999)

    3 weeks later another 1468 files deleted. My god how long does it take them to roll out this fix to the free version of the plugin. Thank goodness I have more than this security plugin installed. It seems that someone “abc” in that other thread is also seeing this occurring at about the same time on their site as well

    • This reply was modified 5 years, 9 months ago by frustrated999.

    The fix I mentioned in an earlier post is included in the 7.3.0 release which was made available 4 days ago.

    If you have already updated to the 7.3.0 release and the issue persists you might try and add the entry below to the wp-config.php file:

    define('ITSEC_USE_CRON', true);

    This will force the iTSec plugin to only use WP Cron for processing scheduled tasks.
    No guarantees, there may still very well be bugs in the File Change scanning code.
    (I know for sure a Windows platform specific bug still exists …)

    Thread Starter frustrated999

    (@frustrated999)

    Yes it was already using 7.3.0 so I added that line into wp-config file.

    Thread Starter frustrated999

    (@frustrated999)

    Well that implementation caused both sites to load at all. I had to comment it out of the wp-config.php file. Both sites are also using Cloudflare by the way

    Hmm, weird. No errors ?
    Difficult to say what’s bugging these envs.

    The iTSec plugin includes a debug page, but it must also be enabled in the wp-config.php file, very similar to how forcing the plugin to use only WP Cron for scheduled tasks is configured:

    define('ITSEC_DEBUG', true );

    Once ITSEC_DEBUG is (properly) set to true you’ll notice a new Debug entry under the Security menu. Once in the debug page, the Scheduler section gives you an overview of scheduled iTSec plugin tasks. Interesting to see what’s listed there.

    Notice there is also the possibility to Reset the ITSEC_Scheduler_Cron underneath the section. But let’s first have a look at the Scheduler list.

    Thread Starter frustrated999

    (@frustrated999)

    // BEGIN iThemes Security - Do not modify or remove this line
    // iThemes Security Config Details: 2
    define( 'DISALLOW_FILE_EDIT', true ); // Disable File Editor - Security > Settings > WordPress Tweaks > File Editor
    // END iThemes Security - Do not modify or remove this line
    
    //02_19_19 added to fix iThemes Security from flagging files as being deleted when they are not 
    //define('ITSEC_USE_CRON', true);
    

    That is what is in my wp-config.php file for one site. If I uncomment the line
    define('ITSEC_USE_CRON', true);

    then the site refuses to display at all. I had to FTP in this morning and comment the line out. Same with the other website. I only had added that define('ITSEC_USE_CRON', true); to the file nothing more about 2 days ago.

    Let me try something and I will update this post in a day or so.

    • This reply was modified 5 years, 9 months ago by frustrated999.

    The syntax of the line is fine, though I would prefer to place it much further down the wp-config.php file like this:

    define( 'WP_DEBUG', false );
    
    // 02_19_19 added to fix iThemes Security from flagging files as being deleted when they are not
    define( 'ITSEC_USE_CRON', true );
    
    // 02_21_19 Enable/disable iTSec plugin Debug page
    define( 'ITSEC_DEBUG', true );
    
    /* That's all, stop editing! Happy publishing. */

    Basically place the new entries between the existing
    define( 'WP_DEBUG' ...
    and
    /* That’s all, ...
    lines.

    Do note, manually editing the wp-config.php file is considered risky business. A tiny mistake can render a site useless.

    Thread Starter frustrated999

    (@frustrated999)

    Ok uncommented one the initial suggestion for one of the sites and added the define(‘ITSEC_DEBUG’, true ); This is what it shows for jobs

    iTSec chron

    Ok, the screenshot shows no cron jobs at all.
    So I guess it’s time to hit that Reset button I mentioned earlier.

    Thread Starter frustrated999

    (@frustrated999)

    Ok hit the reset on that site and there are these jobs scheduled to run. Will see if the plugin is any more stable and reliable using this method.

    backup 2019-02-26 20:15:19 (1 min) backup
    clear-locks 2019-02-26 20:25:19 (11 mins) daily
    purge-lockouts 2019-02-26 20:30:19 (16 mins) daily
    purge-log-entries 2019-02-26 20:35:19 (21 mins) daily

    So there is still no file-change cron job scheduled ?
    If the File Change Detection module is still enabled there should be a file-change cron job scheduled.

    Thread Starter frustrated999

    (@frustrated999)

    Ya it was enabled but would not show up. Had to disable it and re-enable it. It now shows up in the schedule under Debug.

    Had so much issue with the plugin throwing errors in the past I had given up on it for a while.

Viewing 15 replies - 1 through 15 (of 19 total)
  • The topic ‘Failed scan = thousands of changed file alert’ is closed to new replies.