Dyn: le DNS géré, limite de responsabilité pour la continuité des revenus

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 seconde vague, plus globale, a débuté 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 d'observation mondiaux et a rapporté qu'environ 75 % de ses points d'observation ont envoyé 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 Dyn plutôt que plusieurs fournisseurs DNS.
• Attribution limitée:Dyn a déclaré que l'analyse de Flashpoint et Akamai avait confirmé qu'une source du trafic provenait de dispositifs infectés par Mirai. Le DOJ a annoncé par la suite des plaidoyers de culpabilité des créateurs de Mirai et un plaidoyer de culpabilité distinct d'un individu dont l'attaque par botnet de variante Mirai, le 21 octobre 2016, a impacté Dyn et rendu des sites tels que Sony, Twitter, Amazon, PayPal, Tumblr, Netflix et Southern New Hampshire University 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 observé par Dyn ce jour-là.
• Évaluation:L'incident a été une défaillance en mode commun par dépendance. Dyn contrôlait sa plateforme DNS géré, ses partenaires de mitigation, ses communications et l'architecture de son infrastructure. Les clients contrôlaient la diversification du DNS autoritaire chez plusieurs fournisseurs et l'adéquation des pratiques de TTL, de basculement et de surveillance avec leurs propres revendications de disponibilité. Les fournisseurs IoT, les propriétaires d'appareils, les FAI, les régulateurs et les attaquants contrôlaient des parties distinctes du problème de botnet.

Registre des preuves et leur utilisation

Cet article utilise la déclaration publique de Dyn, des mesures DNS indépendantes, des archives du DOJ, des normes DNS, des recherches en sécurité, des conseils sur les DDoS et le contexte du marché comme preuves stratifiées. Ce tableau n'affirme pas que chaque source citée prouve la perte de chaque client affecté; il explique quels documents publics soutiennent l'analyse de responsabilité.

Le DNS a échoué avant l'application web

Un utilisateur ne remarque généralement le DNS que lorsqu'il ne fonctionne plus. Le nom du site semble normal. Le navigateur fonctionne. La connexion de l'utilisateur peut être saine. L'application de destination peut toujours fonctionner. Pourtant, si le chemin DNS autoritaire ne peut pas répondre, le service peut disparaître comme si les serveurs eux-mêmes étaient hors ligne. C'est ce qui a rendu l'incident Dyn si déroutant. De nombreux services n'étaient pas nécessairement défaillants 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 leur DNS autoritaire auprès d'un fournisseur géré parce que ce fournisseur pouvait offrir une portée mondiale anycast, une gestion du trafic, une expertise opérationnelle et une préparation aux 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é sur l'Internet public des appareils connectés non sécurisés, souvent avec des identifiants par défaut faibles ou des chemins de mise à jour insuffisants. 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 laDé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 tentative de vague que Dyn a déclaré avoir atténuée sans impact sur les clients. Dyn a également déclaré n'avoir subi aucune panne à l'échelle du système à aucun moment, et que certains utilisateurs, comme ceux atteignant les sites affectés depuis la côte Ouest des États-Unis pendant la première vague, auraient réussi à se connecter.

Ce détail est important. L'incident n'était pas une panne binaire nette où chaque client 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 TTL, la configuration des domaines clients 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 les utilisateurs ailleurs constataient un échec. Un propriétaire de plateforme pouvait avoir des serveurs applicatifs sains tout en recevant des plaintes selon lesquelles le service était hors ligne.

Un utilisateur pouvait attendre jusqu'à ce qu'une réponse DNS en cache expire, puis soudainement perdre 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, fournit l'explication publique la plus claire de la dépendance 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, et une atténuation ultérieure avec des attaques persistantes ou du blackholing. Au plus fort de l'attaque, environ trois quarts de ses points d'observation mondiaux ont envoyé 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 sévère. Dyn exploitait des serveurs autoritaires pour les domaines clients. Si un résolveur n'avait pas déjà une réponse en cache fraîche et ne pouvait pas joindre les serveurs autoritaires de Dyn, il ne pouvait pas obtenir l'adresse nécessaire pour se connecter. Des valeurs 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 d'une résolution autoritaire réussie. Un TTL bas n'est pas mauvais en soi; c'est un compromis.

