Dyn a montré que l'externalisation du DNS peut devenir une défaillance de mode commun

Résumé

• Confirmé:Le 21 octobre 2016, Dyn a signalé des attaques DDoS contre son infrastructure DNS géré. Sa déclaration publique indiquait que la première vague avait commencé vers 7h00, heure de l'Est, affectant les utilisateurs dirigés vers les serveurs Dyn de la côte Est des États-Unis, et avait été atténuée environ deux heures plus tard. Une deuxième vague, plus globale, a commencé juste avant midi et a été atténuée en un peu plus d'une heure. Dyn a déclaré qu'une troisième tentative de vague avait été atténuée sans impact sur les clients.
• Observé:ThousandEyes a mesuré des taux d'échec élevés des requêtes DNS depuis ses points de vue mondiaux et a rapporté qu'environ 75 % de ses points de vue envoyaient des requêtes restées sans réponse des serveurs de Dyn au plus fort de l'attaque. Il a également observé environ 1 200 sites et services affectés parmi ceux surveillés par ses clients, et a constaté que de nombreux clients vulnérables n'utilisaient que les serveurs de noms de Dyn plutôt que plusieurs fournisseurs DNS.
• Attribution limitée:Dyn a déclaré que les analyses de Flashpoint et Akamai confirmaient qu'une source du trafic était des appareils infectés par Mirai. Le ministère de la Justice américain a ensuite annoncé des plaidoyers de culpabilité de la part des créateurs de Mirai et un plaidoyer de culpabilité séparé d'un individu dont l'attaque par botnet utilisant une variante de Mirai le 21 octobre 2016 a affecté Dyn et rendu des sites comme Sony, Twitter, Amazon, PayPal, Tumblr, Netflix et l'Université Southern New Hampshire inaccessibles ou intermittents pendant plusieurs heures. Les archives publiques ne prouvent pas qu'un seul acteur, un seul botnet ou un seul vecteur d'attaque explique tout le trafic que Dyn a vu ce jour-là.
• Évaluation:L'incident était une défaillance de dépendance de mode commun. Dyn contrôlait sa plateforme DNS géré, ses partenaires de mitigation, ses communications et l'architecture de son infrastructure. Les clients contrôlaient si le DNS faisant autorité était diversifié entre plusieurs fournisseurs et si les pratiques de TTL, de basculement et de surveillance correspondaient à leurs propres déclarations de disponibilité. Les fournisseurs IoT, les propriétaires, les FAI, les régulateurs et les attaquants contrôlaient des parties distinctes du problème des botnets.

Le DNS a échoué avant l'application web

Un utilisateur ne remarque généralement le DNS que lorsqu'il tombe en panne. Le nom du site semble normal. Le navigateur fonctionne. La connexion de l'utilisateur peut être saine. L'application de destination peut encore fonctionner. Pourtant, si le chemin du DNS faisant autorité ne peut pas répondre, le service peut disparaître comme si les serveurs eux-mêmes étaient hors service. C'est ce qui a rendu l'incident Dyn si déroutant. De nombreux services n'étaient pas nécessairement en panne au niveau de leur propre couche applicative. Leurs noms ne pouvaient pas être résolus de manière suffisamment fiable pour que les utilisateurs puissent les atteindre.

L'incident d'octobre 2016 se situe à l'intersection de deux formes d'externalisation. Premièrement, de nombreuses entreprises numériques externalisaient le DNS faisant autorité auprès d'un fournisseur géré parce que ce fournisseur pouvait offrir une portée anycast mondiale, une orientation du trafic, une expertise opérationnelle et une préparation anti-DDoS que de nombreux clients ne pouvaient pas construire seuls de manière économique. Deuxièmement, des millions de foyers et d'organisations avaient placé des appareils connectés non sécurisés sur l'internet public, souvent avec des identifiants par défaut faibles ou des chemins de mise à jour médiocres. Mirai a transformé ce deuxième choix d'externalisation en trafic d'attaque contre le premier.

