Il y a un an, une attaque DDoS a perturbé le fonctionnement de quelques-uns des acteurs majeurs du web. Le botnet Mirai a réduit en esclavage des centaines de milliers de dispositifs IoT et perpétré des attaques visant plusieurs entités, y compris le fournisseur de DNS (Domain Name System) managé Dyn.

L’attaque de Dyn a été vécue comme un signal d’alarme appelant à renforcer la sécurité d’Internet. Pourtant l’industrie ne s’est pas réveillée pour autant.

Imaginez les serveurs DNS comme votre liste de contacts sur votre mobile. Sans cette liste, comment vous rappeler autant de numéros ? Cibler l’infrastructure DNS empêche les internautes de se connecter à leurs sites web et services habituels. L’attaque a perturbé la connexion entre les noms de domaine et les adresses IP correspondantes, rompant une connexion essentielle pour l’accès à l’information et aux contenus en ligne.

L’attaque Dyn a exposé une vulnérabilité qui n’est certes pas nouvelle, mais que peu d’entreprises avaient protégée jusque-là.

Afin de se protéger de ce type d’attaques, la solution pour les opérateurs de site web réside dans l’utilisation de plusieurs fournisseurs de DNS, en se ménageant une option de basculement chaque fois qu’une portion du système DNS est hors-service.

Après l’attaque Dyn, on aurait pu s’attendre à ce que davantage d’entreprises adoptent ce modèle de pluralité des fournisseurs DNS ; un fournisseur principal, un autre secondaire et un troisième éventuellement pour la redondance.

Je me suis demandé combien d’entreprises avaient effectivement choisi ce modèle. En me basant sur les classements Alexa des pages et du trafic web, j’ai extrait une liste des 100 premiers sites web américains. J’ai rentré cette liste dans un petit script que j’ai créé pour obtenir l’ensemble des serveurs de noms faisant autorité pour chaque domaine de la liste.

De là, j’ai pu analyser les données des domaines et de leurs serveurs de noms respectifs. J’ai découvert que 68 des 100 premiers sites web américains (ou plus des deux tiers d’après les classements Alexa) utilisent toujours un seul fournisseur DNS pour leur domaine, dont certaines directement affectées par l’attaque Dyn.

Certains des sites web affectés par l’attaque originale sont toujours hébergés auprès d’un seul fournisseur, comme le service DNS managé d’Amazon.

On peut s’étonner qu’une entreprise victime d’un DNS unique choisisse comme solution un autre fournisseur unique de DNS. Dans le cas précité, Amazon dispose d’une formidable largeur de bande passante, et comme son trafic est essentiellement sortant, elle est suffisante pour supporter les attaques entrantes. Il y a d’autres avantages encore, mais vous vous rendrez compte rapidement qu’un fournisseur unique le reste et demeure donc un point unique de défaillance. Les attaques d’API et les erreurs humaines qui provoquent des défaillances en cascade posent problème dans les grands réseaux hautement automatisés.

Qui d’autre a été affecté ?

Bien sûr, Dyn et ses clients ont été affectés. Mais d’autres dommages collatéraux ont touché les réseaux de FAI. L’anatomie de cette attaque DNS est la suivante :

– Un véritable dispositif présent sur le réseau envoie une requête de sous-domaine aléatoire ou de FQDN (Fully Qualified Domain Name).
– Ces noms d’hôtes uniques ne sont pas mis en cache sur le résolveur DNS récursif local, si bien que la requête doit transiter en amont par le nom de serveur faisant autorité. Cette tâche peut mobiliser beaucoup de ressources sur le serveur récursif quand elle s’effectue par larges vagues comme ici, si bien que les services DNS locaux sont aussi impactés pour les réseaux locaux (y compris les FAI).
– Le serveur de noms faisant autorité reçoit des requêtes pour un nombre infini de FQDN inexistants de résolveurs DNS légitimes du monde entier. Non seulement, ils sont bombardés par des requêtes à grosse volumétrie de paquets par seconde, mais ils doivent les traiter une par une.

Il faut noter que des FAI ont rapporté individuellement un impact sur leur propre infrastructure causé par les simples consultations des dispositifs à proximité. Il est donc important de protéger également les serveurs récursifs le cas échéant.

