Détournement Route 53 2018: responsabilité BGP-DNS

Résumé

L’analyse de routage contemporaine de Cloudflare a enregistré des annonces plus spécifiques non autorisées à partir d’environ 11 h 05 UTC le 24 avril 2018 pour des préfixes /24 situés dans les plages d’adresses Route 53 couvrantes d’Amazon. L’origine observée était eNet, AS10297, et certains chemins passaient par Hurricane Electric, AS6939. L’état de routage anormal a duré environ deux heures. [1]
Le mécanisme relevait de l’infrastructure réseau, non de la métaphore. Les réseaux acceptant les routes plus spécifiques ont envoyé le trafic d’une partie du service DNS faisant autorité d’Amazon vers la mauvaise origine. Les systèmes joints par ce chemin ont renvoyé de fausses réponses pourmyetherwallet.com, permettant à une requête de domaine légitime d’orienter les utilisateurs vers un point de terminaison imposteur. [1]
L’incident n’a pas prouvé qu’Amazon émettait les routes, que tous les clients Route 53 étaient touchés ni que BGP à lui seul contournait TLS. Cloudflare a signalé que le point de terminaison imposteur utilisait un certificat qui n’était normalement pas approuvé. L’utilisateur devait franchir un avertissement du navigateur pour que la voie de vol d’identifiants décrite aboutisse. [1]
Les enregistrements de ressources numériques et de registres associaient l’espace d’adressage à Amazon et à AS16509, mais les routeurs agissaient selon les annonces de routes acceptées. La vérité du registre restait une preuve essentielle, tandis que l’état de routage en cours déterminait l’acheminement des paquets. Cette différence est la surface centrale de responsabilité. [7]-[9][14]
La validation d’origine RPKI peut transformer un enregistrement d’autorisation en décision de routage exécutoire. AWS a documenté ultérieurement une couverture ROA étendue et le rejet des routes invalides RPKI dans son réseau. Ces déclarations ultérieures indiquent une direction de réparation; elles ne prouvent pas les contrôles exacts déployés sur chaque réseau concerné en avril 2018. [3][4][17]-[19]
DNSSEC peut permettre aux résolveurs valideurs d’authentifier des données DNS signées. Il ne rend pas une route BGP légitime, ne rétablit pas la joignabilité et ne protège pas une zone qui n’était pas correctement signée et validée. Le paquet public n’établit pas l’état DNSSEC historique complet du domaine concerné; cet article traite donc DNSSEC comme un contrôle conditionnel borné. [5][6]
RouteViews, RIPE RIS et RIS Live, CAIDA BGPStream, RIPEstat, les journaux de routeurs, les captures de réponses DNS et les preuves de certificats répondent à des questions différentes. Aucun ne prouve à lui seul l’incident entier, l’intention de l’opérateur, chaque cache empoisonné ou chaque perte. [8]-[13]
La responsabilité suit le contrôle pratique de l’origine des routes, du filtrage à l’importation, de l’autorisation des ressources, de la surveillance, du DNS faisant autorité, de la validation par les résolveurs, de la sécurité des domaines, de la communication d’incident et de la preuve de réparation. Elle ne peut pas être attribuée en traitant une entrée de registre, un collecteur de routes ou un nom d’entreprise comme souverain sur tout le chemin.

Deux plans de contrôle se sont rencontrés dans une défaillance visible par l’utilisateur

L’incident a réuni deux systèmes que les utilisateurs ne rencontrent normalement qu’à travers leurs résultats.

Le premier était le routage interdomaine. Le protocole BGP permet à des réseaux exploités de manière indépendante d’échanger des informations de joignabilité. Une annonce de route indique qu’un réseau peut acheminer le trafic d’un préfixe par un chemin particulier. BGP ne fournit pas, à lui seul, une preuve cryptographique universelle que l’origine est autorisée à annoncer cet espace d’adressage. Les opérateurs ajoutent autour du protocole des politiques, des filtres, des données de registre, la validation RPKI, la surveillance et des relations commerciales. [14][15]

Le second était le système de noms de domaine. Un service DNS faisant autorité répond aux questions sur les enregistrements d’un domaine. Les résolveurs récursifs interrogent les serveurs faisant autorité, mettent les réponses en cache et les renvoient aux clients. Route 53 fournissait les adresses de serveurs faisant autorité concernées par cet événement. Si les paquets destinés à ces adresses sont redirigés avant d’atteindre le service légitime, un résolveur peut recevoir une réponse d’un système qui n’aurait jamais dû faire autorité. [1][5][6]

L’utilisateur voyait un nom de domaine et s’attendait au service correspondant. Le réseau devait d’abord décider où les adresses des serveurs DNS faisant autorité étaient joignables. Le serveur qui répondait fournissait ensuite une adresse pour le domaine. Le navigateur devait enfin décider si le certificat du point de terminaison était digne de confiance.

Ce sont des décisions distinctes:

Quel réseau est autorisé à annoncer les préfixes des serveurs DNS?
Quelle route chaque réseau de transit ou d’accès accepte-t-il?
Quel serveur reçoit réellement la requête du résolveur?
La réponse DNS est-elle authentique?
Le point de terminaison présente-t-il un certificat approuvé pour le nom demandé?
L’utilisateur ou l’application s’arrête-t-il lorsqu’un contrôle de confiance échoue?