Lors d'un événement DDoS chez un fournisseur DNS, cela peut raccourcir le temps entre « le cache sait encore où aller » et « le résolveur doit à nouveau interroger l'autorité indisponible ».

ThousandEyes a également décrit la popularité de Dyn pour la gestion 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 en 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 elle devenait attrayante en tant que plan de contrôle partagé.

La conclusion la plus importante de ThousandEyes pour la responsabilité était l'architecture client. De nombreux clients Dyn affectés n'utilisaient que les serveurs de noms Dyn plutôt que de diversifier entre plusieurs fournisseurs DNS. L'analyse opposait les clients avec 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 schéma d'indisponibilité totale observé par beaucoup d'autres. Cela ne signifie pas que chaque client aurait pu passer à 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 d'AP relayé par le Chicago Sun-Times a capturé l'expérience publique: des réactions en chaîne pour les utilisateurs essayant d'atteindre des sites Web populaires aux États-Unis et en Europe, avec Twitter, Netflix et le PlayStation Network de Sony parmi les services apparemment affectés. Le reportage contemporain du Guardian a listé 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 l'étendue et la perception publique; ils ne prouvent pas que chaque service nommé ait subi le même mode de défaillance technique ou la même durée.

La défaillance en mode commun se cache dans le 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 autoritaires peuvent être géographiquement dispersés. Le problème est que la redondance peut être formelle sans être indépendante des pannes.

RFC 2182stipule depuis 1997 qu'une raison majeure d'avoir plusieurs serveurs DNS est de maintenir les informations de zone disponibles même lorsqu'un serveur est injoignable, 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 locale. En langage courant: plusieurs serveurs de noms ne suffisent pas s'ils tombent en panne ensemble.

Le cas Dyn a traduit ce principe de la localisation physique à la dépendance au fournisseur. Un client pouvait lister plusieurs serveurs de noms Dyn et n'avoir pourtant qu'un seul fournisseur, une seule relation commerciale, un seul chemin de support opérationnel, un seul jeu 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 pouvaient sembler diversifiés. Du point de vue de la responsabilité, ils font toujours partie d'une dépendance commune au fournisseur.

L'articleThe Lack of Redundancy in DNS Resolution by Major Websites and Servicesa examiné la concentration et la diversification du DNS après l'incident Dyn. Il a constaté une concentration croissante parmi 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 utilisant 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 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'Internet dans son ensemble. Ils soutiennent néanmoins la leçon pratique. Le DNS permettait la diversification des fournisseurs, mais de nombreux clients avaient choisi la simplicité opérationnelle plutôt que l'indépendance aux pannes. Cela n'est pas irrationnel.

Un DNS autoritaire multi-fournisseurs introduit de la complexité: données de zone cohérentes, signature DNSSEC et gestion des clés, comportement des vérifications d'état, différences de gestion 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 du manque de diversification peut également devenir réel, et peut survenir via un fournisseur plutôt que par l'infrastructure propre du client.

L'anycast est puissant, mais pas magique

L'infrastructure de Dyn, comme celle 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 pannes locales car le trafic peut se déplacer autour du réseau. C'est l'une des raisons pour lesquelles les fournisseurs de DNS géré peuvent offrir une large portée et une réponse rapide.

L'anycast ne rend pas la capacité infinie. Il peut distribuer le trafic, mais il peut également distribuer la pression d'une attaque. Si l'attaque est suffisamment importante, large ou ciblée de manière à saturer les liens en amont, le peering ou les préfixes partagés, les emplacements anycast peuvent tomber 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 par 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 de l'incident et les communications avec les clients. Elle indiquait é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 l'atténuation des DDoS était une simple question d'achat de bande passante.

Les très grandes attaques distribuées créent des erreurs de mesure, des tempêtes de tentatives répétées, 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.

