Hébergement multisite - vulnérabilité importante manquée pour sécuriser les sites les uns des autres?

EDIT # 2 23 juillet 2015: à la recherche d'une nouvelle réponse qui identifie un élément de sécurité important manquant dans la configuration ci-dessous ou peut donner des raisons de croire que tout est couvert.

EDIT # 3 29 juillet 2015: Je recherche en particulier une mauvaise configuration possible comme autoriser par inadvertance quelque chose qui pourrait être exploité pour contourner les restrictions de sécurité ou pire encore laisser quelque chose de grand ouvert.

Il s'agit d'une configuration d'hébergement multi-site / partagé et nous voulons utiliser une instance Apache partagée (c'est-à-dire qu'elle s'exécute sous un seul compte utilisateur) mais avec PHP / CGI fonctionnant en tant qu'utilisateur de chaque site Web pour garantir qu'aucun site ne peut accéder aux fichiers d'un autre site, et nous voulons assurez-vous que rien ne manque (par exemple si nous ne connaissions pas la prévention des attaques par lien symbolique).

Voici ce que j'ai jusqu'à présent:

• Assurez-vous que les scripts PHP s'exécutent en tant que compte et groupe d'utilisateurs Linux du site Web et sont soit emprisonnés (comme CageFS), soit au moins correctement restreints à l'aide des autorisations du système de fichiers Linux.
• Utilisez suexec pour vous assurer que les scripts CGI ne peuvent pas être exécutés en tant qu'utilisateur Apache.
• Si Options IncludesNOEXECvous avez besoin d'une prise en charge côté serveur (comme dans les fichiers shtml), utilisez-la pour empêcher CGI d'être exécuté lorsque vous ne vous y attendez pas (bien que cela ne devrait pas être un problème si vous utilisez suexec).
• Mettez en place une protection contre les attaques par lien symbolique afin qu'un pirate ne puisse pas tromper Apache pour qu'il serve les fichiers d'un autre site Web sous forme de texte en clair et divulgue des informations exploitables comme les mots de passe de base de données.
• Configurez AllowOverride/ AllowOverrideListpour n'autoriser que les directives qu'un pirate ne pourrait pas exploiter. Je pense que cela est moins préoccupant si les éléments ci-dessus sont effectués correctement.

J'irais avec MPM ITK si ce n'était pas si lent et ne s'exécutait pas en tant que root, mais nous souhaitons spécifiquement utiliser un Apache partagé tout en nous assurant qu'il est fait en toute sécurité.

J'ai trouvé http://httpd.apache.org/docs/2.4/misc/security_tips.html , mais ce n'était pas complet sur ce sujet.

S'il est utile de le savoir, nous prévoyons d'utiliser CloudLinux avec CageFS et mod_lsapi.

Y a-t-il autre chose à faire ou à savoir?

EDIT 20 juillet 2015: Les gens ont soumis de bonnes solutions alternatives qui sont utiles en général, mais veuillez noter que cette question ne concerne que la sécurité d'une configuration Apache partagée. Plus précisément, y a-t-il quelque chose qui n'est pas couvert ci-dessus qui pourrait permettre à un site d'accéder aux fichiers d'un autre site ou compromettre d'autres sites d'une manière ou d'une autre?

Merci!

Je suis entièrement d'accord avec les articles que vous possédez jusqu'à présent.

J'avais l'habitude d'exécuter une telle configuration multi-utilisateurs il y a quelques années et j'ai essentiellement trouvé le même compromis: mod_php est rapide (en partie parce que tout se déroule dans le même processus) et suexec est lent mais sûr (car chaque demande crée un nouveau processus). Je suis allé avec suexec, car l'isolement des utilisateurs était requis.

Actuellement, il existe une troisième option que vous pourriez envisager: donner à chaque utilisateur son propre démon php-fpm. La faisabilité dépend du nombre d'utilisateurs, car chacun d'eux doit obtenir au moins un processus php-fpm à l'aide de son compte utilisateur (le démon utilise ensuite un mécanisme de type préfork pour évoluer pour les demandes, donc le nombre de processus et leur utilisation de la mémoire peut être un facteur limitant). Vous aurez également besoin d'une génération de configuration automatisée, mais cela devrait être possible avec quelques scripts shell.

Je n'ai pas utilisé cette méthode dans de grands environnements, mais à mon humble avis, c'est une bonne solution pour fournir de bonnes performances de site 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 voir 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. Donc, même si chaque site et ses processus et scripts correspondants sont correctement emprisonnés et que tout a son propre utilisateur et les autorisations qu'un pirate avec root s'en fiche, ils contournent 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 OS. Cela vous permet, en tant qu'administrateur système, de ne pas vous soucier d'un seul site compromis. Si un pirate prend racine en exploitant php (ou tout autre logiciel) sur la machine virtuelle d'un site, il suffit de suspendre la machine virtuelle et de la disséquer plus tard, d'appliquer des correctifs ou de revenir à un état ininterrompu. Cela permet également aux administrateurs de site d'appliquer un logiciel ou un paramètre de sécurité spécifique à leur environnement de site spécifique (ce qui pourrait endommager un autre site).