L’incident d’avril 2018 a franchi chaque frontière dans l’ordre. C’est pourquoi le décrire seulement comme « un détournement BGP » est incomplet, tandis que le décrire seulement comme un « empoisonnement DNS » masque la défaillance de contrôle des routes qui a rendu le faux serveur joignable.

La chaîne explique aussi pourquoi la responsabilité ne peut pas être attribuée à un seul acteur simplement parce que sa marque apparaissait dans le nom du service. Amazon contrôlait ses ressources d’adressage, les opérations de Route 53, la surveillance, la communication et le déploiement ultérieur de la sécurité des routes. Elle ne contrôlait pas tous les routeurs BGP externes. L’origine non autorisée et ses relations amont contrôlaient d’autres points. Les opérateurs de résolveurs récursifs, l’opérateur du domaine et le comportement du navigateur ou de l’utilisateur contrôlaient les limites ultérieures.

Un compte rendu rigoureux suit la capacité et la preuve tout au long de la chaîne.

Ce que le dossier public de routage établit

L’article technique de Cloudflare décrivait des annonces BGP observées entre environ 11 h 05 et 12 h 55 UTC. Il listait cinq préfixes /24 dans l’espace d’adressage d’Amazon et montrait des chemins impliquant AS10297 et AS6939. Les plages couvrantes légitimes étaient des /23 associés à Amazon, AS16509. [1]

La distinction entre un /23 et un /24 est importante sur le plan opérationnel. Le routage sélectionne normalement le préfixe correspondant le plus long. Un /24 couvre un bloc d’adresses plus petit qu’un /23. Lorsque les deux sont disponibles, la route plus spécifique peut attirer le trafic même si la route couvrante légitime reste visible.

Ce comportement rend une annonce plus spécifique non autorisée puissante. Un attaquant ou un réseau mal configuré n’a pas nécessairement besoin d’effacer la route légitime. Il peut publier une revendication concurrente plus étroite. Les réseaux qui l’acceptent et la propagent peuvent rediriger le trafic pour la plage plus petite.

Les collecteurs de Cloudflare voyaient les adresses Route 53 dans ces plages. Pendant la fenêtre de routage anormal, les systèmes qui répondaient servaient un comportement propre àmyetherwallet.com, notamment une fausse adresse, tandis que certaines requêtes produisaient des échecs. Cloudflare a aussi signalé que son propre résolveur 1.1.1.1 était affecté dans certains emplacements. Un résolveur n’avait pas besoin d’être exploité par un réseau ayant directement accepté la mauvaise annonce si son chemin vers le serveur faisant autorité traversait un réseau qui l’avait fait. [1]

Le dossier conforte plusieurs constats bornés:

Les préfixes étaient plus spécifiques que les routes couvrantes d’Amazon.
L’ASN d’origine observé ne correspondait pas à AS16509 d’Amazon.
Au moins un chemin de propagation incluait AS6939.
Les adresses étaient utilisées par le DNS faisant autorité de Route 53.
De fausses réponses pour un domaine ont été observées par le chemin détourné.
L’état de routage était géographiquement inégal plutôt qu’universellement identique.

Le même dossier ne prouve pas:

Qui a émis chaque commande de routeur.
Si AS10297 a été délibérément compromis, utilisé abusivement en interne ou mal configuré.
Quelle relation contractuelle a permis chaque étape de propagation.
Quels réseaux ont rejeté les routes.
Chaque résolveur récursif qui a mis en cache une fausse réponse.
Chaque utilisateur qui a vu une page imposteur.
Chaque perte financière attribuée à l’événement.

Cette limite compte parce que les collecteurs de routes observent des messages visibles de l’extérieur. Ils constituent une preuve solide de ce que des pairs sélectionnés ont entendu. Ils ne sont pas des caméras dans chaque centre d’opérations réseau.

RouteViews fournit des données de mises à jour archivées pour avril 2018. RIPE RIS et RIS Live documentent un autre système de mesure des mises à jour BGP. CAIDA BGPStream propose une plateforme de recherche pour analyser les événements de routage. RIPEstat fournit des vues de ressources et de routage pour AS16509 et AS10297. Ensemble, ces systèmes peuvent tester si un compte rendu est cohérent avec les preuves de routage publiques. [8]-[13]

Leur rôle approprié est la corroboration et la reconstruction. Un article ne doit pas transformer les points de vue limités d’un collecteur en affirmation de propagation universelle.

Pourquoi la vérité du registre n’a pas imposé la vérité des paquets

Les ressources d’adressage concernées étaient associées à Amazon. Cette association comptait. Elle donnait aux opérateurs et aux enquêteurs une référence pour juger l’origine inattendue.

Elle n’obligeait pas chaque routeur à rejeter l’annonce.

C’est la différence entre un enregistrement et un mécanisme d’application. Un registre peut conserver qui détient une ressource numérique, quel ASN est censé annoncer un préfixe et quels contacts ou métadonnées de sécurité y sont associés. Les routeurs ont encore besoin d’une politique opérationnelle qui consomme des données dignes de confiance et applique une décision.

Sans cette étape, un enregistrement exact peut coexister avec une route inexacte.

