En bref : l'utilisateur du serveur web sous lequel PHP s'exécute devrait, selon le principe des droits minimaux (moindre privilège), lire uniquement ce dont le site a besoin et écrire uniquement là où il stocke des données. Il n'a ni shell de connexion, ni droits sudo, ni tâches cron propres, ni clés SSH, et son compte de base de données peut seulement lire et modifier des données. Des options systemd comme ProtectSystem et PrivateTmp confinent en plus PHP-FPM.
La question après l'intrusion : que peut faire ce processus ?
PHP2Shell concerne l'exécution de code malveillant à distance, sans authentification. Lorsque l'attaque réussit, le code ne s'exécute pas dans le vide, mais sous un utilisateur bien précis : celui du processus PHP. Tout ce que cet utilisateur peut faire, l'attaquant peut le faire dès cet instant.
Sur de nombreux serveurs, c'est étonnamment beaucoup. L'utilisateur possède l'ensemble du code du programme, dispose d'un shell, peut créer ses propres tâches cron, et le compte de base de données de l'application a tous les droits sur toutes les bases. Pour un attaquant, c'est la situation idéale pour s'installer durablement.
Le guide Droits d'accès aux fichiers sur le serveur web explique comment attribuer correctement fichiers et dossiers. Cet article se concentre sur le compte lui-même : connexion, privilèges spéciaux, tâches planifiées, base de données et limites que pose systemd.
État des lieux : qui est l'utilisateur du serveur web ?
Commencez par établir quels utilisateurs sont impliqués. Avec PHP-FPM, chaque pool définit avec user et group sous quel compte tournent ses workers. Avec mod_php, PHP s'exécute sous l'utilisateur d'Apache. Le fonctionnement conjoint du maître et des workers dans PHP-FPM est expliqué dans PHP-FPM expliqué : gestionnaire de processus, pools et workers. Les commandes suivantes sont en lecture seule :
# Sous quels utilisateurs tournent le serveur web et PHP ?
ps -eo user,group,cmd | grep -E "[p]hp-fpm|[n]ginx|[a]pache2|[h]ttpd" | sort | uniq -c
# Informations du compte : répertoire personnel et shell (adapter l'utilisateur)
getent passwd www-data
# L'utilisateur a-t-il des droits sudo ?
sudo -l -U www-data
# Tâches cron propres ?
sudo crontab -l -u www-data
# Clés SSH dans le répertoire personnel (sous Debian/Ubuntu, c'est /var/www)
sudo ls -la /var/www/.ssh 2>/dev/null
Notez les résultats pour chaque utilisateur de pool. Si tous les sites tournent sous le même utilisateur, c'est le premier point de la liste ; la séparation est décrite dans Isoler les pools PHP-FPM site par site.
Droits de l'utilisateur du serveur web : ce dont le compte n'a pas besoin
Le tableau suivant montre ce dont un utilisateur du serveur web n'a généralement pas besoin et comment le lui retirer.
| Droit | Pourquoi c'est dangereux | Recommandation |
|---|---|---|
| Shell de connexion | Connexion et usage interactif possibles | Shell /usr/sbin/nologin |
| Entrées sudo | Chemin vers les droits root | aucune entrée, pas même pour une commande isolée |
| Crontab propre | Porte dérobée durable qui survit à chaque redémarrage | aucune, limiter via /etc/cron.allow |
| Clés SSH | Connexion depuis l'extérieur | aucun authorized_keys |
| Propriété du code du programme | Le code peut être modifié | Le propriétaire est un utilisateur de déploiement |
| Droits d'écriture hors des dossiers de données | Dépôt de code malveillant | uniquement uploads, cache, temp |
| Droits complets sur la base de données | Bases d'autres applications, accès aux fichiers via la base | uniquement sa propre base, uniquement des droits sur les données |
Vous définissez le shell avec usermod -s /usr/sbin/nologin www-data. Pour cron : si /etc/cron.allow existe, seuls les utilisateurs qui y figurent peuvent créer leurs propres tâches cron. Des tâches cron récemment créées ou des clés SSH inconnues indiquent typiquement que quelqu'un s'est installé durablement. Un signal d'alerte particulièrement net est décrit dans l'article Signal d'alerte : le serveur web lance un shell.
La base de données : limiter les droits au nécessaire
Le compte de base de données d'un site est en pratique un second utilisateur du serveur web. Ses identifiants figurent dans le fichier de configuration de l'application et sont lisibles par du code injecté. Il ne devrait donc pouvoir faire que ce dont l'application a besoin en fonctionnement.
-- Exemple MySQL/MariaDB : un compte par site, uniquement des droits sur les données
CREATE USER 'seite1'@'localhost' IDENTIFIED BY 'hier-ein-langes-Zufallspasswort';
GRANT SELECT, INSERT, UPDATE, DELETE ON seite1.* TO 'seite1'@'localhost';
-- Vérifier les droits
SHOW GRANTS FOR 'seite1'@'localhost';
Un compte d'application n'a pas besoin de droits comme FILE, SUPER ou GRANT OPTION, ni d'un accès à *.*. De nombreux CMS exigent en outre CREATE, ALTER, INDEX et DROP pour les mises à jour. Il est plus propre d'utiliser un compte distinct pour les mises à jour et les migrations, employé uniquement pendant la maintenance. Vérifiez les exigences dans la documentation de l'éditeur.
Confiner PHP-FPM davantage avec systemd
systemd peut restreindre la vision du système qu'a un service. Pour PHP-FPM, quelques options de la documentation systemd conviennent particulièrement bien. Elles agissent aussi sur le processus maître, qui démarre sous root.
# sudo systemctl edit php8.3-fpm
[Service]
# /usr, /boot et /etc en lecture seule
ProtectSystem=full
# /home, /root et /run/user invisibles
ProtectHome=true
# /tmp et /var/tmp propres, réservés à ce service
PrivateTmp=true
# pas d'élévation de privilèges via setuid ou les capabilities de fichiers
NoNewPrivileges=true
Testez ces options avant la mise en production. Si des sites se trouvent sous /home, ProtectHome=true bloque l'accès. NoNewPrivileges=true peut perturber des programmes appelés par PHP qui changent de groupe au démarrage, par exemple certains programmes de messagerie locaux pour la fonction PHP mail(). Procédez donc par étapes :
- Ajouter une option, redémarrer le service, vérifier avec
systemctl status php8.3-fpm. - Tester les fonctions essentielles du site : connexion, formulaires, envoi d'e-mails, uploads, tâches cron de l'application.
- Analyser le journal d'erreurs de PHP-FPM et de l'application.
- Ensuite seulement, ajouter l'option suivante.
Pour finir, le socket : selon le manuel PHP, il reçoit par défaut les droits 0660 pour l'utilisateur et le groupe du pool. Définissez listen.owner et listen.group de sorte que seul le serveur web puisse s'y connecter, et non n'importe quel utilisateur local.
Les droits minimaux sont un état d'esprit, pas un projet ponctuel. Refaites l'état des lieux décrit dans cet article après chaque refonte et chaque nouveau site, car les nouveaux services apportent souvent des droits par défaut généreux.
Conclusion : l'attaquant hérite de ce que vous autorisez
Le moindre privilège semble théorique, mais c'est une question très pratique : que peut faire quelqu'un qui exécute du code en tant qu'utilisateur du serveur web ? Sur un serveur avec shell, entrée sudo, crontab propre et compte de base de données disposant de tous les droits, la réponse est : presque tout. Sur un serveur cloisonné, l'incident reste plutôt limité à un seul site, ce qui permet de le détecter et de l'assainir.
La mise en œuvre n'exige aucun nouveau logiciel, seulement un état des lieux soigneux et des tests progressifs. Commencez par les points qui risquent le moins de casser quelque chose, à savoir shell, sudo et clés SSH, puis passez aux droits de la base de données et aux options systemd.
Comment PHP SOS aide-t-il concrètement ?
- Contrôler les comptes : nous relevons, pour chaque pool et chaque serveur web, l'utilisateur, le shell, les entrées sudo, les tâches cron, les clés SSH et les droits de base de données.
- Réduire les droits : nous retirons ce qui n'est pas nécessaire et séparons les comptes de déploiement, d'exécution et de maintenance.
- Confiner les services : nous activons les options de protection systemd par étapes et testons le site après chaque étape.
- Maintenir dans la durée : dans le cadre du durcissement du serveur, nous documentons le concept de droits pour les modifications futures.
Questions fréquentes
Sous quel utilisateur PHP s'exécute-t-il sur mon serveur ?
Cela dépend du mode d'exécution. Avec mod_php, PHP s'exécute sous l'utilisateur d'Apache, par exemple www-data ou apache. Avec PHP-FPM, chaque pool définit son utilisateur avec user et group ; le processus maître tourne généralement sous root, les workers sous l'utilisateur du pool. La commande ps l'indique rapidement.
L'utilisateur du serveur web a-t-il besoin d'un shell de connexion ?
Non. Ni Nginx, ni Apache, ni PHP-FPM n'ont besoin d'une connexion interactive pour cet utilisateur. Un shell comme /usr/sbin/nologin empêche toute connexion avec ce compte. Les déploiements passent par un utilisateur distinct.
Pourquoi aucun droit sudo pour www-data, pas même pour une seule commande ?
Parce que le code injecté hérite exactement de ces droits. Une commande apparemment anodine, mal autorisée, peut mener à des droits root. Les tâches qui nécessitent des droits élevés relèvent de services ou de processus distincts, en dehors du serveur web.
Cela protège-t-il contre PHP2Shell ?
Cela ne corrige pas la faille : pour cela, il faut la mise à jour de PHP et le redémarrage de tous les workers. Des droits minimaux limitent toutefois ce qu'un attaquant peut faire après une exploitation réussie : modifier des fichiers, s'installer durablement, atteindre d'autres sites.