En 2016, l’attaque Mirai contre OVH a transformé la capacité anti

Résumé

OVHcloud a publiquement indiqué avoir subi, en septembre 2016, une attaque associée à Mirai dépassant un térabit par seconde. Cette valeur est une mesure attribuée à l’opérateur. Elle ne constitue pas un audit indépendant, paquet par paquet, de l’ensemble des cibles, des interfaces, des équipements compromis ou des conséquences pour les clients. [1][2]
Les travaux présentés à USENIX Security fournissent la reconstruction technique indépendante la plus solide de Mirai. Ils situent le début des attaques contre l’infrastructure d’OVH au 18 septembre 2016, décrivent une population du botnet ayant culminé autour de 600 000 infections et analysent plus de 15 000 attaques sur la période observée. Ils éclairent la chronologie et la mécanique du botnet, mais ne révèlent ni l’architecture privée d’OVH ni un bilan exhaustif de la continuité de chaque service hébergé. [3][4]
L’épisode OVH doit rester distinct des attaques contre KrebsOnSecurity et Dyn. Le recours à une même famille de logiciel malveillant ne transforme pas des cibles, des dates, des dépendances et des effets opérationnels différents en un incident unique. Chez OVH, le cœur de l’analyse porte sur la continuité d’un réseau d’hébergement confronté à un déluge distribué et sur la capacité de mitigation nécessaire pour maintenir un chemin utilisable vers les services légitimes.
Mirai pouvait émettre directement depuis des caméras, enregistreurs et autres objets connectés compromis, au moyen d’adresses sources normalement routables. Cette mécanique diffère d’une attaque par réflexion-amplification reposant sur des adresses usurpées. Le filtrage à la source recommandé par les BCP 38 et 84 reste essentiel contre l’usurpation, mais il n’aurait pas, à lui seul, empêché des appareils compromis d’envoyer directement leur trafic vers OVH. [15][16][19][20]
La capacité anti-DDoS d’un hébergeur ne se résume pas à un plafond exprimé en térabits par seconde. Elle dépend aussi du nombre de paquets par seconde, de la capacité de traitement des routeurs, de la stabilité du plan de contrôle, de la disponibilité des tables et règles de filtrage, du transport entre sites, de la réserve des plateformes de scrubbing et, surtout, de la possibilité de remettre le trafic légitime sur un chemin fonctionnel.
Une mitigation réussie doit produire deux résultats simultanés : rejeter ou contenir le trafic hostile et livrer le trafic utile. Un système peut afficher des milliards de paquets bloqués tout en laissant les clients injoignables si le chemin de sortie de la plateforme de filtrage est saturé, si une règle supprime des protocoles légitimes ou si une modification de routage provoque une panne secondaire.
La responsabilité est distribuée selon les moyens de contrôle réels. Les fabricants influencent les identifiants par défaut, les services exposés, les mises à jour et la durée de support. Les propriétaires d’équipements peuvent corriger, isoler ou remplacer leurs appareils. Les réseaux d’accès peuvent repérer des comportements sortants anormaux. Les opérateurs de transit et d’hébergement contrôlent capacité, filtrage, ingénierie de trafic, télémétrie et rétablissement. Les autorités judiciaires traitent la conduite des opérateurs du botnet. [5][9]-[14]
Les sources publiques ne permettent pas d’affirmer combien de clients OVH furent affectés, pendant combien de temps, selon quelles obligations contractuelles ou avec quelles pertes. Elles ne révèlent pas davantage les seuils privés, la topologie exacte de scrubbing, les politiques de routage ou la réserve de capacité. La conclusion défendable porte donc sur la qualité des preuves qu’un opérateur devrait pouvoir conserver et rapprocher : mesures horodatées, activation maîtrisée, trafic légitime observable, dommages collatéraux bornés et rétablissement vérifiable.

Un térabit par seconde : un signal majeur, pas un bilan complet

En septembre 2016, OVHcloud a rapporté un trafic d’attaque supérieur à un térabit par seconde au cours de la première grande vague associée à Mirai. La chronologie publiée par l’entreprise et un article technique ultérieur présentent Mirai comme le premier botnet ayant généré plus de 1 Tbit/s contre son infrastructure. [1][2] Ce chiffre reste marquant : il montrait qu’un vaste ensemble d’appareils grand public compromis pouvait mobiliser une puissance suffisante pour menacer une infrastructure d’hébergement internationale.

Mais un pic de débit ne répond pas, à lui seul, aux questions qui déterminent la continuité d’un service. Il ne dit pas nécessairement où la mesure a été prise, si elle correspondait à une seule interface ou à l’agrégation de plusieurs sites, si elle précédait ou suivait un premier filtrage, combien de temps le maximum avait duré, ni quelle proportion du trafic avait effectivement atteint les réseaux des clients.

L’emplacement de la mesure change pourtant son interprétation. Un relevé effectué sur plusieurs liens de transit décrit une pression globale différente d’une mesure sur l’interface d’un seul routeur. Une valeur observée avant scrubbing ne renseigne pas directement sur la charge résiduelle du réseau interne. Une valeur prise après élimination d’une partie du trafic peut, inversement, sous-estimer la quantité que les équipements en amont ont dû recevoir et classifier.

Le débit en bits ne révèle pas non plus la composition du flux. À volume binaire égal, de nombreux petits paquets imposent davantage d’opérations de lecture, de classification, de recherche en table, de mise en file et de comptabilisation qu’un nombre plus faible de grands paquets. Deux attaques affichant le même nombre de gigabits par seconde peuvent ainsi éprouver des ressources tout à fait différentes.

La durée importe autant que le sommet. Un réseau peut tolérer une pointe très brève grâce aux files, aux réserves ou à une marge temporaire, mais ne pas soutenir une charge proche de cette limite pendant plusieurs minutes. À l’inverse, un débit inférieur au record peut provoquer davantage de dommages s’il se concentre sur une destination, un protocole, une ligne de carte ou un composant de contrôle moins bien dimensionné.