Un modèle sain de responsabilité des infrastructures traite les registres comme des grands livres et des conservateurs de documents plutôt que comme des souverains. Ce cadrage correspond précisément à l’incident. Il ne diminue pas la valeur du registre. Il situe cette valeur correctement.

L’enregistrement d’adresses fournit une preuve. Une autorisation d’origine de route peut fournir une autorité d’origine signée cryptographiquement. Un validateur peut classer une route reçue. La politique de routeur peut rejeter une route invalide. La surveillance peut alerter lorsqu’une origine inattendue apparaît. Les équipes opérationnelles peuvent coordonner le retrait et la récupération. Le chemin opérationnel émerge de toutes ces fonctions, non d’une simple déclaration de base de données.

Ce modèle de responsabilité place aussi le code en cours au-dessus du théâtre d’autorisation. Un détenteur de ressources approuvé, un ticket correct ou une politique de routage publiée ne fait pas suivre aux paquets le chemin prévu. La route installée dans le système de transfert est le fait opérationnel. La réponse DNS renvoyée par ce chemin est un autre fait. Le certificat présenté au point de terminaison en est un autre.

Un opérateur responsable a donc besoin de réconciliation, pas seulement d’enregistrement:

Chaque préfixe annoncé est-il couvert par l’autorisation prévue?
La longueur maximale de préfixe n’autorise-t-elle que les plus spécifiques voulus?
Les filtres client et pair sont-ils générés à partir de données actuelles et vérifiées?
Les routeurs rejettent-ils les origines invalides RPKI?
Les moniteurs comparent-ils les origines en direct avec l’autorité des ressources?
L’équipe peut-elle contacter rapidement l’amont concerné et le détenteur des ressources?
Le service DNS faisant autorité reste-t-il joignable depuis des réseaux indépendants?

L’événement de 2018 est devenu nuisible parce que la route opérationnelle et la preuve de ressource ont divergé assez longtemps pour que le trafic DNS atteigne un système de réponse non autorisé.

La validation d’origine BGP est puissante et bornée

RPKI offre un moyen de lier des préfixes IP à des ASN d’origine autorisés au moyen d’objets signés. Une autorisation d’origine de route identifie quel ASN peut annoncer un préfixe et la longueur maximale autorisée. Les parties utilisatrices valident ces objets. Les routeurs peuvent recevoir des données d’origine validées et classer les routes BGP comme valides, invalides ou non trouvées. [17]-[19]

Pour un événement où un ASN différent annonce un préfixe plus spécifique, ce contrôle est directement pertinent.

Supposons qu’Amazon autorise AS16509 à annoncer un préfixe couvrant et fixe une longueur maximale excluant le /24 non autorisé. Une route d’AS10297 pour ce /24 devrait être invalide RPKI. Un réseau appliquant la validation d’origine peut la rejeter.

C’est un mécanisme préventif concret. Il convertit l’autorité des ressources numériques en décision de routage.

Ce n’est pas un compte rendu complet de la sécurité du routage Internet.

La validation d’origine évalue la relation entre un préfixe, sa longueur et l’ASN d’origine. Elle n’authentifie pas chaque ASN du chemin. Une origine valide peut encore être impliquée dans une fuite de route. Une mauvaise politique peut encore exporter des routes au-delà de leur portée prévue. Une ROA obsolète ou incorrecte peut invalider à tort des routes légitimes. Un réseau qui n’effectue pas de validation peut encore accepter et propager une route invalide. [15]-[20]

La RFC 7908 définit les fuites de routes comme une propagation au-delà de la portée de politique prévue. La RFC 9234 ajoute les rôles BGP et l’attribut « Only-to-Customer » comme mécanisme ultérieur pour signaler et contraindre certains schémas de fuite. Ces contrôles traitent des relations de politique de chemin que la validation d’origine ne prouve pas. [16][20]

La limite historique est tout aussi importante.

AWS a écrit en 2021 que plus de 99 % de son espace d’adressage IPv4 et IPv6 était couvert par des ROA et qu’elle supprimait les routes invalides RPKI à ses points de présence. En 2025, AWS a décrit une implémentation RPKI plus large avec des contrôles de sécurité supplémentaires et un travail continu sur l’autorisation des chemins. [3][4]

Ces déclarations montrent ce qu’AWS dit avoir déployé plus tard. Elles n’établissent pas la couverture ROA exacte, les longueurs maximales, l’application du transit externe ni la configuration de surveillance au 24 avril 2018.

Un article responsable utilise donc les publications ultérieures comme preuve de remédiation:

AWS reconnaît le détournement d’origine BGP comme un risque réseau important.
Elle identifie AS16509 comme un ASN principal d’AWS.
Elle décrit les ROA et le rejet des routes invalides comme des contrôles.
Elle documente des contrôles de sécurité parce que les erreurs RPKI peuvent elles-mêmes affecter la connectivité.
Elle reconnaît que la sécurité du routage exige une coopération entre réseaux.

L’article ne doit pas réécrire rétroactivement ces contrôles ultérieurs dans l’incident.

Le filtrage des routes reste une responsabilité d’opérateur

RPKI est une source de données d’autorisation. Les opérateurs contrôlent aussi ce qu’ils acceptent de leurs clients, pairs et amonts.

