Résumé

  • L'interruption d'octobre 2021 suivit une maintenance planifiée destinée à renforcer la protection anti-DDoS, mais les éléments publics n'attribuent pas la panne elle-même à une attaque.
  • OVHcloud a expliqué qu'une commande liée à la redistribution de BGP vers OSPF avait annoncé la table Internet complète dans son IGP, rempli la table OSPF, surchargé la mémoire et le processeur d'un routeur, puis rendu IPv4 inopérant tandis qu'IPv6 restait joignable.
  • La modification avait été préparée au moyen d'un CAB, d'un MOP et d'une revue par les pairs ; l'enjeu de responsabilité concerne donc la validation sémantique, la limitation du rayon d'impact, l'observation de l'état réel et l'efficacité du retour arrière, non une prétendue absence de contrôle.
  • La remise en service fut progressive : le problème apparut vers 09 h 20 CET, le routeur fautif fut éteint à 10 h 18, les premiers services revinrent à 10 h 20 et la crise technique fut déclarée terminée à 10 h 57.
  • Les faits étayent une perte étendue de joignabilité IPv4, mais ne donnent ni nombre exact de clients ou de services touchés, ni preuve de perte de données, d'incendie, de destruction physique, de préjudice financier total ou d'une erreur de copier-coller comme cause certaine.

Une raison de maintenance n'est pas une cause de panne

Au matin du 13 octobre 2021, OVHcloud intervenait sur son infrastructure de routage de production. L'opérateur a situé cette intervention dans un contexte d'attaques DDoS plus intenses et a présenté son objectif comme un renforcement de la protection. Cette motivation est importante pour comprendre la décision de changer le réseau. Elle ne permet toutefois pas de dire que le trafic hostile a provoqué l'interruption. Le mécanisme décrit publiquement commence avec la modification de configuration elle-même.

La différence détermine la bonne attribution des responsabilités. Une entreprise peut devoir adapter en urgence ses capacités de filtrage ou d'absorption sans que l'urgence efface les exigences de continuité. Lorsque la modification destinée à réduire un risque en crée un autre, la question n'est plus seulement de savoir si la menace externe était réelle. Il faut établir si l'exposition nouvelle avait été modélisée, bornée et observable avant l'exécution.

Cette précision évite aussi un récit trop commode. Qualifier l'événement de cyberattaque déplacerait l'attention vers un adversaire dont les actions ne sont pas présentées comme la cause technique de la panne. À l'inverse, parler d'une simple erreur humaine réduirait une chaîne de défaillances à un geste individuel que les sources ne permettent pas d'attribuer. Le dossier décrit une modification planifiée, un résultat de routage inattendu, une propagation, un retour arrière inefficace et une isolation physique tardive. C'est cette chaîne qui doit être examinée.

La frontière BGP–OSPF a transformé une commande en événement réseau

BGP et OSPF n'assument pas la même fonction. BGP échange des informations de joignabilité entre domaines de routage et peut porter une vision très large des préfixes Internet. OSPF sert à calculer les chemins au sein d'un domaine de routage. Redistribuer des routes entre ces univers n'est donc pas une opération neutre : elle peut faire passer un volume et une diversité d'informations d'un plan de contrôle à un autre, avec des hypothèses de capacité et de stabilité différentes.

Selon OVHcloud, la commande concernait précisément une redistribution de BGP vers OSPF. Un routeur ne l'aurait pas interprétée correctement. La table de routage Internet complète aurait alors été annoncée dans l'IGP. La table OSPF se serait remplie, tandis que la mémoire vive et le processeur du routeur auraient été surchargés. Une boucle de convergence entre BGP et OSPF aurait ensuite rendu le routage IPv4 inopérant.

La séquence est essentielle parce qu'elle relie une instruction de configuration à un état mesurable. Le problème n'est pas seulement qu'une commande n'a pas produit le résultat attendu. Le réseau a accepté un ensemble de routes qui dépassait le périmètre voulu, puis a consacré ses ressources à traiter, diffuser et recalculer cet état. Une validation limitée à la syntaxe ou à l'apparence du texte ne suffisait pas ; il fallait vérifier la population de routes que l'instruction pouvait réellement injecter et le comportement du plan de contrôle lorsque cette population divergeait de l'intention.

Les informations disponibles ne précisent ni le modèle de routeur, ni le fournisseur, ni la version logicielle, ni le texte exact de la commande. Elles ne permettent donc pas de conclure à un défaut particulier d'équipement ou de parseur. Elles permettent en revanche d'identifier le point de contrôle : la frontière de redistribution devait empêcher qu'un ensemble de routes sans rapport avec l'objectif approuvé puisse envahir l'IGP.

IPv4 en panne, IPv6 encore joignable

