Support

Look at your screen. You have two files with similar names but different letter case:

• WebConfigMakerController.php
• WebconfigmakerController.php

Only the latter is the correct file. The former should be deleted.

Admin Tools is correct in marking these two files as a problem. When restoring this site on a non-case-sensitive filesystem (e.g. Windows, or newer macOS) one file would "shade" the other by overwriting it due to the way non-case-sensitive filesystems work. The only way we can bring your attention to them is to report them both as modified when their contents and filestamps are not identical, which is exactly what happened here.

Hello,

I think the problem comes from the case of the file. Linux system is case-sensitive, so those are indeed two different files for it.

You can safely ignore those entries.

So when we regularly update extensions this list will always contain a whole lot of files. Going through them would be almost impossible to do (takes a lot of time) for all our sites. So this makes me wonder what the point is of this metric? Or am I missing something? Focussing only on the possible threats seems to be more productive?

You didn't read the link I provided. I explain that in there. The TL;DR is that once you update extensions you run a scan. Then you know that the only changed files are those from the update. Insofar you trust the extension developer, you mark those change files safe. The same with core Joomla! updates.

The idea is that when you see a changed file when you don't expect any files to change you need to start looking closer. The Threat Score tells you how likely it is to be something malicious.

I suppose there is no way to skip files from extension updates since the last scan?

They are not recorded by Joomla, so no.

And since I am asking stuff: I was thinking, would it be possible to somehow combine the backup (Akeeba Backup of course)  and the file scanning? That way the server only needs to access / process the files once instead of at different times? Just a thought...

In theory? Yes. In practice? That would be really bad for your backup.

You need to run the backup as fast as possible. Ideally, you should be running a backup with your web server shut down for external traffic to ensure backup consistency. Since this is not practical, we go with running the backup as fast as possible when it comes to database data and .php file, i.e. what would most likely be problematic for consistency.

If you add the scanning in the backup process you will be slowing down the backup of .php file by one or two orders of magnitude. This increases the chance of consistency issues during backup from "it practically doesn't matter" to "there's an one in a hundred chance the restored site won't work". The latter is unacceptable, hence the scanner running as its own, separate process which needs to be temporally removed from the backup process.

You will not have updates every day, but you are going to be running the scanner every day.

What you ask is impractical to develop, especially as mass distributed software. It only fits your unique use case.

Beyond that, .php files are source code. There is absolutely no tool whatsoever which can correctly identify a source code file as legitimate or malicious -- and yes, I am aware of LLMs ("AI"), as well as their limitations in deriving context from single source files without being fed the entire environment they execute into.

Moreover, in many if not most cases, that distinction would be meaningless. A knife can be used to cut bread, or someone's throat. Is a knife legitimate or malicious? Even taken in context, it doesn't preclude the use of a knife which has a legitimate place in a kitchen from being used by the sous-chef to murder a waiter in that same kitchen. Some things can be used as a weapon of opportunity. For example, any bugs in the update code of any CMS are treated as security issues because they are knives in the kitchen; if they can be abused, they can inflict significant injury. This is why any tool that scans source code files comes up with a score, not a binary malicious/innocent verdict.

Hosted services suck the contents of your sites as part of their scanning. Therefore, they can always tell you if a specific file, let's say /administrator/components/com_example/src/Model/Foo.php, is likely to be legitimate by comparing it to the same /administrator/components/com_example/src/Model/Foo.php file installed on other sites. If it's identical across enough sites, it's likely to be legitimate, therefore not marked as potentially dangerous.

And here is the crux of the issue.

ARE YOU OKAY WITH A THIRD PARTY HAVING ACCESS TO ALL OF YOUR SITES' FILES WITHOUT ANY NDA AGREEMENT?

Think about it. The only way these services can work is if they have full access to all of your site, at any time. Even if you trust them to be legitimate, do you trust them to never be hacked?

As to whether why we couldn't make such a service for Panopticon. Sure we can. It's easy. It would cost quite a bit, but you could all chip in -- which is problem number one. However, is that given Panopticon's nature (mass distributed software) there is no way to know which requests to the service reporting file locations and contents are legitimate, and which are sent by malicious actors who try to spam the service with hundreds of thousands of fake instances of their malicious file so that when they attack your site their malicious file does not raise any alarms. The only way to prevent that is if you had to pay us not a single fee to use that service, but a per-site fee to register each of your sites with the service. At this point, the whole point of using Panopticon starts becoming moot. It would also turn us into what we hate: the people who have all of your sites' contents, which is definitely not something I am keen on doing at all.

So, here's your choice.

Use a third party site monitoring service which makes things easy for you BUT has zero privacy or non-compete guarantee.

- or -

Use a self-hosted site monitoring software which makes things a bit harder for you BUT has a guarantee of absolute privacy and the matter of non-competition is not even relevant anymore.

So, there are two schools of thought.

One school of thought is that the more redundant layers of security you have, the better. If you ascribe to that school of thought, you need the PHP File Change Scanner just in case.

The other school of thought is that you need to have a practical amount of security. If you ascribe to that school of thought, you don't really want to use the PHP File Change Scanner because it's unlikely it will catch something that's not caught during the attack phase by your other layers of security.

In very practical terms, the PHP File Change Scanner protects you from "slow burn" attacks. I have seen cases where the site was compromised at one point, the attacker didn't immediately make their presence felt, and a few months (or years!) later they used their backdoor to use the site for something nefarious, typically serving malware and/or phishing pages. You can't catch this kind of attacks with anything but the File Change Scanner or a similar tool, especially if the backdoor is well-written to not raise any icky code alerts and the attacker was careful enough.

In your particular use case I am inclined to say that you probably don't need the file change scanner. However, I'd feel more confident telling you that if I knew that plain FTP was turned off on your servers, SFTP access is only possible using certificates, and you are religiously using 2FA/MFA for all kinds of privileged access including the hosting control panel. Basically, if you guarantee you have the absolute minimal exposure to human stupidity, you can maybe afford to shed a protection layer that's troublesome.