La RFC 7454 traite des pratiques opérationnelles pour la sécurité et le filtrage BGP. MANRS décrit des actions pour prévenir les annonces incorrectes, prévenir le trafic usurpé, soutenir la coordination et permettre la validation mondiale. [15][22]

La question importante n’est pas de savoir si un réseau possédait un document intitulé « politique de routage ». C’est de savoir si la politique appliquée sur la session concernée aurait rejeté l’annonce observée.

Pour un client ou un petit réseau, un amont peut maintenir une liste d’autorisation des préfixes et ASN attendus. Les limites de nombre de préfixes peuvent restreindre une expansion inattendue. Les règles de longueur maximale de préfixe peuvent empêcher des annonces plus étroites que le client n’est pas autorisé à exporter. La validation RPKI peut ajouter une preuve cryptographique d’origine. Les alertes peuvent identifier une nouvelle origine ou un chemin inattendu avant l’arrivée de signalements manuels.

Chaque contrôle a des coûts de maintenance et des modes de défaillance.

Une liste d’autorisation peut devenir obsolète. Une limite de préfixes peut bloquer une expansion légitime ou être fixée trop haut pour aider. Un objet de route peut être inexact. Une ROA peut utiliser la mauvaise longueur maximale. Un moniteur peut alerter sans intervenant ou manquer des régions hors de ses points de vue.

C’est pourquoi la responsabilité exige des preuves de fonctionnement actuel:

L’ensemble approuvé des préfixes clients et sa source.
La date et le propriétaire de la dernière revue.
Le filtre compilé installé sur le routeur.
Un test montrant le rejet des plus spécifiques non autorisés.
Une alerte générée par un exercice contrôlé d’origine inattendue.
Un chemin de contact et de retrait qui fonctionne hors des heures ouvrées.

Le dossier public ne divulgue pas chaque configuration pertinente. L’absence de ces preuves doit rester une inconnue, pas devenir une accusation. L’article peut encore identifier quelles preuves distingueraient une politique qui existe sur papier d’une politique qui modifie l’acceptation des routes.

Le DNS faisant autorité a amplifié l’erreur de routage

Les adresses détournées n’étaient pas des adresses ordinaires de serveurs web. Elles appartenaient à l’infrastructure DNS faisant autorité de Route 53.

Ce rôle a amplifié l’effet.

Un résolveur récursif cherchant une réponse pourmyetherwallet.comdevait d’abord atteindre le serveur faisant autorité du domaine. Si BGP redirigeait ce trafic de serveur, le résolveur pouvait recevoir un enregistrement faux. Il pouvait mettre la réponse en cache et la servir aux clients jusqu’à expiration ou correction. Un utilisateur dont le réseau d’accès n’avait pas directement accepté la route non autorisée pouvait encore recevoir une réponse empoisonnée d’un résolveur récursif qui l’avait fait. [1]

Cela crée deux cartes géographiques:

Les réseaux dont les routes vers le serveur faisant autorité suivaient l’annonce non autorisée.
Les utilisateurs dont les résolveurs récursifs ont obtenu et mis en cache des réponses par ces chemins.

Les cartes se chevauchent mais ne sont pas identiques.

Cette distinction explique pourquoi les rapports d’impact fondés uniquement sur les réseaux d’accès des utilisateurs finaux peuvent être incomplets. Un résolveur peut se trouver dans un autre réseau ou une autre région. Une réponse en cache peut survivre à un changement de route. Inversement, un réseau peut accepter la route alors que le cache d’un résolveur contient déjà une réponse légitime non expirée.

Les preuves de responsabilité devraient donc inclure:

Les mises à jour BGP et l’état des origines.
Les requêtes envoyées aux adresses faisant autorité affectées.
Les réponses DNS observées depuis plusieurs résolveurs et points de vue.
Le comportement TTL et d’expiration du cache.
Les résultats de validation DNSSEC, le cas échéant.
Les observations de certificats au point de terminaison renvoyé.
Les horodatages du retrait de route, des réponses corrigées et de la récupération du cache.

L’événement montre aussi pourquoi le DNS faisant autorité est une dépendance réseau à fort effet de levier. Un changement de route affectant un ensemble relativement petit d’adresses de serveur peut influencer la résolution des domaines délégués à ces serveurs. Cela ne signifie pas que chaque zone Route 53 a été affectée. Cloudflare a observé un comportement centré sur un seul domaine. [1]

L’affirmation correcte est plus étroite: la redirection du trafic DNS faisant autorité a créé un chemin pour de fausses réponses qui pouvait affecter des utilisateurs au-delà des réseaux acceptant directement la mauvaise route.

DNSSEC répond à une autre question de confiance

DNSSEC permet aux résolveurs de valider que les données DNS sont authentiques dans une chaîne de confiance signée. La documentation de Route 53 décrit à la fois les flux d’enregistrement de domaine et de signature de zones hébergées. Elle explique qu’un résolveur valideur peut rejeter des données DNS qui ne valident pas par rapport à la chaîne. [5][6]

Ce contrôle est directement pertinent pour les fausses réponses DNS.

Ce n’est pas un contrôle BGP.