Cependant, 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 des capacités, coordination en amont, architecture anycast, conception de la constellation des serveurs de noms, communication de l'état, support client, préparation des partenaires de mitigation et preuves post-incident. Un compte rendu équitable de la responsabilité peut soutenir ces deux idées à la fois. L'attaque était malveillante et de grande ampleur.

L'activité de Dyn était de maintenir le DNS autoritaire accessible dans des conditions hostiles.

Mirai a déplacé le risque des appareils grand public vers l'infrastructure

Mirai a rendu l'attaque culturellement mémorable parce que le botnet était en grande partie construit à partir d'appareils connectés à Internet ordinaires: caméras, routeurs, enregistreurs vidéo numériques et systèmes embarqués similaires. L'article de USENIXUnderstanding 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 concernant Mirai,Justice Department Announces Charges and Guilty Pleas in Three Computer Crime Cases Involving Significant DDoS Attacks, indiquait que Paras Jha, Josiah White et Dalton Norman avaient plaidé coupable d'avoir exploité le botnet Mirai, qui ciblait des dispositifs 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 dans la variante originale de Mirai avait pris fin lorsque Jha avait publié le code source sur un forum criminel à l'automne 2016. Depuis lors, selon le DOJ, d'autres acteurs ont 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, a relié plus directement un botnet de variante Mirai au jour de l'incident Dyn. 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 avaient utilisé un botnet pour lancer plusieurs attaques DDoS le 21 octobre 2016 dans le but de rendre le PlayStation Network de Sony hors ligne; les attaques ont impacté Dyn, ce qui a rendu des sites comme Sony, Twitter, Amazon, PayPal, Tumblr, Netflix et Southern New Hampshire University 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 l'impact sur Dyn, ni que l'ensemble du 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 ses variantes 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 Mirai,Alerte CISA sur Mirai, avertissait que le logiciel malveillant Mirai analysait les dispositifs IoT vulnérables et que la publication publique du code source de Mirai augmentait le risque de nouveaux botnets. Le rapport ultérieur du Département 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, a formulé le problème à 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 devraient ê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.

Cette formulation écosystémique correspond mieux à l'incident Dyn qu'un récit de blâme étroit. Les attaquants ont abusé d'appareils qu'ils ne possédaient pas. Les fabricants d'appareils avaient souvent livré des produits à bas prix 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 ne l'ont vue que comme un site qui ne se chargeait pas.

La publication ultérieureNISTIR 8259A IoT Device Cybersecurity Capability Core Baselinen'existait pas en 2016 et ne doit pas être traitée comme une obligation légale rétroactive pour Dyn. Elle reste utile comme preuve de ce que l'écosystème a appris à valoriser: l'identification des appareils, la configuration sécurisée, la protection des données, l'accès logique, la capacité de mise à jour logicielle, la sensibilisation à l'état de la cybersécurité et la 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 client é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 profonde pouvait exploiter plusieurs fournisseurs autoritaires, 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, éditeur 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 ces compétences.

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 néanmoins décider quel niveau de défaillance du fournisseur ils peuvent tolérer. La question n'est pas « chaque site Web devrait-il gérer un réseau DNS mondial sur mesure? ». Cela serait économiquement absurde. La question est de savoir si les promesses de disponibilité du client correspondent à sa carte de dépendance. Une entreprise qui considère l'accessibilité en ligne comme critique pour sa mission devrait savoir si un seul fournisseur de DNS géré constitue un point de défaillance unique.

Elle devrait savoir à quelle vitesse elle peut modifier la délégation chez le bureau d'enregistrement, combien de temps les enregistrements NS mis en cache vivront, si un fournisseur secondaire dispose d'une zone à jour, si DNSSEC continuera à 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. Elle 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 d'état 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 qu'une diversité entièrement automatisée, mais cela vaut toujours mieux que de découvrir la dépendance lors d'un incident mondial chez un 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 injoignable répercute les coûts sur les annonceurs, les vendeurs, les équipes de support, les sous-traitants et les clients. L'utilisateur ne peut pas voir si la cause première est le DNS, un 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 redondance ultérieure inutile jusqu'au retour de la résolution de noms.

La communication devait servir deux publics