Il faut donc conserver une formulation stricte : OVH a rapporté un pic supérieur à un térabit par seconde. Les sources disponibles ne permettent pas de transformer cette annonce en expertise indépendante de chaque paquet, de chaque cible ou de chaque impact. Elles ne justifient pas davantage une conclusion automatique de préparation parfaite, d’impréparation, de négligence ou de faute juridique.

La valeur du chiffre réside ailleurs. Il oblige à demander sur quelles ressources reposait la promesse de capacité : liens d’accès, routeurs de bordure, fabric interne, plateformes de filtrage, transport entre centres, capacité de retour du trafic légitime, ou combinaison de ces éléments. Il invite également à vérifier si les hypothèses de dimensionnement couvraient le débit de paquets et les transitions opérationnelles, et non le seul débit binaire nominal.

Une affirmation de capacité devient donc utile lorsqu’elle est accompagnée d’un périmètre. Quelle ressource a été mesurée ? À quel endroit ? Avec quelle distribution de tailles de paquets ? Pendant combien de temps ? Dans quel état de mitigation ? Quel composant a constitué la limite suivante ? Quelle part des transactions légitimes a continué d’aboutir ? Sans ces éléments, le térabit reste une alerte crédible, mais une preuve incomplète.

Ce que l’étude indépendante de Mirai établit

L’étude présentée à USENIX Security en 2017 constitue le socle indépendant de la chronologie technique. Ses auteurs ont croisé plusieurs points d’observation pour reconstruire la croissance de Mirai, ses activités de balayage, ses infections, son infrastructure de commande et son historique d’attaques. Ils indiquent que les attaques contre l’infrastructure d’OVH ont commencé le 18 septembre 2016. [3][4]

L’étude décrit également une population culminant autour de 600 000 appareils infectés et analyse plus de 15 000 attaques pendant la période couverte. Ces résultats montrent qu’un botnet composé d’équipements connectés ordinaires pouvait produire des flux distribués à l’échelle mondiale. Le caractère distribué ne dépendait pas nécessairement de réflecteurs : les équipements compromis pouvaient eux-mêmes générer le trafic.

Cette reconstruction est plus riche qu’un graphique fourni par une seule victime. Elle permet de relier les phases de découverte d’appareils vulnérables, de compromission et d’attaque. Elle contribue aussi à distinguer ce que le botnet était capable de faire de ce qu’un opérateur victime a mesuré à une frontière particulière de son réseau.

Elle ne remplace toutefois pas les données privées d’OVH. Les chercheurs ne disposaient pas, du seul fait de leur étude, de tous les compteurs d’interfaces, journaux de scrubbing, seuils d’activation, sondes applicatives, tickets clients, engagements commerciaux ou décisions internes de l’hébergeur. Leur travail ne constitue donc pas un registre exhaustif des conséquences subies par chaque client.

Le chiffre d’environ 600 000 infections décrit une population observée au cours de la trajectoire du botnet ; il ne signifie pas que chacun de ces appareils a participé à chaque attaque dirigée contre OVH. De même, l’analyse de plus de 15 000 attaques caractérise une période et un système malveillant, pas un ensemble de 15 000 événements tous identiques par cible, volume, durée ou méthode.

Cette distinction évite de confondre deux catégories de preuve. Les chercheurs pouvaient observer des éléments de la structure et du comportement de Mirai. OVH détenait des informations sur son réseau, ses clients et ses décisions de mitigation. Les fabricants, propriétaires d’appareils et réseaux d’accès détenaient d’autres fragments : version du logiciel, exposition du service, abonné concerné, signal de compromission ou action corrective.

Aucun de ces détenteurs ne possédait nécessairement toute la chaîne. Une analyse responsable doit donc rapprocher les sources sans leur attribuer des connaissances qu’elles n’avaient pas. Les données de l’opérateur étayent une mesure attribuée et des descriptions de fonctionnement. L’étude indépendante étaye la chronologie et la mécanique. Les textes institutionnels et les normes décrivent des familles de contrôles. Les procédures judiciaires établissent des faits juridiques circonscrits.

Le ministère américain de la Justice a annoncé des plaidoyers de culpabilité dans des affaires liées à Mirai. [5] Cette source peut établir que des personnes identifiées ont reconnu leur responsabilité pénale pour des conduites décrites dans ces dossiers. Elle ne permet pas de conclure que chaque paquet reçu par OVH avait été ordonné par ces personnes, ni d’identifier l’auteur de chaque campagne observée.

OVH, KrebsOnSecurity et Dyn : ne pas fusionner des incidents distincts

Mirai est associé à plusieurs attaques célèbres de 2016, notamment contre KrebsOnSecurity, OVH et Dyn. Leur proximité historique et l’emploi d’un même logiciel malveillant peuvent inciter à les raconter comme une seule attaque prolongée. Ce raccourci obscurcit pourtant les mécanismes de continuité propres à chaque cible.

L’épisode analysé ici est celui qu’OVH attribue à Mirai en septembre 2016 et que l’étude indépendante situe, pour les premières attaques contre son infrastructure, à partir du 18 septembre. [1]-[4] Le sujet est la capacité d’un réseau d’hébergement à observer, absorber, filtrer et acheminer un déluge direct tout en maintenant un service exploitable.

L’attaque contre Dyn relève d’une dépendance différente : la continuité d’un service DNS faisant autorité et les effets en cascade de la résolution de noms. Une panne de DNS peut rendre des services apparemment absents alors que leurs serveurs fonctionnent toujours. Une saturation visant un hébergeur éprouve, elle, les chemins de transit, les routeurs, les plateformes de mitigation et les réseaux hébergés.

KrebsOnSecurity constituait encore une autre cible, avec ses propres prestataires, chemins, mesures et décisions. Le fait que Mirai ait été impliqué dans plusieurs épisodes ne permet pas de transférer automatiquement à OVH les volumes, durées, conséquences ou mesures de défense documentés ailleurs.

