Antoine Benkemoun

06 juil, 2009

Sécuriser un serveur Apache avec PHP : début de solution

Posté par Antoine dans la catégorie Libre|Sécurité|Web

apache_logoCe billet fait suite au précédent qui avait pour objectif de vous faire une démonstration des problématiques liées au déploiement d’un serveur web mutualisé basé sur Apache. Je vais donc vous présenter des solutions permettant de résoudre ces problèmes.

Limites

Je n’ai pas la prétention de vous permettre de sécuriser parfaitement un serveur Apache. Je vous présente ici une série d’éléments que j’ai pu apprendre à travers mon précédent emploi. Il faut dire qu’un hack de serveur web toutes les deux semaines, ca force à s’occuper de la sécurité des serveurs web. J’exagère, hélas, à peine.

Ces solutions de sécurisation permettent d’éviter qu’un site puisse nuire aux autres sites sur le serveur web. Si un site mal codé dispose de failles de sécurité rendant possible une attaque sur lui même, je n’ai pas de solution coté serveur à vous proposer. Dans ce cas, il faut se plonger dans le code et réparer les failles de sécurité. Ces solutions permettront tout de même de vous prémunir d’une attaque sur toute votre plateforme et de pouvoir rejeter la faute sur vos clients.

Choix du logiciel PHP

Tout d’abord, lorsque vous installez un serveur web, il est fortement recommandé d’installer la version Suhosin. Il s’agit d’une version de PHP qui a été patchée pour réparer des failles de sécurités connues. La liste des améliorations est disponible sur leur site. Si vous avez fait le choix judicieux de prendre une distribution Debian, les versions de PHP qui sont livrées avec disposent d’office du patch Suhosin. Je ne sais pas ce qu’il est des autres distributions mais je doute que ce soit le cas partout.

Ensuite, il faut avoir une version PHP à jour. Ca parait peut être inutile de dire ca mais ca reste une condition essentielle. La mise à jour des logiciels permet de bénéficier de la réactivité des communautés en termes de mises à jour de sécurité. Ce serait quand même dommage de ne pas en profiter et de se faire compromettre un serveur à cause de failles connues depuis plusieurs mois.

Configuration de PHP

La configuration de PHP peut largement influer sur la sécurité du serveur web. Il existe de nombreuses fonctionnalités de PHP qui permettent de faire des choses intéressantes pour le développeur mais très inquiétant pour l’administrateur système.

Tout d’abord, la directive fopen est une directive qui devrait être désactivée par défaut. Cette directive permet d’ouvrir un fichier et ensuite de le modifier ou bien de le lire. Par défaut, si cette directive est activée, il est possible de lire n’importe quel fichier dont /etc/passwd. « Mais /etc/passwd, tout le monde ne peut pas le lire ! ». Et bien si, les droits sur les fichiers /etc/passwd sont de 644. Le monde entier pourra donc trouver la liste des comptes utilisateurs de votre machine sur le web.

Ensuite, si un de vos clients a besoin de la directive fopen, car elle peut quand même être utile. Vous allez donc devoir restreindre l’accès aux fichiers ce qui est possible dans PHP via la directive open_basedir. Grace à cette directive, vous allez donc contraindre vos clients à ne pas sortir de leur répertoire que ce soit pour l’exécution de scripts PHP ou la modification/lecture de fichiers.. Il est également généralement recommandé de désactiver la directive register_globals mais je ne suis pas capable de justifier pourquoi. Je sais juste qu’il s’agit d’une option qui n’est plus d’actualité dans les versions de PHP d’aujourd’hui (Plus d’informations sur ce site).

Grace à ces éléments, la sécurité de votre serveur web sera déjà bien améliorée. Afin de pouvoir aller encore plus loin et améliorer le niveau de sécurité, je vous présenterais suPHP la prochaine fois.

3 Commentaires to "Sécuriser un serveur Apache avec PHP : début de solution"

1 | Seza

juillet 11th, 2009 at 12 h 49 min

Avatar

Attends mais attends !!

Dans ton article précédent tu te permet une critique du comportement X programmeur débutant qui se prend pour un roi en la matière mais là je doit avouer que c’est toi qui passe pour le débutant qui se prend pour un roi de la sécurité !!

Tu ne sais pas de quoi tu parle !!

« Tout d’abord, la directive fopen est une directive qui devrait être désactivée …. »

