Dyn: l'externalisation DNS, 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é. Son communiqué public indiquait que la première vague avait commencé vers 7 h 00, heure de l'Est, touchant les utilisateurs dirigés vers les serveurs Dyn de la côte Est des États-Unis, et qu'elle 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 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. L'entreprise 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 utilisaient uniquement les serveurs de noms de Dyn plutôt que plusieurs fournisseurs DNS.
• Attribution limitée:Dyn a indiqué que les analyses de Flashpoint et Akamai confirmaient qu'une partie du trafic provenait d'appareils infectés par Mirai. Le ministère de la Justice américain a annoncé plus tard des plaidoiries de culpabilité des créateurs de Mirai et une plaidoirie séparée d'un individu dont le botnet utilisant une variante de Mirai avait, le 21 octobre 2016, affecté 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 subi par Dyn 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 l'architecture de son infrastructure. Les clients contrôlaient la diversification du DNS faisant autorité entre plusieurs fournisseurs et l'adéquation des pratiques de TTL, de basculement et de surveillance avec leurs propres déclarations de disponibilité. Les fournisseurs d'IdO, les propriétaires d'appareils, les FAI, les régulateurs et les attaquants contrôlaient chacun une partie distincte du problème du botnet.

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 est peut-être saine. L'application de destination est peut-être toujours 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 é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 couche applicative.

Leurs noms ne pouvaient tout simplement pas être résolus de manière assez fiable pour que les utilisateurs puissent les atteindre.

L'incident d'octobre 2016 se situe à l'intersection de deux formes d'externalisation. D'une part, de nombreuses entreprises numériques avaient externalisé leur DNS faisant autorité auprès d'un fournisseur géré, car celui-ci pouvait offrir une portée anycast mondiale, un pilotage du trafic, une expertise opérationnelle et une préparation aux DDoS que beaucoup de clients ne pouvaient pas construire seuls de manière économique.

D'autre part, 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 insuffisants. Mirai a converti ce deuxième choix d'externalisation en trafic d'attaque contre le premier.

Le communiqué de Dyn, conservé dans une copie PDF publique duCommuniqué 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é. Il décrivait une première vague commençant vers 7 h 00, 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 13 h 00, et une troisième tentative de vague que Dyn a déclaré avoir atténuée sans impact sur les clients. Dyn a également précisé n'avoir subi à aucun moment une panne à l'échelle du système, et que certains utilisateurs, comme ceux qui accédaient aux sites affectés depuis la côte Ouest des États-Unis pendant la première vague, auraient pu le faire avec succès.

Ce détail est important. L'incident n'était pas une panne binaire nette où chaque client de Dyn disparaissait partout. Il s'agissait d'une défaillance de disponibilité façonnée par la géographie, l'anycast, le comportement des résolveurs, le TTL, la configuration du domaine du 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 malgré tout 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,L'attaque DDoS contre l'infrastructure DNS de Dyn, fournit l'explication publique la plus claire de la dépendance côté client. Sa surveillance a identifié trois phases: un impact initial concentré sur la côte Est des États-Unis, un impact mondial plus large, puis une atténuation avec des attaques persistantes ou du blackholing. Au plus fort de l'attaque, environ les trois quarts de ses points d'observation mondiaux ont envoyé des requêtes DNS restées sans réponse des serveurs de Dyn. Il a également fait état d'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 faisant autorité pour les domaines de ses clients. Si un résolveur n'avait pas déjà une réponse en cache valide 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 TTL plus courtes peuvent rendre la gestion du trafic plus agile en fonctionnement normal, mais elles rendent également les utilisateurs plus dépendants de résolutions faisant autorité réussies. Un TTL bas n'est pas mauvais en soi; c'est un compromis.

Lors d'un événement DDoS touchant un fournisseur DNS, cela peut réduire 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 le pilotage du trafic. Le DNS géré n'était pas simplement un annuaire statique. Il aidait les grands services à acheminer les utilisateurs vers les 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 il devenait attractif en tant que plan de contrôle partagé.

