• I am regularly getting file change warnings like the following:

    Check Time Files Added Files Deleted Files Changed Memory Used Details
    Check Time Files Added Files Deleted Files Changed Memory Used Details
    2015-04-20 09:17:42 0 0 30 8.91MB Details
    2015-04-20 09:04:43 2147 0 0 3.69MB Details
    2015-04-19 08:56:03 0 0 0 0.11MB
    2015-04-18 08:56:02 0 2147 0 5.64MB Details

    First it shows pretty much all the files in the WP install as deleted, then a day or two later, all the files being added.

    Any idea what’s causing this?

    https://wordpress.org/plugins/better-wp-security/

Viewing 14 replies - 16 through 29 (of 29 total)
  • Thread Starter billsmithem

    (@billsmithem)

    Yes, I did. All the files were present after the run that “found” them all. After the run that reported them all as deleted, the value of itsec_local_file_list was a:0:{}

    Ok, great. So that looks good.

    I’ve analyzed the file scan code and thought things through.
    There’s a lot happening but let’s stick with the main thread of this process.

    We know that the file list of the last scan is stored in the itsec_local_file_list option.

    Is see in the code that it is compared with the current file list.
    The current file list is composed using a recursive function that traverses through all (sub)directories.

    So any file(s) that does not exist in the current file list compared to the files in the itsec_local_file_list option is marked as deleted.

    Since all files found in the last scan do not exist in the current file list I think it is safe to say something goes wrong in the recursive function when composing the current file list.

    Now there are some os related functions being used in the recursive function. These are preceeded by a @ to suppress any possible warnings/errors …
    I suspect this is where something goes wrong.
    It would also explain why we don’t get any warnings/errors in the log.

    So what we can do is create a debug version of the file that contains the recursive function. The aim is to remove any @’s in the recursive function.
    Then monitor the log file again.

    Just let me know whether you are willing to go this far and I’ll make a seperate post with the correct instructions.
    Any changes will be temporary and once we have the result(s) these changes will be undone.

    dwinden

    Thread Starter billsmithem

    (@billsmithem)

    Yes, I’d definitely like to pursue this – it’s happening daily on multiple sites. I was traveling on business last week and replied to the email notification, but I see it didn’t make it back here to the forum.

    Where do I need to remove the error control operators?

    Ok, no problem.

    First create a backup copy of the class-itsec-file-change.php file.
    Then edit this file and search for the scan_files() function\method.
    It contains 5 commands preceded with @. Remove all 5 @ chars.
    Then retest (scheduled scan).

    (Don’t forget to restore the backup file after the test).

    dwinden

    Thread Starter billsmithem

    (@billsmithem)

    Thanks. All set. I’ll let you know the results when the anomaly occurs again.

    Great.
    Where anomaly is a new File Changes Detected log entry (or email) reporting all files deleted (as a result of a scheduled File Change Detection run).
    Keep an eye on those logs 😉

    dwinden

    Hi,

    Can anyone help me?!

    I have the plugin install it and for couple of the months I receive emails with the files that was changeing on my website, but after some time in the emails the changed files are not display it anymore. I get only:
    File changes detected: iThemes Security detected file changes on your system.
    but I don’t receive witch files was changed!

    How can I make to receive the list with the files changed like it was at the begining.

    Thank you

    Thread Starter billsmithem

    (@billsmithem)

    dwinden, going over the site logs for last week when I was away, I’ve noticed a change in behavior – there were two cycles of “all files deleted / all files added” where the files were not found again on the first scan after they disappeared. I don’t think it’s ever done that before. In one case there were no files detected until the second scan after they were reported deleted, in the other it was three.

    I have no idea if this info is useful or not. See log excerpt below:

    2015-05-28 14:57:57 2661 0 0 4.73MB Details
    2015-05-27 14:54:06 0 0 0 0.05MB
    2015-05-26 14:54:05 0 0 0 0.02MB
    2015-05-25 14:54:04 0 2661 0 7.02MB Details
    2015-05-24 14:26:46 1 1 0 11.57MB Details
    2015-05-23 14:26:45 2661 0 0 4.73MB Details
    2015-05-22 14:24:04 0 0 0 0.01MB
    2015-05-21 13:54:05 0 2656 0 7.04MB Details

    Using common sense I’ve reasoned which of those scans are (if you ask me) correct\incorrect. This is the result:

    (Correct2015-05-28 14:57:57 2661 0 0 4.73MB Details)
    Incorrect 2015-05-27 14:54:06 0 0 0 0.05MB
    Incorrect 2015-05-26 14:54:05 0 0 0 0.02MB
    (Incorrect 2015-05-25 14:54:04 0 2661 0 7.02MB Details)
    Correct 2015-05-24 14:26:46 1 1 0 11.57MB Details
    (Correct 2015-05-23 14:26:45 2661 0 0 4.73MB Details)
    Incorrect 2015-05-22 14:24:04 0 0 0 0.01MB
    (Incorrect 2015-05-21 13:54:05 0 2656 0 7.04MB Details)

    The ones between () are easy (2 correct and 2 incorrect).
    That leaves 1 correct and 3 incorrect ones.
    It’s interesting to see that the 3 incorrect ones report no changes whatsoever AND the memory usage is very low …
    These scans are incorrect as we know the files are there and the low memory seems to indicate there is as good as no data being processed.
    I believe this indicates there is no data to process during these scans … which again is invalid.

    3 out of 8 are correct
    5 out of 8 are incorrect

    Could be coincidence but it looks like the bad scans outnumber the good ones. Perhaps fifty fifty …

    It’s still a mystery to me why it sometimes works and why it (seemingly) more often doesn’t …
    All my hopes are on the result of the next scheduled scan reporting all files as deleted …

    dwinden

    Thread Starter billsmithem

    (@billsmithem)

    Scan reported all files deleted again, but nothing in the error_log. I went up a level to the function calling scan_files(), execute_file_check(), where there were calls to array_diff_assoc() and array_diff_key() with errors suppressed, and removed them just to see if I got any errors.

    This generates thousands of type conversion warnings on every scan:

    PHP Notice: Array to string conversion in /home/digitalg/public_html/dgpwpinst/wp-content/plugins/better-wp-security/modules/free/file-change/class-itsec-file-change.php on line 231

    though I don’t know if that’s relevant.

    Have not seen another “all files deleted” event since changing execute_file_check(), but will watch for it.

    Ok, I see.

    The notices are expected. This is exactly why the array_diff_assoc() function is preceded with a @.
    It seems to be related to comparing 2 multidimensional arrays.
    Currently rethinking our strategy …

    dwinden

    I think it is fair to say that most of the times it works fine.
    So there is some fluke that sometimes occurs that we are chasing …

    However it works fine on my Linux env. And I know it works fine om many other envs.
    So basically the File Change Detection code is fine.

    However you seem to have this issue on several envs …
    Perhaps we should look at the env (PHP version etc) of all the envs where you are experiencing this issue.

    There must be a common factor …

    dwinden

    Thread Starter billsmithem

    (@billsmithem)

    Now that I’ve been tracking this more carefully, I believe my previous statement that it’s happening with more than one hosting provider was incorrect.

    The hosting where this is happening blocks wget (which was how I was running wp-cron before moving the sites), so I used their recommended method of running wp-cron.php directly via php in the cron command. Given the fact that it doesn’t seem to happen except via cron, I’m now thinking that must be causing this is related to running it directly, and there is occasionally some change in the environment that’s causing the problem.

    I’ve discovered that it’s possible to use curl to run wp-cron.php if I specify a user agent, and have configured several of the sites to use that method. I’m now waiting to see if the problem happens on any of those sites.

    Ok.
    Just to give you an idea how the env can influence the File Change Detection result read this topic:

    https://wordpress.org/support/topic/file-change-notification-mail

    dwinden

Viewing 14 replies - 16 through 29 (of 29 total)
  • The topic ‘File Change Warnings For All Files’ is closed to new replies.