Super php ne peut plus lire, écrire de fichier (tu peux arrêter ton article sur la sécurisation, suPHP et tout le blablabla ne servira à rien).

Tu confonds plutôt avec allow_url_fopen qui supprime la possiblité à php d’ouvrir des fichiers distant ce qui pourrait permettre à n’importe quel attaquant d’injecter du ce qu’il souhaite dans l’application.

« La directive fopen, car elle peut quand même être utile… Il parait. Vous allez donc devoir restreindre l’accès aux fichiers ce qui est possible dans PHP via la directive open_basedir »

Oui, oui rien que pour écrire un fichier de cache par exemple ! Alors deuxième boulette, le open_basedir restreint oui la possiblité d’ouvrir/écrire des fichier à droite et à gauche mais surtout, excuse moi, SURTOUT, permet de limité les dossier dans lesquels peuvent être lancé des scripts php par apache !!! (par exemple ne pas mettre dans l’open_basedir le dossier qui récupère les fichiers uploader par les utilisateurs de l’application web)

« Il est également généralement recommandé de désactiver la directive register_globals mais je ne suis pas capable de justifier pourquoi. Je sais juste qu’il s’agit d’une option qui n’est plus d’actualité dans les versions de PHP d’aujourd’hui. »

Et la c’est le bouquet, c’est la plus importante des chose à faire certainement !
register_globals permet de faire de l’injection de variable directement dans le script qui s’éxécute c’est super dangereux.
Lit ça http://www.php.net/manual/fr/security.globals.php pour ton éducation.

2 | admin

juillet 12th, 2009 at 11 h 51 min

Avatar

Alors je vais quand même te demander de rester correct, on est là pour discuter et pour corriger d’éventuelles erreurs. C’était un petit passage humoristique plus ou moins réussi dans mon précédent article, on fait ce qu’on peut… De plus, si je me mettais à coder du PHP, je tomberais sans aucun doute dans cette catégorie car je n’ai aucune connaissance en sécurisation de code.

Pour fopen, la plupart des sites conventionnels ne nécessitent pas l’écriture de fichiers mais passent plus par une base de données. J’estime qu’il est judicieux de le désactiver par défaut et puis de l’activer au cas par cas. J’ai effectivement oublié allow_url_fopen. Merci pour l’ajout.

Pour open_basedir, je n’ai effectivement pas précisé si il s’agissait d’ouverture de fichier ou d’exécution de scripts mais je pensais aux deux.

Merci pour la précision concernant register_globals, comme je l’ai précisé je n’avais pas eu d’explication quant à son utilité.

3 | ChRiiS

novembre 10th, 2010 at 16 h 21 min

Avatar

Modulo le ton, je suis assez d’acord avec Seza, surtout que j’arrive ici suite au commentaire sur le planete-libre ;)
Je ne vais donc pas paraphraser Seza, mais juste rajouter une remarque.
Tu dis :
« Pour fopen, la plupart des sites conventionnels ne nécessitent pas l’écriture de fichiers mais passent plus par une base de données. »
Mais même si wordpresse (dans ton exemple) utilise une BDD pour stocker pas mal de chose, à côté de ça tu es bien content d’avoir une image d’illustration pour tes articles, merci à php de pouvoir écrire dans wp-content ;)
Bon ok on pourrais ajouter un champs « url », uploader soit même le fichier sur le ftp, en déduire l’url et l’entrer. Faut quand même avouer que c’est beaucoup plus long qu’un champs avec un bouton parcourir (sans parler de la pérennité du/des fichier(s)) ;)

Ajoutez votre commentaire


  • Cdric: Bonjour, Ton article est pas mal mais au final je suis intrigué. Surtout par ton schéma. Si je regarde l'illustration de droite, on a : - m
  • ligne sip: perso je l'utilise tous les jours pour du pro. Il ya des coupure certes mais comme je forward sur le portable, il n'y a pasde discontinuite de serv
  • mophete: Bonjour, nous avons donc distingué 4 VRF, au lieu de 5, non ? ou alors j'ai loupé quelque chose ? En dehors de ca, les 3 articles sont...simpleme

A propos de ce blog

Ce blog a pour objectif de partager des informations avec tous les internautes. Comme indiqué dans le titre, je traiterais de différrents sujets gravitant autour de la sécurité informatique, de la virtualisation, de la l'administration système et du réseau.