La propre déclaration de Dyn, conservée dans une copie PDF publique de laDyn Statement on 10/21/2016 DDoS Attack(Déclaration de Dyn sur l'attaque DDoS du 21/10/2016), indiquait que l'entreprise avait subi des attaques DDoS contre son infrastructure DNS géré. Elle décrivait une première vague commençant vers 7h00, heure de l'Est, un rétablissement environ deux heures plus tard, une deuxième vague plus globale juste avant midi, un rétablissement vers 13h00, et une troisième vague tentée que Dyn a déclaré avoir atténuée sans impact sur les clients. Dyn a également déclaré qu'il n'y avait jamais eu de panne à l'échelle du système, et que certains utilisateurs, comme ceux atteignant les sites affectés depuis la côte Ouest des États-Unis lors de la première vague, auraient réussi.

Ce détail est important. L'incident n'était pas une panne binaire simple où chaque client de Dyn disparaissait partout. C'était une défaillance de disponibilité façonnée par la géographie, l'anycast, le comportement des résolveurs, le temps de vie (TTL), la configuration du domaine client et l'intensité changeante du trafic DDoS. Cela a rendu la communication difficile. Un client pouvait tester depuis un réseau et constater un succès tandis que des utilisateurs ailleurs constataient un échec. Un propriétaire de plateforme pouvait avoir des serveurs d'application sains et recevoir quand même des plaintes indiquant que le service était en panne. Un utilisateur pouvait attendre que la réponse DNS en cache expire et perdre soudainement l'accès.

La dépendance partagée était visible dans les mesures

L'analyse de ThousandEyes,The DDoS Attack on Dyn's DNS Infrastructure(L'attaque DDoS contre l'infrastructure DNS de Dyn), fournit l'explication publique la plus claire de la dépendance du côté client. Sa surveillance a observé trois phases: un impact initial concentré sur la côte Est des États-Unis, un impact mondial plus large, puis une atténuation ultérieure avec des attaques persistantes ou du blackholing. Au plus fort de l'attaque, environ trois quarts de ses points de vue mondiaux envoyaient des requêtes DNS restées sans réponse des serveurs de Dyn. Elle a également signalé environ 1 200 sites et services affectés parmi les domaines surveillés par ses clients.

Le point technique était simple mais grave. Dyn gérait des serveurs faisant autorité pour les domaines de ses clients. Si un résolveur n'avait pas déjà une réponse en cache fraîche et ne pouvait pas atteindre les serveurs faisant autorité de Dyn, il ne pouvait pas obtenir l'adresse nécessaire pour se connecter. Des valeurs de temps de vie (TTL) plus courtes peuvent rendre la gestion du trafic plus agile en fonctionnement normal, mais elles font également dépendre les utilisateurs plus fréquemment de la résolution faisant autorité réussie. Un TTL faible n'est pas mauvais en soi; c'est un compromis. Lors d'un événement DDoS chez un fournisseur DNS, il peut raccourcir le délai entre 'le cache sait encore où aller' et 'le résolveur doit interroger à nouveau l'autorité indisponible'.

ThousandEyes a également décrit la popularité de Dyn pour l'orientation du trafic. Le DNS géré n'était pas simplement un annuaire téléphonique statique. Il aidait les grands services à diriger les utilisateurs vers des centres de données proches, à déplacer le trafic et à optimiser les performances. Cela signifie que le produit qui améliorait la résilience et la vitesse dans des conditions normales est également devenu une dépendance dont la dégradation pouvait affecter de nombreux clients à la fois. Plus la proposition de valeur du fournisseur était forte, plus il devenait attrayant en tant que plan de contrôle partagé.

La conclusion la plus importante de ThousandEyes en matière de responsabilité concernait l'architecture des clients. De nombreux clients affectés de Dyn n'utilisaient que les serveurs de noms de Dyn au lieu de diversifier entre plusieurs fournisseurs DNS. L'analyse opposait les clients ayant un seul fournisseur DNS géré à Amazon.com, qui utilisait plus d'un fournisseur et a subi des temps de chargement plus lents plutôt que le même modèle d'indisponibilité complète observé par beaucoup d'autres. Cela ne signifie pas que chaque client pouvait basculer vers un DNS multi-fournisseurs du jour au lendemain. Cela signifie que le risque était architectural, visible et en partie contrôlé par les clients.

L'article de l'Associated Press repris par le Chicago Sun-Timesa capturé l'expérience publique: des répercussions pour les utilisateurs essayant d'accéder à des sites web populaires aux États-Unis et en Europe, Twitter, Netflix et le PlayStation Network de Sony figurant parmi les services apparemment affectés. Lerapport contemporain du Guardiana énuméré Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News et de grands journaux parmi les services signalés hors ligne ou dégradés. Ces rapports sont utiles pour la portée et la perception du public; ils ne prouvent pas que chaque service nommé a connu le même mode de défaillance technique ou la même durée.

La défaillance de mode commun se cache dans un DNS « redondant »

Le DNS a une redondance intégrée dans sa conception. Les domaines listent plusieurs serveurs de noms. Les résolveurs peuvent essayer des alternatives. Les serveurs faisant autorité peuvent être géographiquement dispersés. Le problème est que la redondance peut être formelle sans être indépendante des défaillances.

LaRFC 2182indique depuis 1997 qu'une raison majeure d'avoir plusieurs serveurs DNS est de garder les informations de zone disponibles même lorsqu'un serveur est inaccessible, et que les serveurs secondaires doivent être géographiquement et topologiquement dispersés. Elle met en garde contre les configurations où tous les serveurs partagent le même mode de défaillance local. En langage courant: plusieurs serveurs de noms ne suffisent pas s'ils tombent en panne ensemble.

Le cas Dyn a transposé ce principe de l'emplacement physique à la dépendance vis-à-vis du fournisseur. Un client peut lister plusieurs serveurs de noms Dyn et avoir malgré tout un seul fournisseur, une seule relation commerciale, un seul chemin de support opérationnel, un seul ensemble d'identifiants de gestion DNS et une seule exposition à une attaque majeure sur ce fournisseur. Du point de vue du domaine, ces serveurs de noms peuvent sembler diversifiés. Du point de vue de la responsabilité, ils font toujours partie d'une dépendance commune à un fournisseur.

L'articleThe Lack of Redundancy in DNS Resolution by Major Websites and Services(Le manque de redondance dans la résolution DNS des principaux sites et services web) a examiné la concentration et la diversification du DNS après l'incident Dyn. Il a constaté une concentration croissante sur un petit nombre de fournisseurs DNS et une forte tendance des domaines à ne pas utiliser plusieurs fournisseurs de gestion DNS. Dans son échantillon, la proportion de domaines n'utilisant qu'un seul fournisseur était d'environ 91 % à 93 % avant l'attaque, et elle est passée de 92,2 % à 89,4 % entre octobre 2016 et novembre 2016. Parmi les clients de Dyn, la part des domaines non diversifiés a fortement chuté après l'incident et a continué de baisser jusqu'en mai 2017.

Ces chiffres doivent être considérés comme des résultats de recherche dans un ensemble de données spécifique, et non comme un recensement exact de l'ensemble de l'internet. Ils confirment néanmoins la leçon pratique. Le DNS rendait possible la diversification des fournisseurs, mais de nombreux clients avaient choisi la simplicité opérationnelle plutôt que l'indépendance vis-à-vis des défaillances. Ce n'est pas irrationnel. Un DNS faisant autorité multi-fournisseurs introduit de la complexité: cohérence des données de zone, signature et gestion des clés DNSSEC, comportement des vérifications d'état, différences d'orientation du trafic, délais de propagation, risque de split-brain, surveillance et responsabilité contractuelle. Le coût de la diversité est réel. L'attaque Dyn a montré que le coût de ne pas diversifier peut aussi devenir réel, et peut survenir via un fournisseur plutôt que par la propre infrastructure du client.

L'anycast est puissant, mais pas magique

L'infrastructure de Dyn, comme de nombreuses plateformes DNS mondiales, utilisait l'anycast. L'anycast permet à plusieurs emplacements d'annoncer la même adresse IP afin que le routage internet puisse envoyer un résolveur vers une instance proche ou préférée. Il améliore la latence et absorbe de nombreuses défaillances locales car le trafic peut se déplacer sur le réseau. C'est l'une des raisons pour lesquelles les fournisseurs DNS gérés peuvent offrir une large couverture et une réponse rapide.

L'anycast ne rend pas la capacité infinie. Il peut distribuer le trafic, mais il peut aussi distribuer la pression de l'attaque. Si l'attaque est suffisamment importante, suffisamment large ou ciblée de manière à congestionner les liaisons en amont, le peering ou les préfixes partagés, les emplacements anycast peuvent tomber en panne ensemble ou osciller de manière complexe. ThousandEyes a observé que de nombreuses requêtes ne pouvaient pas passer par les fournisseurs d'accès Internet de Dyn ou la périphérie de son réseau, et que les serveurs de noms au sein de la même constellation et du même groupe montraient des performances corrélées. Cette observation ne prouve pas que la conception interne de Dyn était négligente. Elle montre pourquoi « nous avons plusieurs points de présence » n'est pas la même chose que « nous avons une disponibilité indépendante dans toutes les conditions DDoS plausibles ».

La déclaration de Dyn indiquait qu'elle pratiquait des scénarios, disposait de procédures, utilisait des partenaires de mitigation et avait lancé la gestion des incidents et les communications avec les clients. Elle précisait également que les attaques étaient hautement distribuées, impliquaient des dizaines de millions d'adresses IP discrètes associées à Mirai et utilisaient plusieurs vecteurs et emplacements internet. Un fournisseur ne doit pas être jugé comme si la mitigation DDoS était une simple question d'achat de bande passante suffisante. Les très grandes attaques distribuées créent des erreurs de mesure, des tempêtes de nouvelles tentatives, du trafic collatéral, de l'instabilité de routage et des compromis difficiles entre le filtrage du trafic d'attaque et la préservation des requêtes légitimes.

Pourtant, les clients achètent du DNS géré parce que le fournisseur revendique une expertise précisément dans ce domaine opérationnel. Dyn assumait donc le côté fournisseur de la résilience: planification de la capacité, coordination en amont, architecture anycast, conception de la constellation de serveurs de noms, communication de statut, support client, préparation des partenaires de mitigation et preuves post-incident. Un compte rendu équitable de la responsabilité peut retenir les deux idées à la fois. L'attaque était malveillante et de grande ampleur. Le métier de Dyn était de maintenir le DNS faisant autorité accessible dans des conditions hostiles.

Mirai a transféré le risque des appareils grand public dans l'infrastructure

Mirai a rendu l'attaque culturellement mémorable parce que le botnet était construit en grande partie à partir d'appareils connectés à Internet ordinaires: caméras, routeurs, enregistreurs vidéo numériques et systèmes embarqués similaires. L'étude USENIX Understanding the Mirai Botnetdécrit Mirai comme composé principalement d'appareils embarqués et IoT et indique qu'il a atteint un pic d'environ 600 000 infections. L'article soutient que la simplicité de la méthode d'infection et la croissance rapide ont montré que des techniques relativement peu sophistiquées pouvaient compromettre suffisamment d'appareils bas de gamme pour menacer des cibles bien défendues.

L'annonce de 2017 du ministère de la Justice américain,Justice Department Announces Charges and Guilty Pleas in Three Computer Crime Cases Involving Significant DDoS Attacks(Le ministère de la Justice annonce des inculpations et des plaidoyers de culpabilité dans trois affaires de criminalité informatique impliquant des attaques DDoS significatives), indiquait que Paras Jha, Josiah White et Dalton Norman avaient plaidé coupable d'avoir opéré le botnet Mirai, qui ciblait des appareils IoT tels que des caméras sans fil, des routeurs et des enregistreurs vidéo numériques. Le DOJ a déclaré que Mirai était composé de centaines de milliers d'appareils compromis à son apogée, et que l'implication des créateurs originaux avec la variante originale de Mirai a pris fin lorsque Jha a publié le code source sur un forum criminel à l'automne 2016. Depuis lors, le DOJ a déclaré que d'autres acteurs avaient utilisé des variantes de Mirai dans d'autres attaques.

L'annonce de 2020 du ministère de la Justice,Individual Pleads Guilty to Participating in Internet-of-Things Cyberattack in 2016(Un individu plaide coupable d'avoir participé à une cyberattaque de l'Internet des objets en 2016), a relié un botnet basé sur une variante de Mirai au jour de l'attaque Dyn de manière plus directe. Elle indiquait qu'un individu, anciennement mineur, avait plaidé coupable en lien avec une cyberattaque d'octobre 2016. Selon le DOJ, l'individu et d'autres ont utilisé un botnet pour lancer plusieurs attaques DDoS le 21 octobre 2016 dans le but de mettre le PlayStation Network de Sony hors ligne; les attaques ont affecté Dyn, ce qui a rendu des sites comme Sony, Twitter, Amazon, PayPal, Tumblr, Netflix et l'Université Southern New Hampshire inaccessibles ou intermittents pendant plusieurs heures.

Ce dossier d'attribution doit être utilisé avec prudence. Il ne dit pas que l'acteur mineur était la cause unique de tout impact sur Dyn, ni que tout le trafic de Dyn provenait d'un seul botnet. Dyn elle-même a déclaré qu'une source du trafic d'attaque était des appareils infectés par Mirai. Le fournisseur a également décrit plusieurs vecteurs et emplacements internet. La conclusion la plus sûre est que Mirai et les variantes de Mirai ont été matériellement impliqués, et que la couche de conduite criminelle est distincte de la couche d'architecture de résilience.

L'alerte de la CISA sur la menace Miraiavertissait que le malware Mirai analysait les appareils IoT vulnérables et que la publication du code source de Mirai augmentait le risque de nouveaux botnets. Le rapport ultérieur du ministère du Commerce et de la Sécurité intérieure hébergé par le NIST,Enhancing the Resilience of the Internet and Communications Ecosystem Against Botnets and Other Automated, Distributed Threats(Améliorer la résilience de l'écosystème Internet et des communications contre les botnets et autres menaces automatisées et distribuées), a encadré le problème comme étant à l'échelle de l'écosystème: les attaques distribuées automatisées sont mondiales, les outils efficaces ne sont pas largement utilisés, les produits doivent être sécurisés tout au long de leur cycle de vie, les incitations sont mal alignées et aucune communauté de parties prenantes ne peut résoudre le problème seule.