DNSSEC ne décide pas quel ASN peut annoncer un préfixe IP. Il ne rend pas un serveur faisant autorité joignable. Il n’empêche pas le trafic d’être détourné. Il permet à un résolveur valideur de demander si les données DNS reçues sont cryptographiquement authentiques.

Si la zone concernée était correctement signée, la chaîne intacte et le résolveur récursif appliquait la validation, une réponse falsifiée sans signature valide devrait échouer. Un échec de validation peut protéger l’intégrité en renvoyant une erreur, mais il peut encore créer un problème de disponibilité.

Si la zone n’était pas signée, ou si le résolveur ne validait pas, DNSSEC ne fournirait pas cette protection.

Le paquet source n’établit pas l’état DNSSEC historique complet demyetherwallet.comau 24 avril 2018. Il serait incorrect d’affirmer que le domaine avait ou n’avait pas une configuration spécifique sans preuve primaire supplémentaire.

La formulation responsable est conditionnelle:

RPKI peut aider à valider l’origine des routes.
DNSSEC peut aider à valider les données DNS.
TLS peut authentifier le point de terminaison auprès du navigateur.
Aucun ne remplace les autres.

La conception en couches n’est une force que si les applications s’arrêtent lors d’un échec. Une réponse DNS validée DNSSEC envoyée par un chemin détourné peut encore être authentique si elle provient du signataire légitime. Une réponse invalide DNSSEC devrait échouer au niveau d’un résolveur valideur. Une réponse DNS valide peut encore pointer vers une application compromise. Une route correcte peut encore transporter du contenu malveillant. Un avertissement de certificat peut encore être ignoré.

La responsabilité exige de tester le comportement en cas d’échec à chaque frontière.

TLS restait un signal d’arrêt visible

Cloudflare a signalé que le point de terminaison imposteur présentait un certificat qui n’était normalement pas approuvé. Le nom de domaine apparaissait correct dans les données du certificat, mais le certificat était auto-signé plutôt qu’enchaîné à une autorité de confiance. Un navigateur devrait afficher un avertissement. [1]

Cette preuve fixe une limite importante.

La manipulation BGP et DNS pouvait diriger un utilisateur vers le mauvais serveur. Elle ne donnait pas automatiquement à l’attaquant un certificat approuvé. Le chemin de vol décrit exigeait que les utilisateurs poursuivent malgré l’avertissement ou utilisent un logiciel qui n’appliquait pas correctement la frontière du certificat.

Ce fait n’excuse pas les défaillances de routage ou de DNS. Les utilisateurs ne devraient pas être placés devant un point de terminaison imposteur. Il empêche en revanche l’affirmation exagérée que BGP rendait TLS sans objet.

L’incident montre plutôt une défense en couches sous contrainte:

Les contrôles d’origine des routes pouvaient arrêter le détournement avant le DNS.
La validation DNSSEC pouvait arrêter une réponse DNS falsifiée pour une zone signée.
La validation TLS pouvait arrêter la confiance dans le point de terminaison imposteur.
Le comportement de l’interface utilisateur et de l’application pouvait arrêter la soumission d’identifiants.

La sauvegarde restante était imparfaite. Les utilisateurs peuvent cliquer à travers les avertissements. Les applications peuvent mal gérer la validation. Certaines interfaces rendent le risque difficile à comprendre. Mais les preuves publiques disent que l’avertissement existait.

Une revue de responsabilité devrait préserver les défenses qui ont fonctionné tout en examinant pourquoi les contrôles antérieurs ont échoué. Sinon, l’article punirait des preuves exactes en aplatissant chaque couche en une seule défaillance totale.

La responsabilité suit le contrôle pratique

L’incident impliquait plusieurs acteurs aux capacités différentes.

L’origine non autorisée et ses opérateurs de réseau

Le réseau identifié comme l’origine observée contrôlait ou était associé à la session BGP d’où les routes plus spécifiques sont apparues. Les preuves pertinentes incluraient la configuration des routeurs, l’authentification, l’accès aux comptes, les journaux de modifications, les relations clients et les journaux d’incidents. Les collecteurs publics montrent des annonces attribuées à un ASN; ils n’identifient pas l’individu ou le système qui les a émises. [1][9]

Les amonts et réseaux de transit qui propagent

Les amonts contrôlaient les filtres d’importation, l’autorisation des préfixes clients, les réglages de préfixes maximaux, la validation d’origine et la propagation. Une route visible par AS6939 établit une observation de chemin, pas un constat contractuel complet ni de négligence. La question de preuve est de savoir si le réseau disposait de contrôles à jour qui auraient dû rejeter l’annonce et si ces contrôles fonctionnaient.

Amazon Web Services

AWS contrôlait la ressource d’adressage, le service Route 53, les enregistrements de ressources publics, la posture de sécurité des routes, la surveillance du service et la communication avec les clients. Elle pouvait publier des ROA, surveiller les origines inattendues, se coordonner avec les pairs et documenter les mesures correctives. Elle ne pouvait pas programmer unilatéralement chaque routeur externe. Ses publications RPKI ultérieures décrivent à la fois une validation interne et une coopération industrielle, ce qui reflète cette frontière partagée. [3][4]

Les opérateurs de résolveurs récursifs

