Antoine Benkemoun

11 Juil, 2009

Sécuriser un serveur Apache avec PHP : suPHP

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

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

3 Commentaires to "Sécuriser un serveur Apache avec PHP : suPHP"

1 | Seza

juillet 11th, 2009 at 12 h 32 min

Avatar

Je ne comprend vraiment pas l’intérêt de suPHP ?

Surtout que l’affirmation suivante est fausse :

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

Tu peux paramétré PHP par virtual host indépendamment les un des autre avec les commande php_admin etc…, tu as les .htaccess qui te permettre encore de modifié la config de php par dossier. Et aujourd’hui tu as la possibilité d’utiliser un php.ini par dossier comme le .htaccess.

Le second point :
Cette directive vous permet de configurer le répertoire dans lequel suPHP aura le droit d’exécuter des scripts PHP.

La directive open_basedir de PHP est largement et effectue le même travail.

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 :
PHP s’execute avec les droits du serveur apache. lancé avec avec des droit trop important est dangereux !! Diminué les droits qu’obtient php c’est bien, réduire directement ceux d’apache c’est mieux (et suPHP devient alors inutile).

Personnellement, le seul avantage que peut offrir finalement suPHP c’est de pouvoir faire tourner php sous différent utilisateur. Même est-ce vraiment utile ?

– si c’est pour du multihosting, et donc plusieurs site, je trouve cela bien compliqué que chaque utiliseur est ses propres droit.
ça signifie avoir un utilisateur physique par site hébergé c’est énorme.

Personnellement pour du multihosting tout les utilisateurs sont sous les même droits ça me permet de branché un ftp sur leur site web sans avoir de problème de droit justement.

suPHP est apparu alors que les gens ne savais pas paramétré leur serveur ftp. du chaque compte ftp était équivalent à un utilisateur différent et donc un problème pour faire tourner php (souvent en safe mode) sur des fichier d’utilisateur diffférent que celui d’apache.

Pour du multihosting, savoir créer des utilisateurs virtuels ftp est la première case sécurité avant de passer à la configuration de apache et php.

Et dernier point. Si un utilisateur différent de celui d’apache à besoin de récupéré (lire/écrire/supprimé) des fichiers créer via php par exemple.
Il est très facile de mettre le répertoire en setgid sous un groupe X ou Y auquel l’utilisateur appartient et le problème est réglé.

2 | Ludo

juillet 11th, 2009 at 23 h 22 min

Avatar

J’ai bien peur que tu te mettes le doigt dans l’oeil.
La solution que tu proposes n’offre que des possibilités très limités, et la sécurité dans tout cela est bien maigre. Il suffit de trouver un moyen de sortir de la « cage » virtuelle qu’offre php via openbasedir (qui n’est pas très propre) pour supprimer les fichiers de tous tes utilisateurs.

Tu ne pourras pas non plus supporté d’autres langages que PHP. Tu ne peux pas leur donner un accès SSH.
Je vais pas commenter plus longtemps ta solution ma ça me semble vraiment la sécurité du pauvre.

Utiliser les possibilités des comptes UNIX est bien plus sécurisante.

Pour revenir sur ton billet précédent :
<>
Pour l’injection, c’est vrai, mais en un script PHP correctement fait (i.e. qui initialise ses variables, comme dans tous les autres langages) n’encour aucun risque. Après, il faut évidemment le désactiver parce que certains scripts sont mal faits :-)

3 | admin

juillet 12th, 2009 at 11 h 42 min

Avatar

Alors je vais répondre :-) Le but n’était pas d’offrir une sécurité absolue mais d’arriver à un niveau correct. Donc dire que ce n’est pas parfait, c’est vrai et ca n’avait pas pour but de l’être.

@Seza, l’option des .htaccess est pas acceptable. Les clients ont besoin d’avoir accès à leur .htaccess pour l’URL Rewriting entre autre. Tu es donc obligé de leur laisser un accès ce qui réduit la sécurisation à néant. Après, si tu as des clients qui n’ont pas besoin du .htaccess ta solution est bonne effectivement. J’ai parlé de l’open_basedir dans un article précédent, fallait lire =)
Avoir un compte UNIX par site, c’est pas bien compliqué. Un client = un FTP = un compte UNIX. C’est toujours le cas sur tous les serveurs web que j’ai rencontré… Il y a NIS pour synchroniser tout ca.
Le problème n’est pas dans le fait qu’Apache ait des droits augmentés mais que tous les sites aient les scripts PHP s’exécutent avec les mêmes droits.

@Ludo, le mécanisme que je propose permet l’implémentation de deux cages, open_basedir (cf article précédent) et suPHP. Ca fait donc un double mécanisme. Après, une fois de plus, on atteindra pas la perfection c’est sur mais ca permet d’atteindre un niveau correct. Sinon, tu as raison, la sécurité idéale c’est d’avoir des applis bien codées sauf que quand tu héberges des gens dans un contexte commercial tu ne les tries pas sur la qualité du code de leur application…

Sinon pour conclure, j’ai déjà implémenté ces deux mécanismes (suPHP + directives PHP) sur un serveur mutualisé dont des sites se sont fait hackés moultes fois et ca a toujours cloisonné le hack à un seul site. C’est donc un retour d’expérience qui a fonctionné après c’est très loin d’être exhaustif.

Ajoutez votre commentaire

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.