Ce cadrage écosystémique correspond mieux à l'incident Dyn qu'à une histoire de blâme étroite. Les attaquants ont abusé d'appareils qui ne leur appartenaient pas. Les fabricants d'appareils avaient souvent livré des produits à bas coût sans contrôles solides de mise à jour, d'identité et de cycle de vie. Les propriétaires d'appareils comprenaient rarement qu'une caméra ou un enregistreur dans un placard pouvait participer à une attaque contre l'infrastructure DNS. Les FAI avaient une visibilité partielle sur le trafic des appareils infectés mais des incitations mitigées et des limites pratiques. Les fournisseurs DNS ont vu l'attaque lorsqu'elle a atteint leur périphérie. Les clients l'ont vue lorsque leurs noms ont cessé de se résoudre. Les utilisateurs l'ont seulement vue comme un site qui ne se chargeait pas.

Le document ultérieurNISTIR 8259A IoT Device Cybersecurity Capability Core Baseline(Base de référence des capacités de cybersécurité des appareils IoT) n'existait pas en 2016 et ne doit pas être traité comme une obligation légale rétroactive de Dyn. Il reste utile comme preuve de ce que l'écosystème a appris à valoriser: identification des appareils, configuration sécurisée, protection des données, accès logique, capacité de mise à jour logicielle, sensibilisation à l'état de la cybersécurité et documentation. Mirai a réussi parce que trop d'appareils ne pouvaient pas être gérés comme des entités responsables de l'internet.

