Security: File audit tool or file cleaning process
Permalink 1 user found helpful
I need to cleanse a concrete5 site that has been infiltrated with php files to facilitate the sending of spam from the site. It's vital that all php files except those officially part of concrete5 be removed.
Is there a file auditing tool available for concrete5 that will identify and report any unofficial files?
Alternatively there might be a way to save all content data (files, database), reinstate a concrete5 installation with a clean set of files, then reinstate the data to the install. Can anyone point me to instructions on how that should be done?
Finally, is there a list of folder permission settings available that would allow vast tracts of the concrete5 installation to be write protected and thus protected from further infection?
Any tips on any aspect of recovery and prevention of this widespread problem will be gratefully received.
Is there a file auditing tool available for concrete5 that will identify and report any unofficial files?
Alternatively there might be a way to save all content data (files, database), reinstate a concrete5 installation with a clean set of files, then reinstate the data to the install. Can anyone point me to instructions on how that should be done?
Finally, is there a list of folder permission settings available that would allow vast tracts of the concrete5 installation to be write protected and thus protected from further infection?
Any tips on any aspect of recovery and prevention of this widespread problem will be gratefully received.
The main top level /concrete folder never changes or has any writeable files within it.
This means that you can simply delete this entire core folder and replace it with a clean copy from a corresponding version. Sometimes when I have to move a site and there's no nice way to take a full zip, I'll download everything via FTP except this core directory, as I can always get it from a fresh copy. That's where the bulk of concrete5's folders and file are.
The only complexity with this is if you are applying updates automatically. In this case the /updates folder will have a copy of the active concrete5 core. In this case you could remove all the old version folders and just update the active one with a fresh copy of the core.
With the /packages folder, the same sort of goes for the individual packages. You could manually download fresh copies (of the same installed version) and replace each folder. Although the packages folder is writable, the files and folder within aren't constantly modified. You can manually download the package zips through the concrete5 marketplace, under licenses. You could also possibly look through the packages manually, as most aren't that big and unwanted files should be fairly easy to spot.
With the /files directory - this should only have folders and files in it, not any PHP scripts. So that should be easy to search through for.
Finally it's just a case of looking through the other top level folders to see where overrides may have been placed. Overrides tend to be only a few files or folders here and there, so can be manually inspected I guess.
With permissions, only the /files, /updates, /packages and /config folders need to be writable by the webserver, and then it should only be 755 permissions. Everything else can be write protected.
You could effectively recreate the same install by setting up the core, package files, all overrides and all the valid files in the files directory elsewhere and then point it at a copy of the database.