Hébergement multisite - une importante faille est manquée pour sécuriser les sites les uns des autres ?

Votre cas d'utilisation est idéal pour les conteneurs Docker.

Chaque conteneur peut représenter un client, avec des identifiants uniques attribués à chaque groupe de conteneurs Apache pour plus de sécurité. La clé est d'abandonner les privilèges root au démarrage du conteneur, avant de démarrer la pile Apache. Chaque client obtient son propre service de base de données avec ses propres mots de passe uniques, sans le casse-tête de la mise en place de dizaines de machines virtuelles, chacune nécessitant ses propres noyaux spéciaux "snowflake" et autres frais généraux. Après tout, le chroot est au cœur de Docker. Correctement administré, je le préférerais à un cluster virtuel typique n'importe quand.

Il y a déjà beaucoup de bonnes suggestions ici. Il y a cependant des choses qui ont été oubliées dans la discussion jusqu'à présent.

Faites attention aux processus autres que ceux qui sont exécutés dans le cadre de la fourniture de pages Web. Par exemple, assurez-vous que toutes vos tâches cron qui touchent des données non fiables sont exécutées par l'utilisateur approprié et dans la prison appropriée, que ces tâches soient définies par l'utilisateur ou non.

D'après mon expérience, des choses comme l'analyse des journaux, lorsqu'elles sont fournies par le service d'hébergement, sont exécutées en tant que root presque aussi souvent qu'elles ne le sont pas, et le logiciel d'analyse des journaux ne bénéficie pas d'un audit de sécurité aussi poussé que nous le souhaiterions. Faire cela correctement est un peu délicat, et dépend de la configuration. D'une part, vous ne voulez pas que le processus apache appartenant à root (c'est-à-dire le processus parent) écrive dans un répertoire que l'utilisateur pourrait compromettre. Cela signifie probablement ne pas écrire directement dans le jail. D'autre part, vous devez mettre ces fichiers à la disposition des processus de l'environnement jail pour analyse, et vous aimeriez que cela soit aussi proche du temps réel que possible. Si vous pouvez donner à vos prisons l'accès à un montage en lecture seule d'un système de fichiers avec les journaux, cela devrait être bon.

Les applications PHP ne servent généralement pas leurs propres fichiers statiques, et si vous avez un processus apache partagé, je suppose que votre processus apache lit les données directement dans les jails de l'environnement hôte ? Si c'est le cas, cela pose un certain nombre de problèmes.

.htaccess Les fichiers sont un cas évident, où vous devez faire très attention à ce que vous autorisez. De nombreuses applications php, si ce n'est la plupart, sont très dépendantes des arrangements de fichiers .htaccess que vous ne pouvez probablement pas autoriser sans compromettre votre plan.

Ce qui est moins évident, c'est la façon dont Apache décide de ce qu'est un fichier statique, par exemple, ce qu'il fait d'un fichier *.php.gif o *.php.en fichier ? Si ce mécanisme ou un autre trompe la discrimination sur ce qu'est un fichier statique, est-il possible pour Apache d'exécuter php du tout depuis l'extérieur de la prison ? Je mettrais en place un serveur web léger séparé pour le contenu statique, qui n'est pas configuré avec des modules pour exécuter du contenu dynamique, et j'aurais un équilibreur de charge qui déciderait quelles requêtes envoyer au serveur statique et lesquelles au serveur dynamique.

En ce qui concerne la suggestion de Stefan concernant Docker, il est possible d'avoir un seul serveur web qui se trouve à l'extérieur du conteneur, et qui parle aux démons php dans chaque conteneur pour le contenu dynamique, tout en ayant également un deuxième serveur web, qui se trouve dans un conteneur Docker, et qui partage les volumes que chacun utilise pour son contenu, et est donc capable de servir le contenu statique, ce qui est à peu près la même chose que dans le paragraphe précédent. Je recommande docker parmi les différentes approches de type jail, mais avec cette approche ou d'autres approches de type jail, vous aurez un tas d'autres problèmes à résoudre. Comment fonctionne le téléchargement de fichiers ? Mettez-vous des démons de transfert de fichiers dans chaque conteneur ? Adoptez-vous une approche de type PAAS basée sur git ? Comment rendre accessibles les journaux générés dans le conteneur et les transférer ? Comment gérez-vous et exécutez-vous les tâches cron ? Allez-vous donner aux utilisateurs une sorte d'accès Shell, et si oui, est-ce un autre démon à l'intérieur du conteneur ? etc, etc.

La première chose que je ne vois pas est la gestion des processus afin qu'un processus ne puisse pas priver un autre processus de CPU ou de RAM (ou d'E/S d'ailleurs, bien que votre système de fichiers puisse être conçu pour empêcher cela). Un avantage majeur de l'approche "conteneurs" pour vos instances PHP par rapport à l'utilisation d'une image "OS" est que vous pouvez mieux restreindre l'utilisation des ressources de cette façon. Je sais que ce n'est pas votre conception, mais c'est quelque chose à considérer.

Quoi qu'il en soit, revenons à l'utilisation de PHP derrière Apache qui fonctionne comme un proxy. suexec fait pas empêcher quelque chose de s'exécuter en tant qu'utilisateur d'apache - il fournit l'option capacité pour s'exécuter en tant qu'autre utilisateur. Il faudra donc s'assurer que tout est fait correctement - la page de la doc sur le sujet signale ce danger potentiel : https://httpd.apache.org/docs/2.2/suexec.html . Donc, vous savez, le grain de sel et tout ça.

Du point de vue de la sécurité, il peut être utile de disposer d'un ensemble restreint de binaires utilisateur avec lesquels travailler (ce que cagefs fournit), en particulier s'ils sont compilés différemment ou avec une bibliothèque différente (par exemple, une qui n'inclut pas de capacités non désirées). mais le danger est qu'à ce moment-là vous ne suivez plus une distribution connue pour les mises à jour, vous suivez une distribution différente (cagefs) pour vos installations PHP (au moins en ce qui concerne les outils de l'espace utilisateur). Mais comme vous suivez probablement déjà une distribution spécifique avec cloudlinux, c'est un risque supplémentaire, pas nécessairement intéressant en soi.

Je laisserais AllowOverride là où vous l'aviez prévu. L'idée principale derrière la défense en profondeur est de ne pas compter sur une seule couche pour protéger toute votre pile. Supposez toujours que quelque chose peut mal tourner. Réduisez les risques lorsque cela se produit. Répétez l'opération jusqu'à ce que vous ayez pris toutes les mesures d'atténuation possibles, même si vous n'avez qu'une seule barrière devant vos sites.

La gestion des journaux sera essentielle. Avec de multiples services fonctionnant dans des systèmes de fichiers isolés, l'intégration d'activités permettant d'établir des corrélations en cas de problème peut s'avérer très difficile si vous ne l'avez pas mis en place dès le départ.

C'est ma vidange de cerveau. J'espère qu'il y a quelque chose de vaguement utile là-dedans. :)