Cette séparation protège également l’attribution. Une infrastructure de botnet peut évoluer, être partagée, modifiée ou réutilisée. Une chronologie générale ne suffit pas à établir l’identité de l’opérateur d’une attaque particulière. Les éléments judiciaires postérieurs doivent rester rattachés aux faits qu’ils documentent. [5]

Elle protège enfin l’analyse des contrôles. Une mesure pertinente pour un fournisseur DNS n’a pas forcément le même poids pour un hébergeur. Une réponse efficace pour une cible unique ne se transpose pas nécessairement à des milliers de préfixes ou de services clients. Les contraintes de routage, de connaissance applicative et de dommages collatéraux ne sont pas interchangeables.

La comparaison peut être instructive, mais elle doit rester explicite : même famille de menace, incidents distincts. Les dates, les cibles, les dépendances, les effets et les actions de mitigation doivent être conservés dans leurs périmètres respectifs.

Mirai n’était pas simplement une attaque par réflexion-amplification

Une attaque par réflexion commence généralement par une requête envoyée à un service tiers avec une adresse source falsifiée, celle de la victime. Le service répond alors à la victime. Lorsque la réponse est nettement plus volumineuse que la requête, le mécanisme produit une amplification. Il combine donc deux propriétés : l’usurpation de l’adresse source et l’existence d’un protocole ou service susceptible de réfléchir une réponse.

Le filtrage des adresses usurpées est particulièrement efficace contre cette famille. Le BCP 38, défini par le RFC 2827, recommande aux réseaux de bloquer en entrée les paquets dont l’adresse source ne correspond pas aux préfixes attendus. Le RFC 3704, associé au BCP 84, approfondit la question pour les réseaux multihébergés, où l’asymétrie légitime des chemins rend les contrôles trop simplistes dangereux. [15][16]

Le RFC 7039 et les recommandations de MANRS complètent ce cadre en décrivant des améliorations et pratiques opérationnelles de validation des adresses sources. [19][20] Une adoption plus large réduit les possibilités d’émettre du trafic usurpé et améliore la qualité des indices disponibles lors d’un incident.

Le cœur de la capacité offensive de Mirai ne dépendait cependant pas de ce schéma. Des caméras, enregistreurs et autres appareils infectés pouvaient envoyer directement des paquets à une victime en utilisant leurs adresses normalement routables. La distribution du trafic venait de la multitude d’équipements compromis, non de l’obligation de passer par des services réflecteurs. [3][4]

Dans ce cas, un filtre anti-usurpation peut fonctionner parfaitement et laisser tout de même passer le déluge : l’adresse source appartient bien au réseau qui transmet le paquet. Il faut alors détecter un comportement abusif produit par une adresse valide, informer ou contraindre la source, coordonner les opérateurs en amont et protéger la destination.

Dire que le BCP 38 n’aurait pas suffi n’en diminue pas l’importance. Le filtrage à la source reste indispensable contre les vecteurs qui reposent sur la falsification. Il réduit aussi certains obstacles à l’analyse. Mais le présenter comme le remède universel à Mirai déplacerait la responsabilité vers un contrôle qui ne correspond pas entièrement au mécanisme observé.

Une attaque peut par ailleurs combiner trafic direct, réflexion, protocoles multiples et changements de vecteur. L’opérateur doit donc classifier ce qu’il voit, puis conserver le degré de confiance attaché à cette classification. Une règle fondée sur l’hypothèse d’une réflexion UDP ne répondra pas nécessairement à un flux TCP direct, à un taux élevé de petits paquets ou à une séquence qui change de protocole.

Les publications du NIST sur la résilience des échanges interdomaines décrivent une défense en profondeur comprenant sécurité du routage, validation des adresses sources, détection, filtrage, limitation de débit, mise en trou noir déclenchée à distance, FlowSpec et coordination. [13][14] Ces documents, postérieurs à l’incident, offrent un cadre de contrôle ; ils ne prouvent pas qu’OVH avait déployé chacun de ces outils en septembre 2016.

Le RFC 4732 rappelle en outre que les contre-mesures à un déni de service peuvent causer leurs propres dommages. [17] Bloquer trop largement, déplacer le trafic vers un chemin sous-dimensionné ou retirer une route essentielle peut transformer la défense en seconde panne. La précision sur le mécanisme de l’attaque détermine donc non seulement l’efficacité du remède, mais aussi son risque collatéral.

La continuité d’hébergement traverse toute la chaîne réseau

Pour OVH, la surface centrale de responsabilité était le réseau exploité au bénéfice des clients. Face à un déluge distribué, l’opérateur devait détecter la charge avant la défaillance complète, décider quand activer la mitigation, acheminer ou filtrer les flux sans déstabiliser le routage et préserver un chemin pour les paquets légitimes.

Cette chaîne ne s’arrête pas à la bordure. Elle implique les liens de transit, les routeurs de périphérie, le backbone, les plateformes de scrubbing, le transport entre sites, les équipements proches des réseaux clients, les systèmes d’automatisation, les sondes de service et le commandement de l’incident.

La détection doit associer plusieurs vues. Les compteurs d’interface mesurent bits et paquets. Les données de flux décrivent protocoles, ports, distribution des sources et concentration des destinations. Les compteurs de routeurs révèlent pertes, files et pression sur le plan de contrôle. Les plateformes de filtrage indiquent leurs classifications et actions. Les sondes externes disent si un service utile répond encore.

Aucune de ces vues n’est suffisante isolément. Une hausse de trafic peut être une attaque, un lancement commercial ou une erreur de mesure. Une grande diversité de sources peut signaler un botnet, mais aussi un événement légitime mondial. Un équipement de scrubbing peut comptabiliser des millions de rejets tandis que les clients demeurent injoignables, faute de capacité sur le chemin du trafic filtré.

Le routage doit également être observé. Une route présente dans une table interne ne prouve pas qu’elle est correctement propagée dans toutes les régions. Une annonce BGP visible depuis un collecteur ne décrit pas tous les chemins privés ni toutes les décisions de préférence. Une modification apparemment correcte peut converger lentement ou être refusée par un partenaire.

