Dyn a fait du DNS géré une 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é. Son communiqué officiel a indiqué que la première vague a commencé vers 7 h 00, heure de l'Est, a affecté les utilisateurs dirigés vers les serveurs Dyn sur la côte Est des États-Unis et a été atténuée environ deux heures plus tard. Une deuxième vague, plus mondiale, 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 vague tentée a été atténuée sans impact client.
• Observé:ThousandEyes a mesuré des taux élevés d'échec de requêtes DNS depuis ses points d'observation globaux et a signalé qu'environ 75 % de ses points d'observation ont envoyé des requêtes qui sont restées sans réponse par les serveurs 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 constaté que de nombreux clients vulnérables n'utilisaient que des serveurs de noms Dyn plutôt que plusieurs fournisseurs DNS.
• Attribution encadrée:Dyn a déclaré que l'analyse de Flashpoint et Akamai a confirmé qu'une source du trafic était des appareils infectés par Mirai. Le DOJ a ensuite annoncé des plaidoyers de culpabilité des créateurs de Mirai et un plaidoyer de culpabilité distinct d'un individu dont l'attaque de botnet variante de Mirai du 21 octobre 2016 a impacté Dyn et rendu des sites comme Sony, Twitter, Amazon, PayPal, Tumblr, Netflix et la Southern New Hampshire University inaccessibles ou intermittents pendant plusieurs heures. Le dossier public ne prouve 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 en mode commun. Dyn contrôlait sa plateforme DNS géré, ses partenaires d'atténuation, ses communications et son architecture d'infrastructure. Les clients contrôlaient si le DNS faisant autorité était diversifié entre les fournisseurs et si les pratiques de TTL, de basculement et de surveillance correspondaient à leurs propres revendications de disponibilité. Les fournisseurs d'IoT, les propriétaires, les FAI, les régulateurs et les attaquants contrôlaient des parties distinctes du problème des botnets.

Registre des preuves et leur utilisation

Cet article utilise le communiqué officiel de Dyn, les mesures DNS indépendantes, les dossiers du DOJ, les normes DNS, la recherche en sécurité, les conseils DDoS et le contexte du marché comme preuves superposées. Le 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 fait généralement l'expérience du DNS que lorsqu'il tombe en panne. Le nom du site semble normal. Le navigateur fonctionne. La connexion de l'utilisateur est peut-être saine. L'application de destination peut encore être en cours d'exécution. Pourtant, si le chemin DNS faisant autorité ne peut pas répondre, le service peut disparaître comme si les serveurs eux-mêmes avaient disparu. C'est ce qui a rendu l'incident Dyn si désorientant. De nombreux services n'étaient pas nécessairement en panne au niveau de leur propre application.

Leurs noms ne pouvaient pas être résolus de manière 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 ont externalisé le DNS faisant autorité vers un fournisseur géré parce que ce fournisseur pouvait offrir une portée mondiale anycast, une orientation du trafic, une expertise opérationnelle et une préparation 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 de mauvaises voies de mise à jour.

Mirai a converti ce deuxième choix d'externalisation en trafic d'attaque contre le premier.

Le communiqué officiel de Dyn, conservé dans une copie PDF publique duDyn Statement on 10/21/2016 DDoS Attack, indiquait que la société avait subi des attaques DDoS contre son infrastructure DNS géré. Il décrivait une première vague commençant vers 7 h 00, heure de l'Est, une restauration environ deux heures plus tard, une deuxième vague plus mondiale juste avant midi, une restauration vers 13 h 00, et une troisième vague tentée que Dyn a déclaré avoir atténuée sans impact client. Dyn a également déclaré n'avoir subi aucune panne généralisée à aucun moment, et que certains utilisateurs, comme ceux accédant aux sites affectés depuis la côte Ouest des États-Unis pendant la première vague, auraient réussi.

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 du résolveur, la durée de vie, 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 voir un succès tandis que les utilisateurs ailleurs voyaient 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 qu'une réponse DNS mise 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, fournit l'explication publique la plus claire de la dépendance côté client. Sa surveillance a vu trois phases: un impact initial concentré sur la côte Est des États-Unis, un impact mondial plus large, et plus tard une atténuation avec des attaques persistantes ou du blackholing. Au plus fort de l'attaque, environ trois quarts de ses points d'observation globaux ont envoyé des requêtes DNS qui sont restées sans réponse par les serveurs Dyn. Il 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 exécutait des serveurs faisant autorité pour les domaines clients. Si un résolveur n'avait pas déjà une réponse mise en cache fraîche et ne pouvait pas joindre les serveurs faisant autorité de Dyn, il ne pouvait pas obtenir l'adresse nécessaire pour se connecter. Des valeurs de durée de vie plus courtes peuvent rendre la gestion du trafic plus agile en fonctionnement normal, mais elles rendent également les utilisateurs plus dépendants d'une résolution réussie et fréquente de l'autorité. Un TTL faible 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 redemander à 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 statique. Il aidait les grands services à acheminer 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 attractif en tant que plan de contrôle partagé.