Le contrôle des clients était réel, mais inégal

Les clients du DNS géré n'étaient pas des spectateurs passifs. Le propriétaire du domaine contrôle les choix de délégation, la sélection du fournisseur, la surveillance, la politique de TTL, la conception du basculement et la capacité des services critiques à survivre à la perte d'un fournisseur DNS. Mais le contrôle n'était pas égal entre les clients. Une grande plateforme disposant d'une équipe d'infrastructure approfondie pouvait utiliser plusieurs fournisseurs faisant autorité, auto-héberger une partie de la pile, maintenir une automatisation de la cohérence et tester la résolution depuis de nombreux réseaux. Un petit éditeur, détaillant, fournisseur de logiciels, organisation à but non lucratif ou service municipal pouvait avoir acheté du DNS géré précisément pour éviter d'avoir besoin de cette compétence.

C'est là que la dépendance aux services cloud devient un problème de responsabilité. Un fournisseur peut vendre de l'expertise, mais les clients doivent encore décider quel niveau de défaillance du fournisseur ils peuvent tolérer. La question n'est pas « chaque site web devrait-il faire fonctionner un réseau DNS mondial sur mesure? » Ce serait économiquement absurde. La question est de savoir si les promesses de disponibilité du client correspondent à sa carte des dépendances. Une entreprise qui considère l'accessibilité en ligne comme critique pour sa mission doit savoir si un fournisseur DNS géré unique est un point de défaillance unique. Elle doit savoir à quelle vitesse elle peut changer la délégation au niveau du bureau d'enregistrement, combien de temps les enregistrements NS mis en cache vivront, si un fournisseur secondaire a une zone à jour, si DNSSEC continuera de valider, et si le basculement peut être testé sans créer un incident public.