Le choix entre protection permanente et activation à la demande ne se réduit pas à une opposition commerciale. Une solution à la demande conserve le chemin ordinaire en temps normal, mais introduit une transition au moment critique. Une solution permanente élimine cette transition particulière, tout en créant une dépendance constante à la plateforme de mitigation et à ses propres limites de classification et de capacité.

La bonne architecture dépend de la menace, des services, de la distribution géographique et des tests. Un dispositif hybride peut protéger certains préfixes en permanence et en détourner d’autres à la demande. Mais toute variante doit démontrer que les autorisations de route, les sessions, les capacités de retour et les sondes sont prêtes avant l’incident.

Le rapport du NSTAC sur la résilience des communications et les travaux gouvernementaux sur les botnets renforcent cette logique de dépendances partagées et de coordination entre acteurs. [6][10][11] Ils ne fournissent pas le schéma privé d’OVH ; ils montrent pourquoi la continuité ne peut pas reposer sur un équipement ou une organisation unique.

Les sources publiques ne permettent pas de reconstruire l’architecture complète d’OVH en 2016. L’évaluation doit donc porter sur les catégories de preuve nécessaires : état du réseau avant l’attaque, mesure du déluge, changement de mitigation, fonctionnement du chemin légitime et signal de rétablissement.

Débit en bits et débit de paquets : deux contraintes, plusieurs goulets

Le débit en bits par seconde est intuitif. Un lien possède une capacité nominale ; une attaque s’en approche ou la dépasse. Pourtant, cette grandeur ne mesure qu’une dimension de l’effort imposé au réseau. Chaque paquet, quelle que soit sa taille, demande au matériel de lire des en-têtes, consulter des tables, appliquer des règles, gérer une file, incrémenter des compteurs et décider d’un prochain saut.

Une attaque composée de petits paquets peut donc produire un débit binaire inférieur tout en épuisant la capacité de traitement en paquets par seconde. Cette distinction est particulièrement importante pour les routeurs de cœur et les équipements de filtrage. L’article technique ultérieur d’OVHcloud sur les attaques à fort taux de paquets éclaire ce risque général. [2] Il ne permet pas d’identifier rétrospectivement le composant limitant de l’incident de 2016.

Les limites d’un routeur ne forment pas un nombre unique. Les ports, circuits de transfert, matrices de commutation, mémoires tampon, processeurs de route, capacités de journalisation et tables de règles peuvent atteindre leurs seuils séparément. Une règle de filtrage peu coûteuse sur un modèle peut devenir lourde sur un autre. Une collecte de télémétrie trop détaillée peut elle-même aggraver la pression.

La topologie introduit d’autres contraintes. Un ensemble de sites peut annoncer une capacité globale impressionnante sans que cette capacité soit disponible pour chaque destination. Le trafic peut se concentrer sur une zone, un fournisseur de transit ou un chemin interne. Une réserve partagée peut être consommée par une première attaque alors qu’une seconde cible en a besoin.

Le passage en mitigation constitue un test distinct du régime stable. Une plateforme peut absorber le trafic une fois les routes et règles établies, mais échouer pendant la convergence, l’installation des filtres ou la montée du volume de journaux. Tester uniquement l’état final laisse ce moment critique sans preuve.

Les essais devraient couvrir plusieurs tailles de paquets, protocoles, distributions de sources, nombres de destinations et jeux de règles. Ils devraient mêler trafic hostile et trafic légitime, car un générateur qui n’envoie que l’attaque ne révèle pas le taux de faux positifs. Ils devraient aussi simuler la perte d’un site de scrubbing, d’un lien de retour ou d’un fournisseur.

Les résultats doivent conserver leurs hypothèses. Une capacité annoncée sous forme d’un débit maximal n’est comparable à une charge réelle que si la distribution des paquets, la configuration des règles, le nombre de préfixes, la journalisation et la durée sont documentés. Les chiffres de laboratoire ou de fournisseur doivent être distingués des observations de production.

Les tendances publiées par Akamai pour le troisième trimestre 2016 contribuent à situer l’environnement général des attaques de l’époque. [7][8] Elles ne constituent pas une mesure indépendante de l’événement OVH. Leur rôle est contextuel : elles montrent que la montée en puissance des attaques distribuées concernait un écosystème plus large, sans combler les lacunes propres au dossier d’OVH.

Pour un conseil d’administration ou un client, la question utile n’est donc pas seulement « combien de térabits ? ». Elle est : quelle ressource est testée, dans quelles conditions, avec quelles marges, quelles dépendances et quel résultat pour le service ? Une capacité sans matrice d’essai peut rassurer, mais elle ne décrit pas le point de rupture.

Le scrubbing doit prouver que le trafic légitime arrive

Une mitigation DDoS poursuit deux objectifs indissociables : contenir le trafic hostile et livrer le trafic utile. Le premier est facile à mettre en scène avec des volumes reçus ou bloqués. Le second exige de vérifier qu’une requête légitime accomplit réellement son parcours jusqu’au service, puis que la réponse revient à l’utilisateur.

Une route peut être annoncée alors que l’application reste inaccessible. Une connexion TCP peut s’ouvrir alors qu’une transaction échoue. Une moyenne mondiale peut masquer la disparition du service dans une région. Un tableau de bord de scrubbing peut afficher un grand nombre de paquets rejetés alors que le tunnel ou le lien ramenant le trafic filtré vers l’hébergeur est saturé.

La classification du trafic peut s’appuyer sur la validité du protocole, les comportements des sources, la réputation, la forme des paquets, le débit, la destination et la connaissance applicative. Chaque méthode comporte des faux positifs et faux négatifs. Un blocage UDP très large peut réduire une attaque tout en interrompant DNS, voix, jeux, télémétrie ou autres usages légitimes.

Une limitation par adresse source peut pénaliser de nombreux utilisateurs partageant une passerelle. Un mécanisme de défi adapté à un navigateur peut casser une API ou un équipement automatisé. Une interdiction visant un ASN ou une région peut contenir des sources malveillantes tout en excluant des clients sans rapport avec l’attaque.