Dyn avait deux problèmes de communication. Il devait dire à ses clients directs ce qui se passait et ce à quoi ils pouvaient s'attendre. Il 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é Internet plus large, une urgence de botnet ou un problème de concentration du DNS.

La déclaration de Dyn a fourni 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 de l'incident 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 de DDoS ne devrait pas publier un plan complet d'atténuation pendant une attaque active ou reproductible.

Pourtant, les clients avaient besoin de plus que d'être rassurés. Ils avaient besoin d'aide à la décision. Devaient-ils changer de fournisseur DNS immédiatement? Devaient-ils modifier les TTL? Devaient-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? Le problème était-il susceptible de se reproduire? Plus un fournisseur se présente comme une infrastructure Internet, plus sa communication d'état devient une partie intégrante du service.

L'incident a également montré pourquoi les clients ont besoin d'une surveillance indépendante. La page d'état d'un fournisseur peut être en retard ou simplifier. Les propres vérifications applicatives d'un client peuvent manquer une défaillance DNS si elles s'exécutent depuis un réseau avec des caches chauds. La surveillance devrait tester la consultation autoritaire, la résolution récursive depuis plusieurs régions, l'accessibilité de l'application et la défaillance spécifique à la dépendance.

L'analyse publique de ThousandEyes était puissante parce qu'elle séparait l'échec des requêtes DNS du sentiment général des utilisateurs selon lequel « l'Internet est en panne ».

Caches, tentatives répétées et préparation ont façonné l'ampleur du préjudice

La défaillance DNS n'est pas vécue uniformément car la couche récursive se situe entre les utilisateurs et les fournisseurs autoritaires. Si un résolveur récursif a déjà une réponse valide en cache, un utilisateur peut continuer à atteindre un service même si les serveurs autoritaires sont défaillants. 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 injoignable depuis ce réseau. Deux utilisateurs dans la même ville peuvent donc signaler des résultats différents parce que leurs résolveurs, leurs caches et le moment de leurs requêtes diffèrent.

Ce comportement complique à la fois l'attribution de blâme et la réponse. Un propriétaire de service peut regarder ses serveurs d'origine et voir un état de santé normal. Un fournisseur de DNS géré peut voir un mélange de trafic d'attaque, de tentatives légitimes des résolveurs, d'effets de cache périmé et de changements d'itinéraire. Les opérateurs récursifs peuvent augmenter la pression des requêtes en réessayant lorsque les réponses expirent. Les utilisateurs voient une accessibilité intermittente et peuvent supposer que l'application est cassée.

Le récit public devient « les principaux sites Web sont en panne », tandis que la réalité technique est plus proche de « certains résolveurs ne peuvent pas obtenir ou actualiser les réponses autoritaires pour certains domaines pendant certaines fenêtres ».

L'aperçu de RIPE Labs sur l'attaque de Dyn,A quick look at the attack on Dyn, a 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, a souligné que le trafic de 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 par protocole DNS. Il ne s'agit pas de jugements juridiques sur Dyn. Ils expliquent pourquoi l'atténuation des DDoS DNS est plus désordonnée que le blocage d'une seule source hostile ou l'ajout d'un seul serveur de secours.

La recherche post-incident a fait le même constat sous un autre angle. L'articleWhen the Dike Breaks: Dissecting DNS Defenses During DDoSsoutient 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 racines, 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 est faible. C'est que l'architecture, la mise en cache, la diversité, le volume de trafic et les pratiques de l'opérateur 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 de risques. Le client doit savoir quels enregistrements sont assez stables pour une durée de vie de cache plus longue, quels enregistrements nécessitent une gestion 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 une modification d'urgence du TTL est utile avant un incident ou surtout symbolique après que les caches contiennent 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. La collection de guides sur le déni de service du National Cyber Security Centre du Royaume-Uni,Denial of Service guidance collection, 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 publication de la CISAUnderstanding Denial-of-Service Attacksexplique le problème de disponibilité de base: les utilisateurs légitimes ne peuvent pas accéder aux systèmes d'information, aux dispositifs ou aux ressources réseau. Le guide ultérieur de la CISA, du FBI et du MS-ISAC,Understanding and Responding to Distributed Denial-of-Service Attacks, est plus large que le DNS, mais le principe s'applique: les organisations ont besoin d'une préparation préalable, d'une coordination avec les fournisseurs de services, de références 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'exploitation DNS, mais il ne peut pas externaliser la connaissance de la façon dont une défaillance DNS affecte sa propre activité. Dyn pouvait atténuer les attaques sur son infrastructure; il ne pouvait pas connaître l'état dégradé acceptable pour chaque client. Une banque, une place de marché, un éditeur, une université, un réseau de jeux et un portail de rendez-vous hospitalier ont des tolérances différentes pour une résolution lente, des réponses périmées et une perte d'accessibilité régionale.