Pour les petites organisations, la réponse pratique n'est peut-être pas une architecture multi-fournisseurs parfaite. Cela peut être un plan de récupération plus étroit: un deuxième fournisseur configuré pour les enregistrements les plus importants, des TTL plus longs pour les actifs stables lorsque cela est approprié, des identifiants de bureau d'enregistrement accessibles à plus d'une personne de confiance, des pages de statut hors bande, des informations de contact d'urgence mises en cache et une surveillance qui distingue la défaillance de résolution DNS de la défaillance applicative. C'est moins élégant que la diversité entièrement automatisée, mais c'est toujours mieux que de découvrir la dépendance lors d'un incident mondial chez le fournisseur.

Le risque s'étend également aux utilisateurs en aval. Une place de marché, un éditeur, un fournisseur SaaS ou un service de paiement qui devient inaccessible transfère les coûts aux annonceurs, vendeurs, équipes de support, sous-traitants et clients. L'utilisateur ne peut pas voir si la cause racine est le DNS, le DDoS, l'hébergement cloud, le routage du FAI ou un bogue applicatif. Il ne peut tout simplement pas effectuer de transaction. Parce que le DNS géré se situe si tôt dans le chemin, sa défaillance peut rendre toute la redondance ultérieure inutile jusqu'à ce que la résolution de noms revienne.

La communication devait servir deux publics

Dyn avait deux problèmes de communication. Elle devait dire à ses clients directs ce qui se passait et à quoi ils pouvaient s'attendre. Elle devait également communiquer avec la communauté internet au sens large parce que la panne était visible bien au-delà de la base de clients sous contrat de Dyn. Les utilisateurs publics, les journalistes, les régulateurs, les pairs de l'infrastructure et les concurrents avaient tous intérêt à comprendre si l'événement était une panne de plateforme ciblée, une instabilité plus large de l'internet, une urgence de botnet ou un problème de concentration DNS.

La déclaration de Dyn a donné un récit prudent du fournisseur: pas à l'échelle du système, variable selon les régions, deux vagues ayant impacté les clients, une troisième tentative atténuée, gestion des incidents activée, partenaires de mitigation impliqués, Mirai confirmé comme une source de trafic, et plus de détails retenus pour préserver les défenses futures. Cet équilibre est défendable. Un fournisseur DDoS ne devrait pas publier un plan de mitigation complet pendant une attaque active ou reproductible.

Pourtant, les clients avaient besoin de plus que de réassurance. Ils avaient besoin d'aide à la décision. Devraient-ils changer de fournisseur DNS immédiatement? Devraient-ils modifier les TTL? Devraient-ils communiquer des avis de panne à leurs propres clients? La propagation de la zone était-elle retardée? Toutes les régions étaient-elles affectées? Les enregistrements DNS des clients étaient-ils intacts? Quels groupes de serveurs de noms étaient dégradés? L'incident devait-il se reproduire? Plus un fournisseur se vend comme une infrastructure internet, plus sa communication de statut devient une partie du service.

L'incident a également montré pourquoi les clients ont besoin d'une surveillance indépendante. La page de statut d'un fournisseur peut prendre du retard ou simplifier. Les propres vérifications applicatives d'un client peuvent manquer la défaillance DNS si elles sont exécutées depuis un réseau avec des caches chauds. La surveillance devrait tester la recherche de l'autorité, la résolution récursive depuis plusieurs régions, l'accessibilité de l'application et la défaillance spécifique aux dépendances. L'analyse publique de ThousandEyes était puissante car elle séparait l'échec de la requête DNS du sentiment général de l'utilisateur que « l'internet est en panne ».

Les caches, les nouvelles tentatives et la préparation ont modifié la forme des dommages

La défaillance DNS n'est pas vécue de manière uniforme parce que la couche récursive se situe entre les utilisateurs et les fournisseurs faisant autorité. Si un résolveur récursif a déjà une réponse en cache valide, un utilisateur peut continuer à accéder à un service même pendant que les serveurs faisant autorité sont dégradés. Si la réponse en cache expire, ou si le résolveur n'a pas de réponse, le même service peut soudainement devenir inaccessible depuis ce réseau. Deux utilisateurs dans la même ville peuvent donc signaler des résultats différents parce que leurs résolveurs, caches et horaires de requête diffèrent.