L’hébergeur doit donc disposer de politiques assez générales pour protéger son réseau, mais assez adaptables pour tenir compte des services clients. Cette tension est structurelle : un fournisseur mutualisé ne connaît pas toujours à l’avance tous les comportements légitimes. Les clients doivent communiquer leurs protocoles essentiels, leurs contacts d’urgence et leurs contraintes ; l’opérateur doit offrir des mécanismes de dérogation contrôlés.

La preuve de continuité doit combiner sondes synthétiques et observations réelles. Des tests lancés depuis plusieurs réseaux et régions peuvent mesurer résolution, connexion, transaction, latence et perte. Ils doivent être rapprochés des compteurs de routeurs, des données de scrubbing et de l’état de l’origine.

Le rétablissement ne se réduit pas au premier signal vert. Une route peut revenir avant la stabilité. Une règle temporaire peut continuer à bloquer un segment de clientèle. Une seconde vague peut apparaître après le retrait de la mitigation. Une période d’observation doit donc suivre le retour apparent, avec des critères explicites de réactivation.

Les effets collatéraux doivent être consignés. Quels protocoles, réseaux ou clients furent contraints ? Quelles exceptions ont été nécessaires ? Une règle a-t-elle protégé une cible en déplaçant la charge vers une autre ? Combien de temps le trafic légitime est-il resté dégradé après la baisse du volume hostile ? Ces informations améliorent les contrôles futurs et permettent un compte rendu défendable.

Il n’est ni nécessaire ni prudent de publier toutes les signatures et tous les seuils. Un rapport public peut néanmoins décrire l’intervalle, le vecteur, l’ordre de grandeur attribué, l’action principale, le signal de rétablissement et les incertitudes. Des clients, auditeurs ou autorités dûment habilités peuvent examiner des éléments plus sensibles sous des conditions appropriées.

Les documents disponibles établissent l’ampleur annoncée par OVH et la nécessité d’une mitigation. Ils ne fournissent pas un registre client par client du trafic légitime livré pendant tout l’événement. Cette absence doit rester une inconnue : elle ne prouve ni une continuité parfaite ni une indisponibilité générale.

Une responsabilité distribuée selon les moyens de contrôle

Mirai a transformé des appareils compromis en composantes involontaires d’une infrastructure d’attaque. La chaîne de responsabilité commence donc bien avant l’arrivée des paquets chez l’hébergeur. Elle ne se concentre toutefois pas automatiquement sur un seul acteur.

Les fabricants de matériels et éditeurs de logiciels déterminent les identifiants initiaux, les services exposés, les possibilités de mise à jour, l’authentification des correctifs et la durée de support. Des identifiants uniques, des interfaces d’administration restreintes et une maintenance durable réduisent la probabilité qu’un parc entier soit compromis de manière répétable.

L’ENISA a souligné que des objets connectés d’usage quotidien pouvaient être incorporés à des botnets. [9] Les rapports des départements américains du Commerce et de la Sécurité intérieure ont ensuite appelé à une action coordonnée dans tout l’écosystème technologique. [10][11] Ces documents décrivent une répartition des contrôles ; ils ne prouvent pas qu’un fabricant précis a sciemment causé l’attaque contre OVH.

Les propriétaires d’appareils influencent leur déploiement. Ils peuvent modifier des identifiants, réduire l’exposition, installer des mises à jour, segmenter un réseau, isoler un équipement ou remplacer un produit devenu impossible à maintenir. Leur capacité d’action dépend cependant de la conception du produit, de l’existence d’un correctif et de leurs compétences.

Les réseaux d’accès peuvent observer des balayages sortants, un grand éventail de destinations ou un débit d’attaque inhabituel. Ils peuvent maintenir des contacts d’abus opérationnels, informer les abonnés et appliquer des mesures proportionnées. Mais une adresse vue dans un flux ne suffit pas à démontrer qu’un opérateur d’accès connaissait la compromission ou avait délibérément laissé agir l’appareil.

Les opérateurs de transit peuvent offrir capacité, filtrage, FlowSpec, mise en trou noir et coordination en amont. Leur position leur permet parfois de réduire la charge avant qu’elle n’atteigne les accès de la victime. Ils doivent en contrepartie maîtriser l’autorisation et les dommages collatéraux : une annonce ou un blackhole mal délimité peut supprimer le service que la mesure devait protéger.

OVH contrôlait sa bordure d’hébergement, l’ingénierie de ses chemins, ses mécanismes de mitigation, une partie de la communication client et les preuves internes de rétablissement. Cela en fait l’opérateur central de cette analyse. L’entreprise ne contrôlait ni le micrologiciel de tous les appareils compromis ni les mesures prises par chaque réseau source.

Les forces de l’ordre interviennent sur l’enquête et la poursuite des opérateurs du botnet, non sur le filtrage en temps réel. Le dossier du ministère américain de la Justice fournit un contexte juridique délimité. [5] Il ne remplace pas les mesures réseau et n’autorise pas une attribution générale de tous les flux reçus par OVH.

Le NIST a consacré des travaux à la réduction des DDoS fondés sur l’Internet des objets et, plus largement, à la résilience des échanges interdomaines. [12]-[14] Leur apport principal est de montrer qu’aucun contrôle isolé ne couvre la chaîne complète. La sécurité des appareils, la validation des sources, le routage, le filtrage, la capacité et les procédures d’intervention doivent se compléter.

La responsabilité suit donc la capacité pratique d’observer et de modifier. Il faut demander à chaque acteur ce qu’il pouvait voir, quelle action il pouvait prendre, quelles limites il rencontrait et quelle preuve il pouvait transmettre à l’acteur suivant. Cette méthode évite d’attribuer tous les dommages à la marque la plus visible ou, à l’inverse, de diluer toute responsabilité dans la complexité d’Internet.

Des données de source utiles sans accusation hâtive

