Que recommandez-vous pour la mise en place d'un serveur partagé avec php [fermé]

Question

Que recommandez-vous pour configurer un serveur partagé avec php du point de vue sécurité / performances?

• Apache mod_php (comment sécurisez-vous cela? autre que safe_mode car il ne sera pas en PHP6)
• Apache CGI + suexec
• Lighttpd et générer un FastCGI par utilisateur

LE: Je ne suis pas intéressé par l’utilisation d’un panneau de commande déjà créé, j’essaie d’écrire le mien, alors je veux savoir quelle est la meilleure façon de le configurer moi-même. Je pensais utiliser Lighttpd et créer un fastcgi pour chaque utilisateur hébergé faisant exécuter le processus fcgi sous ses informations d'identification (il existe un tutoriel pour cela sur le wiki lighttpd). Ce serait un peu sécurisé, mais cela affecterait les performances (beaucoup d’utilisateurs / mémoire nécessaire pour chaque fcgi), au point que ce n’est pas une solution viable?

Answer 1

Personnellement, bien que Lighttpd soit OK, je choisirais Nginx + FastCGI si vous utilisiez un serveur Web léger + une solution FastCGI. J'ai exécuté des tests de performance et lu tout le code, et Nginx est un ordre de grandeur plus rapide / plus stable sous charge - c'est très bon.

Mais ce n’est pas ce que vous avez demandé. En gros, je dirais qu’il ya un large éventail de compromis entre sécurité et évolutivité / vitesse dans les trois options que vous avez énumérées, et qu’il vous suffit de décider où vous voulez aller. Si vous êtes un fournisseur d'hébergement partagé avec des utilisateurs non fiables en installant des applications PHP géniales, vous vous intéresserez davantage à la sécurité. Si cette fonctionnalité est partagée entre des utilisateurs plus fiables, vous pourriez vous intéresser davantage aux performances. Voici mes pensées:

CGI + suexec: : il s'agit de loin du plus sûr et du plus efficace / évolutif en termes de nombre d'utilisateurs / de sites dans un environnement d'hébergement partagé. Les processus sont générés et la mémoire utilisée uniquement lorsque les demandes arrivent. Bien entendu, la génération CGI en fait le temps le plus lent pour l'exécution de scripts individuels. Combien plus lent? Il faudrait bien évaluer les performances, mais généralement, si les utilisateurs exécutent des applications de longue durée (par exemple WordPress, qui prend 0,25 à 0,5 seconde pour charger ses bibliothèques et s'initialiser à chaque requête), la pénalité générée par CGI commence à être jolie. négligeable dans le contexte.

FastCGI: Le problème ici (peu importe si votre serveur Web est Apache, Lighttpd ou Nginx) consiste à déterminer le nombre de processus enfants FCGI que vous laissez chaque utilisateur s'exécuter, car chaque processus mange de la mémoire égale à la taille de l'interpréteur PHP (sous Linux, tout n'est pas câblé, bien sûr, mais je digresse). Et, contrairement à mod_php, ces processus ne sont pas partagés entre les utilisateurs. Vous devez donc limiter le nombre d'utilisateurs. Par exemple, Dreamhost limite ce nombre à 3 pour ses clients. Désormais, pour un client exploitant un site Web qui reçoit des rafales de plus de 2 à 5 pages vues par seconde, c'est en fait assez dommage, car ces demandes se superposent et le site se bloque. Maintenant, j'aime FastCGI avec un serveur Web léger lorsque j'exécute des applications sur un serveur / cluster dédié , lorsque je peux donner à l'application des centaines d'enfants FCGI (tous avec des privilèges de serveur Web bien sûr, à la Apache / prefork + mod_php). Mais, je ne pense pas que cela ait du sens pour l’hébergement partagé où vous devez allouer / limiter les enfants FCGI par utilisateur.

Apache + mod_php: Le moins sécurisé, car tout fonctionne avec des privs de serveur Web, mais votre pool de processus PHP en direct est partagé, de sorte que vos performances sont optimales. En tant que développeur, je ne peux pas tolérer le mode php_safe, et d’un point de vue administrateur système, il s’agit en réalité d’une illusion de sécurité (elle atténue les problèmes des utilisateurs stupides mais ne protège pas contre une attaque réelle); une autre option doit inclure safe_mode.

Dreamhost utilise une sorte d’hybride, Apache CGI + suexec par défaut, mais laisse le (petit) pourcentage d’utilisateurs plus sophistiqués choisir de faire de la FCGI s’ils le souhaitent, sous réserve d’un plafond et de leur propre surveillance. de l'utilisation de la mémoire. Cela économise une tonne de ressources mémoire par rapport à l'activation de FCGI pour tout le monde par défaut.

Un autre problème en matière d’hébergement partagé commercial standard est qu’Apache est complet, comporte des modules pour à peu près tout (y compris des choses comme mod_security que vous voudriez peut-être), et vos utilisateurs aimeront cela parce que tous leurs fichiers .htaccess. les configs fonctionneront, etc. - vous rencontrerez des problèmes de support technique lors de l’installation de Drupal, WordPress ou autre (un problème beaucoup moins grave si nous parlons d’utilisateurs internes).

Personnellement, je vous conseillerais de garder simple le démarrage et l'utilisation de CGI + suexec pour une sécurité et une évolutivité optimales. Si vos utilisateurs veulent FCGI ou mod_php et que vous avez un bon canal ouvert pour des suggestions / communications avec eux, ils le demanderont, mais l'un de ces problèmes est un casse-tête beaucoup plus important pour vous avec des améliorations de performances marginales pour eux, alors ma suggestion serait de ne faire l’un d’eux au début, mais d’être réactif s’ils le réclament.

Je sympathise avec le désir de faire quelque chose "d’intéressant". comme Lighttpd + FCGI au lieu du standard Apache + CGI + suexec, mais au fond, je ne peux vraiment pas le recommander.

Si vous utilisez plusieurs serveurs, vous pouvez éventuellement placer CGI sur certains serveurs et quelque chose d’autre pour les utilisateurs expérimentés des autres. Et assurez-vous d’avoir tous les répertoires www de cron grep pour des choses comme les anciennes versions de phpBB!

Answer 2

Je recommande Suhosin

Answer 3

En ce qui concerne PHP + FastCGI et la sécurité, vérifiez cet article de blog .

  

Le défi de la sécurité partagée   serveur d'hébergement est comment sécuriser le   site Web d'attaque à la fois de la   dehors et de l'intérieur. PHP a   fonctionnalités intégrées pour aider, mais   c’est finalement le mauvais endroit pour   résoudre le problème.

     

J'ai déjà écrit sur un certain nombre de   des solutions qui fonctionnent, mais une option   On m'a demandé maintes et maintes fois de   regardez utilise PHP + FastCGI. le   croyance est que l'utilisation de FastCGI   surmonter les problèmes de performance de   Suexec ou mod_suphp d’Apache, car   Les processus FastCGI persistent entre les pages   vues.

     

Mais avant que nous puissions regarder la performance,   la première question est: comment exactement   nous obtenons PHP et FastCGI en cours d'exécution en tant que   différents utilisateurs sur le même serveur Web   en premier lieu?

Answer 4

J'utilise InterWorx depuis environ un an et j'ai été très impressionné. Il maintient un serveur LAMP avec vos scripts pour la sécurité.

J'ai également utilisé Ensim , mais je ne l'ai pas trouvé aussi convivial, rapide et efficace. t ont autant de fonctionnalités. De plus, cela coûte beaucoup plus cher.