Le plan de continuité du client doit traduire l'état du fournisseur en décisions commerciales: faut-il notifier les utilisateurs, changer de canal, suspendre les transactions, passer en mode dégradé ouvert, fermé, ou accepter une accessibilité partielle jusqu'à ce que le DNS se stabilise.

Pour Dyn, le même principe de préparation s'applique en sens inverse. Un fournisseur de DNS géré doit comprendre qu'un événement DDoS contre sa propre infrastructure n'est pas seulement un incident technique interne à 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 des zones de manière incohérente ou en inondant le support.

Les procédures du fournisseur doivent donc inclure l'atténuation, la segmentation de la clientèle, la précision de l'état 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 autoritaire. De nombreux chefs d'entreprise et utilisateurs ne les comprenaient pas. Certains clients comprenaient la diversification 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 parcs d'appareils non gérés. Des millions d'appareils étaient déjà exposés.

Une défaillance en mode commun est souvent ce qui arrive lorsque des connaissances spécialisées existent dans des communautés distinctes mais n'ont pas été converties en engagements opérationnels partagés.

La limite 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é client, l'implication de Mirai et des plaidoyers de culpabilité ultérieurs. Elles ne permettent pas d'établir 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 clients, des polices d'assurance et des dépendances tierces ne sont pas publics d'une manière qui permettrait des conclusions juridiques générales.

Cette limite ne devrait pas affaiblir la leçon opérationnelle. Elle la rend plus claire. La faute juridique dépend du 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 des fournisseurs 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 uniquement dans la mesure où les produits le permettaient.

Les FAI et les entreprises de sécurité contrôlaient les choix de détection, de notification et d'atténuation. 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 responsabilité parce qu'aucune couche ne pouvait à elle seule réparer l'ensemble de la défaillance. Un client parfaitement diversifié au niveau DNS pouvait encore souffrir d'un botnet massif ailleurs dans sa pile. Une gamme de produits IoT bien conçue ne diversifierait pas le DNS autoritaire d'un client. Un brillant fournisseur DNS pouvait encore faire face à un trafic hostile sans précédent provenant d'appareils qu'il n'a pas vendus. Un rapport gouvernemental pouvait recommander la sécurité du cycle de vie, mais pas remplacer instantanément des millions d'appareils exposés.

La défaillance en mode commun est apparue de l'ajustement entre ces couches.

Le signal du marché post-incident

Un mois après l'attaque, Oracle a annoncé avoir conclu un accord pour acquérir Dyn. Le communiqué de presse d'Oracle,Oracle achète Dyn, décrivait Dyn comme un fournisseur de premier plan de services de performance Internet et de DNS basés sur le cloud, indiquait que son réseau pilotait 40 milliards de décisions d'optimisation du trafic par jour pour plus de 3 500 entreprises clientes, et nommait des clients tels que Netflix, Twitter, Pfizer et CNBC. L'acquisition ne doit pas être interprétée comme une conséquence de l'attaque sans preuves; le communiqué ne le disait pas. Cela donne néanmoins un contexte utile sur le rôle de marché de Dyn. Il ne s'agissait pas d'un service de niche amateur. C'était une plateforme majeure de DNS géré pour des entreprises numériques de premier plan.