Ce comportement complique à la fois le blâme et la réponse. Un propriétaire de service peut regarder ses serveurs d'origine et constater une santé normale. Un fournisseur DNS géré peut voir un mélange de trafic d'attaque, de nouvelles tentatives légitimes des résolveurs, d'effets de cache périmé et de changements de route. Les opérateurs récursifs peuvent augmenter la pression des requêtes en réessayant lorsque les réponses expirent. Les utilisateurs constatent une accessibilité intermittente et peuvent supposer que l'application est cassée. Le récit public devient « les grands sites web sont en panne », tandis que la réalité technique est plutôt « certains résolveurs ne peuvent pas obtenir ou actualiser les réponses faisant autorité pour certains domaines pendant certaines fenêtres de temps ».

Lecoup d'œil rapide de RIPE Labs sur l'attaque contre Dyna utilisé les mesures de RIPE Atlas pour observer l'événement à partir de sondes distribuées. Une note complémentaire de RIPE Labs,Speculating on DNS DDoS(Spéculations sur les DDoS DNS), a souligné que le trafic de nouvelles tentatives récursives peut aggraver l'impact et qu'il peut être difficile de distinguer le trafic DNS légitime du trafic d'attaque lors d'un DDoS sur le protocole DNS. Il ne s'agit pas de jugements juridiques sur Dyn. Ils expliquent pourquoi la mitigation des DDoS DNS est plus compliquée que le simple blocage d'une source hostile unique ou l'ajout d'un serveur de sauvegarde unique.

Des recherches après l'incident ont fait le même constat sous un autre angle. L'articleWhen the Dike Breaks: Dissecting DNS Defenses During DDoS(Quand la digue cède: Dissection des défenses DNS pendant un DDoS) soutient que la mise en cache est un facteur important de la résilience DNS et que différentes couches DNS peuvent subir un DDoS de manière très différente. L'article utilise l'incident Dyn comme exemple d'une panne visible affectant les domaines utilisant Dyn comme fournisseur DNS, tout en notant que d'autres cibles DNS, comme les serveurs racine, avaient absorbé des attaques sans pannes de service visibles. La leçon n'est pas qu'une couche DNS est sûre et une autre faible. C'est que l'architecture, la mise en cache, la diversité, le volume de trafic et les pratiques des opérateurs se combinent pour déterminer l'impact public.

Pour un client de DNS géré, cela signifie que la préparation doit inclure plus qu'un nom de fournisseur sur un registre des risques. Le client doit savoir quels enregistrements sont suffisamment stables pour une durée de vie de cache plus longue, quels enregistrements nécessitent une orientation dynamique, quels résolveurs récursifs sont importants pour ses utilisateurs et comment les réponses périmées pourraient affecter un basculement. Il doit également décider si un changement d'urgence du TTL est utile avant un incident ou surtout symbolique après que les caches détiennent déjà l'ancienne valeur. Les changements DNS dépendent du temps; un plan de récupération qui suppose une propagation mondiale instantanée n'est pas un plan de récupération.

Les conseils généraux sur les DDoS renforcent la même discipline opérationnelle. Lacollection de conseils sur le déni de servicedu National Cyber Security Centre (NCSC) du Royaume-Uni structure la préparation autour de quatre pratiques: comprendre le service, comprendre les défenses, créer un plan de réponse et tester la réponse. La pageUnderstanding Denial-of-Service Attacks(Comprendre les attaques par déni de service) de la CISA explique le problème de disponibilité de base: les utilisateurs légitimes ne peuvent pas accéder aux systèmes d'information, aux appareils ou aux ressources réseau. Le document ultérieurUnderstanding and Responding to Distributed Denial-of-Service Attacks(Comprendre et répondre aux attaques par déni de service distribué) de la CISA, du FBI et du MS-ISAC est plus large que le DNS, mais le principe s'applique: les organisations ont besoin de préparation à l'avance, de coordination avec les fournisseurs de services, de lignes de base de trafic, de procédures de réponse et de plans de communication.

Ces pratiques exposent une vérité inconfortable sur les dépendances cloud. Un client peut externaliser l'opération DNS, mais il ne peut pas externaliser la connaissance de la manière dont une défaillance DNS affecte son propre activité. Dyn pouvait atténuer les attaques sur son infrastructure; elle ne pouvait pas connaître l'état dégradé acceptable de chaque client. Une banque, une place de marché, un éditeur, une université, un réseau de jeux et un portail de rendez-vous hospitaliers ont des tolérances différentes pour la résolution lente, les réponses périmées et la perte d'accessibilité régionale. Le plan de continuité du client doit traduire le statut du fournisseur en décisions commerciales: s'il faut informer les utilisateurs, changer de canal, suspendre les transactions, basculer en mode ouvert, en mode fermé ou accepter une accessibilité partielle jusqu'à ce que le DNS se stabilise.

Pour Dyn, le même principe de préparation fonctionne dans la direction opposée. Un fournisseur DNS géré doit comprendre qu'un événement DDoS contre sa propre infrastructure n'est pas seulement un incident technique à l'intérieur de son réseau. C'est une crise simultanée pour les clients. Les clients ont besoin de suffisamment d'informations pour éviter d'aggraver l'événement en improvisant des changements de délégation, en raccourcissant les TTL, en déplaçant les zones de manière incohérente ou en inondant le support. Les procédures du fournisseur doivent donc inclure la mitigation, la segmentation des clients, la précision du statut et des conseils pour les clients ayant différents niveaux de sophistication DNS.