Les opérateurs de résolveurs contrôlaient les chemins amont utilisés par leurs serveurs, la validation DNSSEC, la mise en cache des réponses, la télémétrie conservée et la rapidité d’élimination des fausses données connues. Ils n’émettaient pas les préfixes Route 53 et ne signalent pas la zone du domaine.

L’opérateur du domaine

L’opérateur du domaine contrôlait les choix de délégation, la signature DNSSEC, la gestion des enregistrements, le déploiement TLS, les communications avec les utilisateurs et la réponse aux incidents. Il ne contrôlait pas l’acceptation BGP mondiale. L’article ne doit pas déduire la configuration DNSSEC historique sans preuve.

Les opérateurs de navigateurs et d’applications

Les opérateurs de navigateurs et de clients contrôlaient la validation des certificats et le comportement d’avertissement. Leur protection formait une frontière ultérieure après que le routage et le DNS avaient déjà échoué.

Les utilisateurs

Les utilisateurs pouvaient s’arrêter à un avertissement de certificat, mais ils ne contrôlaient pas l’origine des routes, l’infrastructure DNS faisant autorité ni la politique des résolveurs. Attribuer la responsabilité principale aux utilisateurs parce que certains ont pu cliquer ignorerait les contrôles en amont qui ont créé le faux chemin.

La carte des responsabilités n’est pas une formule pour un blâme égal. C’est une carte des preuves et des capacités.

La détection devrait réconcilier autorisation, route et réponse

Un système de détection utile ne surveillerait pas une seule couche.

La surveillance des ressources peut comparer les ASN d’origine en direct avec les ROA et les origines attendues. Les collecteurs de routes peuvent identifier une nouvelle annonce plus spécifique et sa propagation. Les opérateurs DNS faisant autorité peuvent sonder les adresses de service depuis plusieurs réseaux. Les moniteurs de résolveurs peuvent comparer les réponses et l’état de validation. Les moniteurs de certificats peuvent identifier des points de terminaison inattendus.

Chaque signal peut être bruité ou incomplet.

Une nouvelle origine peut être une migration planifiée. Une route plus spécifique peut être de l’ingénierie de trafic légitime. Une réponse DNS peut varier intentionnellement. Un certificat peut être renouvelé. Un collecteur de routes peut manquer une région.

La réponse est la corrélation avec l’autorité de changement:

La route est-elle couverte par une autorisation actuelle?
L’annonce correspond-elle à un déploiement approuvé?
Plusieurs collecteurs indépendants la voient-ils?
Les sondes DNS faisant autorité renvoient-elles les données signées attendues?
Les réponses des résolveurs et les chaînes de certificats concordent-elles?
Un propriétaire responsable a-t-il confirmé le changement?

Une alerte devrait conserver les preuves utilisées dans la décision. Un événement BGP transitoire peut disparaître avant le début d’une enquête. Les archives RouteViews et RIPE RIS fournissent des enregistrements historiques; les journaux de routeurs locaux et les captures DNS ajoutent des détails propres à l’opérateur. [10]-[13]

La réponse a aussi besoin d’une carte d’autorité. Qui peut retirer la route? Qui peut contacter l’origine et l’amont? Qui peut mettre à jour une ROA en toute sécurité? Qui peut avertir les clients DNS? Qui peut identifier et vider les caches de résolveurs faux? Qui peut coordonner la réponse du domaine et du certificat?

Un tableau de bord sans responsable de réponse n’est pas un contrôle.

La réparation doit fermer toute la chaîne

Le retrait de la route non autorisée est nécessaire. Il peut ne pas achever la récupération.

Les résolveurs peuvent conserver des réponses fausses en cache jusqu’à l’expiration du TTL ou un vidage. Les utilisateurs peuvent avoir des sessions actives ou des identifiants compromis. Les opérateurs de domaines peuvent devoir changer des secrets, enquêter sur des transactions et publier des avertissements. Les détenteurs de routes peuvent devoir corriger des ROA, des filtres ou la surveillance. Les amonts peuvent devoir examiner pourquoi la route a été acceptée.

Le dossier de clôture devrait donc séparer:

L’heure de correction de la route.
Le déclin de la propagation mondiale.
La correction des réponses DNS faisant autorité.
La récupération du cache des résolveurs.
La vérification des certificats et des points de terminaison.
La notification des utilisateurs.
La protection des identifiants ou des actifs.
La remédiation à long terme du contrôle de routage.

Ces horodatages répondent à des questions différentes. Déclarer l’incident clos lorsque la route disparaît peut cacher un préjudice DNS ou utilisateur résiduel. Attendre chaque conséquence en aval avant de déclarer la récupération du réseau peut aussi brouiller le dossier.

Une clôture précise indique quelle couche a récupéré et ce qui reste.

Les déclarations ultérieures de déploiement RPKI d’AWS offrent une preuve d’une direction à long terme. Elles décrivent la couverture ROA, le rejet des routes invalides et des contrôles de sécurité. La bonne question suivante est de savoir si les tests actuels montrent que les contrôles rejettent une route plus spécifique non autorisée équivalente sans bloquer le service légitime. [3][4]

