En bref : durcir son serveur pour PHP, c'est faire en sorte qu'une seule faille n'ouvre pas tout le serveur. Nous séparons les sites les uns des autres, configurons PHP et le serveur web de façon sûre, restreignons les droits et les accès, et documentons chaque modification. Ainsi, les dégâts restent plus limités si quelque chose se produit malgré tout.
Pourquoi le durcissement est devenu plus important après PHP2Shell
PHP2Shell a montré avec quelle rapidité une faille dans PHP lui-même devient un problème pour tous les sites web d'un serveur. Avec CVE-2026-109618 et CVE-2026-109619, des attaquants peuvent exécuter du code sans authentification. Le correctif ferme cette porte. Le durcissement répond à une autre question : que peut faire quelqu'un qui parvient malgré tout à entrer, par cette faille ou par la suivante ?
Sur un serveur non durci, tous les sites web fonctionnent souvent sous le même utilisateur, PHP a le droit d'exécuter des commandes système, et les identifiants sont lisibles par tous les processus. L'intrusion dans un petit site annexe suffit alors pour atteindre la boutique en ligne. Un bon durcissement sépare ces domaines. Ce n'est pas une action unique, mais un état de base qui doit être maintenu pour chaque nouveau site web et chaque changement de version.
Durcir un serveur pour PHP : ce que nous ajustons concrètement
Isolation par site web
Chaque site web reçoit son propre utilisateur système et son propre pool PHP-FPM. Avec open_basedir et des droits de fichiers adaptés, une application ne voit que son propre répertoire. Pour en savoir plus, voir open_basedir et isolation par site web.
Configuration PHP sûre
Nous définissons php.ini et la configuration des pools de telle sorte que les applications ne puissent pas écraser elles-mêmes les valeurs relatives à la sécurité. Voici un extrait de ce à quoi cela peut ressembler dans un pool FPM :
; Valeurs imposées dans le pool FPM, non modifiables via ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
Les fonctions qu'il est possible de bloquer en plus dépendent de l'application. Des indications figurent sous Configurer php.ini de façon sûre et Bien utiliser disable_functions.
Droits sur les fichiers et accès en écriture
Le serveur web ne doit écrire que là où c'est nécessaire, par exemple dans le dossier d'envoi. Dans les répertoires d'envoi, l'exécution de PHP est bloquée. Le code du programme appartient à un autre utilisateur que celui sous lequel PHP fonctionne. Les principes sont expliqués dans Droits sur les fichiers du serveur web.
Accès, services et journaux
SSH uniquement avec clé, interfaces d'administration avec authentification à deux facteurs, services et ports inutiles fermés. Les journaux sont conservés et sécurisés de façon à exister encore après un incident. Nous vérifions que les sauvegardes peuvent être restaurées.
Serveur web et en-têtes de sécurité
Le serveur web lui-même fait aussi partie du durcissement : masquer les indications de version, désactiver les listes de répertoires, bloquer l'accès aux fichiers de configuration, de sauvegarde et de gestion de versions, et sécuriser en plus les espaces d'administration, par exemple par autorisation d'adresses IP. Des en-têtes de sécurité comme Content-Security-Policy ou HSTS protègent dans le navigateur les visiteurs de votre site web.
Ce que nous trouvons souvent lors de l'inventaire
De nombreuses faiblesses se répètent d'un serveur à l'autre. Sont typiques plusieurs sites web sous un utilisateur commun, des interfaces de base de données accessibles publiquement, d'anciennes installations de test dans des sous-dossiers, des versions de PHP oubliées à côté de la version actuelle et des sauvegardes placées dans le répertoire web et téléchargeables. Il manque souvent aussi toute journalisation des connexions, ou bien les journaux sont supprimés au bout de quelques jours.
Aucun de ces points n'est spectaculaire en soi. Ensemble, ils décident toutefois si une intrusion reste limitée à un site web ou touche tout le serveur.
Comment PHP SOS aide-t-il concrètement ?
- Inventaire : nous recensons le système d'exploitation, le serveur web, les versions de PHP, les sites web, les utilisateurs, les services ouverts et les sauvegardes existantes.
- Plan de mesures : vous recevez une liste priorisée avec l'effort et les répercussions possibles pour chaque point. Vous décidez de ce qui est mis en œuvre.
- Mise en œuvre par étapes : nous modifions les configurations après concertation, testons les sites web après chaque étape et consignons comment annuler chaque modification.
- Contrôle : après la mise en œuvre, nous vérifions l'effet, par exemple qu'un site web ne peut effectivement plus lire de répertoires étrangers.
- Remise : vous recevez une documentation du nouvel état, que votre hébergeur ou votre agence peuvent aussi comprendre.
Ce que vous recevez et ce dont nous avons besoin
Vous recevez un rapport de durcissement avec la situation de départ, les mesures mises en œuvre, les points volontairement laissés ouverts avec justification et une recommandation pour le contrôle régulier. Les modifications des fichiers de configuration sont documentées de façon traçable.
De votre part, nous avons besoin de :
- l'accès root ou administrateur au serveur, et, avec des panneaux d'administration, l'accès à ceux-ci
- une liste des applications et de leurs particularités, par exemple envois de fichiers, interfaces, tâches cron
- un interlocuteur technique capable de confirmer les fonctions après les modifications
- des fenêtres de maintenance pour les redémarrages
- une sauvegarde récente ou la mission d'en créer une au préalable
Ce que nous ne promettons pas
Le durcissement ne rend pas un serveur inattaquable. Il réduit la surface d'attaque et limite les dégâts, mais ne remplace ni les mises à jour ni la surveillance. Une version de PHP non corrigée reste vulnérable, quel que soit le réglage du reste. C'est pourquoi nous associons le durcissement au service de correctifs PHP et recommandons ensuite un suivi continu par un contrat de maintenance de sécurité.
Avec un hébergement mutualisé, beaucoup de choses ne sont pas réglables, car l'hébergeur impose la configuration. Nous montrons alors ce qui est possible dans le cadre de votre offre et où le passage à un serveur dédié ou géré serait judicieux.
Questions fréquentes
Que signifie durcir un serveur ?
Durcir signifie désactiver ou restreindre tout ce qui n'est pas nécessaire à l'exploitation. Cela comprend les services superflus, les droits trop larges, les ports ouverts et les réglages par défaut peu sûrs. L'objectif est qu'une seule erreur n'ouvre pas aussitôt tout le serveur.
Le durcissement aurait-il empêché PHP2Shell ?
Non, contre une faille dans PHP lui-même, seul le correctif aide. Le durcissement limite en revanche ce qu'un attaquant peut atteindre après une intrusion réussie, par exemple s'il peut accéder à d'autres sites web ou à des identifiants.
Le durcissement risque-t-il de casser mon site web ?
Ce risque existe si des réglages sont modifiés sans test. Nous mettons en œuvre les modifications étape par étape, vérifions les fonctions après chaque étape et consignons comment annuler chaque modification.
À quelle fréquence le durcissement doit-il être revu ?
Au plus tard après des mises à jour importantes, un changement de version de PHP ou de nouvelles applications sur le serveur. Un contrôle régulier dans le cadre de la maintenance courante est judicieux.