La conclusion la plus importante de ThousandEyes pour la responsabilité concernait l'architecture des clients. De nombreux clients de Dyn affectés utilisaient uniquement les serveurs de noms de Dyn plutôt que de diversifier entre plusieurs fournisseurs DNS. L'analyse opposait les clients ayant un seul fournisseur de DNS géré à Amazon.com, qui utilisait plus d'un fournisseur et avait subi des temps de chargement plus lents plutôt que la même indisponibilité totale observée par beaucoup d'autres. Cela ne signifie pas que chaque client aurait pu 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'AP relayé par le Chicago Sun-Timesa rendu compte de l'expérience publique: des répercussions pour les utilisateurs essayant d'atteindre des sites web populaires aux États-Unis et en Europe, Twitter, Netflix et le PlayStation Network de Sony figurant parmi les services apparemment touchés. Lerapport contemporain du Guardiana 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 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 en mode commun se cache dans un DNS « redondant »

Le DNS intègre de la redondance 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 en cas de panne.

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 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 local. En langage courant: plusieurs serveurs de noms ne suffisent pas s'ils échouent ensemble.

Le cas Dyn a transposé ce principe de la localisation physique à la dépendance envers le fournisseur. Un client pouvait lister plusieurs serveurs de noms Dyn tout en ayant 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 envers un fournisseur.

L'étudeThe Lack of Redundancy in DNS Resolution by Major Websites and Servicesa examiné la concentration et la diversification du DNS après l'incident Dyn. Elle a constaté une concentration croissante autour d'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'Internet dans son ensemble. Néanmoins, ils confirment la leçon pratique. Le DNS rendait possible la diversification des fournisseurs, pourtant de nombreux clients avaient choisi la simplicité opérationnelle plutôt que l'indépendance face aux pannes. Ce n'est pas irrationnel.

Un DNS faisant autorité multi-fournisseurs introduit de la complexité: cohérence des données de zone, signature DNSSEC et gestion des clés, comportement des vérifications de santé, différences de pilotage 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 contre Dyn a montré que le coût de la non-diversification 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 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 orienter un résolveur vers une instance proche ou préférée. Cela améliore la latence et absorbe de nombreuses pannes locales car le trafic peut se déplacer dans le 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 répartir le trafic, mais il peut aussi répartir la pression de l'attaque. Si l'attaque est suffisamment volumineuse, étendue ou ciblée de manière à congestionner les liaisons en amont, le peering ou les préfixes partagés, les emplacements anycast peuvent échouer ensemble ou basculer de manière complexe. ThousandEyes a observé que de nombreuses requêtes ne parvenaient pas à traverser les fournisseurs d'accès à Internet de Dyn ou la périphérie du réseau de Dyn, et que les serveurs de noms au sein d'une même constellation et d'un même groupe montraient une performance corrélée.

Cette observation ne prouve pas que la conception interne de Dyn était négligente. Elle montre pourquoi « avoir plusieurs points de présence » n'est pas la même chose qu'« avoir une disponibilité indépendante dans toutes les conditions DDoS plausibles ».

Le communiqué de Dyn indiquait qu'il pratiquait des scénarios, disposait de manuels opérationnels, utilisait des partenaires d'atténuation et avait lancé la gestion de l'incident et les communications avec les clients. Il 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 l'atténuation des DDoS était une simple affaire 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 détenait 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 l'état, support client, préparation des partenaires d'atténuation et preuves post-incident. Un compte rendu de responsabilité équitable peut contenir les deux idées à la fois. L'attaque était malveillante et de grande ampleur.

L'activité de Dyn était de maintenir le DNS faisant autorité joignable dans des conditions hostiles.

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

