En matière de DNS, Cricket Liu a littéralement écrit le livre. Il a coécrit les cinq éditions du livre « DNS et BIND » d’O’Reilly, qui est généralement considéré comme le guide définitif sur tout ce qui concerne le système de noms de domaine. Cricket est actuellement directeur de l’infrastructure chez Infoblox.
Le DNS est clairement une composante essentielle des réseaux informatiques, mais il arrive que ces outils soient utilisés à des fins malveillantes. Dans le forum New Tech de cette semaine, Cricket se penche sur le problème croissant des attaques DDoS basées sur le DNS et sur la façon d’y faire face. — Paul Venezia
Attaques DDoS basées sur les DNS : Comment elles fonctionnent et comment les arrêter
Les attaques DDoS (distributed denial-of-service attack) basées sur les DNS sont devenues l’une des attaques destructrices les plus courantes sur Internet. Mais comment fonctionnent-elles ? Et que pouvons-nous faire pour nous défendre contre elles ?
Dans cet article, je décrirai comment les attaques DDoS exploitent et ciblent à la fois l’infrastructure DNS. Je vous montrerai également ce que vous pouvez faire pour vous protéger et protéger les autres.
Le grand spoof
Générer une attaque DDoS en utilisant l’infrastructure DNS est remarquablement simple : Les attaquants envoient des requêtes aux serveurs de noms à travers l’Internet, et ces serveurs de noms renvoient des réponses. Cependant, au lieu d’envoyer les requêtes à partir de leurs propres adresses IP, les attaquants usurpent l’adresse de leur cible – qui peut être un serveur Web, un routeur, un autre serveur de noms ou à peu près n’importe quel nœud sur Internet.
L’usurpation des requêtes DNS est particulièrement facile parce qu’elles sont généralement transportées par UDP (le protocole User Datagram sans connexion). L’envoi d’une requête DNS à partir d’une adresse IP arbitraire est à peu près aussi simple et a à peu près le même effet que d’écrire l’adresse de retour de quelqu’un d’autre sur une carte postale.
La mystification des requêtes ne suffit pas à neutraliser une cible, cependant. Si les réponses à ces requêtes n’étaient pas plus importantes que les requêtes elles-mêmes, un attaquant ferait tout aussi bien d’inonder la cible de requêtes usurpées. Non, pour maximiser les dommages causés à la cible, chaque requête doit renvoyer une réponse très importante. Il s’avère que c’est très facile à instiguer.
Depuis l’avènement de l’EDNS0, un ensemble d’extensions du DNS introduites en 1999, les messages DNS basés sur UDP ont pu transporter beaucoup de données. Une réponse peut contenir jusqu’à 4 096 octets. La plupart des requêtes, en revanche, ont une longueur inférieure à 100 octets.
Il fut un temps où il était relativement difficile de trouver une réponse aussi grande dans l’espace de noms de l’Internet. Mais maintenant que les organisations ont commencé à déployer le DNSSEC, les extensions de sécurité du DNS, c’est beaucoup plus facile. DNSSEC stocke des clés cryptographiques et des signatures numériques dans des enregistrements de l’espace de noms. Ceux-ci sont positivement énormes.
Vous pouvez voir un exemple de réponse de la zone isc.org qui contient des enregistrements DNSSEC sur mon blog. La taille de la réponse est de 4 077 octets, par rapport à une requête de seulement 44 octets.
Maintenant, imaginez des attaquants de partout sur Internet envoyant cette requête usurpée de l’adresse IP de votre serveur Web aux serveurs de noms isc.org. Pour chaque requête de 44 octets, votre serveur Web reçoit une réponse de 4 077 octets, soit un facteur d’amplification de près de 93 fois.
Faisons un rapide calcul pour savoir à quel point cela pourrait être grave. Disons que chaque attaquant dispose d’une connexion relativement modeste de 1Mbps à Internet. Il peut envoyer environ 2 840 requêtes de 44 octets par seconde sur ce lien. Ce flux de requêtes se traduirait par des réponses atteignant votre serveur Web à hauteur de 93 Mbps. Tous les 11 attaquants représentent 1Gbps.
Où les attaquants antisociaux trouveraient-ils 10 amis pour les aider à mener à bien une attaque ? En fait, ils n’en ont pas besoin. Ils utiliseront un botnet de milliers d’ordinateurs.
L’effet final est dévastateur. Dans son rapport trimestriel sur les attaques DDoS à l’échelle mondiale, Prolexic (une société spécialisée dans l’atténuation des attaques DDoS) a fait état d’une récente attaque basée sur le DNS contre un client qui a dépassé les 167 Gbps. Prolexic a en outre indiqué que la largeur de bande moyenne des attaques DDoS avait augmenté de 718 % pour atteindre 48 Gbps en un seul trimestre.
Mais attendez ! Les serveurs de noms isc.org ne pourraient-ils pas être modifiés pour reconnaître qu’ils sont interrogés encore et encore pour les mêmes données, à partir de la même adresse IP ? Ne pourraient-ils pas étouffer l’attaque ?
Ils le peuvent certainement. Mais les serveurs de noms isc.org ne sont pas les seuls qu’un attaquant peut utiliser pour amplifier son trafic. Bien sûr, il existe d’autres serveurs de noms faisant autorité que l’attaquant pourrait utiliser, mais les serveurs de noms récursifs ouverts sont encore pires.
Un serveur de noms récursif ouvert est simplement un serveur de noms qui traitera les requêtes récursives de n’importe quelle adresse IP. Je peux lui envoyer cette requête pour les données isc.org et il me répondra, et vous pouvez faire de même.
Il ne devrait pas y avoir beaucoup de serveurs de noms récursifs ouverts sur Internet. La fonction d’un serveur de noms récursif est de rechercher des données dans l’espace de noms de l’Internet pour le compte de clients DNS, comme ceux de votre ordinateur portable ou de votre smartphone. Les administrateurs réseau qui configurent les serveurs de noms récursifs (comme votre service informatique) les destinent généralement à une communauté particulière (par exemple, vous et vos collègues). À moins qu’ils n’utilisent des services tels que OpenDNS ou Google Public DNS, ils n’ont pas l’intention de les faire utiliser par les citoyens de Moldavie. Donc, les administrateurs soucieux du public, de la sécurité et surtout compétents configurent des contrôles d’accès sur leurs serveurs de noms récursifs afin de limiter leur utilisation aux systèmes autorisés.
En tenant compte de cela, quelle importance pourrait avoir un problème de serveurs de noms récursifs ouverts ? Assez important. Le projet Open Resolver a rassemblé une liste de 33 millions de serveurs de noms récursifs ouverts. Les pirates peuvent envoyer des requêtes usurpées à autant d’entre eux qu’ils le souhaitent pour cracher des données isc.org sur votre serveur Web, votre serveur de noms ou votre routeur frontalier jusqu’à ce qu’il s’étrangle.
C’est ainsi que fonctionnent les attaques DDoS basées sur le DNS. Heureusement, nous avons quelques moyens de les combattre.
Comment résister à la tempête
Le premier ordre du jour est l’instrumentation de votre infrastructure DNS, de sorte que vous saurez quand vous êtes attaqué. Trop d’organisations n’ont aucune idée de la charge de leurs requêtes, de sorte qu’elles ne sauraient jamais si elles étaient attaquées en premier lieu.
Déterminer votre charge de requêtes peut être aussi simple que d’utiliser le support de statistiques intégré de BIND. Le serveur de noms BIND déversera des données dans son fichier de statistiques lorsque vous exécuterez rndc stats, par exemple, ou à un intervalle de statistiques configurable. Vous pouvez examiner les statistiques pour connaître le taux de requêtes, les erreurs de socket et d’autres indications d’une attaque. Ne vous inquiétez pas si vous n’êtes pas encore sûr de ce à quoi ressemblera une attaque — une partie de l’objectif de la surveillance du DNS est d’établir une ligne de base, afin que vous puissiez identifier ce qui est anormal.
Puis, jetez un coup d’œil à votre infrastructure tournée vers Internet. Ne vous limitez pas à vos serveurs de noms externes faisant autorité ; examinez votre infrastructure de commutateurs et de routeurs, vos pare-feu et vos connexions à Internet. Identifiez tous les points de défaillance uniques. Déterminez si vous pouvez facilement (et de manière rentable) les éliminer.
Si possible, envisagez une large distribution géographique de vos serveurs de noms externes faisant autorité. Cela permet d’éviter les points de défaillance uniques, bien sûr, mais cela aide également lorsque vous n’êtes pas attaqué. Un serveur de noms récursif résolvant un nom de domaine dans l’une de vos zones tentera d’interroger le serveur de noms faisant autorité le plus proche de lui, de sorte que la répartition géographique aura tendance à fournir de meilleures performances à vos clients et correspondants. Si vos clients sont regroupés dans certaines zones géographiques, essayez de placer un serveur de noms faisant autorité près d’eux pour fournir les réponses les plus rapides.
Peut-être que la façon la plus basique de combattre les attaques DoS est de surprovisionner votre infrastructure. La bonne nouvelle est que le surdimensionnement de vos serveurs de noms n’est pas nécessairement coûteux ; un serveur de noms capable peut gérer des dizaines, voire des centaines de milliers de requêtes par seconde. Vous n’êtes pas sûr de la capacité de vos serveurs de noms ? Vous pourriez utiliser des outils de requête tels que dnsperf pour tester les performances de vos serveurs de noms — de préférence en utilisant une plateforme de test similaire à vos serveurs de noms de production dans un laboratoire plutôt que les serveurs de production eux-mêmes.
Décider à quel point il faut surprovisionner vos serveurs de noms est subjectif : Quelle est la valeur de votre présence en ligne ? Y a-t-il d’autres composants de votre infrastructure tournée vers Internet qui tomberont en panne avant les serveurs de noms ? De toute évidence, il est imprudent de dépenser de l’argent pour construire une infrastructure DNS de première classe derrière un routeur frontalier ou un pare-feu qui échouera bien avant que vos serveurs de noms ne transpirent.
Si l’argent n’est pas un objet, il pourrait être utile de savoir que les attaques DDoS de pointe contre l’infrastructure DNS peuvent dépasser 100Gbps.
L’utilisation d’Anycast peut également aider à résister à une attaque DDoS. L’Anycast est une technique qui permet à plusieurs serveurs de partager une seule adresse IP, et elle fonctionne particulièrement bien avec le DNS. En fait, les serveurs de noms racine d’Internet utilisent Anycast depuis des années pour fournir des données de zone racine dans le monde entier tout en permettant à la liste des racines de tenir dans un seul message DNS basé sur UDP.
Pour déployer Anycast, les hôtes supportant vos serveurs de noms devront exécuter un protocole de routage dynamique, comme OSPF ou BGP. Le processus de routage annoncera à ses routeurs voisins une route vers une nouvelle adresse IP virtuelle sur laquelle votre serveur de noms écoute. Le processus de routage doit également être suffisamment intelligent pour cesser d’annoncer cette route si le serveur de noms local cesse de répondre. Vous pouvez coller votre démon de routage à la santé de votre serveur de noms en utilisant un code de votre propre construction – ou vous pouvez acheter un produit qui s’en occupe pour vous. Le NIOS d’Infoblox, et ce n’est pas une coïncidence, inclut le support Anycast.
Comment Anycast se défend-il contre les attaques DDoS ? Eh bien, disons que vous avez six serveurs de noms externes dans deux groupes Anycast (c’est-à-dire trois partageant une adresse IP Anycast et trois partageant une autre). Chaque groupe contient un membre aux États-Unis, un en Europe et un en Asie. Un hôte qui monte une attaque DDoS contre vous ne peut envoyer du trafic qu’à un seul membre de l’un ou l’autre groupe à la fois, depuis n’importe quel point de l’Internet. À moins que les attaquants ne puissent s’approvisionner en trafic en provenance d’Amérique du Nord, d’Europe et d’Asie simultanément pour submerger votre infrastructure, ils ne réussiront pas.
Enfin, il existe un moyen de tirer parti d’une large distribution géographique et d’Anycast en même temps, sans dépenses d’investissement importantes : Utilisez un fournisseur de DNS basé sur le cloud. Des sociétés telles que Dyn et Neustar gèrent leurs propres serveurs de noms Anycast dans des centres de données du monde entier. Vous les payez pour héberger vos zones et répondre aux requêtes concernant vos données. Vous pouvez continuer à garder un contrôle direct sur les données de vos zones en demandant à un fournisseur de configurer ses serveurs de noms comme secondaires pour vos zones, en chargeant les données à partir d’un serveur de noms maître que vous désignez et gérez en interne. Veillez simplement à exécuter le maître caché (c’est-à-dire sans enregistrement NS pointant vers lui), ou vous courez le risque qu’un attaquant le cible comme point de défaillance unique.
Un mot de prudence lors de l’utilisation de fournisseurs de DNS basés sur le cloud : La plupart vous facturent au moins partiellement en fonction du nombre de requêtes que leurs serveurs de noms reçoivent pour les données de vos zones. Lors d’une attaque DDoS, ces requêtes pourraient augmenter de façon spectaculaire (complètement hors de votre contrôle et pas du tout à votre avantage), alors assurez-vous qu’ils ont une disposition pour faire face aux attaques DDoS sans vous répercuter le coût du trafic.
Comment éviter de devenir complice des attaques DDoS
Maintenant vous savez comment configurer votre infrastructure DNS pour résister à une attaque DDoS. Mais il est presque aussi important de s’assurer que vous n’êtes pas complice d’une attaque DDoS contre quelqu’un d’autre.
Souvenez-vous de la description de la façon dont les serveurs DNS peuvent amplifier le trafic ? Les attaquants peuvent utiliser à la fois les serveurs de noms récursifs ouverts et les serveurs de noms faisant autorité comme amplificateurs, en envoyant des requêtes usurpées qui amènent les serveurs de noms à envoyer des réponses plus de 100 fois plus grandes que la requête à des cibles arbitraires sur Internet. Bien entendu, vous ne voulez pas être la cible d’une telle attaque, mais vous ne voulez pas non plus en être le complice. L’attaque utilise les ressources de vos serveurs de noms ainsi que votre bande passante. Si la cible prend des mesures pour bloquer le trafic de votre serveur de noms vers son réseau, alors après la fin de l’attaque, la cible peut ne pas être en mesure de résoudre les noms de domaine dans vos zones.
Si vous exécutez un serveur de noms récursif ouvert, la solution est simple : Ne le faites pas. Il y a très peu d’organisations qui ont une justification pour exécuter un serveur de noms ouvert aux requêtes récursives. Google Public DNS et OpenDNS sont deux exemples qui me viennent à l’esprit, mais si vous lisez ces lignes, je suppose que ce n’est probablement pas votre cas. Le reste d’entre nous devrait appliquer des contrôles d’accès à nos serveurs de noms récursifs pour s’assurer que seuls les demandeurs autorisés les utilisent. Cela signifie probablement limiter les requêtes DNS aux adresses IP de nos réseaux internes, ce qui est facile à faire sur toute implémentation de serveur de noms digne de ce nom. (Le serveur DNS de Microsoft ne prend pas en charge les contrôles d’accès aux requêtes basés sur les adresses IP. Lisez ce que vous voulez à ce sujet.)
Mais que se passe-t-il si vous exécutez un serveur de noms faisant autorité ? Évidemment, vous ne pouvez pas limiter les adresses IP à partir desquelles vous accepterez des requêtes — ou pas beaucoup, de toute façon (vous pourriez refuser les requêtes provenant d’adresses IP manifestement fausses, telles que les adresses RFC 1918). Mais vous pouvez limiter les réponses.
Deux « chapeaux blancs » de longue date de l’Internet, Paul Vixie et Vernon Schryver, ont réalisé que les attaques DDoS qui utilisent des serveurs de noms faisant autorité pour l’amplification présentent certains modèles de requête. En particulier, les attaquants envoient aux serveurs de noms la même requête à partir de la même adresse IP usurpée (ou bloc d’adresses), encore et encore, afin d’obtenir une amplification maximale. Aucun serveur de noms récursif bien conçu ne ferait cela. Il aurait mis la réponse en cache et ne l’aurait pas redemandée avant que le temps de vie des enregistrements de la réponse ne soit écoulé.
Vixie et Schryver ont mis au point un mécanisme astucieux, appelé Response Rate Limiting (RRL), qui permet à un serveur de noms faisant autorité de suivre le nombre de fois où il a envoyé la même réponse au même interrogateur. Si ce taux dépasse un certain seuil configurable, le serveur de noms cessera d’envoyer cette réponse au quêteur pendant une période déterminée. Si le quêteur cesse de poser la même question au serveur de noms faisant autorité, ce dernier cessera d’étouffer cette réponse. Le résultat est que le serveur de noms faisant autorité n’enverra jamais de réponse à un querier à un taux supérieur au seuil, ce qui le rend inutile dans une attaque DDoS.
RL a été incorporé dans les serveurs de noms BIND dans la version 9.9.4, et quelques autres implémentations de serveurs de noms le supportent maintenant, y compris NSD et Knot. Au fur et à mesure que les gens mettent à niveau leurs serveurs de noms vers des versions plus récentes ou de nouvelles implémentations qui prennent en charge RRL, cela devrait progressivement rendre plus difficile pour les attaquants d’utiliser l’infrastructure DNS comme amplificateurs.
J’espère que cette discussion vous a aidé à comprendre comment l’infrastructure DNS est à la fois ciblée et exploitée dans les attaques DDoS, et comment vous pouvez mieux résister aux attaques DDoS et vous assurer que vos serveurs de noms ne participent pas, à votre insu, à l’une d’entre elles.
Le forum New Tech fournit un moyen d’explorer et de discuter de la technologie émergente de l’entreprise avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous croyons être importantes et du plus grand intérêt pour les lecteurs d’InfoWorld. InfoWorld n’accepte pas de matériel de marketing pour la publication et se réserve le droit d’éditer tout contenu contribué. Envoyez toutes les demandes de renseignements à [email protected].
Cet article, « The ultimate guide to preventing DNS-based DDoS attacks », a été initialement publié sur InfoWorld.com. Pour connaître les dernières nouvelles en matière de technologie commerciale, suivez InfoWorld.com sur Twitter.