Cette position sur le marché explique pourquoi l'incident importe encore. La concentration dans le cloud produit souvent des avantages réels: une meilleure expertise, une portée plus mondiale, une atténuation plus rapide, un personnel spécialisé et des économies d'échelle. Elle modifie également le mode de défaillance. Lorsque de nombreux clients convergent vers le même fournisseur, leurs revendications 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 Département du Commerce et de la Sécurité intérieure soutenait que les incitations du marché étaient mal alignées pour la résilience aux botnets. Un problème d'incitation similaire existait du côté client du DNS géré. Un DNS à fournisseur unique est plus simple à acheter, configurer, surveiller et supporter. Un DNS multi-fournisseurs réduit le risque de mode commun mais augmente la complexité technique et le risque de mauvaise configuration. Le client qui évite cette complexité peut ne jamais en être pénalisé en temps normal.

La pénalité n'apparaît que lorsqu'un fournisseur défaille sous la contrainte, et à ce moment-là, de nombreux clients peuvent subir le même événement ensemble.

Tests pratiques de responsabilité

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

Dépendance au DNS autoritaire:Quel fournisseur répond pour chaque domaine et sous-domaine critiques? 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 injoignable depuis une région majeure?

Indépendance du fournisseur:Existe-t-il un deuxième fournisseur DNS autoritaire avec des données de zone à jour? Si oui, est-il véritablement 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 d'un fournisseur unique?

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

DNSSEC et contrôle des modifications: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 basculement peut échouer de manière sécurisée, ce qui signifie toujours que les utilisateurs ne peuvent pas atteindre le service.

Surveillance:L'organisation peut-elle distinguer une défaillance du DNS autoritaire, des problèmes de résolveur récursif, des problèmes de CDN, une défaillance d'origine et une 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 au niveau 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 secours n'est d'aucune utilité si personne ne peut modifier la délégation en toute sécurité.

Communications avec le fournisseur:Le fournisseur de DNS géré fournit-il des informations d'état au niveau de détail 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 en fin de vie sont-ils conçus pour empêcher que le parc 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 permettent au propriétaire d'un domaine de savoir si « nous avons des serveurs de noms redondants » signifie une véritable indépendance aux pannes ou simplement plusieurs noms d'hôtes au sein d'une même dépendance fournisseur.

La leçon durable

L'incident Dyn n'a pas prouvé que le DNS géré est mauvais. La réalité est plus proche du contraire: le DNS géré existe parce que la disponibilité du DNS est difficile, spécialisée et exposée mondialement. De nombreux clients seraient moins résilients s'ils étaient forcés de gérer leur propre infrastructure autoritaire 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 en mode commun.

Mirai n'a pas non plus prouvé que l'IoT grand public pouvait à lui seul être blâmé pour chaque panne d'infrastructure. Il a prouvé que des appareils de périphérie non sécurisés pouvaient être agrégés en une force suffisamment importante pour menacer les services centraux. Les foyers et les entreprises propriétaires de ces appareils n'avaient pas l'intention d'attaquer Dyn. Les fabricants d'appareils n'avaient peut-être pas imaginé leurs produits comme des éléments d'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 impacté les clients. De nombreux clients dépendaient d'un seul fournisseur pour le DNS autoritaire et ont découvert que plusieurs serveurs de noms ne signifient pas toujours une diversité de fournisseur. Les vendeurs et propriétaires d'appareils IoT avaient permis à des appareils faibles de devenir des ressources d'attaque.

Les gouvernements et les organismes de normalisation ont ensuite formulé la résilience aux botnets comme un problème de marché et d'écosystème, et pas seulement une question de punir un seul attaquant.

La leçon pratique est frappante: l'accessibilité dépend du plan de contrôle ennuyeux. Une entreprise peut construire des serveurs applicatifs redondants, plusieurs clouds, des régions actif-actif et une réponse aux incidents sophistiquée, puis néanmoins disparaître du navigateur des utilisateurs si sa dépendance au DNS autoritaire est mono-fournisseur et injoignable. La délégation DNS est un pouvoir. La traiter comme une simple ligne d'approvisionnement à faible risque, c'est ainsi qu'un service géré devient une défaillance en mode commun.