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

Je suis tout à fait d'accord avec les éléments que vous avez jusqu'à présent.

J'ai utilisé une telle configuration multi-utilisateurs il y a quelques années et j'ai trouvé le même compromis : mod_php est rapide (en partie parce que tout fonctionne dans le même processus) et suexec est lent mais sûr (parce que chaque requête crée un nouveau processus). J'ai opté pour suexec, car l'isolation de l'utilisateur était nécessaire.

Il existe actuellement une troisième option que vous pouvez envisager : donner à chaque utilisateur son propre démon php-fpm. La faisabilité de cette option dépend du nombre d'utilisateurs, car chacun d'entre eux doit obtenir au moins un processus php-fpm en utilisant son compte d'utilisateur (le démon utilise alors un mécanisme de type prefork pour s'adapter aux demandes, donc le nombre de processus et leur utilisation de la mémoire peuvent être des facteurs limitatifs). Vous aurez également besoin d'une certaine génération de configuration automatisée, mais cela devrait être faisable avec quelques Shell Shell.

Je n'ai pas utilisé cette méthode dans de grands environnements mais, à mon avis, c'est une bonne solution pour fournir de bonnes performances aux sites Web PHP tout en isolant les utilisateurs au niveau du processus.

Tout ce que vous avez jusqu'ici semble bien pensé. La seule chose que je pourrais considérer comme un problème est le fait que la plupart des exploits cherchent à obtenir un accès root d'une manière ou d'une autre. Ainsi, même si chaque site et ses processus et scripts correspondants sont emprisonnés correctement et que tout a son propre utilisateur et ses propres permissions, un hacker avec root ne pourrait pas s'en soucier moins, il contournera simplement tout ce que vous avez configuré.

Ma suggestion serait d'utiliser une sorte de logiciel VM (VMware, VirtualBox, Qemu, etc.) pour donner à chaque site sa propre prison de système d'exploitation. Cela vous permet, en tant qu'administrateur système, de ne pas vous soucier d'un seul site compromis. Si un pirate obtient la racine en exploitant php (ou tout autre logiciel) sur la VM d'un site, il suffit de mettre la VM en pause et de la disséquer plus tard, d'appliquer des correctifs ou de revenir à un état intact. Cela permet également aux administrateurs du site d'appliquer des logiciels ou des paramètres de sécurité spécifiques à l'environnement de leur site (ce qui pourrait casser un autre site).

La seule limite à cela est votre matériel, mais avec un serveur décent et les extensions correctes du noyau, c'est facile à gérer. J'ai réussi à faire fonctionner ce type de configuration sur un Linode, mais l'hôte et l'invité étaient très très clairsemés. Si vous êtes à l'aise avec la ligne de commande, ce que je suppose que vous êtes, vous ne devriez pas avoir de problèmes.

Ce type de configuration réduit le nombre de vecteurs d'attaque que vous devez surveiller et vous permet de vous concentrer sur la sécurité des machines hôtes et de traiter tout le reste site par site.

Je suggérerais de faire tourner chaque site sous son propre démon Apache, et de mettre Apache en chroot. Toutes les fonctions du système php échoueront puisque l'environnement chroot d'Apache n'aura pas accès à /bin/sh. Cela signifie également que la fonction mail() de php ne fonctionnera pas, mais si vous utilisez un fournisseur de messagerie externe pour envoyer des messages à partir de votre application de messagerie, cela ne devrait pas être un problème pour vous.

SELinux peut être utile pour mod_selinux . Vous trouverez ici un rapide mode d'emploi :

Comment puis-je utiliser SELinux pour confiner les scripts de PHP ?

Comme les instructions datent un peu, j'ai vérifié si cela fonctionne sur RHEL 7.1 :

J'ai utilisé La version de Fedora 19 et compilé avec mock contre RHEL 7.1 + EPEL.

YMMV si vous utilisez la configuration epel de base avec laquelle mock est livré :

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Mettez d'abord à niveau votre système cible pour vous assurer que selinux-policy est en cours.