La découverte la plus importante de ThousandEyes pour la responsabilité était l'architecture client. De nombreux clients affectés de Dyn n'utilisaient que les serveurs de noms Dyn plutôt que de se diversifier entre plusieurs fournisseurs DNS. L'analyse contrastait les clients avec un seul fournisseur DNS géré avec Amazon.com, qui utilisait plus d'un fournisseur et subissait des temps de chargement plus lents plutôt que la même indisponibilité complète observée par beaucoup d'autres. Cela ne signifie pas que chaque client aurait pu activer le DNS multi-fournisseur du jour au lendemain.

Cela signifie que le risque était architectural, visible et partiellement contrôlé par les clients.

Lereportage de l'AP repris par le Chicago Sun-Timesa capturé l'expérience publique: des effets en cascade 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. Lerapport contemporain du Guardiana listé Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News et des 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 constituent pas une preuve 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 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 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.

RFC 2182dit 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 inaccessible, et que les serveurs secondaires doivent être géographiquement et topologiquement dispersés. Il met en garde contre les configurations où tous les serveurs partagent le même mode de défaillance local. En langage ordinaire: plusieurs serveurs de noms ne suffisent pas s'ils tombent en panne ensemble.

Le cas Dyn a traduit ce principe de l'emplacement physique à la dépendance vis-à-vis du fournisseur. Un client pouvait lister plusieurs serveurs de noms Dyn et avoir encore un fournisseur, une relation commerciale, un chemin de support opérationnel, un ensemble d'identifiants de gestion DNS et une exposition à une attaque majeure contre 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 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 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 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 traités comme des résultats de recherche dans un ensemble de données spécifique, et non comme un recensement exact de l'ensemble d'Internet. Néanmoins, ils soutiennent la leçon pratique. Le DNS rendait la diversification des fournisseurs possible, mais de nombreux clients avaient choisi la simplicité opérationnelle plutôt que l'indépendance face aux défaillances. Ce n'est pas irrationnel.

Le DNS faisant autorité multi-fournisseurs introduit de la complexité: données de zone cohérentes, signature DNSSEC et gestion des clés, comportement des vérifications de santé, 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 la non-diversification peut également devenir réel, et peut arriver 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 de sorte que le routage Internet puisse envoyer un résolveur vers une instance proche ou préférée. Cela améliore la latence et absorbe de nombreuses défaillances 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 aussi distribuer la pression de l'attaque. Si l'attaque est suffisamment grande, large ou ciblée de manière à congestionner les liens montants, le peering ou les préfixes partagés, les emplacements anycast peuvent tomber en panne ensemble ou flapper de manière complexe. ThousandEyes a observé que de nombreuses requêtes ne pouvaient pas passer par les fournisseurs de services Internet de Dyn ou par le bord du réseau de Dyn, 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 ».

Le communiqué de Dyn a déclaré qu'elle pratiquait des scénarios, avait des playbooks, utilisait des partenaires d'atténuation et avait initié la gestion d'incident et les communications avec les clients. Il a également déclaré que les attaques étaient hautement distribuées, impliquaient des dizaines de millions d'adresses IP distinctes associées à Mirai et utilisaient de multiples vecteurs et emplacements Internet. Un fournisseur ne doit pas être jugé comme si l'atténuation DDoS était une simple question d'achat de bande passante suffisante.

Les attaques distribuées très importantes créent des erreurs de mesure, des tempêtes de nouvelles tentatives, un trafic collatéral, une instabilité de routage et des compromis difficiles entre le filtrage du trafic d'attaque et la préservation des requêtes légitimes.

