Sécuriser un serveur Apache avec PHP : suPHP

Ce billet fait suite aux précédents billets sur le sujet de la sécurisation d’Apache avec PHP à savoir la problématique et un premier élément de réponse. Pour résumer rapidement, nous avons vu les problèmes que posait une installation par défaut d’Apache supportant le PHP dans le cas d’un serveur web mutualisé tel qu’on pourrait le trouver chez un hébergeur. Nous avons ensuite vu comment la configuration PHP pouvait influer sur la sécurité de l’installation.  Dans ce billet, nous allons voir la configuration et l’utilisation de suPHP.

Objectif

J’avais parlé de la problématique des droits avec lesquels s’exécutent les scripts PHP ainsi que du fait qu’il n’y ait qu’un seul fichier de configuration PHP pour tous les sites présents sur une même machine. Le module Apache dénommé suPHP va permettre de répondre à ces deux problématiques et de rajouter même quelques fonctionnalités supplémentaires. Si on va sur leur site, on se rend bien compte que l’objectif de suPHP est d’exécuter les scripts PHP avec les droits du propriétaire du script. Ceci va nous permettre d’attribuer un utilisateur par site et donc d’obtenir un meilleur cloisonnement. Nous verrons par la suite plus en détail la configuration et les possibilités offertes par suPHP.

Installation de suPHP

Sur une distribution de type Debian, l’installation se fait via le gestionnaire de paquet traditionnel apt-get.

# apt-get install libapache2-mod-suphp

# a2enmod suphp

Sur les autres distributions, vous pourrez soit passer par le gestionnaire de paquet soit par la compilation à la main. Comme pour tous les modules Apache, la compilation à la main est très simple et efficace. Il ne faut juste pas oublier de déclarer le module dans le fichier de configuration d’Apache.

Configuration de suPHP

Une fois que vous avez installé suPHP, vous n’avez finalement pas rajouté beaucoup de sécurité dans votre installation. Il va falloir s’atteler à la configuration. La première étape de la configuration est de s’assurer que chaque site ait son propre utilisateur. Sans cette mesure, suPHP est largement moins efficace. On va ensuite étudier le fichier de configuration de suPHP qui se trouve dans /etc/suphp/suphp.conf.

;Path all scripts have to be in
docroot=/data/www

Cette directive vous permet de configurer le répertoire dans lequel suPHP aura le droit d’exécuter des scripts PHP. Les scripts en dehors de ce répertoire ne seront pas exécutés et le serveur web affichera une erreur 500 (Internal Server Error).

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

Ce jeu de directives va vous permettre d’autoriser ou non vos utilisateurs à mettre des droits très élargis à leur fichiers. Par exemple, si vous activez la première directive, suPHP refusera d’exécuter les scripts PHP qui permettent l’écriture par le groupe du propriétaire du fichier. A vous de voir si vous voulez implémenter ce type de restrictions. Je ne trouve pas ca très utile si vous avez bien réglé la directive PHP open_basedir.

; Minimum UID
min_uid=100
; Minimum GID
min_gid=100

Ce jeu de directives vous permet de paramétrer l’UID et le GID minimal avec lequel peuvent être exécutés des scripts PHP.  Ceci va vous permettre d’éviter que des scripts soient exécutés avec l’utilisateur www-data voire root. Il existe d’autres lignes de configuration que je n’ai pas explicitées ici. Je vous invite à consulter la documentation pour en savoir plus.

Configuration du VirtualHost

Une fois que nous avons correctement configuré suPHP, il n’est toujours pas actif. Il va falloir l’activer au cas par cas en fonction du VirtualHost. Ceci permet d’avoir une meilleur finesse de réglage quant à l’activation de ce module. Rien de plus simple pour l’activer il suffit de rajouter la ligne suivante dans le VirtualHost.

suPHP_Engine On

On va pouvoir ensuite rajouter plusieurs réglages fournis par suPHP afin d’implémenter plus de sécurité et de flexibilité. Comme je vous en avais parlé précédemment, il va être possible d’attribuer un fichier php.ini par VirtualHost. Il est essentiel que vos clients ne puissent pas modifier ce php.ini directement. Si cela est possible, il sera possible à n’importe qui de modifier la directive open_basedir supprimant ainsi un niveau de sécurité. On va donc rajouter la directive suivante :

 suPHP_ConfigPath /data/www/********.com/priv/php.ini

Au final, à travers ces trois billets nous avons pu faire un tour d’horizon permettant la sécurisation d’un serveur Apache doté de PHP. Je pense que l’implémentation des fonctionnalités présentées à travers ces trois billets permet d’atteindre un niveau de sécurité correct sur un serveur web mutualisé. Il n’existe bien sûr par de sécurité parfaite. Il faut surtout adopter une hygiène de configuration et de paramétrage en association avec la configuration correcte des modules associés.