Installez sur la boîte cible (ou mettez-la d'abord sur votre miroir local) :

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Maintenant, vous devez attribuer une catégorie à chaque hôte virtuel dans apache. Ceci est en ajoutant une ligne, comme dans l'exemple ci-dessous, appelée selinuxDomainVal .

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Ensuite, dans la racine du document de chaque hôte, réétiqueter leurs racines de document à la même catégorie que celles étiquetées dans la configuration de httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Si vous voulez que l'étiquetage soit honoré si vous faites un système vous devez également mettre à jour la politique locale !

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Il y a déjà beaucoup de bonnes réponses techniques fournies (veuillez également jeter un coup d'œil ici : https://security.stackexchange.com/q/77/52572 y Conseils pour sécuriser un serveur LAMP ), mais je voudrais tout de même mentionner ici un point important (d'un autre point de vue) concernant la sécurité : la sécurité est un processus . Je suis sûr que vous y avez déjà réfléchi, mais j'espère quand même qu'il pourrait être utile (également pour d'autres lecteurs) d'y repenser parfois.

Par exemple, dans votre question, vous vous concentrez principalement sur les mesures techniques : "Cette question concerne uniquement la sécurité d'une installation Apache partagée. Plus précisément, existe-t-il des mesures de sécurité qu'il est important de prendre mais qui ne figurent pas dans la liste ci-dessus lors de l'utilisation d'Apache et de PHP partagés."

Presque toutes les réponses ici et sur les deux autres questions que j'ai mentionnées semblent également être purement techniques (sauf la recommandation de rester à jour). Et de mon point de vue, cela pourrait donner à certains lecteurs une impression trompeuse, à savoir que si vous configurez votre serveur selon les meilleures pratiques une fois, vous restez en sécurité pour toujours. Je vous prie donc de ne pas oublier les points que j'ai omis dans les réponses :

1. Tout d'abord, n'oubliez pas que la sécurité est un processus et, en particulier, sur le cycle "Plan-Do-Check-Act", tel que recommandé par de nombreuses normes, dont la norme ISO 27001 ( http://www.isaca.org/Journal/archives/2011/Volume-4/Pages/Planning-for-and-Implementing-ISO27001.aspx ). En gros, cela signifie que vous devez réviser régulièrement vos mesures de sécurité, les mettre à jour et les tester. .

2. Mettez régulièrement votre système à jour. Cela ne vous aidera pas contre les attaques ciblées utilisant des vulnérabilités de type "zero-day", mais cela vous aidera contre presque toutes les attaques automatisées.

3. Surveillez votre système. Je rate vraiment ce point dans les réponses. De mon point de vue, il est extrêmement important d'être informé le plus tôt possible d'un problème avec votre système.

   Voici ce que disent les statistiques à ce sujet : "Le temps moyen entre l'infiltration et la découverte est de 173,5 jours" ( http://www.triumfant.com/detection.html ), "205 nombre médian de jours avant la détection" ( https://www2.fireeye.com/rs/fireye/images/rpt-m-trends-2015.pdf ). Et j'espère que ces chiffres ne sont pas ceux que nous souhaitons tous avoir.

   Il existe de nombreuses solutions (y compris gratuites) non seulement pour surveiller l'état du service (comme Nagios), mais aussi des systèmes de détection d'intrusion (OSSEC, Snort) et des systèmes SIEM (OSSIM, Splunk). Si cela devient trop compliqué, vous pouvez au moins activer quelque chose comme 'fail2ban' et/ou transmettre vos logs à un serveur syslog séparé, et avoir notifications par e-mail sur des événements importants.

   Encore une fois, le point le plus important ici n'est pas le système de surveillance que vous choisissez, le plus important est que vous ayez un certain suivi et que vous le révisiez régulièrement selon votre cycle "Plan-Do-Check-Act". .

4. Soyez conscient des vulnérabilités. Comme pour la surveillance. Il suffit de s'abonner à une liste de vulnérabilités pour être informé lorsqu'une vulnérabilité critique est découverte pour Apache ou un autre service important pour votre installation. L'objectif est d'être informé des éléments les plus importants qui apparaissent avant la prochaine mise à jour prévue.

5. Ayez un plan de ce qu'il faut faire en cas d'incident (et mettez-le régulièrement à jour et révisez-le en fonction de votre cycle "Plan-Do-Check-Act"). Si vous posez des questions sur la configuration sécurisée, cela signifie que la sécurité de votre système devient importante pour vous. Cependant, que devez-vous faire si votre système est piraté malgré toutes les mesures de sécurité ? Encore une fois, je ne parle pas seulement de mesures techniques comme "réinstaller le système d'exploitation" : Où devez-vous signaler un accident selon la loi applicable ? Êtes-vous autorisé à arrêter/déconnecter votre serveur immédiatement (combien cela coûte-t-il à votre entreprise) ? Qui doit être contacté si le principal responsable est en vacances ou malade ?

6. Disposer d'un serveur de sauvegarde, d'archivage et/ou de remplacement/réplication. La sécurité, c'est aussi la disponibilité de votre service. Vérifiez régulièrement votre sauvegarde/archive/réplication et testez aussi régulièrement les procédures de restauration.

7. Tests de pénétration ? (voir le cycle "Planifier-Faire-Vérifier-Agir"). Si cela vous semble trop, vous pouvez au moins essayer des outils en ligne gratuits qui analysent vos services web à la recherche de logiciels malveillants et de problèmes de sécurité.