Néanmoins, les clients achètent du DNS géré parce que le fournisseur revendique une expertise dans exactement ce domaine d'exploitation. Dyn possédait donc le côté fournisseur de la résilience: planification de capacité, coordination avec les fournisseurs en amont, architecture anycast, conception de la constellation de serveurs de noms, communication d'état, support client, préparation des partenaires d'atténuation et preuves post-incident. Un récit de responsabilité équitable peut tenir les deux idées à la fois. L'attaque était malveillante et de grande envergure.

Le métier de Dyn était de maintenir le DNS faisant autorité accessible dans des conditions hostiles.

Mirai a transformé le risque des appareils grand public en infrastructure

Mirai a rendu l'attaque culturellement mémorable parce que le botnet était construit en grande partie à partir d'appareils ordinaires connectés à Internet: caméras, routeurs, enregistreurs vidéo numériques et autres systèmes embarqués. L'articleUSENIX Understanding the Mirai Botnetdécrit Mirai comme composé principalement d'appareils embarqués et IoT et dit 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 du ministère de la Justice de 2017 sur Mirai,Justice Department Announces Charges and Guilty Pleas in Three Computer Crime Cases Involving Significant DDoS Attacks, a déclaré que Paras Jha, Josiah White et Dalton Norman avaient plaidé coupables pour avoir exploité 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 du ministère de la Justice de 2020,Individual Pleads Guilty to Participating in Internet-of-Things Cyberattack in 2016, a relié un botnet variante de Mirai à la journée Dyn plus directement. Elle a déclaré 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 hors ligne le PlayStation Network de Sony; les attaques ont impacté Dyn, ce qui a rendu des sites comme Sony, Twitter, Amazon, PayPal, Tumblr, Netflix et la 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 seule cause de chaque 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 de multiples 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 d'activité criminelle est distincte de la couche d'architecture de résilience.

L'alerte CISA sur la menace Miraiavertissait que le malware Mirai recherchait des appareils IoT vulnérables et que la publication publique du code source de Mirai augmentait le risque de botnets supplémentaires. Le rapport ultérieur 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 cadré 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 devraient être sécurisés tout au long de leur cycle de vie, les incitations sont mal alignées et aucune communauté d'acteurs seule ne peut résoudre le problème.

Ce cadrage écosystémique correspond mieux à l'incident Dyn qu'une histoire de blâme étroite. Les attaquants ont abusé d'appareils qu'ils ne possédaient pas. Les fabricants d'appareils avaient souvent expédié 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 et des limites pratiques mitigées.

Les fournisseurs DNS ont vu l'attaque lorsqu'elle a atteint leur périmètre. 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.

LaNISTIR 8259A IoT Device Cybersecurity Capability Core Baselineultérieure n'existait pas en 2016 et ne doit pas être traitée comme une obligation légale rétroactive pour Dyn. Elle est toujours utile comme preuve de ce que l'écosystème a appris à valoriser: identification de l'appareil, configuration sécurisée, protection des données, accès logique, capacité de mise à jour logicielle, conscience de l'état de cybersécurité et documentation. Mirai a réussi parce que trop d'appareils ne pouvaient pas être gérés comme des entités Internet responsables.

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 avec une équipe d'infrastructure approfondie pouvait exécuter plusieurs fournisseurs faisant autorité, héberger elle-même une partie de la pile, maintenir l'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 exécuter 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 de dépendances. Une entreprise qui considère l'accessibilité en ligne comme critique pour sa mission doit savoir si un seul fournisseur DNS géré est un point de défaillance unique.

Elle doit savoir à quelle vitesse elle peut changer la délégation chez le registrar, 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 d'incident public.

Pour les petites organisations, la réponse pratique peut ne pas être une architecture multi-fournisseur 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 le cas échéant, des identifiants de registrar disponibles pour plus d'une personne de confiance, des pages de statut hors bande, des coordonnées d'urgence mises en cache et une surveillance qui distingue l'échec de résolution DNS de l'échec de l'application.

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 un fournisseur.

Le risque s'étend également aux utilisateurs en aval. Une marketplace, 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 profonde est le DNS, le DDoS, l'hébergement cloud, le routage FAI ou un bug d'application. 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'à ce que la résolution de noms revienne.

La communication devait servir deux publics

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

Le communiqué de Dyn a donné un récit prudent du fournisseur: pas de panne généralisée, variable régionalement, deux vagues avec impact client, une troisième vague tentée atténuée, gestion d'incident activée, partenaires d'atténuation 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 d'atténuation complet pendant une attaque active ou reproductible.