L'un des éléments les plus instructifs de l'incident est la séparation entre familles de protocoles. OVHcloud a indiqué que le trafic IPv4 ne pouvait plus être traité correctement, alors qu'IPv6 restait accessible. Des observateurs indépendants ont également relevé cette différence. Le réseau n'était donc ni totalement détruit ni uniformément disponible : sa continuité dépendait du chemin et de la famille d'adresses utilisés.

Cette asymétrie explique pourquoi un indicateur unique peut induire en erreur. Une sonde IPv6 encore verte ne prouve pas que les clients majoritairement dépendants d'IPv4 disposent du service. À l'inverse, une perte de joignabilité IPv4 n'établit pas que les serveurs, les données ou les centres d'hébergement ont subi un dommage physique. Le service peut être intact derrière une frontière de routage devenue incapable de conduire les paquets jusqu'à lui.

Les effets visibles furent néanmoins larges. Des sites hébergés chez OVHcloud et des serveurs clients devinrent inaccessibles. Le propre site public de l'entreprise renvoya des erreurs, et sa page d'état fut elle aussi indisponible selon les comptes rendus. La presse française cita des milliers de sites et donna des exemples de services publics et commerciaux. Ces observations montrent l'étendue de la dépendance, mais elles ne constituent pas un inventaire exhaustif ni un décompte audité de tous les clients touchés.

La panne illustre ainsi la différence entre intégrité des actifs et disponibilité du service. Rien dans les quatre sources ne permet d'affirmer que des données clients ont été perdues ou que des machines ont été détruites. L'événement de mars 2021 à Strasbourg, marqué par un incendie de centre de données, est un autre incident. Mélanger ces deux histoires produirait une description matérielle fausse de la défaillance d'octobre.

Une chronologie de propagation, d'échec et d'isolement

Le compte rendu détaillé situe le début du changement planifié à 09 h 05 CET. À 09 h 18, des actions d'isolation BGP et de mise à jour de configuration étaient en cours. Le problème de configuration apparut à 09 h 20, puis les difficultés de performance du routeur furent détectées et escaladées à 09 h 21. Ces repères montrent que la dégradation s'est révélée rapidement, mais que la détection n'a pas immédiatement fourni un moyen de confinement efficace.

À 09 h 30, le retour arrière avait échoué et l'équipe choisit l'isolement physique. Ce détail est central. Un plan de restauration qui dépend du bon fonctionnement du routeur modifié peut perdre sa capacité d'action au moment même où l'équipement est surchargé. Retirer des routes, recalculer des tables et traiter des commandes consomment les ressources déjà épuisées par la mauvaise propagation. Le retour arrière doit donc être évalué dans les conditions de défaillance, pas seulement lors d'un essai propre.

Le routeur fut finalement éteint à 10 h 18. Deux minutes plus tard, à 10 h 20, OVHcloud annonçait le retour des premiers services après convergence du réseau. La crise technique ne fut toutefois déclarée terminée qu'à 10 h 57. Les formulations responsables doivent conserver ces jalons séparés. Le premier service revenu ne signifie pas que toute la plateforme était stable ; l'isolement de l'équipement ne signifie pas que toutes les dépendances avaient déjà récupéré.

Une communication plus précoce du même jour employait des horaires plus arrondis, notamment 09 h 12 pour l'intervention et 10 h 15 pour l'isolation. Le compte rendu post-incident détaillé fournit la base la plus précise pour analyser la séquence. La différence entre une mise à jour de crise et une reconstruction ultérieure n'est pas en elle-même suspecte, mais elle rappelle que les horodatages doivent être attribués au document qui les porte.

Les contrôles existaient, mais n'ont pas borné l'état produit

OVHcloud a indiqué que la modification avait été préparée dans son comité consultatif des changements, documentée dans une méthode opératoire et relue par des pairs. Il serait donc inexact d'affirmer que l'intervention n'avait pas été examinée. Cette existence de contrôles rend au contraire l'incident plus utile : elle permet de distinguer l'approbation formelle de la preuve technique qu'un changement restera dans une enveloppe sûre.

Un CAB peut juger la nécessité, le calendrier, les dépendances et le plan de retour. Un MOP peut ordonner les étapes et préciser les commandes. Une revue par les pairs peut repérer une faute apparente. Aucun de ces dispositifs ne garantit, à lui seul, que le routeur interprétera l'instruction comme prévu, que la redistribution restera limitée ou que le réseau refusera automatiquement un volume de routes incompatible avec son IGP.

La question n'est donc pas de remplacer la procédure par l'automatisation. Elle est de relier chaque approbation à une preuve exécutable. Avant l'intervention, les opérateurs devraient connaître les préfixes autorisés, la variation maximale du nombre de routes, les transformations d'attributs attendues, les filtres appliqués et les domaines qui recevront l'annonce. Pendant l'intervention, l'état observé devrait être comparé à cette enveloppe. En cas d'écart, une limite indépendante de l'équipement modifié devrait stopper la propagation.