L'incident d'octobre 2016 a été dommageable en partie parce qu'il a révélé la minceur de la couche de préparation partagée. Les ingénieurs DNS comprenaient la mise en cache, l'anycast et la résolution faisant autorité. De nombreux dirigeants d'entreprise et utilisateurs ne les comprenaient pas. Certains clients comprenaient la diversité des fournisseurs. Beaucoup ne l'avaient pas mise en œuvre. Les experts en sécurité IoT comprenaient les risques des identifiants par défaut et des flottes d'appareils non gérés. Des millions d'appareils étaient déjà exposés. Une défaillance de mode commun est souvent ce qui arrive lorsque des connaissances spécialisées existent dans des communautés séparées mais n'ont pas été converties en engagements opérationnels partagés.

La frontière juridique est plus étroite que la leçon opérationnelle

Les archives publiques établissent une activité DDoS malveillante, une perturbation du service Dyn, des problèmes d'accessibilité pour les clients, l'implication de Mirai et des plaidoyers de culpabilité ultérieurs. Elles n'établissent pas que Dyn a violé un contrat spécifique, que chaque client affecté manquait d'une architecture raisonnable, que chaque fabricant IoT a violé une obligation légale ou que toutes les pertes peuvent être attribuées à un seul défendeur. Les termes des contrats individuels de Dyn, des accords de niveau de service client, des polices d'assurance et des dépendances de tiers ne sont pas publics de manière à soutenir des conclusions juridiques larges.

Cette frontière ne devrait pas affaiblir la leçon opérationnelle. Elle la rend plus claire. La faute juridique est spécifique au forum. Le contrôle opérationnel est visible dans les choix de conception. Dyn contrôlait la résilience au niveau du fournisseur et les communications. Les clients contrôlaient la diversification du fournisseur DNS et la planification de la continuité. Les fournisseurs IoT contrôlaient les identifiants par défaut, les chemins de mise à jour et le support du cycle de vie. Les propriétaires d'appareils contrôlaient le déploiement et le durcissement de base seulement dans la mesure où les produits le permettaient pratiquement. Les FAI et les entreprises de sécurité contrôlaient la détection, la notification et les choix de mitigation. Les gouvernements contrôlaient les incitations, les normes, la réponse des forces de l'ordre et la coordination public-privé.

L'incident relève de l'analyse de la responsabilité car aucune couche unique ne pouvait réparer l'ensemble de la défaillance. Un client DNS multi-fournisseurs parfait pourrait encore souffrir d'un botnet massif ailleurs dans sa pile. Une gamme de produits IoT bien construite ne diversifierait pas le DNS faisant autorité d'un client. Un fournisseur DNS brillant pourrait encore faire face à un trafic hostile sans précédent provenant d'appareils qu'il n'a pas vendus. Un rapport gouvernemental pourrait recommander la sécurité du cycle de vie, mais ne pourrait pas remplacer instantanément des millions d'appareils exposés. La défaillance de mode commun est née de l'ajustement entre ces couches.

Le signal du marché après l'incident

Un mois après l'attaque, Oracle a annoncé qu'il avait accepté d'acquérir Dyn. Lecommuniqué de pressed'Oracle décrivait Dyn comme un fournisseur leader de performance internet et de DNS basé sur le cloud, indiquait que son réseau générait 40 milliards de décisions d'optimisation du trafic par jour pour plus de 3 500 entreprises clientes, et nommait des clients comme Netflix, Twitter, Pfizer et CNBC. L'acquisition ne doit pas être interprétée comme une conséquence de l'attaque sans preuve; le communiqué ne le disait pas. Cela reste un contexte utile pour le rôle de marché de Dyn. Il ne s'agissait pas d'un service de niche pour amateurs. C'était une plateforme DNS gérée majeure pour des entreprises numériques de premier plan.

Cette position sur le marché est la raison pour laquelle l'incident est toujours important. La concentration dans le cloud produit souvent des avantages réels: une meilleure expertise, une plus grande portée mondiale, une mitigation plus rapide, un personnel spécialisé et des économies d'échelle. Cela change également le mode de défaillance. Lorsque de nombreux clients convergent vers le même fournisseur, leurs déclarations indépendantes de continuité d'activité peuvent devenir corrélées. Une plateforme peut externaliser une fonction tout en assumant les conséquences de l'architecture d'externalisation.

Le rapport de 2018 du ministère du Commerce et de la Sécurité intérieure soutenait que les incitations du marché étaient mal alignées pour la résilience des botnets. Un problème d'incitation similaire existait du côté client du DNS géré. Le DNS avec un seul fournisseur est plus simple à acheter, configurer, surveiller et soutenir. Le DNS multi-fournisseurs réduit le risque de mode commun mais augmente la complexité d'ingénierie et le risque de mauvaise configuration. Le client qui évite cette complexité peut ne jamais être puni en temps ordinaire. La pénalité n'apparaît que lorsqu'un fournisseur échoue sous la pression, et à ce moment-là, de nombreux clients peuvent vivre le même événement ensemble.

Tests pratiques de responsabilité

Le cas Dyn donne aux dirigeants plusieurs tests qui restent utiles.