Pourtant, les clients avaient besoin de plus que des paroles rassurantes. Ils avaient besoin d'un soutien à la décision. Doivent-ils changer immédiatement de fournisseur DNS? Doivent-ils modifier les TTL? Doivent-ils communiquer des avis de panne aux clients finaux? 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 devait-il se reproduire? Plus un fournisseur se vend comme infrastructure Internet, plus sa communication d'état fait 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 être en retard ou simplifiée. Les vérifications d'application propres du client peuvent manquer l'échec DNS si elles s'exécutent depuis un réseau avec des caches chauds. La surveillance devrait tester la recherche faisant autorité, la résolution récursive depuis plusieurs régions, l'accessibilité de l'application et l'échec spécifique à la dépendance.

L'analyse publique de ThousandEyes a été puissante parce qu'elle a séparé l'échec de requête DNS du sentiment général de l'utilisateur que « Internet est en panne ».

Les caches, les nouvelles tentatives et la préparation ont façonné l'ampleur du dommage

L'échec DNS n'est pas vécu de manière uniforme car 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 valide mise en cache, un utilisateur peut continuer à atteindre un service même pendant que les serveurs faisant autorité sont dégradés. Si la réponse mise 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 temporisations 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 voir une santé normale. Un fournisseur de DNS géré peut voir un mélange de trafic d'attaque, de nouvelles tentatives légitimes de résolveurs, d'effets de cache obsolète 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 voient une accessibilité intermittente et peuvent supposer que l'application est en panne.

Le récit public devient « les grands sites Web sont en panne », tandis que la réalité technique ressemble plus à « certains résolveurs ne peuvent pas obtenir ou rafraîchir les réponses faisant autorité pour certains domaines pendant certaines fenêtres ».

Lecoup d'œil rapide de RIPE Labs sur l'attaque Dyna utilisé les mesures RIPE Atlas pour observer l'événement depuis des sondes distribuées. Une note compagnon de RIPE Labs,Speculating on DNS DDoS, a souligné que le trafic de nouvelle tentative récursive peut aggraver l'impact et qu'il peut être difficile de distinguer le trafic DNS légitime du trafic d'attaque pendant un DDoS au niveau du protocole DNS. Ce ne sont pas des jugements juridiques sur Dyn. Ils expliquent pourquoi l'atténuation des DDoS DNS est plus complexe que le blocage d'une seule source hostile ou l'ajout d'un seul serveur de secours.

La recherche après l'incident a fait le même point 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 très différemment. 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 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 DNS géré, cela signifie que la préparation doit inclure plus qu'un nom de fournisseur dans un registre des risques. Le client doit savoir quels enregistrements sont suffisamment stables pour une durée de vie en cache plus longue, quels enregistrements nécessitent une orientation dynamique, quels résolveurs récursifs sont importants pour ses utilisateurs et comment des réponses obsolètes pourraient affecter un basculement. Il doit également décider si un changement de TTL d'urgence est utile avant un incident ou surtout symbolique après que les caches contiennent déjà l'ancienne valeur.

Les changements DNS sont dépendants 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 conseils du National Cyber Security Centre du Royaume-Uni,Denial of Service guidance collection, cadre 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 page de la CISA,Understanding Denial-of-Service Attacks, explique le problème de base de la disponibilité: les utilisateurs légitimes ne peuvent pas accéder aux systèmes d'information, aux appareils 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 avancée, d'une coordination avec les fournisseurs de services, de bases de référence du 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 entreprise. 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 marketplace, 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 obsolètes et une perte d'accessibilité régionale.

Le plan de continuité du client doit traduire l'état du fournisseur en décisions commerciales: informer les utilisateurs, changer de canaux, suspendre les transactions, fail open, fail closed, ou accepter une accessibilité partielle jusqu'à ce que le DNS se stabilise.

Pour Dyn, le même principe de préparation va dans la direction opposée. Un fournisseur de 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 client simultanée. 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 playbooks du fournisseur doivent donc inclure l'atténuation, 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 la 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 se produit 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