Cette logique protège également les personnes. Lorsque la sécurité dépend d'un individu qui reconnaît instantanément un comportement complexe sous pression, l'organisation transforme une faiblesse systémique en risque personnel. Des bornes techniques, des canaris, une activation progressive et une autorité d'arrêt explicite réduisent la nécessité de deviner la cause avant d'agir.

Ce que signifie un retour arrière réellement utilisable

Le terme « retour arrière » peut désigner plusieurs capacités. Il peut s'agir de saisir une commande inverse, de restaurer une configuration antérieure, de retirer une session, d'isoler une redistribution ou de couper physiquement un équipement. Ces actions n'ont ni la même vitesse, ni les mêmes dépendances, ni le même effet lorsque le plan de contrôle converge en boucle.

Dans cet incident, le retour logiciel tenté ne rétablit pas le service. L'équipe dut se rendre jusqu'au routeur, l'isoler puis l'éteindre. Le fait que cette action ait permis la convergence ne révèle pas pourquoi le retour précédent avait échoué, mais il démontre la valeur d'un chemin de commande indépendant. Une organisation ne devrait pas découvrir pendant une panne que son seul moyen de contrôler un équipement traverse précisément le réseau que cet équipement perturbe.

Un plan crédible doit donc préciser les conditions qui déclenchent le passage d'une stratégie à l'autre. Si le nombre de routes ne redescend pas dans un délai défini, si l'accès de gestion est perdu ou si les ressources du routeur empêchent l'exécution, l'équipe doit savoir qui peut ordonner l'isolement et par quel canal. Attendre une certitude complète peut rendre l'état plus difficile à inverser.

Le test du retour doit aussi porter sur le service. Une configuration antérieure chargée avec succès n'est pas une preuve de récupération si les adjacences continuent de battre, si les tables restent hors limite ou si les clients n'atteignent toujours pas leurs applications. Les critères doivent combiner stabilité des protocoles, pression sur les ressources, retour de la joignabilité IPv4 et observations depuis l'extérieur du réseau.

Une page d'état doit survivre à l'incident qu'elle décrit

L'indisponibilité rapportée du site et de la page d'état d'OVHcloud ajoute une dimension de continuité opérationnelle. Lorsqu'un canal d'information partage les mêmes dépendances de routage que les services affectés, il peut disparaître au moment où clients et équipes ont le plus besoin de lui. La communication devient alors une victime du même rayon d'impact.

Une page d'état indépendante ne répare pas BGP ou OSPF, mais elle réduit l'incertitude. Elle permet de publier des jalons distincts, d'indiquer la différence entre IPv4 et IPv6 et d'éviter que le premier signe de reprise soit interprété comme une restauration complète. Elle donne aussi aux clients la possibilité d'ajuster leurs propres décisions sans multiplier les requêtes vers des systèmes déjà fragilisés.

L'indépendance doit être vérifiée de bout en bout : autorité DNS, hébergement, réseau de distribution, accès administratif et mécanisme de publication. Déplacer une page sur un autre serveur du même domaine de panne ne suffit pas. Le même raisonnement vaut pour l'accès hors bande aux routeurs et pour les sondes de disponibilité : une redondance nominale n'est utile que si elle ne partage pas le contrôle qui vient d'échouer.

Les inconnues fixent la limite de l'attribution

Les sources publiques ne donnent pas le texte exact de la commande, le nombre de routes, le nombre de routeurs affectés, la topologie complète ni les journaux de décision. Elles ne nomment pas l'ingénieur responsable de l'exécution et ne permettent pas de savoir ce que chaque participant comprenait à chaque minute. Une attribution personnelle dépasserait donc les faits disponibles.

Certains articles ont relayé, à propos d'un message de direction ensuite supprimé, l'hypothèse d'une erreur de copier-coller. Le compte rendu détaillé publié plus tard ne confirme pas cette hypothèse comme cause définitive. Ce qui peut être affirmé est plus circonscrit : le routeur n'a pas interprété correctement une commande de redistribution, la table Internet complète a atteint l'IGP et les conséquences sur le plan de contrôle ont rendu IPv4 inopérant.

Le bilan quantitatif connaît la même limite. Les observations attestent une perturbation étendue et de nombreux sites inaccessibles, mais aucun nombre exact de clients, de services, de pays ou de pertes financières n'est établi. L'absence d'un chiffre total ne diminue pas la gravité de l'incident ; elle empêche simplement de transformer des exemples visibles en mesure exhaustive.

Ces limites conduisent à une conclusion plus solide. Une modification de sécurité planifiée et revue a créé un état de routage hors enveloppe, épuisé les ressources du plan de contrôle, résisté au retour logiciel et exigé une intervention physique. La responsabilité de l'entreprise consiste à montrer que les routes sont désormais validées par leur effet, que la redistribution est bornée, que l'accès de secours est indépendant et que le rétablissement se mesure du point de vue du service. Les informations disponibles ne démontrent pas l'efficacité actuelle de ces mesures.

Sources