En bref : un inventaire informatique pour les serveurs web est une liste de tous les sites, portails, boutiques et serveurs, avec les informations dont on a immédiatement besoin lors d'une alerte de sécurité : où cela tourne, avec quelle version et quel mode d'exécution de PHP, quelle application, qui est responsable et quelles données seraient concernées. Sans cette liste, chaque réaction commence par une recherche. Avec elle, le rapprochement pour une alerte comme PHP2Shell prend des minutes au lieu de jours.
La première question était : où tourne PHP chez nous ?
Lorsque le projet PHP a publié les correctifs le 21/10/2026 et que le BSI (office fédéral allemand de la sécurité des technologies de l'information) a recommandé d'agir immédiatement, la consigne était claire : mettre PHP à jour, redémarrer tous les processus. Pour de nombreuses entreprises, la première étape n'a pourtant pas été la mise à jour, mais un inventaire. Le site principal était connu. Mais le portail revendeurs ? Le site carrières chez un autre prestataire ? La page d'atterrissage d'une campagne d'il y a trois ans ? Le wiki interne ?
La presse spécialisée et les services de mesure ont rendu visible l'ampleur du problème. Palo Alto Networks (Unit 42) a recensé plus de 22,6 millions d'instances exposées et potentiellement vulnérables. Parmi elles figurent sans doute de nombreux systèmes auxquels leurs exploitants ne pensent tout simplement plus.
Ce qui doit figurer dans un inventaire de serveurs web
Un inventaire utilisable est un tableau avec une ligne par site ou application. Ces colonnes ont fait leurs preuves :
| Colonne | Exemple | À quoi cela sert |
|---|---|---|
| Adresse | shop.exemple.fr | identification univoque |
| Finalité et importance | boutique en ligne, critique pour le chiffre d'affaires | priorisation |
| Hébergeur ou emplacement | serveur managé chez le prestataire X | qui appeler |
| Serveur et système d'exploitation | vServer, Debian | voie de mise à jour, sources de sécurité |
| Serveur web et mode d'exécution de PHP | Nginx avec PHP-FPM | risque, par ex. mod_php |
| Version de PHP et état du paquet | 8.3, paquet daté | rapprochement avec les alertes |
| Application et version | Shopware, extensions | alertes des éditeurs |
| Responsable interne / externe | responsable informatique / agence Y | qui agit |
| Données traitées | comptes clients, commandes | obligations de notification, urgence |
| Sauvegardes | quotidiennes, externes, dernier test le … | restauration |
| Dernière preuve de correctif | date et justificatif | preuve vis-à-vis de tiers |
Le mode d'exécution mérite une attention particulière. Pour PHP2Shell, l'équipe PHP a jugé le risque le plus élevé avec Apache et mod_php. Celui qui sait quels systèmes fonctionnent ainsi peut s'en occuper en premier. La colonne sur l'état du paquet est importante, car le numéro de version affiché reste souvent identique après des rétroportages ; des indications à ce sujet figurent dans Vérifier correctement la version de PHP et l'état des correctifs.
Retrouver les systèmes oubliés : comment procéder
Les systèmes connus sont vite saisis. Le vrai travail, ce sont les inconnus. Ces sources aident à les débusquer :
- Domaines et DNS : parcourir tous les domaines de l'entreprise et leurs sous-domaines. Chaque entrée qui pointe vers un serveur web est un candidat.
- Factures : la comptabilité connaît chaque hébergeur, registraire et fournisseur de cloud qui reçoit de l'argent. C'est souvent la liste la plus complète.
- Agences et services métiers : le marketing, la vente et les ressources humaines commandent volontiers des sites directement. Posez la question.
- Serveurs connus : sur chaque serveur, la configuration montre quels sites il diffuse réellement.
- Équipements avec interface web : les NAS, routeurs et appliances embarquent parfois leur propre PHP, voir PHP sur les NAS, routeurs et appliances.
Pour l'étape 4, quelques commandes en lecture seule aident sur les serveurs Linux. Elles montrent les sites configurés, les services PHP et les pools FPM :
# Sites configurés (Apache ou Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Services et processus PHP en cours d'exécution
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# Pools FPM sous Debian et Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Si plusieurs versions de PHP tournent côte à côte sur un serveur, chacune doit figurer dans la liste. Chacune doit être mise à jour et redémarrée séparément.
Inscrivez aussi les systèmes qui devraient en réalité être arrêtés. Ce sont souvent eux qui tournent encore, ne sont plus mis à jour depuis des années et sont oubliés. Avec une entrée « arrêter d'ici … », la tâche reste visible.
Garder l'inventaire à jour
Un inventaire ne vaut que par sa dernière mise à jour. Trois règles le maintiennent vivant. Premièrement : une personne en est responsable et est informée de chaque nouveau site, de chaque migration et de chaque arrêt, même si c'est une agence qui effectue le travail. Deuxièmement : une fois par trimestre, la liste est rapprochée du DNS, des factures et de la configuration des serveurs. Troisièmement : l'inventaire fait partie du plan d'urgence et existe aussi en dehors de l'informatique interne, par exemple sur papier.
Pour les entreprises disposant de nombreux systèmes répartis, comme des portails revendeurs, des configurateurs et des accès fournisseurs, Sécurité informatique pour les PME et l'industrie décrit les endroits où l'on en trouve typiquement. La manière d'intégrer l'inventaire au plan d'urgence est expliquée dans Établir un plan d'urgence informatique pour les serveurs web.
Erreurs fréquentes dans l'inventaire des serveurs web
De nombreux inventaires existent, mais n'aident pas en cas de crise. Les causes se ressemblent :
- Des serveurs, mais pas de sites : la liste cite les machines, mais pas les sites qui y tournent ni qui en est responsable sur le plan métier. En cas de faille, personne ne sait quel service est concerné.
- La version plutôt que l'état du paquet : « PHP 8.3 » ne dit pas grand-chose après PHP2Shell. Seuls l'état du paquet et sa date montrent si le correctif est inclus.
- Les systèmes externes manquent : ce qui tourne chez une agence ou un service de plateforme est omis, parce qu'on n'y serait « pas responsable ». La responsabilité des données reste pourtant dans l'entreprise.
- Pas d'interlocuteurs : une entrée sans nom ni numéro de téléphone du service responsable fait perdre du temps en cas d'urgence.
- Une action unique : l'inventaire est établi pendant une semaine de crise, puis plus jamais rouvert. Au bout d'un an, une bonne partie est devenue inexacte.
Celui qui évite ces cinq points dispose, à la prochaine alerte, d'une liste avec laquelle on peut réellement travailler.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons avec vous tous les sites et serveurs, y compris les oubliés, par le DNS, les factures, les prestataires et la configuration des serveurs.
- Nous déterminons pour chaque système le mode d'exécution, la version de PHP et l'état réel du paquet.
- Nous hiérarchisons les systèmes selon leur accessibilité, leurs données et leur mode d'exécution, et nous indiquons où agir en premier.
- Là où PHP2Shell reste ouverte, nous fermons la faille par l'aide immédiate PHP2Shell et consignons la preuve dans l'inventaire.
Conclusion : un inventaire est la mesure de sécurité la plus discrète et en même temps la plus efficace. Celui qui sait ce qui tourne peut agir immédiatement à la prochaine alerte, au lieu de devoir d'abord chercher.
Questions fréquentes
Quelles informations un inventaire de serveurs web doit-il contenir au minimum ?
L'adresse du site, le serveur ou l'hébergeur, le mode d'exécution de PHP, la version de PHP avec l'état du paquet, l'application avec sa version, le responsable en interne et en externe, le type de données traitées et l'emplacement des sauvegardes. Avec ces informations, chaque nouvelle alerte de sécurité peut être rapprochée rapidement.
Comment retrouver des sites dont plus personne n'a connaissance ?
Par plusieurs voies à la fois : la gestion des domaines et les zones DNS, les factures des hébergeurs et des registraires, des questions aux agences et aux services métiers, ainsi que la configuration des serveurs connus. D'anciens sites de campagne, des systèmes de test et des sous-domaines apparaissent généralement ainsi.
Qui devrait tenir l'inventaire à jour ?
Une personne désignée, le plus souvent au sein de l'informatique ou chez le responsable informatique. L'important est que toute modification des sites et serveurs y soit signalée, même si elle est demandée par un service métier ou une agence.
Un tableau suffit-il, ou faut-il un logiciel ?
Pour la plupart des PME, un tableau bien tenu suffit. Un logiciel se justifie lorsque de nombreux systèmes doivent être recensés automatiquement. Ce qui compte, c'est l'actualité des données, pas l'outil.