Le dossier public établit une activité DDoS malveillante, une perturbation du service Dyn, des problèmes d'accessibilité des clients, l'implication de Mirai et des plaidoyers de culpabilité ultérieurs. Il n'établit pas que Dyn a violé un contrat spécifique, que chaque client affecté manquait d'architecture raisonnable, que chaque fabricant d'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 des clients, des polices d'assurance et des dépendances tierces ne sont pas publics d'une manière qui soutient 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 des fournisseurs DNS et la planification de la continuité. Les fournisseurs d'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 rendaient pratique. Les FAI et les sociétés 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 appartient à l'analyse de responsabilité parce qu'aucune couche unique ne pouvait résoudre l'ensemble de la défaillance. Un client DNS multi-fournisseur parfait pourrait encore souffrir d'un botnet massif ailleurs dans sa pile. Une gamme de produits IoT bien conçue 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 pas remplacer instantanément des millions d'appareils exposés.

La défaillance de mode commun a émergé de l'ajustement entre ces couches.

Le signal post-incident du marché

Un mois après l'attaque, Oracle a annoncé qu'elle avait convenu d'acquérir Dyn. Le communiqué de presse d'Oracle,Oracle buys Dyn, décrivait Dyn comme un fournisseur leader de performance Internet et de DNS géré basé sur le cloud, indiquait que son réseau générait 40 milliards de décisions d'optimisation du trafic quotidiennement pour plus de 3 500 clients entreprises, 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 l'a pas dit. Elle est toujours un contexte utile pour le rôle de Dyn sur le marché. Ce n'était pas un service de niche pour amateurs. C'était une plateforme DNS géré majeure pour des entreprises numériques de premier plan.

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

Le rapport de 2018 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 mono-fournisseur est plus simple à acheter, configurer, surveiller et supporter. Le DNS multi-fournisseur 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 être puni en temps normal.

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

Tests pratiques de responsabilité

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

Dépendance 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 région majeure?

Indépendance du fournisseur:Existe-t-il un deuxième fournisseur DNS faisant autorité avec des données de zone actuelles? 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 d'atténuation DDoS? Sinon, l'organisation a-t-elle consciemment accepté le risque de fournisseur unique?

Stratégie TTL et cache:Les TTL DNS reflètent-ils le besoin réel de l'organisation en matière d'agilité par rapport à la tolérance aux pannes? Les enregistrements les plus stables ont-ils une durée de vie en cache suffisante pour réduire la dépendance évitable aux interrogations fréquentes des autorités en cas de problème transitoire chez le fournisseur?

DNSSEC et contrôle des modifications:Si DNSSEC est activé, les signatures, les clés et les enregistrements DS peuvent-ils survivre à un fonctionnement multi-fournisseur 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 une défaillance DNS faisant autorité, des problèmes de résolveur récursif, des problèmes de CDN, une défaillance d'origine et une défaillance d'application? 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 chez le registrar:Les identifiants du registrar, 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 pas utile si personne ne peut changer la délégation en toute sécurité.

Communications avec le fournisseur:Le fournisseur de 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 canaux 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 la flotte d'appareils de devenir la capacité DDoS de quelqu'un d'autre?

Ces tests ne sont pas une pureté d'ingénierie abstraite. C'est ainsi qu'un propriétaire de domaine apprend si « nous avons des serveurs de noms redondants » signifie une véritable indépendance face aux défaillances ou simplement plusieurs noms d'hôte au sein d'une dépendance à un seul 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é du DNS est difficile, spécialisée et mondialement exposée. De nombreux clients seraient moins résilients s'ils étaient contraints d'exploiter 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 chez un fournisseur et exige ensuite que le client décide si le fournisseur est un composant ou une dépendance de mode commun.

Mirai non plus n'a pas 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 grande pour menacer des services essentiels. Les foyers et les entreprises qui possédaient ces appareils n'avaient pas l'intention d'attaquer Dyn. Les vendeurs d'appareils n'avaient peut-être pas imaginé leurs produits comme des pièces d'infrastructure Internet. Mais l'Internet public en a fait des entités quand même.

La mémoire responsable de l'incident Dyn devrait donc être superposé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 quand même subi des perturbations affectant 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 d'IoT et les propriétaires avaient permis à des appareils faibles de devenir des ressources d'attaque.

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

La leçon pratique est crue: 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 sophistiquée aux incidents, puis disparaître des navigateurs des utilisateurs si sa dépendance DNS faisant autorité est mono-fournisseur et inaccessible. La délégation DNS est un pouvoir. La traiter comme une ligne d'approvisionnement à faible risque est la façon dont un service géré devient une défaillance de mode commun.