Support

1. Not really. A fluctuation of the files is normal if you have extensions which write .php files to your site to store private data which must not be web accessible (they put a die statement in the top of the .php file to achieve that) or even some templates which use .php files to deliver combined and/or GZipped (compressed) CSS and JS files.

2. I can rephrase your question as "Do you feel lucky?". If you feel lucky, sure, go ahead and blindly mark those files are safe. If you want to be absolutely sure those files are safe you'd better check them against a fresh local installation which is guaranteed not to be hacked OR check these files manually if you are a developer. Since you're not a developer the documentation suggestion should work best for you.

3. Correct. It helps developers manually inspect suspicious files.

4. I am not here to teach PHP development. It suffices to say that none of them on its own right is malicious. If there were purely malicious PHP functions it stands to reason that they would have been removed from the language. Like with any language (programing or even human) you can combine otherwise innocuous constructs to inflict damage. The threat score merely gives a ballpark estimate of the concentration of constructs which are typically used in malicious code (but NOT ONLY in malicious code!).

Think about having a library of thousands of books and you're tasked to ferret out the ones that incite racial hatred. Going through all of these books one by one would take you more than a lifetime. You can, however, make a weighted criteria matrix for each of the books, correlating possibly troubling words (like the n-word, "race" and its derivatives, "inferior" etc) with a weight factor and number of occurances. The sum of all the weight times number of occurances products would give you a Threat Score. Most of the books would have a zero –or near zero– score, making them unlikely to be inciting racial hatred. Those with a high score are the ones you need to read – or ask your colleagues from other libraries whether they are safe or not. In fact, it could work on books written in languages you don't speak, as long as someone provided the weighted matrix criteria for you. And since you don't speak the language you'd just have to list the suspect books and ask around if they are safe.

Sounds familiar? That's exactly what the Threat Score does. The entire point is that you don't speak PHP, you don't need to speak PHP and I can provide you with the weighed matrix. In the end of the day I give you a small list of files to check which you can check against a predictably safe, easy to obtain source. If you want to delve deeper you will need to learn how to speak PHP but that's way beyond the scope of support.

5. Yes, files with a non-zero threat score retain their status and get reported again and again. Otherwise you'd miss them: normall files which are neither modified or new don't get reported, at all.

6. I cannot answer that question. See #2 and #4 about what you should be doing.

7. No, changing the permissions of folders WILL NOT help with being web accessible in most cases. Please take a look at the .htaccess Maker. It actually blocks web access very efficiently at the Apache (web server) level. That's before PHP even has the chance to load, let alone run. Or put a .htaccess file whcih prevents web access inside each one of these directories.

8. Manual scans never email you. CRON scans should be emailing you. Which CRON method do you use, the admintools-filescanner.php script or the front-end scheduling URL? Actually, please file a different ticket for this issue to make it easier to manage :)

9. Basically this is a "don't press that button unless I tell you so" kind of thing.

The PHP File Change Scanner keeps a database table with the paths to each scanned file, its size, modification date/time stamp, MD5 checksum and SHA-1 checksum. If you have enabled the diff feature it also keeps a copy of the contents of the file so we can produce a diff on the next run. This is how it "remembers" files between runs and knows if a file has been added or modified between this and the previous run of the file scanner.

If you deliberately make large changes to your site (like unhacking a site) or you've blindly marked as safe more files than you really should have you may want to purge that database table and start the file scanning afresh. Same goes in the very rare case something is stuck and we need you to purge that table (very, very, very, VERY rare issue). Typically we'd tell you to go to the database management tool (e.g. phpMyAdmin) and do that but it's not very user-friendly. So we added a button. It's not documented because you're not really supposed to press that unless we tell you. You must definitely NOT do that periodically.