Are there universal ways to secure php sites?

Question

linux

Sometimes I help my friends host some php site (most often wordpress, but there are options up to magento).
To do this, I collect a standard LAMP stack like:
Apache2 + PHP 5.x + ModPHP + Mod security with standard configs
I am very far from the CMS used themselves and would not want to go into it.
Despite all the explanatory work, these sites often break - most often through some holey shit plugin that friends install themselves.
Friends are crying, I restore everything from backups, delete the leaky plugin and after a while the story repeats with another plugin.
Question: what are the ways to secure such sites at the level of the OS and the system software used (not by means of CMS). I understand that there is no silver bullet, but perhaps there are ways to reduce the risks?
PS: Technical solutions are of interest. Administrative I can think of myself.

Answer 1

Prevent friends from installing plugins.

Answer 2

Either automate the restoration of sites from a backup so that your friends have a button, and you will forget about this hemorrhoid, or take money for each restoration.

Answer 3

https://sitecoder.blogspot.ru/2016/05/website-prot...

Answer 4

Mandatory:
* Install and configure SUExec, and it is desirable to configure it so that the site folder (for example, "Public_HTML" or "www", or site1 / www, site2.www, etc.) is in the hamster of the beast (it will be more convenient to climb through SFTP)
* Each beast must have its own UNIX account and reg on the MySQL server (one or more databases for each)
* It is advisable to build php from sources and run it via CGI (SUExec only works on CGI), you can assign INI files to users individually (for example, enable/disable certain modules)
As for the CMS themselves, using OS tools, you can only assign the owner to the root and make the regular CMS files read-only. Thus, no one will be able to change the files of the CMS itself, but it’s good to use it. Only one negative: the ability to auto-update is lost, root is required to replace such files. On the MySQL side, it will not save you from a crash if one of the plugins clumsily tries to change one of the existing tables (thus ruining it), and not add a new one for itself.