Faut-il couper son site en cas de faille critique ?
Ce que les mises hors ligne du 21 octobre apprennent aux PME : quatre questions pour décider, les alternatives et la marche à suivre
Image générée par IA (art. 50 AI Act)
Analyse 2LKATIME
Le 21 octobre, des milliers de sites ont disparu d'Internet en quelques heures. Préfectures, ministères, services publics européens : tous coupés par précaution. Un dirigeant de PME se demande alors s'il aurait dû faire pareil. Cet article donne une méthode en quatre questions. Il complète nos articles sur les failles PHP et sur la détection d'une attaque.
Le risque pour le dirigeant : décider trop tard
La pire décision est celle qu'on prend après l'intrusion. Si votre site a été compromis alors que l'ANSSI avait recommandé d'isoler les serveurs, et qu'aucune décision n'a été tracée, vous aurez du mal à expliquer votre choix à vos clients, à votre assureur et à la CNIL.
Couper un site coûte de l'argent, et ne pas le couper aussi. Le 21 octobre, la consigne officielle penchait nettement d'un côté : l'ANSSI et le CERT-FR demandaient d'isoler les équipements concernés et, si possible, de les mettre hors ligne jusqu'à l'application du correctif. Pour une PME, la bonne réponse dépend de quatre faits que l'on peut vérifier en dix minutes.
Les grands comptes ont un plan de crise. La plupart des PME n'ont rien d'écrit : la décision se prend dans un échange de messages, avec un prestataire injoignable. Mieux vaut y réfléchir avant la prochaine alerte, parce qu'il y en aura une.
1. Ce qui s'est passé le 21 octobre
21 oct.
Mises hors ligne à la demande de l'ANSSI, le jour du correctif PHP
600 000
Serveurs PHP en France selon l'ANSSI, d'après la presse
22 M
Plateformes exposées comptées par Palo Alto Networks
24 oct.
Premières exécutions de commandes réussies, sur des pièges à attaquants
Le 21 octobre, le projet PHP a publié deux failles critiques et leur correctif. Selon France 24, la NSA américaine et le centre de cybersécurité britannique (NCSC) ont recommandé à tous les sites utilisant PHP de se déconnecter avant de mettre le logiciel à jour. En France, les sites de toutes les préfectures ont été suspendus à la demande de l'ANSSI, et le ministère de l'Intérieur a fermé ses sites exposés. Des services publics ont aussi été coupés en Finlande, au Royaume-Uni, en Allemagne, au Danemark, aux Pays-Bas et en Belgique.
Les failles ont été trouvées par la société Calif, avec un modèle d'IA d'OpenAI, et par Wiz de son côté. Cette découverte assistée par IA réduit le temps dont disposent les défenseurs : entre la publication et les premières attaques, il ne s'écoule plus des semaines mais des heures. Les premières tentatives datent même du 17 octobre, quatre jours avant le correctif, selon Amazon.
Les chiffres varient selon les sources. Les 22 millions de plateformes viennent de Palo Alto Networks, les 600 000 serveurs français de l'ANSSI, rapportés par la presse. Aucun n'est un décompte de sites réellement vulnérables.
2. Hors ligne ne veut pas dire piraté
Beaucoup de lecteurs ont compris que les sites coupés avaient été attaqués. Les sources disent autre chose : selon la Banque des Territoires, il s'agissait d'une maintenance préventive, pas d'une cyberattaque. Les administrateurs ont coupé avant de savoir s'ils étaient visés, parce que le risque d'attendre était plus grand que le coût de la coupure.
Ce choix s'est avéré raisonnable. Le 24 octobre, un chercheur de Perplexity a enregistré 35 exécutions de commandes réussies sur trois pièges à attaquants tournant sous Apache mod_php, avec PHP 8.4.26. La CISA a ajouté les deux failles à son catalogue des vulnérabilités exploitées le 26 octobre. Ces essais portaient sur des serveurs-pièges, dans une configuration favorable à l'attaquant : le chercheur lui-même précise qu'ils ne mesurent pas la fiabilité de l'exploit ailleurs. Ils montrent que la capacité existe.
3. Les quatre questions qui décident
Pas besoin d'être expert pour y répondre. Il faut seulement avoir les informations sous la main avant l'alerte.
1. La faille est-elle exploitée ?
Cherchez trois signaux : un avis de l'ANSSI ou du CERT-FR, une inscription au catalogue des vulnérabilités exploitées de la CISA, un code d'attaque public. Un seul signal justifie de se préparer, deux justifient d'agir dans l'heure.
2. Un correctif existe-t-il, et en combien de temps l'appliquez-vous ?
Pour PHP2Shell, le correctif est sorti le 21 octobre. Si vous pouvez le poser en moins d'une heure, la coupure n'a pas de raison d'être. Si votre prestataire met trois jours, la question change.
3. Votre site est-il vraiment exposé ?
Regardez la version de PHP, le mode d'exécution (mod_php est le plus exposé, PHP-FPM l'est sous conditions), la présence d'un WordPress et l'ouverture du site sur Internet. Un site purement statique, servi sans PHP, n'est pas concerné.
4. Que perdez-vous en coupant, et en vous faisant compromettre ?
Comptez les ventes par heure, les rendez-vous pris en ligne, la visibilité dans les moteurs de recherche. Mettez en face le coût d'une intrusion : nettoyage, restauration, notification des clients, perte de confiance. Le calcul penche presque toujours vers la coupure quand les trois premières réponses sont oui.
4. Le tableau de décision
Ce tableau simplifie volontairement. Il donne un point de départ, à adapter selon votre activité et l'avis de votre prestataire.
| Situation | Décision | Pourquoi et comment |
|---|---|---|
| Exploitée, correctif disponible, pose en moins d'une heure | Ne coupez pas | Appliquez le correctif tout de suite, sauvegarde avant, redémarrage après. |
| Exploitée, correctif disponible, pose en plusieurs jours | Coupez ou réduisez | Maintenance 503 ou page statique jusqu'à la mise à jour. |
| Exploitée, aucun correctif | Coupez ou isolez | Seule solution fiable. Servez une version statique si le site doit rester visible. |
| Non exploitée, aucun correctif | Ne coupez pas | Surveillez, appliquez les mesures provisoires, préparez la page de maintenance. |
| Site statique, sans PHP | Ne coupez pas | Vérifiez que rien n'envoie de requête vers PHP, puis passez à autre chose. |
Le cas qui pose problème est le deuxième : un correctif existe, mais votre prestataire ne l'appliquera pas avant plusieurs jours. Dans cette situation, c'est la durée de l'exposition qui décide, pas l'existence du correctif.
5. Les alternatives à l'arrêt complet
Couper n'est pas le seul levier. Quatre autres existent, de la plus efficace à la plus fragile.
Appliquer le correctif sans attendre
C'est la réponse à la plupart des cas. Un correctif posé dans l'heure rend la coupure inutile. Prévoyez la fenêtre de mise à jour avant d'en avoir besoin.
Servir une version statique
Gardez les pages vitrines visibles sans passer par PHP, et coupez uniquement les parties dynamiques : espace client, formulaires, boutique. Cela demande une préparation à l'avance.
Désactiver ce qui est inutile
Fonction d'envoi de fichiers, suivi de progression des sessions (session.upload_progress.enabled=0 pour la troisième faille), extensions que personne n'utilise. Chaque fonction coupée réduit la surface d'attaque.
Filtrer en amont
Un pare-feu applicatif ou une règle nginx qui refuse les requêtes multipart bloque une partie des attaques. Le CERT-FR rappelle que ces mesures ne sont pas qualifiées : elles gagnent du temps, elles ne remplacent pas le correctif.
6. Le coût réel d'une coupure
Une coupure de quelques heures pèse peu pour un site vitrine et beaucoup pour une boutique ou un service de réservation. Chiffrez-la avant la crise : chiffre d'affaires moyen par heure, rendez-vous pris en ligne, appels générés par le site. Ce chiffre, divisé par la durée prévue de l'arrêt, donne la perte maximale acceptable.
Côté référencement, signalez la panne correctement. Un code 503 avec un en-tête Retry-After dit aux moteurs de recherche de revenir plus tard. Une page d'erreur 404 ou une page vide en code 200 laisse croire que le contenu a disparu. Si la coupure dure, prévenez aussi vos clients : un site muet sans explication abîme plus la confiance qu'un message clair.
Face à cela, une intrusion coûte le nettoyage, la restauration, parfois une notification à la CNIL, et un risque de vol de données ou de ransomware. Aucun chiffre unique ne vaut pour toutes les structures, mais l'écart penche presque toujours du côté de la prévention quand l'exploitation est active.
7. La marche à suivre : avant, pendant, après
Avant la crise
Nommez la personne qui décide et son suppléant. Préparez une page de maintenance qui renvoie un code 503. Testez-la une fois. Notez qui a la main sur le serveur, l'hébergeur et le DNS, avec les numéros d'urgence. Vérifiez que vos sauvegardes se restaurent.
Pendant la coupure
Affichez la page 503 avec un en-tête Retry-After. Prévenez vos clients par un canal qui ne dépend pas du site : mail, réseaux sociaux, téléphone. Copiez les journaux avant qu'ils ne tournent, appliquez le correctif, testez sur une copie si vous le pouvez.
Après la remise en ligne
Vérifiez la version de PHP réellement chargée par le service web, pas seulement celle de la ligne de commande. Relisez les journaux de la période d'exposition avec notre guide de détection. Changez les secrets en cas de doute. Écrivez ce qui a marché et ce qui a traîné, pendant que c'est frais.
8. Conformité
Le RGPD (article 32) demande de garantir la confidentialité, l'intégrité et la disponibilité des systèmes. Couper un site par précaution relève de cette logique. Une coupure décidée et maîtrisée n'est pas en soi une violation de données ; confirmez ce point avec votre délégué à la protection des données si vous en avez un. Si une intrusion est avérée et touche des données personnelles, la notification à la CNIL se fait sous 72 heures.
Pour les entités soumises à NIS2, un incident significatif suppose une alerte précoce sous 24 heures. Dans les deux cas, tracer la décision (qui, quand, sur quels éléments) protège le dirigeant.
9. Ce que 2LKATIME recommande
Écrivez votre procédure de coupure cette semaine, en une page, et testez la page de maintenance une fois. Nos audits cybersécurité incluent un plan de réponse aux alertes critiques, avec les critères de décision et les contacts d'urgence.
Les entreprises de Paris, de Nantes ou de Lille trouveront les formules sur nos pages tarifs. L'accompagnement se fait aussi à distance partout en France.
FAQ - Couper son site en cas de faille critique
Mon site est hors ligne : a-t-il été piraté ?
Pas forcément. Le 21 octobre, la plupart des sites coupés l'étaient par précaution, à la demande de l'ANSSI, avant même de savoir s'ils étaient visés. Une mise hors ligne protège, elle ne prouve aucune intrusion. Pour savoir si un site a été touché, il faut lire les journaux, les fichiers et les processus du serveur.
Une coupure de quelques heures pénalise-t-elle mon référencement ?
Une indisponibilité courte et bien signalée a peu d'effet. Renvoyez un code 503 avec un en-tête Retry-After : les moteurs de recherche comprennent que la panne est temporaire. Une page d'erreur 404 ou une page vide renvoyée avec un code 200 est bien plus risquée, surtout si la coupure dure.
J'ai un WordPress sur un hébergement mutualisé : que puis-je faire ?
Vous ne contrôlez pas la version de PHP : c'est l'hébergeur qui la met à jour. Demandez-lui la date du correctif et ce qu'il a vérifié. En attendant, vous pouvez mettre votre site en maintenance, désactiver les extensions d'envoi de fichiers et changer les mots de passe si vous avez un doute.
Cloudflare ou un pare-feu applicatif évite-t-il la coupure ?
Il réduit le risque sans le supprimer. Cloudflare a activé des règles par défaut, et les attaquants ont adapté leurs requêtes en quelques heures. Le CERT-FR juge d'ailleurs les mesures provisoires non qualifiées : seule la mise à jour règle le problème. Un pare-feu vous donne du temps, pas une solution.
Qui doit prendre la décision de couper ?
Une seule personne nommée à l'avance, avec un suppléant : le dirigeant, le DSI ou le prestataire d'exploitation. Les critères doivent être écrits avant la crise. Discuter à plusieurs pendant une attaque en cours coûte des heures que vous n'avez pas.
Sources
Savez-vous qui décide si votre site doit être coupé ?
2LKATIME rédige avec vous un plan de réponse aux alertes critiques : critères de décision, page de maintenance, contacts d'urgence et modèle de communication client.