Pour les réseaux externes, les preuves peuvent inclure la génération de filtres de préfixes clients, le rejet des invalides RPKI, la détection de fuites de routes et les procédures de contact. Pour les opérateurs DNS, elles peuvent inclure des sondes de joignabilité anycast, la validation des zones signées et la réponse du cache des résolveurs. Pour les opérateurs de domaines, elles peuvent inclure l’état DNSSEC, les contrôles de certificats et un manuel d’incident testé.

La réparation devient responsable lorsqu’elle est testable.

Un programme de preuves pratique

Les conseils d’administration, les régulateurs, les clients et les opérateurs de réseau n’ont pas besoin de chaque ligne de configuration privée pour poser des questions utiles. Ils ont besoin de preuves liées au contrôle.

Autorité des ressources numériques

Quels enregistrements RIR couvrent l’espace d’adressage?
Quels ASN sont autorisés à annoncer chaque préfixe?
Quelles longueurs maximales sont autorisées?
Qui possède la création, la revue, l’expiration et la correction d’urgence des ROA?
Les changements d’autorisation sont-ils approuvés de manière indépendante?

Acceptation des routes

Quels préfixes chaque client peut-il annoncer?
Quelle source génère le filtre?
À quelle vitesse se met-il à jour?
Les routes invalides RPKI sont-elles rejetées?
Les routes inconnues sont-elles acceptées selon une politique de risque documentée?
Les limites de préfixes maximaux et de plus spécifiques sont-elles testées?

Surveillance

Quels collecteurs et flux internes détectent les origines inattendues?
Quel est le seuil d’alerte?
Une alerte peut-elle distinguer une migration planifiée d’un détournement?
Existe-t-il un responsable de réponse 24 heures sur 24?
Les observations de routes et de DNS sont-elles conservées?

DNS faisant autorité

Les adresses de service sont-elles sondées depuis des réseaux indépendants?
Les zones sont-elles signées lorsque requis?
Les résolveurs valideurs rejettent-ils les fausses données?
Les opérateurs peuvent-ils identifier quels caches ont reçu une mauvaise réponse?
La communication client est-elle indépendante du chemin DNS affecté?

Confiance des points de terminaison

Le client rejette-t-il un certificat non approuvé?
Les avertissements sont-ils clairs et difficiles à contourner accidentellement?
L’opérateur du domaine peut-il révoquer les sessions et changer les identifiants?
La surveillance des transactions est-elle reliée à la chronologie de l’incident?

Preuve de réparation

Un exercice d’origine non autorisée a-t-il été réalisé?
Les filtres et la validation l’ont-ils rejetée?
La surveillance a-t-elle alerté avant les signalements d’utilisateurs?
Le DNS faisant autorité est-il resté correct?
L’équipe de réponse a-t-elle achevé le chemin de contact et de retrait?
Les exceptions, échecs et nouveaux tests sont-ils enregistrés?

Ce programme évite le faux choix entre publier des configurations sensibles et n’offrir qu’une assurance générale. Les preuves peuvent être spécifiques sans exposer chaque détail privé.

Pourquoi cette chaîne de contrôle est spécifique

La question de responsabilité n’est pas simplement de savoir si BGP est insécurisé. Dans cet événement, le routage interdomaine a déterminé quel serveur répondait aux requêtes d’une partie de l’espace d’adressage DNS faisant autorité de Route 53. Le système atteint a ensuite renvoyé de fausses données DNS pour un domaine, créant un chemin vers un point de terminaison imposteur où TLS fournissait une frontière d’avertissement distincte. Cette séquence relie l’autorisation des ressources numériques, l’acceptation des routes, l’intégrité du DNS faisant autorité, le comportement des résolveurs et l’authentification du point de terminaison.

[1][14]

La chaîne de contrôle de Route 53 comprend donc:

les préfixes ciblés servaient le DNS faisant autorité;
des routes plus spécifiques ont changé quel serveur répondait aux requêtes des résolveurs;
de fausses données DNS pour un domaine ont créé un chemin de point de terminaison imposteur;
DNSSEC et TLS fournissaient des frontières d’intégrité distinctes;
le comportement de cache des résolveurs prolongeait l’analyse au-delà de l’acceptation directe des routes.

C’est plus étroit qu’une analyse générique de fuite de route. Sa question spécifique est de savoir comment l’autorisation des ressources numériques et le filtrage des routes se relient à l’intégrité des réponses DNS et à la confiance du point de terminaison. La preuve doit donc montrer non seulement quelle route a été acceptée, mais aussi quel système faisant autorité a été atteint, quelle réponse il a renvoyée, comment les résolveurs ont traité cette réponse et si le client a préservé la dernière frontière d’authentification.

Limites des sources

La publication de Cloudflare du 24 avril 2018 est la principale source technique contemporaine. Elle inclut les préfixes observés, les heures, les chemins AS, l’utilisation des adresses Route 53, le comportement DNS et la frontière de certificat. Cloudflare était un observateur et un opérateur de résolveur affecté, pas un tribunal ni un régulateur neutre. Ses collecteurs ne voyaient pas tous les routeurs. [1]

L’article ultérieur de Cloudflare sur la détection de détournements explique son modèle de surveillance et utilise le même événement comme exemple. Il est utile pour le contexte du mécanisme et de la remédiation, pas comme corroboration indépendante de chaque détail de 2018. [2]