Dans un déluge direct, l’adresse source peut être techniquement valide tout en identifiant seulement une connexion d’abonné, une passerelle de partage d’adresses, une entreprise ou un équipement compromis. Elle ne désigne pas nécessairement la personne qui a décidé de lancer l’attaque.

Une notification exploitable doit comporter un horodatage avec fuseau, les adresses source et destination, le protocole, les ports, les nombres de paquets et d’octets, la méthode d’échantillonnage, le degré de confiance, l’action de mitigation et le résultat du contrôle d’usurpation. Lorsque le droit et la proportionnalité le permettent, un échantillon court ou une signature peut aider le réseau d’origine à distinguer l’abus d’un usage normal.

Les registres d’adresses IP et d’ASN permettent d’identifier le réseau auquel une ressource a été déléguée et les contacts qui lui sont associés. Ils constituent des répertoires de ressources et de métadonnées opérationnelles. Ils ne prouvent pas l’identité humaine de l’émetteur d’un paquet.

De même, l’origine BGP d’une route indique quel système autonome annonçait la joignabilité d’un préfixe à un moment donné. Elle ne permet pas, à elle seule, de savoir qui possédait l’appareil compromis, si l’adresse était partagée, ni si le réseau annonçant la route avait déjà détecté le comportement.

La valeur d’un registre dépend donc de son raccordement aux opérations. Les données doivent être exactes et suffisamment actuelles pour que le contact reçoive le signal. Le destinataire doit disposer d’informations permettant de retrouver le client ou l’équipement. L’émetteur doit conserver le ticket, la réponse, l’action et toute récidive observée.

Une répétition documentée peut révéler une faiblesse systémique. Un seul signal peut résulter d’une compromission temporaire, d’une adresse réaffectée ou d’une mesure imparfaite. Il faut distinguer l’observation technique, le rattachement à une ressource réseau et l’attribution d’une intention.

Les recommandations de MANRS rendent les attentes d’anti-usurpation et de coordination plus concrètes. [20] Leur valeur ne tient cependant pas à une simple déclaration d’adhésion. Un opérateur doit pouvoir montrer que ses filtres, contacts et procédures fonctionnent sur le réseau en exploitation.

Pour OVH, des informations précises sur les sources auraient pu faciliter les notifications et le filtrage ciblé. Les sources publiques ne révèlent ni l’ensemble des systèmes autonomes concernés ni la réponse de chacun. Ces éléments demeurent entre les mains des opérateurs qui les ont observés.

Activer la mitigation sans provoquer une seconde panne

Le moment où un opérateur modifie le traitement du trafic est lui-même dangereux. Une règle peut bloquer des paquets légitimes. Une route peut retirer le mauvais préfixe. Une session vers une plateforme de scrubbing peut ne pas s’établir. Deux équipes peuvent appliquer des changements incompatibles.

Une politique d’activation doit préciser qui peut agir, sur quels préfixes et services, avec quels signaux déclencheurs et selon quels critères de réussite. L’automatisation réduit les délais, mais elle doit être limitée à des objets et chemins autorisés. L’intervention humaine traite l’inédit, mais elle suppose des rôles clairs et un responsable unique de l’incident.

Avant une attaque, l’opérateur doit tester les autorisations de route, les sessions, les communautés, les listes de préfixes, les capacités de retour et les sondes. Il doit connaître le comportement des services avec des chemins asymétriques et vérifier qu’une diversion partielle ne crée pas d’état incohérent.

Les exercices doivent inclure la défaillance d’un composant. Une plateforme de scrubbing peut être indisponible, un transit saturé ou un chemin de retour insuffisant. Tester uniquement la situation idéale prouve que le scénario idéal fonctionne, non que le service résiste à une attaque réelle combinée à une panne ordinaire.

Pendant l’incident, les changements significatifs doivent être inscrits dans un journal commun et horodaté. Le but n’est pas de ralentir l’intervention par une cérémonie administrative, mais de permettre aux équipes de savoir quelle action est active, qui en est responsable, quel résultat est attendu et ce qui devra être annulé.

Le retour à l’état normal mérite autant d’attention que l’activation. Retirer la mitigation trop tôt expose le service à une reprise. Conserver indéfiniment une règle d’urgence peut produire une dégradation silencieuse. Un retrait progressif, une période stable d’observation et un seuil clair de réactivation réduisent ces risques.

Le RFC 4732 insiste sur les effets indésirables possibles des défenses contre le déni de service. [17] Le RFC 4948 replace ces difficultés dans un ensemble plus large de défis de sécurité, de responsabilités distribuées et d’incitations incomplètes. [18] Ces textes ne décrivent pas le manuel privé d’OVH ; ils justifient l’exigence de mesurer la défense par ses conséquences.

Une procédure peut être cohérente sur le papier et échouer à la frontière réelle : annonce refusée, tunnel trop étroit, dépendance client hors du chemin filtré ou sonde incapable de représenter l’usage. La preuve décisive vient d’un exercice ou d’un incident montrant que le chemin prévu a effectivement transporté le service.

Le dossier de preuve attendu d’un opérateur d’hébergement

Un compte rendu solide ne promet pas qu’aucune attaque ne réussira jamais. Il indique ce qui a été observé, quelles ressources ont été sollicitées, quelles décisions ont été prises, quel trafic utile a subsisté et quelles inconnues restent ouvertes.

