En bref : après l'alerte sur PHP2Shell, des sites web ont été coupés en Allemagne, dont, selon les médias, le portail web de la ville de Mayence ainsi que des sites du gouvernement du Land de Hesse et du BKA (office fédéral allemand de la police criminelle). Il s'agissait de précaution suivant la recommandation du BSI (office fédéral allemand de la sécurité des technologies de l'information), non d'attaques confirmées. Les entreprises peuvent en tirer une leçon : une mise hors ligne est une option légitime lorsqu'un correctif n'est pas possible immédiatement, et elle réussit le mieux lorsqu'elle est préparée.
Sites coupés à cause de PHP : ce qui s'est passé le 21 octobre
Le jour des mises à jour de sécurité de PHP, de nombreux sites publics étaient inaccessibles en Allemagne. Selon des articles de presse, la ville de Mayence a mis son portail web central hors ligne par précaution. Les services municipaux sont restés joignables par téléphone et par e-mail.
En Hesse, selon hessenschau, des sites du gouvernement du Land, de l'Office fédéral de la police criminelle ainsi que des villes de Cassel et de Wiesbaden, entre autres, ont été temporairement hors ligne. La chancellerie d'État a parlé d'adaptations techniques et n'a signalé aucune attaque. Les sites du Land étaient de nouveau accessibles le soir. D'autres communes, établissements d'enseignement supérieur et cliniques ont également, selon des rapports, mis des services hors ligne par précaution.
À l'origine se trouve la recommandation du BSI sur PHP2Shell : mettre à jour immédiatement et, si ce n'est pas possible tout de suite, mettre temporairement hors réseau les serveurs web concernés. Ce que le BSI conseille en détail est résumé sur la page Ce que le BSI recommande pour PHP2Shell.
Hors ligne ne veut pas dire piraté
Dans les commentaires et sur les réseaux sociaux, « hors ligne » est vite devenu « piraté ». D'après tout ce que l'on sait, c'est faux. Les coupures étaient une mesure de protection à un moment où de nombreux exploitants ne connaissaient pas encore avec certitude le niveau de correctif de leurs serveurs.
Pour les entreprises, cette distinction est doublement importante. D'abord vers l'extérieur : qui coupe lui-même par précaution devrait le dire ainsi et ne pas se taire. Ensuite en interne : une mise hors ligne ne répond pas à la question de savoir si le serveur a été attaqué auparavant. Elle ne fait qu'arrêter de nouvelles tentatives. La recherche de traces reste nécessaire.
Un troisième point est souvent négligé : une mise hors ligne ne doit pas détruire de traces. Qui réinstalle simplement le serveur pour le couper ou supprime des journaux pour libérer de la place se prive de la possibilité de déterminer plus tard ce qui s'est passé avant la coupure. Il vaut mieux rediriger le serveur web vers une page d'urgence ou bloquer l'accès depuis l'extérieur, et laisser le serveur lui-même intact avec tous ses journaux.
Pourquoi les services publics en particulier ont réagi ainsi
Les autorités exploitent souvent de nombreux sites côte à côte : portail principal, portails spécialisés, services de formulaires, sites de services et d'établissements individuels. Plusieurs prestataires y participent fréquemment. Le jour de l'alerte, il était tout simplement impossible pour de nombreuses administrations d'obtenir en quelques heures un niveau de correctif documenté pour chaque système. Dans cette situation, la mise hors ligne préventive était le moyen le plus rapide de suivre la recommandation du BSI.
Pour les entreprises disposant d'un paysage informatique construit par strates, la situation est souvent similaire. La question « Tout est-il corrigé ? » n'échoue pas à cause de la technique, mais du manque de vue d'ensemble.
Il est également remarquable de voir avec quelle rapidité les sites du Land de Hesse sont, selon des rapports, revenus : le soir même. Cela montre qu'une mise hors ligne préventive ne doit pas durer des jours. Qui connaît ses systèmes et maîtrise la méthode de mise à jour peut corriger, vérifier et remettre en ligne en quelques heures. La coupure ne fait alors que combler le temps jusqu'à ce que la clarté soit faite.
Quand une mise hors ligne préventive se justifie pour une entreprise
Les autorités sont dans une situation particulière : de nombreux sites, souvent gérés de manière dispersée, et une forte visibilité publique. L'arbitrage auquel elles ont été confrontées est toutefois le même que dans toute entreprise. Le tableau suivant aide à décider :
| Situation | Plutôt couper | Plutôt laisser en ligne |
|---|---|---|
| Niveau de correctif | incertain ou non confirmé | corrigé et prouvé, processus redémarrés |
| Version de PHP | 8.1 ou plus ancienne sans rétroportage confirmé | branche prise en charge, à jour |
| Mode d'exécution | Apache avec mod_php | PHP-FPM corrigé avec mesures transitoires appliquées |
| Données sur le serveur | données clients, identifiants, données de paiement | contenus purement statiques |
| Disponibilité du prestataire | correctif possible seulement dans quelques jours | correctif planifié à brève échéance |
L'article Corriger, couper ou attendre ? approfondit l'arbitrage entre corriger, couper et attendre. Ce qui est techniquement possible comme solution transitoire lorsque la mise à jour manque encore figure sous Mesures immédiates sans correctif.
Couper temporairement une boutique ou un portail client coûte du chiffre d'affaires. Un serveur compromis contenant des données clients peut coûter nettement plus, jusqu'à des obligations de notification. Prenez la décision en connaissance de cause et consignez-la par écrit.
Comment préparer une mise hors ligne
Mayence a montré ce qui compte : l'administration est restée joignable par d'autres canaux. Cela n'est possible que si c'est préparé. Ces étapes valent la peine avant la prochaine urgence :
- Tenir une page d'urgence prête : une page HTML statique sans PHP, avec une brève explication, un contact téléphonique et e-mail et, si nécessaire, des informations sur les commandes ou rendez-vous en cours.
- Définir la voie de basculement : qui peut rediriger le site vers la page d'urgence, via le serveur web, le DNS ou un service placé en amont ? Combien de temps cela prend-il ?
- Clarifier le pouvoir de décision : qui peut ordonner une mise hors ligne, y compris en dehors des heures de bureau ?
- Connaître les services dépendants : des interfaces, des applications ou des partenaires dépendent-ils du site ? Qui doit être informé au préalable ?
- Définir les critères de retour : correctif prouvé, redémarrage effectué, première recherche de traces sans résultat.
- Préparer le message : deux à trois phrases pour les clients, partenaires et la presse.
La manière de communiquer vers l'extérieur dans une telle situation est décrite dans le guide sur la communication de crise.
Comment PHP SOS aide-t-il concrètement ?
- Base de décision : nous déterminons le niveau de correctif, le mode d'exécution et la nature des données de vos serveurs et vous donnons une évaluation claire sur l'opportunité d'une mise hors ligne.
- Mise hors ligne ordonnée : nous basculons vers une page d'urgence statique sans perdre de journaux ni de traces.
- Correctif et vérification : nous mettons à jour PHP, redémarrons tous les processus et recherchons des anomalies.
- Retour contrôlé : nous ne remettons le site en ligne que lorsque les critères convenus sont remplis et documentés.
Le déroulement est décrit dans l'assistance immédiate PHP2Shell.
Conclusion
Les coupures des autorités n'étaient pas un signe de perte de contrôle, mais une précaution délibérée. Pour les entreprises, c'est la véritable leçon : passer hors ligne est une décision légitime lorsque le niveau de correctif est incertain. Qui a préparé page d'urgence, responsabilité et critères de retour la prend en quelques minutes plutôt qu'en quelques heures.
Questions fréquentes
Pourquoi des sites d'autorités ont-ils été coupés à cause de PHP ?
Pour PHP2Shell, le BSI recommande la mise à jour immédiate et, si elle n'est pas possible tout de suite, de mettre temporairement les serveurs web hors réseau. Plusieurs autorités ont suivi cette recommandation par précaution, jusqu'à ce que leurs systèmes soient vérifiés et mis à jour.
Un site coupé signifie-t-il qu'il a été piraté ?
Non. Une mise hors ligne préventive est une mesure de protection. La chancellerie d'État de Hesse, par exemple, n'a expressément signalé aucune attaque, selon hessenschau. Seule une vérification permet de savoir si un serveur était touché avant la coupure.
Combien de temps un site devrait-il rester hors ligne ?
Jusqu'à ce que PHP soit à un niveau corrigé, que tous les processus PHP aient été redémarrés et qu'un premier examen des traces n'ait rien révélé d'anormal. Il n'existe pas de durée fixe ; selon des rapports, les sites du Land de Hesse étaient de nouveau accessibles le soir du même jour.
Que montrer aux visiteurs pendant que le site est hors ligne ?
Le mieux est une page d'urgence simple et statique, sans PHP, avec une brève explication et les moyens de contact par lesquels vous restez joignable. Elle doit être préparée avant d'être nécessaire.