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


9

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!


attendez donc vous êtes ou ne bloquez-vous pas des commandes comme shell_exec
Michael Bailey

Ou plutôt des fonctions. Pas des commandes.
Michael Bailey

1
Correct - nous ne bloquons pas ces commandes. Parce que CageFS isole PHP à un tel degré, limiter ces commandes dans le cadre d'une approche de défense en profondeur ne semble pas valoir la peine étant donné que nous les utilisons parfois à des fins légitimes. Si le serveur était une cible de grande valeur pour les pirates (par exemple, les données de carte de crédit stockées ou quelque chose comme ça), alors les avantages pourraient l'emporter sur les inconvénients, mais dans notre cas, je ne pense pas que la restriction soit justifiée. C'est quelque chose qui vaut vraiment la peine d'être envisagé pour les personnes qui n'utilisent pas CageFS ou une solution équivalente.
sa289

1
Malheureusement, vous avez réduit les bonnes réponses grâce à CPanel - le reste appartient à l'histoire.
user9517

2
Voici un résumé des raisons pour lesquelles j'ai «actualisé» ces réponses. Apache dédié par site ou conteneurs Docker - nécessite plus d'adresses IP publiques dédiées ou une complexité supplémentaire de proxy inverse. Selinux - nécessite la configuration et l'exécution de selinux en mode d'application. VM - nécessite des ressources système supplémentaires par rapport à une configuration non VM. Je pense que ce sont toutes de bonnes solutions, mais pas sans inconvénients avec lesquels je préférerais ne pas aller.
sa289

Réponses:


9

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.


Corrigez-moi si je me trompe, mais je pense que la solution mod_lsapi + CageFS que nous prévoyons déjà d'utiliser pour PHP est au moins aussi bonne sinon meilleure que PHP-FPM, n'est-ce pas? Merci
sa289

Je n'ai aucune expérience avec mod_lsapi et aurais des réserves faisant confiance à une solution de fournisseur unique de source fermée. Mais selon sa page de publicité, il devrait être tout aussi bon et aussi rapide, oui. - Un point que j'examinerais est de savoir comment il engendre de nouveaux processus (sur de nouvelles demandes) et comment il change leur identifiant utilisateur effectif en l'utilisateur. En ce qui concerne la sécurité, c'est le point le plus faible; la documentation suexec a une bonne explication des choses à rechercher.
mschuett

Je suppose qu'il y a des raisons de ne pas faire confiance à hehe, qu'il soit fermé ou open source (Shellshock a mis 25 ans à découvrir, Heartbleed 2 ans, et qui connaît TrueCrypt). Heureusement, je pense que mod_lsapi est basé sur l'offre open source de LiteSpeed, donc il y a au moins quelques fournisseurs qui en examinent certains, plus ceux qui veulent regarder le code open source sur lequel il est basé. Je recherche en particulier les éléments de sécurité clés que je pourrais manquer dans la configuration proposée (par exemple, faire fonctionner PHP en tant qu'utilisateur du site mais oublier SuEXEC pour les scripts CGI). Merci
sa289

Nous utilisons cette approche (serveur Web avec php-fpm) sur des sites Web à grande échelle (où la batterie de serveurs Web se connecte à la batterie php-fpm via un équilibreur de charge). La beauté d'une telle configuration que les hôtes virtuels sont séparés au niveau du système d'exploitation et que la frontière n'est pas facilement contournée (assurez-vous simplement que le répertoire de base de l'hôte virtuel dispose d'autorisations comme 0710 avec la propriété de l'utilisateur vhost et du groupe du processus de serveur Web , alors c'est une question d'autorisations appropriées - si un fichier est lisible, il sera accessible au serveur web)
galaxy

4

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 suis d'accord qu'ils offrent une meilleure sécurité et présentent d'autres avantages, mais ils présentent également des inconvénients, dont certains que vous avez mentionnés. La prémisse de cette question est d'avoir un Apache partagé. Avec CageFS, les chances d'un exploit root devraient être réduites - pas aussi efficacement qu'une machine virtuelle, mais à un niveau qui me fait du bien étant donné les sites que nous utilisons. Mon objectif principal est d'éviter tout faux pas dans une bonne sécurité, de sorte que cela devrait être une tempête parfaite pour que quelqu'un puisse accéder à la racine. Par exemple, j'aurais pu facilement voir ne pas connaître les attaques de liens symboliques dans le passé et cela avait été une grave erreur. Thx
sa289

4

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.


Je voudrais le faire de cette façon - nous l'avons fait de cette façon dans le passé (moins le chrootage), mais malheureusement, cela nous empêche d'utiliser une configuration de panneau de contrôle standard et il faut également plus d'adresses IP dédiées à moins de faire plus - configuration de proxy inverse compliquée avec écoute Apache sur les adresses IP internes comme celle documentée sur le site Apache.
sa289

Ah oui, c'est un bon point que vous avez mentionné ici. Cela nécessitera certainement d'avoir plus d'IP dédié IP ou de revenir à un proxy inverse.
Alpha01