Surface de contrôle	Preuve à conserver	Essai opérationnel	Limite importante
Détection	Compteurs d’interface, données de flux, taux de paquets et sondes de service synchronisés	Plusieurs signaux identifient le déluge avant la défaillance dure	Échantillonnage et agrégation peuvent masquer une pointe locale
Limite de capacité	Capacités des liens, du transfert, des filtres et du chemin légitime pour des mélanges de paquets définis	La charge représentative reste dans les limites testées	Un chiffre de laboratoire peut différer de la production
Autorité de mitigation	Préfixes approuvés, responsables, sessions et conditions de déclenchement	Seules les routes et règles prévues changent	L’autorisation interne ne garantit pas la convergence externe
Diversion du trafic	Annonces avant/après, observations externes et acceptation par les partenaires	Le trafic prévu rejoint le chemin de mitigation	Aucun collecteur n’observe tous les chemins privés
Classification	Protocoles, distribution des sources, échantillon et degré de confiance	Les règles réduisent le vecteur observé	Le vecteur peut changer et une signature peut surbloquer
Livraison légitime	Sondes régionales, transactions, latence et état de l’origine	Les requêtes utiles aboutissent pendant la mitigation	Les sondes peuvent manquer un usage propre à un client
Effets collatéraux	Classes légitimes bloquées, exceptions et signalements clients	Les dommages restent dans des limites explicites	Certains utilisateurs ne déclarent pas leur échec
Coordination des sources	Notifications horodatées, contacts, réponses et récurrences	Le réseau d’origine peut retrouver et contraindre l’équipement	L’adresse ne prouve ni identité humaine ni intention
Retour à la normale	Journal des changements, responsable, critères et retrait progressif	Le routage normal revient sans rechute immédiate	Une nouvelle vague peut imposer une réactivation
Durabilité	Exercices, révisions de capacité, exceptions et procédures à jour	Les contrôles continuent de réussir dans le temps	Un incident bien géré n’est pas une preuve permanente

Cette grille sépare documents et résultats. Un ticket montre qu’une action a été demandée. Un plan de capacité décrit une hypothèse. Une entrée ASN relie une ressource à un réseau. Une configuration décrit une règle. Aucun de ces éléments ne prouve isolément que les utilisateurs ont achevé leurs transactions pendant l’attaque.

Le principe essentiel est le rapprochement des mesures. Les compteurs d’interface doivent être cohérents avec la télémétrie de scrubbing. Les changements de route doivent correspondre aux observations externes. Les filtres doivent être comparés à l’état des origines et aux sondes applicatives. Les signalements clients doivent être rapprochés des mesures régionales.

Une divergence ne signifie pas nécessairement qu’une source est fausse. Elle peut révéler des périmètres différents : mesure avant ou après filtrage, agrégation sur plusieurs sites, horloges décalées, échantillonnage, visibilité partielle ou panne limitée à une région. Le dossier doit conserver ces différences et leur résolution.

Les éléments peuvent être répartis selon leur sensibilité. Le public peut recevoir l’intervalle, le vecteur, l’ordre de grandeur, les principales actions, le signal de retour et les inconnues. Les clients, auditeurs ou autorités peuvent examiner sous protection la topologie, les seuils, les échantillons, les obligations contractuelles et les décisions internes.

La qualité du dossier ne dépend donc pas de la publication de secrets défensifs. Elle dépend de l’existence d’éléments vérifiables, reliés par le temps et suffisamment précis pour expliquer ce qui a fonctionné, ce qui a échoué et ce qui a été corrigé.

Ce que les sources publiques ne permettent pas d’affirmer

Le dossier public étaye l’existence d’attaques Mirai contre l’infrastructure d’OVH et le pic supérieur à un térabit par seconde annoncé par l’opérateur. [1]-[4] Il étaye également l’échelle du botnet, sa capacité à produire du trafic direct distribué et la pertinence d’une réponse multicouche.

Il ne précise pas toutes les cibles OVH, le nombre de clients affectés, la durée de chaque interruption ou dégradation, ni la part de trafic légitime livrée pendant chaque phase. Il ne révèle pas les pertes financières, les crédits de service, les obligations contractuelles ou un éventuel manquement à une norme juridique.

Il ne donne pas la topologie complète des plateformes de scrubbing, les seuils d’activation, les signatures de filtrage, les réserves de capacité, les politiques privées de routage ou les limites détaillées des équipements. Il ne fournit pas non plus d’audit indépendant de chaque paquet composant le pic annoncé.

Il n’identifie pas l’ensemble des appareils ou des systèmes autonomes ayant participé à chaque attaque contre OVH. Une adresse source ou une route observée ne suffit pas à conclure qu’un réseau savait qu’il transportait un trafic malveillant, ni qu’il avait la possibilité immédiate de l’arrêter sans dommage disproportionné.

Les documents postérieurs d’OVH, du NIST, de la NTIA, de l’ENISA, de l’IETF et de MANRS éclairent les contrôles applicables. [2][9]-[20] Ils ne doivent pas être utilisés comme preuve rétroactive que chacun de ces contrôles était déployé dans le réseau privé d’OVH en septembre 2016.

Le dossier judiciaire américain établit des faits limités concernant des personnes ayant plaidé coupable dans des affaires liées à Mirai. [5] Il ne permet pas d’attribuer chaque attaque observée par OVH, ni chaque paquet, aux mêmes individus.

Ces lacunes ne rendent pas l’épisode impropre à l’analyse. Elles définissent la frontière d’une conclusion sérieuse. Il est possible d’évaluer les preuves et contrôles qu’un hébergeur devrait posséder sans inventer un rapport d’incident privé à partir de résumés publics.

Questions que les opérateurs et leurs clients devraient poser

Les opérateurs d’hébergement et de transit devraient vérifier :

si leurs références de trafic associent débit en bits, taux de paquets, protocoles et réussite applicative ;
quel composant atteint sa limite pour de petits paquets, de grands paquets et un mélange réaliste ;
quels préfixes, sites et clients peuvent être filtrés ou détournés indépendamment ;
si les sessions de mitigation, autorisations de route et chemins de retour sont exercés ;
si les équipes peuvent observer la capacité des partenaires et l’état des filtres pendant l’incident ;
si une autorité unique contrôle l’activation, les exceptions et le retour à la normale ;
si les notifications aux réseaux sources contiennent des preuves précises et proportionnées ;
si le rétablissement dépend de systèmes eux-mêmes exposés à la saturation.

Les fabricants et propriétaires d’appareils devraient vérifier :

si les identifiants sont uniques et les interfaces d’administration restreintes par défaut ;
si les mises à jour sont authentifiées et disponibles pendant la durée de vie utile ;
si la fin du support est annoncée avant que l’équipement ne devienne une infrastructure non maintenue ;
si les comportements sortants anormaux peuvent être observés ;
si l’isolation ou le remplacement d’un appareil irréparable est réaliste.