Mirai a rendu l'attaque culturellement mémorable car 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 l'USENIXUnderstanding the Mirai Botnetdécrit Mirai comme étant composé principalement d'appareils embarqués et d'IdO, 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 du ministère de la Justice de 2017 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 opéré le botnet Mirai, qui ciblait les appareils IdO tels que les caméras sans fil, les routeurs et les enregistreurs vidéo numériques. Le DOJ a précisé que Mirai comptait des 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, selon le DOJ, d'autres acteurs ont 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, reliait plus directement un botnet utilisant une variante de Mirai à la journée de l'attaque 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 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 affecté 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 cause unique de chaque impact sur Dyn, ni que l'ensemble du trafic de Dyn ce jour-là provenait d'un seul botnet. Dyn lui-même a déclaré qu'une source du trafic d'attaque provenait d'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 du comportement criminel est distincte de la couche de l'architecture de résilience.

L'alerte de la CISA sur la menace Miraiavertissait que le malware Mirai recherchait activement les appareils IdO vulnérables et que la publication du code source de Mirai augmentait le risque de nouveaux botnets. 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, cadrait 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 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 convient mieux à l'incident Dyn qu'un récit étroit de blâme. Les attaquants ont abusé d'appareils qu'ils ne possédaient pas. Les fabricants d'appareils avaient souvent commercialisé 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.

Le document ultérieurNISTIR 8259A IoT Device Cybersecurity Capability Core Baselinen'existait pas en 2016 et ne doit pas être traité comme une obligation juridique rétroactive pour 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, 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 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 ce contrôle n'était pas égal entre tous les clients. Une grande plateforme disposant d'une équipe d'infrastructure étoffée pouvait opérer 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, association à 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 encore décider quel niveau de défaillance du fournisseur ils peuvent tolérer. La question n'est pas « chaque site web devrait-il exploiter un réseau DNS mondial sur mesure? » Ce serait absurde économiquement. La question est de savoir si les promesses de disponibilité du client correspondent à sa carte de dépendances. Une entreprise qui considère la joignabilité 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 changer la délégation au niveau du registraire, combien de temps les enregistrements NS en cache resteront valides, si un fournisseur secondaire dispose d'une zone à jour, si la validation DNSSEC continuera de fonctionner, 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 restreint: 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 registraire accessibles à plus d'une personne de confiance, des pages d'état hors bande, des informations de contact d'urgence en cache et une surveillance qui distingue les échecs de résolution DNS des défaillances applicatives.

C'est moins élégant qu'une 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 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 racine est le DNS, une DDoS, l'hébergement cloud, le routage du FAI ou un bug 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'à ce que la résolution de noms reprenne.

La communication devait servir deux publics

Dyn avait deux problèmes de communication. Il devait informer ses clients directs de ce qui se passait et de ce à quoi ils pouvaient s'attendre. Il devait également communiquer avec la communauté Internet au sens large, car 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 ciblée de plateforme, une instabilité plus large de l'Internet, une urgence de botnet ou un problème de concentration du DNS.

Le communiqué de Dyn donnait un récit prudent du fournisseur: pas à l'échelle du système, variable selon les régions, deux vagues avec impact client, une troisième tentative de vague atténuée, la gestion de l'incident activée, les partenaires d'atténuation impliqués, Mirai confirmé comme une source de trafic, et d'autres détails non divulgués pour préserver les défenses futures. Cet équilibre est défendable. Un fournisseur de services de protection DDoS ne devrait pas publier un plan complet d'atténuation pendant une attaque active ou susceptible de se reproduire.

Pourtant, les clients avaient besoin de plus que de simples assurances. Ils avaient besoin d'aide à la décision. Devraient-ils changer immédiatement de fournisseur DNS? 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? S'attendait-on à ce que le problème se reproduise?

Plus un fournisseur se vend 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 la situation. 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 encore chauds. La surveillance devrait tester la résolution faisant autorité, la résolution récursive depuis plusieurs régions, la joignabilité applicative et les défaillances spécifiques à la dépendance.

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

Les caches, les nouvelles tentatives et la préparation ont modifié l'ampleur des dégâts