La seule limitation à cela est votre matériel, mais avec un serveur décent et les extensions de noyau correctes, c'est facile à gérer. J'ai réussi à exécuter ce type de configuration sur un Linode, étant donné que l'hôte et l'invité étaient très très rares. Si vous êtes à l'aise avec la ligne de commande que je suppose que 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 gérer tout le reste site par site.

Je suggérerais que chaque site fonctionne sous son propre démon Apache et chroote Apache. Toute fonction php du système échouera car l'environnement chroot Apache n'aura pas accès à / bin / sh. Cela signifie également que la fonction mail () de php ne fonctionnera pas également, mais si vous utilisez un fournisseur de messagerie externe pour envoyer du courrier à partir de votre application de messagerie, cela ne devrait pas vous poser de problème.

SELinux pourrait être utile avec mod_selinux. Un guide rapide est présenté ici:

Comment puis-je utiliser SELinux pour confiner des scripts PHP?

Les instructions étant un peu datées, j'ai vérifié si cela fonctionne sur RHEL 7.1:

J'ai utilisé la version de Fedora 19 et compilé avec une simulation contre RHEL 7.1 + EPEL.

YMMV si vous utilisez la maquette de configuration epel de base livrée avec:

[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 qu'il selinux-policyest à jour.

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

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

Maintenant, vous devez attribuer à chaque hôte virtuel dans apache une catégorie. Cela se fait 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 pour chaque hôte, renommez leurs racines de document dans la même catégorie que celles étiquetées dans la configuration httpd.

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

Si vous souhaitez que l'étiquetage soit honoré si vous effectuez un réétiquetage du système, vous feriez mieux de mettre à jour la politique locale aussi!

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 consulter ici: https://security.stackexchange.com/q/77/52572 et conseils pour sécuriser un serveur LAMP ), mais je voudrais quand même mentionner ici un point important (sous un autre angle encore) sur la sécurité: la sécurité est un processus . Je suis sûr que vous y avez déjà pensé, mais j'espère toujours qu'il pourrait être utile (aussi pour d'autres lecteurs) de parfois y repenser.

Par exemple, dans votre question, vous vous concentrez principalement sur les mesures techniques: "cette question ne concerne que la sécurité d'une configuration Apache partagée. Plus précisément, y a-t-il des étapes de sécurité importantes à prendre mais qui manquent dans la liste ci-dessus lors de l'exécution partagée Apache et PHP. "

Presque toutes les réponses ici et sur les 2 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, que si vous configurez votre serveur selon les meilleures pratiques une fois, vous restez en sécurité pour toujours. Alors n'oubliez pas les points qui me manquent dans les réponses:

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

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

3. Surveillez votre système. Je manque 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.

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

   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 transférer vos journaux vers un serveur syslog séparé, et recevoir des notifications par courrier électronique sur les é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 une surveillance et que vous le révisiez régulièrement en fonction de votre cycle "Planifier-Faire-Vérifier-Agir" .

4. Soyez conscient des vulnérabilités. Identique à la surveillance. Abonnez-vous simplement à une liste de vulnérabilités pour être averti, lorsqu'une vulnérabilité critique est découverte pour Apache ou un autre service important pour votre configuration. Le but est d'être informé des choses les plus importantes qui apparaissent avant votre prochaine mise à jour prévue.

5. Ayez un plan que faire en cas d'incident (et mettez-le régulièrement à jour et révisez-le en fonction de votre cycle "Planifier-Faire-Vérifier-Agir"). 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 ici uniquement de mesures techniques comme «réinstaller le système d'exploitation»: où devez-vous signaler un accident conformément à 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 la principale personne responsable est en vacances / malade?

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

7. Tests de pénétration? (encore une fois, 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 pour détecter les logiciels malveillants et les problèmes de sécurité.

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

Chaque conteneur peut représenter un client ou un client, avec des ID utilisateur uniques attribués à chaque groupe de conteneurs Apache comme sécurité supplémentaire. La clé serait de supprimer les privilèges root au démarrage du conteneur, avant de démarrer votre pile apache. Chaque client obtient son propre service de base de données avec ses propres mots de passe uniques, sans avoir à gérer des dizaines de machines virtuelles, chacune nécessitant ses propres noyaux de flocons de neige spéciaux et autres frais généraux. Après tout, au cœur de docker se trouve le chroot. Correctement administré, je prendrais cela sur un cluster virtuel typique tous les jours.

Beaucoup de bonnes suggestions ici déjà. Il y a cependant des choses qui ont été manquées jusqu'à présent.

Faites attention aux processus en dehors de ceux exécutés dans le cadre de la diffusion de pages Web. Par exemple, assurez-vous que tous vos travaux cron qui touchent des données non fiables s'exécutent en tant qu'utilisateur approprié et dans la prison appropriée, que ces travaux soient définis 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'autrement, et le logiciel d'analyse des journaux n'est pas soumis à autant d'audits de sécurité que nous le souhaiterions. Bien faire cela est un peu délicat et dépend de la configuration. D'une part, vous ne voulez pas que votre processus apache appartenant à la racine (c'est-à-dire le processus parent) écrive dans un répertoire que l'utilisateur pourrait compromettre. Cela signifie probablement ne pas écrire directement dans la prison. D'un autre côté, vous devez mettre ces fichiers à la disposition des processus de la prison pour analyse, et vous souhaitez que cela soit aussi proche que possible du temps réel. Si vous pouvez donner à vos prisons accès à un montage en lecture seule d'un système de fichiers avec les journaux, cela devrait être bien.

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 des informations directement dans les prisons de l'environnement hôte? Si tel est le cas, cela ouvre une série de préoccupations.

.htaccessles fichiers sont évidents, où vous devez faire très attention à ce que vous autorisez. De nombreuses applications php, sinon la plupart, sont très dépendantes des arrangements de fichiers .htaccess que vous ne pouvez probablement pas autoriser sans renverser votre schéma prévu.

Quoi qu'il en soit, la façon dont Apache décide ce qu'est un fichier statique est moins évidente. Par exemple, que fait-il avec un fichier *.php.gifou *.php.en? Si ce mécanisme ou un autre trompe la discrimination quant à 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 distinct pour le contenu statique, qui n'est configuré avec aucun module pour exécuter le contenu dynamique, et je disposerais d'un équilibreur de charge qui déciderait quelles demandes envoyer au serveur statique et lesquelles au dynamique.

En ce qui concerne la suggestion de Stefan 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 ainsi en mesure de servir le contenu statique, qui est à peu près le même que dans le paragraphe précédent. Je recommande Docker parmi les différentes approches de type prison, mais avec celle-ci ou d'autres approches de type prison, 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 basée sur le style PAAS? Comment rendre les journaux générés à l'intérieur du conteneur accessibles, et les rouler? 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 c'est le cas, est-ce un autre démon dans le conteneur? etc.

La première chose que je ne vois pas est la gestion des processus, donc un processus ne peut pas affamer un autre processus de CPU ou de RAM (ou d'E / S d'ailleurs, bien que votre système de fichiers puisse être architecturé pour empêcher cela). Un avantage majeur d'une approche «conteneurs» de vos instances PHP par rapport à une tentative de les exécuter toutes sur 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 design, mais c'est quelque chose à considérer.

Quoi qu'il en soit, revenons au cas d'utilisation de PHP fonctionnant derrière Apache fonctionnant essentiellement comme un proxy. suexec n'empêche pas quelque chose de s'exécuter en tant qu'utilisateur apache - il offre la possibilité de s'exécuter en tant qu'autre utilisateur. Donc, une préoccupation va être de s'assurer que tout est fait correctement - la page de documentation pour cela appelle ce danger potentiel: https://httpd.apache.org/docs/2.2/suexec.html . Donc, vous savez, du grain de sel et tout ça.

Du point de vue de la sécurité , il peut être utile d'avoir un ensemble restreint de binaires utilisateur de travailler avec ( ce qui cagefs les fournitures), en particulier si elles sont compilées différemment ou contre une autre bibliothèque (par exemple , celui qui ne comprend pas les fonctions non désirées) , mais la le danger est qu'à ce stade 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). Cependant, puisque vous suivez probablement déjà une distribution spécifique avec cloudlinux, c'est un risque incrémentiel, pas nécessairement intéressant en soi.

Je laisserais AllowOverride là où vous l'auriez voulu. L'idée de base de la défense en profondeur est de ne pas compter sur une seule couche pour protéger l'ensemble de votre pile. Supposez toujours que quelque chose peut mal tourner. Atténuez lorsque cela se produit. Répétez jusqu'à ce que vous ayez atténué le mieux possible, même si vous n'avez qu'une seule clôture devant vos sites.

La gestion des journaux va être la clé. Avec plusieurs services exécutés dans des systèmes de fichiers isolés, l'intégration d'activités pour établir une corrélation en cas de problème peut être un problème mineur si vous ne l'avez pas configuré depuis le début.

C'est ma décharge cérébrale. J'espère qu'il y a quelque chose de vaguement utile là-dedans. :)