Si quelqu'un qui lit cette réponse est intéressé par la documentation de la configuration du proxy inverse, consultez wiki.apache.org/httpd/DifferentUserIDsUsingReverseProxy
sa289

4

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(/.*)?'

J'aime l'idée de cela, mais je dois activer selinux sur le serveur, ce qui peut entraîner d'autres difficultés. +1 cependant, car je pense que cela pourrait être une excellente solution pour les personnes qui ne s'en soucient pas.
sa289

4

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é.


1
Bon ajout à garder à l'esprit. Au cas où cela serait utile à quelqu'un, j'ai passé beaucoup de temps à parcourir les deux premiers liens que vous avez publiés et à quoi ils ont lié pour voir si je pouvais trouver quelque chose d'important que j'avais manqué. Les ressources liées à celles que je pensais être les plus utiles étaient cependant benchmarks.cisecurity.org/downloads/show-single/… et iase.disa.mil/stigs/app-security/web-servers/Pages/index.aspx . il y avait une quantité décente de chevauchement entre les deux. Je n'ai rien trouvé de majeur mais ça vaut quand même la peine d'être lu si la sécurité est primordiale.
sa289

3

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.


Cela signifierait-il qu'il y aurait effectivement un démon Apache dédié par client? Si oui, je pense que l'inconvénient serait similaire à la réponse d'Alpha01.
sa289

Oui, il est très similaire à Alpha01, bien que l'ancrage des applications enlève une grande partie du casse-tête de configuration de l'hôte. Cela dit, votre problème de panneau de configuration persiste, que vous utilisiez l'approche chroot / conteneur ou l'approche une machine virtuelle par client.
Stephan

Merci. Même sans panneau de contrôle, je préfère toujours éviter de faire un proxy inverse ou de demander plus d'adresses IP publiques à moins que je ne comprenne mal comment cette configuration fonctionnerait.
sa289

1
La plupart des magasins que j'ai vus (grands et petits) adoptent l'approche du proxy inverse. J'utilise HAProxy personnellement, il est idéalement adapté au type d'isolement à grande échelle que vous recherchez. Il est très performant et vous permet de faire évoluer horizontalement très efficacement, et ne nécessite pas le genre de complexité exotique qui semble être évidente dans la solution de mschuett.
Stephan

2

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.


Merci. Pour répondre à votre question - il n'est pas possible pour PHP de s'exécuter en dehors de la prison même si une extension de fichier différente est utilisée en raison de CageFS pour autant que je sache. J'ai essayé les deux SetHandleret AddTypefaire en sorte qu'une nouvelle extension soit traitée en PHP et elle a été emprisonnée. Je ne sais pas s'il y a un moyen de contourner cela, mais c'est ce que j'espère que quelqu'un signalera si j'ai raté quelque chose. Oui, Apache lit directement des prisons. Bon point de vue sur les tâches cron - il semble que diverses choses comme ça qui s'exécutent en tant que root sont une source de nombreuses vulnérabilités signalées.
sa289

RE: .htaccessdans le AllowOverrideList utilisé I conf pour permettre ces: Add{Charset,DefaultCharset,Encoding,Handler,OutputFilter,OutputFilterByType,Type} Allow Auth{GroupFile,Name,Type,UserFile} Deny DirectoryIndex ErrorDocument Expires{Active,ByType,Default} FileETag ForceType Header IndexIgnore Order php_flag php_value Redirect RedirectMatch Remove{Handler,Type} RequestHeader Require Rewrite{.various.} Satisfy Set{Env,EnvIf,EnvIfNoCase,Handler} SSLRequireSSL. Ma préoccupation est AddType, AddHandler et SetHandler, mais Drupal utilise SetHandler pour la défense en profondeur dans les répertoires de téléchargement de fichiers par exemple.
sa289

Si vous autorisez des personnes à bricoler des gestionnaires, vous devez passer par toutes les actions définies et vous assurer qu'elles sont sûres, pas seulement php.
mc0e

Bon point! J'ai confirmé SetHandler server-infoou SetHandler server-statusdans un fichier htaccess est une façon pour quelqu'un de faciliter une attaque ou de divulguer des informations qui, idéalement, ne seraient pas divulguées, comme tous les VirtualHosts sur le serveur (qui pourraient être utilisés pour le hameçonnage par exemple) ou le trafic actuel vers d'autres sites . Je devrais peut-être simplement recourir à la suppression de certains de ces gestionnaires / types de mon AllowOverrideList. Connaissez-vous une liste de toutes les actions / gestionnaires possibles? J'ai essayé de chercher en ligne mais je n'ai pas trouvé de bonne réponse.
sa289

1
Vous a décerné la prime parce que notre discussion a conduit à la vulnérabilité de divulgation d'informations que je n'avais pas couverte. Veuillez me faire savoir si vous avez une réponse concernant la liste des actions / gestionnaires. Thx
sa289

1

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. :)


Merci. Pour aider à résoudre le problème de ressources que vous avez mentionné, CloudLinux a quelque chose appelé Lightweight Virtual Environment (LVE) et MySQL Governor.
sa289

C'est très cool.
Mary
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.