L'échec du DNS n'est pas ressenti uniformément car la couche récursive se situe entre les utilisateurs et les fournisseurs faisant autorité. Si un résolveur récursif dispose déjà d'une réponse en cache valide, un utilisateur peut continuer à atteindre un service même si 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 injoignable depuis ce réseau. Deux utilisateurs situés dans la même ville peuvent donc signaler des résultats différents car leurs résolveurs, leurs caches et le moment de leurs requêtes diffèrent.

Ce comportement complique à la fois l'attribution des responsabilités et la réponse. Un propriétaire de service peut consulter ses serveurs d'origine et constater un état de santé normal. Un fournisseur de DNS géré peut voir un mélange de trafic d'attaque, de nouvelles tentatives légitimes des résolveurs, d'effets de cache obsolète et de changements de route. Les opérateurs de résolveurs récursifs peuvent augmenter la pression des requêtes en réessayant lorsque les réponses expirent. Les utilisateurs voient une joignabilité 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 ressemble davantage à « certains résolveurs ne peuvent pas obtenir ou rafraîchir les réponses faisant autorité pour certains domaines pendant certaines fenêtres de temps ».

Lecoup d'œil rapide sur l'attaque contre Dynde RIPE Labs a utilisé les mesures de RIPE Atlas pour observer l'événement depuis des sondes distribuées. Une note complémentaire de RIPE Labs,Speculating on DNS DDoS, 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'une DDoS utilisant le protocole DNS. Il ne s'agit pas de jugements juridiques sur Dyn. Ils expliquent pourquoi l'atténuation des DDoS DNS est plus compliquée que le simple blocage d'une source hostile unique ou l'ajout d'un serveur de secours unique.

Des recherches postérieures à l'incident ont 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 les DDoS de manière très différente. L'article utilise l'incident Dyn comme exemple d'une panne visible affectant des domaines utilisant Dyn comme fournisseur DNS, tout en notant que d'autres cibles DNS, comme les serveurs racine, ont 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 simple 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 un pilotage 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 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 guides généraux sur les DDoS renforcent la même discipline opérationnelle. Lacollection de guides sur le déni de servicedu National Cyber Security Centre britannique 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. L'Understanding Denial-of-Service Attacksde la CISA explique le problème fondamental de disponibilité: les utilisateurs légitimes ne peuvent pas accéder aux systèmes d'information, aux appareils ou aux ressources réseau. Le document 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 révèlent une vérité inconfortable sur les dépendances cloud. Un client peut externaliser l'exploitation du DNS, mais il ne peut pas externaliser la connaissance de la manière dont une défaillance DNS affecte sa propre activité. Dyn pouvait atténuer les attaques contre 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 vidéo et un portail de rendez-vous hospitaliers ont des tolérances différentes pour une résolution lente, des réponses obsolètes et une perte de joignabilité régionale.

Le plan de continuité du client doit traduire l'état du fournisseur en décisions métier: informer les utilisateurs, basculer vers d'autres canaux, suspendre les transactions, ouvrir en cas d'échec, fermer en cas d'échec, ou accepter une joignabilité 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 à 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 saturant le support.

Les manuels opérationnels 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é préjudiciable 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é de l'IdO comprenaient les risques des identifiants par défaut et des flottes d'appareils non gérées. 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 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 de joignabilité pour les clients, l'implication de Mirai et des plaidoiries de culpabilité ultérieures. Il n'établit pas que Dyn a violé un contrat spécifique, que chaque client affecté manquait d'une architecture raisonnable, que chaque fabricant d'IdO a violé une obligation légale, ni 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 avec les clients, des polices d'assurance et des dépendances de tiers ne sont pas publics d'une manière qui étaye des conclusions juridiques générales.

Cette frontière ne doit pas affaiblir la leçon opérationnelle. Elle la rend plus claire. La faute juridique dépend de la juridiction compétente. 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 d'IdO 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 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é car aucune couche ne pouvait à elle seule remédier à l'ensemble de la défaillance. Un client parfait avec un DNS multi-fournisseurs pourrait tout de même souffrir d'un botnet massif ailleurs dans sa pile. Une gamme de produits IdO bien conçue ne diversifierait pas le DNS faisant autorité d'un client. Un brillant fournisseur DNS pourrait tout de même 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 en mode commun est née de l'assemblage de ces couches.