Les publications d’AWS de 2021 et 2025 sur la sécurité du routage sont des descriptions de première partie de contrôles ultérieurs. Elles ne prouvent pas l’état exact des contrôles en 2018 ni l’adoption externe. [3][4]

La documentation AWS Route 53 explique DNSSEC et le comportement du service tel que documenté plus tard. Elle n’établit pas l’état complet historique de signature et de validation du domaine concerné. [5][6]

La documentation des plages IP AWS et RIPEstat fournissent un contexte de ressources. Elles ne prouvent pas l’intention ni chaque relation opérationnelle. [7]-[9]

RouteViews, RIPE RIS, RIS Live et CAIDA BGPStream fournissent des capacités publiques de mesure. Leur visibilité dépend des pairs et des points de collecte. Ils n’exposent pas chaque route privée, configuration de routeur, cache DNS ou décision d’opérateur. [10]-[13]

Les RFC définissent des protocoles, des classes de risque et des mécanismes recommandés. Elles ne prouvent pas qu’un opérateur particulier a déployé un contrôle ni qu’il avait une obligation légale particulière. [14]-[20]

La documentation d’ARIN et de MANRS explique des outils et normes opérationnels. Elle n’établit pas la conformité de chaque acteur de l’événement. [21][22]

Cet article n’établit pas d’intention malveillante d’un opérateur nommé, de responsabilité pénale, de négligence, de rupture contractuelle, de nombre de victimes vérifié, de perte totale vérifiée, d’empoisonnement complet des caches ni de remédiation durable sur chaque réseau. Il n’affirme pas que RPKI, DNSSEC ou TLS seuls auraient empêché tout préjudice.

Ces limites font partie du dossier de responsabilité. Elles identifient ce qu’une enquête plus solide devrait obtenir.

Conclusion

Le détournement de Route 53 de 2018 a montré comment un désaccord entre l’autorité des ressources numériques et l’état de routage opérationnel peut pénétrer dans le DNS et la confiance des utilisateurs.

Les enregistrements de registre et d’allocation associaient les préfixes à Amazon. Les routeurs acceptaient encore des annonces plus spécifiques d’une autre origine. Les résolveurs récursifs atteignaient des serveurs par ces chemins. De fausses réponses pourmyetherwallet.comorientaient les utilisateurs vers un point de terminaison imposteur. TLS restait une frontière d’avertissement ultérieure plutôt que de disparaître.

Chaque couche répondait à une question différente:

Données de registre: qui détient la ressource?
ROA et RPKI: quel ASN peut l’annoncer?
Politique BGP: quelle route le réseau acceptera-t-il?
Surveillance des routes: qu’a annoncé l’Internet?
DNS faisant autorité: quelle réponse le serveur atteint a-t-il fournie?
DNSSEC: les données DNS sont-elles authentiques?
TLS: le point de terminaison est-il authentifié?
Comportement de l’utilisateur et de l’application: la transaction s’arrête-t-elle en cas d’échec?

La responsabilité suit les opérateurs qui pouvaient rendre ces réponses exactes et les garder alignées.

La réparation la plus solide n’est pas une affirmation selon laquelle l’enregistrement d’adresses a toujours été correct. C’est la preuve qu’un état opérationnel incorrect est rejeté, détecté et contenu. Les détenteurs de ressources maintiennent des autorisations précises. Les réseaux d’origine et de transit appliquent des filtres et la validation. Les opérateurs DNS observent la joignabilité et l’intégrité des réponses. Les résolveurs valident les données signées. Les navigateurs s’arrêtent sur les certificats invalides.

Les équipes d’incident conservent un enregistrement horodaté du changement de route jusqu’à la récupération du cache et des utilisateurs.

Voilà la couche de réalité opérationnelle. Un registre est indispensable comme grand livre. Il n’est pas souverain sur les paquets. Le code en cours et la politique installée décident où va le trafic. Les ressources numériques ont besoin d’unicité, d’autorisations exactes, de métadonnées de sécurité et de continuité opérationnelle, car l’enregistrement doit être utile aux systèmes qui l’appliquent.

L’événement reste important non parce qu’il prouve qu’une entreprise contrôlait tout l’Internet. Il prouve le contraire. Le routage interdomaine et le DNS sont des systèmes partagés. Une réparation qui n’existe que chez un seul entité peut réduire le risque mais ne peut pas garantir tout le chemin. La norme responsable est donc à la fois locale et coopérative: contrôler ce que l’opérateur peut contrôler, publier des preuves de ce contrôle et rendre les signaux utilisables par les réseaux qui doivent agir avec eux.

Le test final est opérationnel. Annoncer une route plus spécifique non autorisée dans un exercice sûr. Vérifier que les données d’autorisation sont correctes, que les filtres la rejettent, que les moniteurs alertent, que les réponses DNS restent authentiques, que les clients préservent les contrôles de certificats, que les intervenants atteignent les pairs responsables et que les preuves conservées expliquent chaque décision.

Si l’exercice ne peut pas être présenté, l’entrée de registre n’est encore qu’une promesse sur le chemin. S’il le peut, l’enregistrement est devenu partie d’un contrôle opérationnel.

Le détournement de Route 53 en 2018 a fait de la confiance BGP-DNS un test de responsabilité

Pourquoi c'est important