Dépendance au DNS faisant autorité:Quel fournisseur répond pour chaque domaine et sous-domaine critique? Tous les serveurs de noms listés sont-ils exploités par le même fournisseur ou via le même plan de contrôle de routage et de gestion? Quels services échouent si ce fournisseur est inaccessible depuis une grande région?

Indépendance du fournisseur:Existe-t-il un deuxième fournisseur DNS faisant autorité avec des données de zone à jour? Si oui, est-il vraiment indépendant en termes de réseau, de plan de contrôle, d'identifiants, de chemin de support et de mitigation DDoS? Sinon, l'organisation a-t-elle consciemment accepté le risque de fournisseur unique?

Stratégie de TTL et de cache:Les TTL DNS reflètent-ils le besoin réel de l'organisation en agilité par rapport à la tolérance aux pannes? Les enregistrements les plus stables bénéficient-ils d'une durée de vie de cache suffisante pour réduire la dépendance évitable aux recherches fréquentes de l'autorité pendant les problèmes transitoires du fournisseur?

DNSSEC et contrôle des changements:Si DNSSEC est activé, les signatures, les clés et les enregistrements DS peuvent-ils survivre à une exploitation multi-fournisseurs ou à un changement d'urgence de fournisseur? Sinon, le repli peut échouer de manière sécurisée, ce qui signifie toujours que les utilisateurs ne peuvent pas accéder au service.

Surveillance:L'organisation peut-elle distinguer la défaillance du DNS faisant autorité, les problèmes de résolveur récursif, les problèmes de CDN, la défaillance d'origine et la défaillance applicative? Les tests sont-ils exécutés depuis suffisamment de réseaux et de régions pour détecter un problème DNS anycast ou régional?

Récupération du bureau d'enregistrement:Les identifiants du bureau d'enregistrement, les verrous de registre, les contacts d'urgence et les procédures de changement de délégation sont-ils documentés, protégés et disponibles pendant un incident? Un fournisseur DNS de sauvegarde n'est pas utile si personne ne peut changer la délégation en toute sécurité.

Communications avec le fournisseur:Le fournisseur DNS géré fournit-il des détails de statut au niveau dont les clients ont besoin pour prendre des décisions, sans exposer les méthodes défensives? Les chemins de support client sont-ils conçus pour un événement à impact simultané où de nombreux clients demandent de l'aide en même temps?

Exposition aux botnets:Pour les organisations qui fabriquent, déploient ou gèrent des appareils connectés, les identifiants par défaut, les mises à jour sécurisées, l'identité des appareils, le signalement des vulnérabilités et le support de fin de vie sont-ils conçus pour empêcher que la flotte d'appareils ne devienne la capacité DDoS de quelqu'un d'autre?

Ces tests ne relèvent pas d'une pureté d'ingénierie abstraite. Ils sont la manière dont un propriétaire de domaine apprend si « nous avons des serveurs de noms redondants » signifie une véritable indépendance vis-à-vis des défaillances ou simplement plusieurs noms d'hôte au sein d'une même dépendance fournisseur.

La leçon durable

Dyn n'a pas prouvé que le DNS géré est mauvais. Le contraire est plus proche de la vérité: le DNS géré existe parce que la disponibilité DNS est difficile, spécialisée et exposée mondialement. De nombreux clients seraient moins résilients s'ils étaient obligés de gérer leur propre infrastructure faisant autorité sans expertise. L'incident a prouvé que l'externalisation n'efface pas l'architecture. Elle déplace une partie de l'architecture vers un fournisseur et oblige ensuite le client à décider si le fournisseur est un composant ou une dépendance de mode commun.

Mirai n'a pas non plus prouvé que l'IoT grand public seul peut être blâmé pour chaque panne d'infrastructure. Il a prouvé que des appareils de périphérie non sécurisés peuvent être agrégés en une force suffisamment importante pour menacer les services centraux. Les foyers et les entreprises qui possédaient ces appareils n'avaient pas l'intention d'attaquer Dyn. Les fournisseurs d'appareils n'avaient peut-être pas imaginé leurs produits comme des éléments de l'infrastructure internet. Mais l'internet public en a fait des entités malgré tout.

La mémoire responsable de l'incident Dyn devrait donc être stratifiée. Des acteurs criminels ont lancé des attaques. Dyn a défendu une plateforme DNS de grande valeur sous un trafic hostile extrême et a néanmoins subi une perturbation ayant un impact sur les clients. De nombreux clients dépendaient d'un seul fournisseur pour le DNS faisant autorité et ont découvert que plusieurs serveurs de noms ne signifient pas toujours une diversité de fournisseurs. Les fournisseurs et propriétaires IoT avaient permis à des appareils faibles de devenir des ressources d'attaque. Les gouvernements et les organismes de normalisation ont ensuite encadré la résilience des botnets comme un problème de marché et d'écosystème, pas seulement comme une question de punition d'un attaquant.

La leçon pratique est brutale: l'accessibilité dépend du plan de contrôle ennuyeux. Une entreprise peut construire des serveurs d'application redondants, plusieurs clouds, des régions actif-actif et une réponse aux incidents sophistiquée, puis disparaître des navigateurs des utilisateurs si sa dépendance au DNS faisant autorité est unique et inaccessible. La délégation DNS est un pouvoir. La traiter comme une ligne d'approvisionnement à faible risque est la manière dont un service géré devient une défaillance de mode commun.