Le signal du marché après l'incident

Un mois après l'attaque, Oracle a annoncé avoir accepté d'acquérir Dyn. Lecommuniqué de presse d'Oracledécrivait Dyn comme un fournisseur leader de performance Internet et de DNS basé 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 citait 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é n'indiquait pas cela. Cela reste un contexte utile pour le rôle de marché de Dyn. Il ne s'agissait pas d'un service de niche ou amateur. C'était une plateforme majeure de DNS géré pour des entreprises numériques de premier plan.

C'est cette position sur le marché qui fait que l'incident importe encore aujourd'hui. La concentration dans le cloud produit souvent des avantages réels: meilleure expertise, portée mondiale plus large, 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 déclarations indépendantes de continuité d'activité peuvent devenir corrélées. Une plateforme peut externaliser une fonction tout en restant propriétaire des 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 face aux botnets. Un problème d'incitation similaire existait du côté des clients du DNS géré. Le DNS à fournisseur unique est plus simple à acheter, configurer, surveiller et supporter. 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 n'être jamais pénalisé en temps normal.

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

Tests pratiques de responsabilité

Le cas Dyn propose 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 opéré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 de DNS faisant autorité 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 d'atténuation DDoS? Si non, l'organisation a-t-elle accepté consciemment le risque du fournisseur unique?

Stratégie de TTL et de cache:Les TTL DNS reflètent-ils le besoin réel de l'organisation entre agilité et 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 à des résolutions faisant autorité fréquentes lors de problèmes transitoires chez le fournisseur?

DNSSEC et contrôle des changements:Si DNSSEC est activé, les signatures, les clés et les enregistrements DS peuvent-ils survivre à une opération multi-fournisseurs ou à un changement d'urgence de fournisseur? Si ce n'est pas le cas, le repli peut échouer de manière sécurisée, ce qui signifie tout de même que les utilisateurs ne peuvent pas atteindre le service.

Surveillance:L'organisation peut-elle distinguer une défaillance du 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 applicative? Les tests sont-ils exécutés depuis suffisamment de réseaux et de régions pour détecter un problème anycast ou DNS régional?

Récupération du registraire:Les identifiants du registraire, 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 modifier en toute sécurité la délégation.

Communications avec le fournisseur:Le fournisseur de DNS géré fournit-il des détails sur l'état au niveau nécessaire pour que les clients puissent 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é de l'appareil, le signalement des vulnérabilités et le support en 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 permettent au propriétaire d'un domaine d'apprendre si « nous avons des serveurs de noms redondants » signifie une véritable indépendance face aux pannes ou simplement plusieurs noms d'hôtes à l'intérieur d'une dépendance envers un seul fournisseur.

La leçon durable

Dyn n'a pas prouvé que le DNS géré est mauvais. C'est plutôt le contraire qui 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 oblige ensuite le client à décider si ce fournisseur est un composant ou une dépendance en mode commun.

Mirai n'a pas non plus prouvé que l'IdO grand public pouvait être le seul responsable de 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 les services centraux. Les foyers et les entreprises qui possédaient ces appareils n'avaient pas l'intention d'attaquer Dyn. Les fournisseurs de ces appareils n'avaient peut-être pas imaginé leurs produits comme des éléments de l'infrastructure Internet. Mais l'Internet public en a néanmoins fait des entités.

La mémoire responsable de l'incident Dyn doit 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 tout en subissant 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 d'IdO et les propriétaires d'appareils avaient permis à des appareils faibles de devenir des ressources d'attaque.

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

La leçon pratique est brutale: la joignabilité dépend du plan de contrôle, aussi ennuyeux soit-il. Une entreprise peut construire des serveurs applicatifs 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 au DNS faisant autorité repose sur un fournisseur unique injoignable. La délégation DNS est un pouvoir. La traiter comme un simple poste d'achat à faible risque, c'est ainsi qu'un service géré devient une défaillance en mode commun.