Sécuriser php en environnement multi-utilisateurs ou multi-sites

La hantise de tout admin serveur web: que tout tombe.
Le problème: une mini faille sur un site inutile, completement oublié et donc pas à jour peut suffire à TOUT faire tomber … (on se souvient du cas de sivit)
La solution: tout tenir toujours à jour, tout développer comme une bete et non pas à l’arrache à coup de « Ca marche c’est bon », ne pas utiliser de cms … ?
Facile à dire …

Je vous parle ici surtout du cas de php utilisé dans 99% des sites web dynamiques et je vais essayer de vous présenter quelques astuces ou solutions pour vous éviter le pire.

Exemple concret:
Un client/pote à installé un phpBB il y a 3 ans sur votre serveur, autant dire qu’il n’est pas à jour.
Un gentil pirate se pointe et grace à une faille sur ce pauvre petit forum de 10 visiteurs/an accède à tous les fichiers du serveur, serveur qui contient une dizaine d’autres sites extremement importants.
Sans protections spéciales mises en place le vilain peut modifier / effacer … TOUT les fichiers / dossiers de TOUT le serveur auxquels apache à accès !
Suivant donc comment vous configurer vos groupes ca peut faire très très mal !

Heureusement il existe quelques solutions qui nous permettent de sécuriser un peu php via son l’UID ou le parker dans une zone bien definie (ou les deux) et votre shop ecommerce ne tombera plus à cause de vos photos de vacances mises en ligne avec un script datant de mathusalem 😉

Il y a différentes écoles toutes avec leurs avantages et inconvenients pour parker php dans son coin ou bidouiller ses droits:

SUPHP

suPhp est un module apache qui permet d’éxecuter les scripts php avec les permissions de leurs propriétaires.
Avantages:

• User1 ne pourra pas modifier les fichiers de User2.
• De base apache pourra modifier les fichiers de user1 s’il se trouve sur le site web de user1, plus besoin de chmoder.

Si vous installez suphp, il vous suffit donc par exemple de créer un user par site ou si vous créez un nouvel users, vous êtes sur qu’il ne pourra venir foutre le merdier chez vous.

Inconvenient:

• Cela ralentirait quelque peu le serveur
• Il vaut mieu avoir mis cette technique en pratique dès le départ
• Un user par sites si vous en avez beaucoup ca commence à être lourd a gérer
• Tout le monde n’a pas envie qu’apache puisse modifier tous ces fichiers …

Un exellent tuto la dessus: suphp apache 2 php4 et php5

SUEXEC

La fonctionnalité suEXEC — introduite à partir de la version 1.2 d’Apache — donne aux utilisateurs d’Apache la possibilité d’exécuter des programmes CGI et SSI sous des UID distincts de l’utilisateur associé au serveur Web lui-même. Normalement, lorsqu’un programme CGI ou SSI s’exécute, il tourne sous le même utilisateur que le serveur Web.

Correctement utilisée, cette fonctionnalité peut réduire considérablement les risques lorsque l’autorisation est donnée aux utilisateurs de développer et d’exécuter leurs propres programmes CGI ou SSI. Cependant, si suEXEC n’est pas correctement configuré, de nouveaux problèmes peuvent apparaître, voire de nouveaux « trous » dans votre dispositif de sécurité. Si vous n’êtes pas un familier de la gestion des programmes sous setuid root et de leurs implications sur la sécurité, nous vous recommandons fortement d’éviter d’utiliser suEXEC.
( source )

Les inconvenients sont sensiblement les même que suphp avec en prime une config un poil plus complexe.

Un tuto la dessus égallement: installation-de-apache-php-5-en-cgi-mode-suexec

Open_basedir

Denière métthode de ce papier, l’open_basedir.
Contrairement à suphp ou suexec, l’open basedir ne fonctionne pas par rapport aux utilisateurs mais par dossier:
Si vous tentez d’ouvrir un fichier, php verifie que ce dernier ce sirue bien dans la zone autorisée et si non: il vous refoule.
Vous ne changez donc pas l’UID d’apache, vous indiquez simplement la zone ou php à le droit d’agir.

Avantages: vous pouvez très bien mettre en place cette fonctionnalité une fois le serveur déjà en production car vous n’ajoutez pas de mod apache, open_basedir se configure via les virtualhost apache et peut être automatisé.

Exemple de fichier de configuration:

>VirtualHost *:80<
        ServerAdmin admin@domain.tld
        DocumentRoot /srv/web/domain.tld/htdocs
        ServerName domain.tld
        php_admin_value open_basedir PATH1:PATH2:PATH3
>/VirtualHost<

Attention au "<" et ">" autour de virtualhost à inverser.
La ligne qui nous intéresse est php_admin_value open_basedir.
Remplacez PATHX par les chemins absolus à autoriser. Vous pouvez égallement indiquez "." pour autoriser uniquement le dossier courant (attention modifiable par php ...).

Attention, terminez bien vos path par "/" sinon apache interpretera le path comme path*
Exemple: /var/www/monsite fonctionnera pour /var/www/monsite2, /var/www/monsitecestdlaballe .... à l'inverse de /var/www/monsite/
Sous linux le caractère de séparation des différents chemin est ":" sous windows, c'est ";"

Enfin, n'hésitez pas à jeter un oeil à la doc à apache la dessus et tout particulièrement la page sur les hébergements de masse et la page du wiki dedié à la sécurisation de php lien

Si vous conaissez d'autres astuces je suis preneur ;)