Nous ne sommes pas à l’abri d’une récidive

Même si elle ne se reproduira pas exactement de la même façon. Quand le code source de Mirai a été révélé par son auteur Anna-senpai, le paysage des menaces a encore changé. Tout à coup, tout le monde était capable de développer et déployer son propre botnet Mirai. Chacun avait le code, avec en plus les instructions pour s’en servir. On a même vu des gens proposer leurs services de configuration. Anna-senpai venait de diffuser le premier botnet IoT open source.

Bien que la quantité des dispositifs IoT connectés continue de progresser de même que le nombre des botnets Mirai, ces deux armées sont désormais divisées. Ce qui était à l’origine un botnet de 380 000 dispositifs compte à présent beaucoup plus de botnets avec un plus petit nombre de bots chacun. Des batailles entre botnets existent également, concernant Mirai, Hajime et BrickerBot.

A quoi devons-nous nous attendre ?

L’attaque de Dyn était soi-disant une attaque de l’un de ses clients. Mais que se serait-il passé si les agresseurs avaient ciblé toute l’infrastructure DNS mondiale ? Une version à grande échelle de cette attaque pourrait se produire à nouveau, à l’encontre des principaux fournisseurs DNS.

L’un des atouts de Mirai est que le trafic des attaques émane de véritables serveurs. Il est personnalisable et les hackers peuvent ajouter leurs propres vecteurs d’attaque au code.

Gartner estime qu’il y avait environ 6,4 milliards de dispositifs IoT sur Internet en 2016 et qu’il y en aura près de 20,4 milliards en 2020. Une portion de ces dispositifs sera inévitablement exploitable et utilisée pour perpétrer des attaques. Un grand nombre de développeurs de ces dispositifs ne pensent pas à la sécurité. Ils aspirent surtout à développer une interface utilisateur agréable et fonctionnelle sur un système consommant peu de ressources (stockage, CPU, mémoire, etc.).

Quelle est la meilleure solution ?

Les opérateurs de sites web doivent continuer à penser à l’impact de la disponibilité sur tous les aspects de leur présence en ligne, y compris DNS.

Tout d’abord, il faut tenir compte des menaces et des vulnérabilités les plus évidentes. Bien sûr, des fournisseurs DNS redondants seraient utiles. Il y a une raison pour que le protocole autorise plusieurs serveurs DNS dans une zone, mais la question de la pluralité des fournisseurs DNS est toujours en suspens.

Dans un second temps, les attaques peuvent provenir de l’endroit où vous vous y attendez le moins. Combien d’entre nous ont déjà imaginé qu’un jour une armée de botnets de caméras IP casserait l’Internet ?

Certaines entreprises directement affectées par l’attaque Dyn ont pris la décision de ne conserver qu’un seul fournisseur. Elles ont fait d’autres modifications et je peux comprendre pourquoi. Elles ont déterminé que c’était la meilleure solution pour leur réseau. D’autres entreprises ont choisi de diversifier leurs fournisseurs pour augmenter leur résilience.

Mais 32 seulement des 100 premiers sites web américains font appel à plusieurs fournisseurs DNS si bien que le risque perdure pour les 68 restants. Même si le réseau du fournisseur DNS est robuste et qu’il inclut la protection DDoS, le fait qu’il soit unique implique des risques.

Et demain ?

Au sein de l’écosystème connecté actuel, la sécurité traditionnelle n’est plus à la hauteur des actuelles infrastructures opérationnelles automatisées. Notre taux de connectivité, le rythme du changement et l’évolution sont exponentiels. C’est aussi là que réside notre plus grande vulnérabilité.

Continuez de réfléchir aux conditions de la protection de votre propre infrastructure en ligne et rappelez-vous qu’il y a un an, l’Internet a en grande partie été pris par surprise par cette attaque. Vous ne verrez pas nécessairement venir la prochaine et vous ne saurez même pas quelle forme elle prendra jusqu’au dernier moment. Choisissez une stratégie de protection reposant sur les technologies comportementales pour identifier le trafic anormal et prendre des mesures de protection de votre infrastructure. La pérennité de votre entreprise pourrait en dépendre.

_________
Ron Winward est Security Evangelist chez Radware