Les clients d’un hébergeur devraient demander :

quels volumes et mélanges de paquets ont été testés dans des conditions représentatives ;
si la mitigation est permanente, à la demande ou hybride, et ce qui déclenche la transition ;
quels protocoles légitimes peuvent être restreints par les règles d’urgence ;
comment l’opérateur démontrera la livraison du trafic utile et le rétablissement régional ;
quelles preuves et communications sont fournies après l’incident ;
si les fournisseurs, routes ou origines de secours sont réellement indépendants et testés.

Ces questions n’exigent ni une capacité infinie ni l’absence absolue de panne. Elles évaluent si l’opérateur sait reconnaître une menace connue, agir avec une autorité bornée, protéger un service essentiel et rendre compte du résultat.

Conclusion : la capacité devient crédible lorsque le trafic utile survit

Le pic supérieur à un térabit par seconde rapporté par OVHcloud reste un jalon de l’histoire des DDoS. Les travaux indépendants sur Mirai montrent comment un grand nombre d’appareils compromis pouvait produire directement un déluge distribué. Les normes et rapports institutionnels montrent pourquoi la réponse doit associer sécurité des équipements, réseaux sources, transit, hébergement, filtrage, routage et intervention judiciaire. [1]-[20]

La leçon n’est pas qu’un hébergeur devrait acheter une bande passante illimitée. Aucun réseau sérieux ne peut garantir l’absorption de tout volume imaginable. L’exigence raisonnable consiste à définir les ressources protégées, tester leurs limites, maîtriser les changements d’urgence et conserver la preuve du service rendu.

Cette preuve comprend le débit en bits et en paquets à des frontières nommées, le déclencheur de mitigation, l’autorité sur les routes et les filtres, la capacité du chemin légitime, les sondes applicatives, les effets collatéraux, la coordination avec les réseaux sources et un retour à la normale répété et contrôlé.

Elle exige aussi de respecter la mécanique de l’attaque. Le filtrage anti-usurpation répond aux paquets falsifiés ; il ne remplace ni la sécurité des appareils ni la détection d’un trafic direct provenant d’adresses valides. Une responsabilité précise attribue à chaque acteur les contrôles qu’il détenait réellement.

Les registres IP, numéros d’ASN, graphiques de trafic, plans de capacité et tickets d’incident sont des éléments essentiels. Ils ne sont pas le service lui-même. Pour un réseau d’hébergement sous pression, le résultat décisif est le trafic légitime qui continue d’atteindre sa destination, la ressource contrainte qui reste dans ses limites et le rétablissement qu’un tiers autorisé peut vérifier.

Sources

OVHcloud, « Qu’est-ce qu’une attaque DDoS ? » : https://www.ovhcloud.com/en-gb/security/anti-ddos/ddos-definition/
OVHcloud, « The rise of packet rate attacks: when core routers turn evil » : https://blog.ovhcloud.com/en/posts/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/
USENIX Security 2017, page de présentation de « Understanding the Mirai Botnet » : https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis
Antonakakis et al., « Understanding the Mirai Botnet » : https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf
Département américain de la Justice, poursuites et plaidoyers de culpabilité liés à Mirai : https://www.justice.gov/archives/opa/pr/justice-department-announces-charges-and-guilty-pleas-three-computer-crime-cases-involving
National Security Telecommunications Advisory Committee, rapport sur la résilience d’Internet et des communications : https://www.cisa.gov/sites/default/files/publications/NSTAC%20Report%20to%20the%20President%20on%20ICR%20FINAL%20%2810-12-17%29%20%281%29-%20508%20compliant_0.pdf
Akamai, synthèse du rapport sur la sécurité d’Internet au troisième trimestre 2016 : https://www.akamai.com/site/en/documents/state-of-the-internet/q3-2016-state-of-the-internet-security-executive-summary.pdf
Akamai, annonce du rapport sur la sécurité d’Internet au troisième trimestre 2016 : https://www.akamai.com/content/akamai/it/newsroom/press-release/akamai-releases-third-quarter-2016-state-of-the-internet-security-report1
ENISA, « The Internet of Things: when your washing machine and blood pressure monitor become a target for cyberattacks » : https://www.enisa.europa.eu/news/enisa-news/the-internet-of-things-when-your-washing-machine-and-blood-pressure-monitor-become-a-target-for-cyberattacks
NTIA, annonce du rapport des départements du Commerce et de la Sécurité intérieure sur les botnets : https://www.ntia.gov/press-release/2018/us-departments-commerce-homeland-security-release-report-president-promoting-action-against-botnets
Départements américains du Commerce et de la Sécurité intérieure, rapport sur les botnets : https://www.ntia.gov/sites/default/files/publications/eo_13800_botnet_report_for_public_comment_0.pdf
NIST, « Mitigating IoT-Based DDoS » : https://csrc.nist.gov/pubs/pd/2017/12/14/mitigating-iotbased-ddos/final
NIST, « Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation » : https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation
NIST Special Publication 800-189 : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
IETF, RFC 2827 / BCP 38, filtrage en entrée du réseau : https://datatracker.ietf.org/doc/rfc2827/
IETF, RFC 3704 / BCP 84, filtrage en entrée pour les réseaux multihébergés : https://datatracker.ietf.org/doc/rfc3704/
IETF, RFC 4732, considérations sur le déni de service Internet : https://datatracker.ietf.org/doc/rfc4732/
IETF, RFC 4948, défis de sécurité d’Internet : https://datatracker.ietf.org/doc/rfc4948/
IETF, RFC 7039, amélioration de la validation des adresses sources : https://datatracker.ietf.org/doc/html/rfc7039
MANRS, guide réseau sur l’anti-usurpation : https://docs.manrs.org/docs/network-guide/anti-spoofing/

En 2016, l’attaque Mirai contre OVH a transformé la capacité anti-DDoS en épreuve de responsabilité

Pourquoi c'est important