Support » Plugin: iThemes Security (formerly Better WP Security) » I no longer receive “File change warning” emails

  • pierreripka

    (@pierreripka)


    Hello,

    I manage more than 100 WordPress sites with iThemes Security and I usually receive these “file change warning” emails daily, especially after WP/plugin updates.

    But I have not received a single one since March 2, 2018. I think this coincides with an iThemes Security update (maybe 6.9.0, not sure). I currently have the most recent version (6.9.2) on each of these sites.

    Has anyone else observed this problem? How to solve it?

    Note that I manage in parallel another site with a very old version of WordPress (3.4.1) and iThemes Security (4.3.9), and this one stills send me these emails quite normally. So I think it’s not a problem with my inbox.

    I hope to find a solution because it’s a real security problem, I can’t go check the logs of each site, it takes too much time… So for now I just hope nobody took the opportunity to edit my files.

    Edit: I specify that I still receive the other emails (lockouts alerts) without any problem, and that the notification center is correctly configured. File changes are correctly detected in the logs.

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

    (@nlpro)

    It seems this bug was introduced in the 6.9.0 release. Weird noone else reported it yet …

    Please check in the Logs page whether the affected File Change Detection scan(s) are scheduled ones (probably).

    Simply click on the Show Details link and check the Url field value.

    Scheduled scan values are:

    – “WP-Cron Scheduled Task”
    – Any url that is not pointing to the admin-ajax.php file (that’s a manual scan).

    There is another issue with the plugin not hooking properly into WP-Cron so I expect you’ll probably see the second listed above as Url value. It’s basically the url that kicked off the scheduled scan. It can be a frontend url as well as a backend url.

    It seems the line below is MANDATORY in the wp-config.php file for the plugin to properly hook into WP-Cron:

    define(‘ITSEC_USE_CRON’, true);

    After adding it to the wp-config.php file wait for at least a day (24 hours) then deactivate/activate the plugin. That will make the plugin hook properly into WP-Cron. From that moment on you should see the first as Url value in the Logs page. It’s not going to fix the email issue, but you want WP-Cron to run these type of tasks.

    Let me know whether your scans are scheduled ones and we can look for a temp fix for the email issue.

    • This reply was modified 3 years ago by nlpro.
    Thread Starter pierreripka

    (@pierreripka)

    Thank you for your quick reply.

    I checked on several sites and I see “WP-Cron Scheduled Task” on each one. The latest scans are recent (6 days), it fits with my last plugins update. This really seems to be an email issue only.

    Let me know if I should change the wp-config.php anyway.

    nlpro

    (@nlpro)

    Ok, that’s interesting.

    But I think there is an explanation for that. Could you check on those sites for how many days there are log entries in the Logs page ? Only check on a site where the iTSec plugin 6.9.2 release is installed/updated MORE than 2 weeks ago. Also make sure to click on the All Events link. Then navigate to the last page. At the bottom you’ll find the oldest log entry.

    If the plugin is properly hooking into WP-Cron the Logs page will show data for max 14 days. This is the default setting in the Global Settings module.
    However if the Logs page contains more than 2 weeks of data (again assuming the unchanged default here) then the plugin is not properly hooking into WP-Cron (despite File Change Detection scans being processed by WP-Cron). In that case, yes follow my recommendation anyway.

    I’ll wait for your feedback. Once we have established the plugin is properly hooking into WP-Cron (for all scheduled tasks) we can continue with the email.

    Thread Starter pierreripka

    (@pierreripka)

    On some sites, the oldest logs are 3 months old, sometimes more (8 months!).

    I have also this message when I go to check the logs for the first time: “Migrating log entries from an older format. This message will update when the migration is complete.”

    I will test by modifying some sites this Monday according to your recommendation (it’s already the weekend here!). Will this have an immediate effect on old logs (and potentially e-mails)?

    nlpro

    (@nlpro)

    The migration msg displayed when you access the Logs page for the first time after updating the plugin to the 6.9.0 release or later, is happening because iThemes also introduced a new logging system in the 6.9.0 release.

    The migration creates a new wp_itsec_logs table in your database and then converts and moves records from the old wp_itsec_log table to the new table. Once completed the old wp_itsec_log table is removed from the database.

    Unfortunately the migration of large datasets can have significant impact on the server. So it’s vital that the old wp_itsec_log only contains a small dataset before the migration starts. As you have seen, due to the plugin not properly hooking into WP-Cron the task scheduled for regularly cleaning the wp_itsec_log table is often not running. So instead of the expected 2 weeks dataset (or whatever is configured in the Global Settings module) there is often a larger dataset stored. Best you can do is fix the WP-Cron issue. Then wait for the plugin (cleanup task scheduled in WP-Cron) to truncate the data stored in the wp_itsec_log table.

    Once that is done you can access the Logs page (for the first time) and the migration will only take a few seconds without running the risk of negatively impacting server performance.

    And when all that is done, the email issue is still not solved …
    But we can continue with that after taking care of the WP-Cron issue.
    You’ll probably agree with me that it’s pretty important to get the plugin to properly hook into WP-Cron. It’s not just the log table which is not being truncated on a daily basis, there are another 2 daily tasks for truncating the tables that contain locks and lockouts … those are also currently not running.

    So my recommendation is to execute the 5 steps below first on an env where you know there is a too large dataset (use phpMyAdmin) AND you have not yet accessed the Logs page after updating the plugin to 6.9.0 or later release:

    1. Add the MANDATORY line to the wp-config.php file:

    define(‘ITSEC_USE_CRON’, true);

    2. After adding the line above to the wp-config.php file wait for at least a day (>24 hours).

    3. Then deactivate/activate the plugin.

    4. Wait for another day (Truncating the logs table is a daily task).

    5. Access the iTSec Logs page to start the log migration.

    • This reply was modified 3 years ago by nlpro.
    • This reply was modified 3 years ago by nlpro.
    • This reply was modified 3 years ago by nlpro.
    nlpro

    (@nlpro)

    After giving my latest recommendation one last thought I realized that step 4 will take place on the new wp_itsec_logs table (I verified that in the plugin code).

    If the logs migration has NOT yet taken place that table does not yet exist.
    The logs table is still named wp_itsec_log
    So the scheduled logs cleaning task will fail … unless …
    we make a small temporary code change.

    So after step 3:

    – Make a backup copy of the wp-content/plugins/better-wp-security/core/lib/log.php file.

    – Edit the wp-content/plugins/better-wp-security/core/lib/log.php file and search for the following unique string: {$wpdb->base_prefix}itsec_logs

    – Replace that string with: {$wpdb->base_prefix}itsec_log (We are only removing a single character: s). Save the change.

    Step 4 will now be able to execute without failing.

    After step 4 is completed delete the changed log.php file and restore the backup copy we made.

    Continue with step 5.

    Considering the amount of websites you manage (>100) I aimed for a procedure which is as simple as possible. Unfortunately having to edit a plugin file complicates the procedure. But it’s a necessary step.
    You could make a master copy of the changed log.php file and copy that to the other envs. That limits the edit code part to only once 😉

    Good luck.

    Thread Starter pierreripka

    (@pierreripka)

    Sorry for my reply time, I was on vacation last week.

    I correctly performed steps 1-2-3 and the string replacement in the log.php file on the 103 sites I manage (took so much time!).

    I’ll do step 5 tomorrow, I’ll get back to you when the procedure is over.

    Thanks a lot for your help.

    nlpro

    (@nlpro)

    No problem.

    Just noticed the forum editor unexpectedly converted single quotes in one of my previous posts.

    This made my previous search/replace steps incorrect.
    Below the correct search/replace steps:

    – Edit the wp-content/plugins/better-wp-security/core/lib/log.php file and search for the following unique string:
    ‘{$wpdb->base_prefix}itsec_logs’

    – Replace that string with:
    ‘{$wpdb->base_prefix}itsec_log’
    (We are only removing a single character: s). Save the change.

    The single quotes are very important. Apologies for the inconvenience.

    • This reply was modified 3 years ago by nlpro.
    Thread Starter pierreripka

    (@pierreripka)

    If I understand what you’re saying, this line (132) should not have been changed:

    $result = $wpdb->insert( "{$wpdb->base_prefix}itsec_logs", $data, $format );

    Only this line (259) should have been changed:

    $query = $wpdb->prepare( "DELETE FROM ‘{$wpdb->base_prefix}itsec_logs’ WHERE timestamp<%s", $database_entry_expiration );

    That’s right ?

    Does this mean that I have to edit each file again to restore line 132?
    Can not this affect the running of the procedure?

    nlpro

    (@nlpro)

    Yes, that is 100% correct.

    Use an original unchanged copy of the (4.9.2) log.php file.

    Then perform the corrected search/replace steps on that file. Use the changed file as a master to copy/overwrite the existing file on all the envs. That will limit the edit code part to only once.

    • This reply was modified 3 years ago by nlpro.
    Thread Starter pierreripka

    (@pierreripka)

    I just overwrote the log.php file on all sites.
    Do I have to wait 24 hours from now before doing step 5?

    nlpro

    (@nlpro)

    Yes.

    After waiting 24 hours you can verify using phpMyAdmin whether the wp_itsec_log table is indeed purged to only contain 2 weeks of data before deleting the changed log.php file and restoring the backup copy (the original file). No need to perform the phpMyAdmin check on every env.

    If the wp_itsec_log table still holds more than 2 weeks of data wait a little longer.

    Once the wp_itsec_log table contains only 2 weeks of data proceed with step 5. Log migration should run shortly now.

    Thread Starter pierreripka

    (@pierreripka)

    Is it normal that the “wp_itsec_logs” table already exists and is very heavy?

    The “wp_itsec_log” table doesn’t seem to have changed on most sites. There is still a lot of data, the oldests dating back to January.

    I tested a dozen sites, there is only one where the data seemed correct (less than 30 days, the value that I defined on all sites), but there is already data in the new table.

    nlpro

    (@nlpro)

    Is it normal that the “wp_itsec_logs” table already exists and is very heavy?

    That indicates that the log migration has already taken place. Or in other words in such env the Logs page has already been accessed at least once after updating the plugin to the 6.9.0 or later release. So all log data has already been migrated.

    However such envs would still benefit from the recommended steps but executed without the search/replace step. Also Step 5 is irrelevant as the log has already been migrated.

    Too much data in the wp_itsec_logs table is an indication the iTSec plugin is not properly hooking into WP Cron. Fixing that is our main goal. The side effect of a shorter/faster log migration is a nice extra for those envs where the Logs page has not been accessed yet after updating to the 6.9.0 or later release.

    Thread Starter pierreripka

    (@pierreripka)

    What to do then? It seems that most of my sites are in this case (though I’m sure I did not go on the logs page, only on a few).

    Do you have a procedure that I could apply to each site, regardless of the state of the tables? Even if it requires to completely delete the logs, I will do it if there is no other choice. I need to fix this email problem quickly, I already lost a lot of time on it. Otherwise I will have to find another plugin that does that.

Viewing 15 replies - 1 through 15 (of 20 total)
  • The topic ‘I no longer receive “File change warning” emails’ is closed to new replies.