Le guide ultime pour prévenir les attaques DDoS basées sur DNS

Quand il s'agit de DNS, Cricket Liu a littéralement écrit le livre. Il a co-écrit les cinq éditions du livre "DNS and 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 responsable des infrastructures chez Infoblox.

Le DNS est clairement un composant essentiel des réseaux informatiques, mais il y a des moments où ces outils peuvent être utilisés pour des malversations. Dans le New Tech Forum de cette semaine, Cricket examine le problème croissant des attaques DDoS basées sur DNS et comment y faire face. - Paul Venezia

Attaques DDoS basées sur DNS: comment elles fonctionnent et comment les arrêter

La DDoS basée sur le DNS (attaque par déni de service distribué) est devenue l'une des attaques destructrices les plus courantes sur Internet. Mais comment fonctionnent-ils? Et que pouvons-nous faire pour nous défendre contre eux?

Dans cet article, je vais décrire comment les attaques DDoS exploitent et ciblent l'infrastructure DNS. Je vais également vous montrer ce que vous pouvez faire pour vous protéger et protéger les autres.

La grande parodie

Générer une attaque DDoS à l'aide de l'infrastructure DNS est remarquablement simple: les attaquants envoient des requêtes aux serveurs de noms sur Internet, et ces serveurs de noms renvoient des réponses. 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 car elles sont généralement transmises via UDP (le protocole de datagramme utilisateur sans connexion). Envoyer 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.

Cependant, les requêtes d'usurpation d'identité ne suffisent pas à neutraliser une cible. Si les réponses à ces requêtes n'étaient pas plus volumineuses 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 volumineuse. Il s'avère que c'est très facile à mettre en place.

Depuis l'avènement d'EDNS0, un ensemble d'extensions de DNS introduit en 1999, les messages DNS basés sur UDP ont pu transporter beaucoup de données. Une réponse peut atteindre 4 096 octets. La plupart des requêtes, en revanche, ont une longueur inférieure à 100 octets.

Il était une fois, il était relativement difficile de trouver une réponse aussi large dans l'espace de noms d'Internet. Mais maintenant que les organisations ont commencé à déployer DNSSEC, les extensions de sécurité DNS, c'est beaucoup plus facile. DNSSEC stocke les clés cryptographiques et les signatures numériques dans les enregistrements de l'espace de noms. Ce sont franchement é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, contre une requête de 44 octets seulement.

Maintenant, imaginez des attaquants de partout sur Internet qui envoient cette requête falsifiée depuis 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, pour un facteur d'amplification de près de 93 fois.

Faisons un calcul rapide pour déterminer à quel point cela pourrait devenir grave. Supposons que chaque attaquant dispose d'une connexion Internet de 1 Mbps relativement modeste. Il peut envoyer environ 2 840 requêtes de 44 octets sur ce lien par seconde. Ce flux de requête aboutirait à près de 93 Mbps de réponses atteignant votre serveur Web. Tous les 11 attaquants représentent 1 Gbps.

Où les attaquants antisociaux trouveraient-ils 10 amis pour les aider à mener une attaque? En fait, ils n'en ont pas besoin. Ils utiliseront un botnet de milliers d'ordinateurs.

L'effet ultime est dévastateur. Dans son rapport trimestriel sur les attaques DDoS, Prolexic (une société de lutte contre les DDoS) a signalé une récente attaque DNS contre un client qui dépassait 167 Gbps. Prolexic a en outre signalé que la bande passante moyenne des attaques DDoS était en hausse de 718% à 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 à maintes reprises pour les mêmes données, à partir de la même adresse IP? Ne pourraient-ils pas étouffer l'attaque?

Ils peuvent certainement. Mais les serveurs de noms isc.org ne sont pas les seuls qu'un attaquant puisse utiliser pour amplifier son trafic. Bien sûr, il existe d'autres serveurs de noms faisant autorité que l'attaquant pourrait utiliser, mais pire encore, les serveurs de noms récursifs ouverts.

Un serveur de noms récursif ouvert est simplement un serveur de noms qui traitera les requêtes récursives à partir 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 d'Internet pour le compte de clients DNS, comme ceux de votre ordinateur portable ou de votre smartphone. Les administrateurs réseau qui configurent des 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'exécutent des services tels que OpenDNS ou Google Public DNS, ils ne veulent pas les faire utiliser par les citoyens moldaves. Ainsi, des administrateurs à l'esprit public, soucieux de la sécurité et surtout compétents configurent les contrôles d'accès sur leurs serveurs de noms récursifs pour limiter leur utilisation aux systèmes autorisés.

Compte tenu de cela, quelle pourrait être l'ampleur du problème des serveurs de noms récursifs ouverts? Assez gros. Le projet Open Resolver a rassemblé une liste de 33 millions de serveurs de noms récursifs ouverts. Les pirates peuvent lancer des requêtes frauduleuses sur autant de ces derniers qu'ils le souhaitent pour envoyer des données isc.org sur votre serveur Web, serveur de noms ou routeur frontalier jusqu'à ce qu'il s'étouffe.

C'est ainsi que fonctionnent les attaques DDoS basées sur DNS. Heureusement, nous avons plusieurs moyens de les combattre.

Comment surmonter la tempête

La première chose à faire est d'instrumenter votre infrastructure DNS afin que vous sachiez quand vous êtes attaqué. Trop d'organisations n'ont aucune idée de la charge de leurs requêtes, elles ne sauront donc jamais si elles ont été attaquées en premier lieu.

Déterminer la charge de votre requête peut être aussi simple que d'utiliser la prise en charge des statistiques intégrée de BIND. Le serveur de noms BIND videra les données dans son fichier de statistiques lorsque vous exécutez rndc stats,par exemple, ou à un intervalle de statistiques configurable. Vous pouvez examiner les statistiques pour le taux de requête, les erreurs de socket et d'autres indications d'attaque. Ne vous inquiétez pas si vous ne savez pas encore à quoi ressemblera une attaque - une partie de l'objectif de la surveillance DNS est d'établir une base de référence afin que vous puissiez identifier ce qui est anormal.

Ensuite, jetez un œil à votre infrastructure Internet. Ne vous limitez pas à vos serveurs de noms externes faisant autorité; examinez l'infrastructure de votre commutateur et de votre routeur, vos pare-feu et vos connexions à Internet. Identifiez les points de défaillance uniques. Déterminez si vous pouvez les éliminer facilement (et à moindre coût).

Si possible, envisagez une large répartition géographique de vos serveurs de noms externes faisant autorité. Cela permet d'éviter des 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 essaiera d'interroger le serveur de noms faisant autorité le plus proche de lui, de sorte que la répartition géographique aura tendance à offrir 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é à proximité d'eux pour fournir les réponses les plus rapides.

Le moyen le plus simple de lutter contre les attaques DoS est peut-être de surprovisionner votre infrastructure. La bonne nouvelle est que le surprovisionnement 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 ne savez pas quelle est la capacité de vos serveurs de noms? Vous pouvez 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 plate-forme de test similaire à vos serveurs de noms de production dans un laboratoire plutôt que les serveurs de production eux-mêmes.

Décider de combien surprovisionner vos serveurs de noms est subjectif: que vaut votre présence en ligne? Y a-t-il d'autres composants de votre infrastructure Internet qui échoueront 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 problème, il peut être utile de savoir que les attaques DDoS de pointe contre l'infrastructure DNS peuvent dépasser 100 Gbit / s.

L'utilisation d'Anycast peut également aider à résister à une attaque DDoS. Anycast est une technique qui permet à plusieurs serveurs de partager une seule adresse IP, et cela fonctionne particulièrement bien avec 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 s'intégrer dans un seul message DNS basé sur UDP.

Pour déployer Anycast, les hôtes prenant en charge 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 arrêter la publicité de cet itinéraire 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 le code de votre propre construction - ou vous pouvez acheter un produit qui s'en charge pour vous. NIOS d'Infoblox, pas par hasard, 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 comprend un membre aux États-Unis, un en Europe et un en Asie. Un hôte qui lance une attaque DDoS contre vous ne peut envoyer du trafic et donc attaquer qu'un seul membre de l'un ou l'autre groupe à partir de n'importe quel point d'Internet à la fois. À moins que les attaquants puissent générer suffisamment de trafic en provenance d'Amérique du Nord, d'Europe et d'Asie simultanément pour inonder votre infrastructure, ils ne réussiront pas.

Enfin, il existe un moyen de tirer parti d'une large répartition géographique et d'Anycast en même temps, sans investissement important en capital: utilisez un fournisseur DNS basé sur le cloud. Des sociétés telles que Dyn et Neustar exploitent 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 de vos données. Et vous pouvez continuer à maintenir un contrôle direct sur vos données de zone 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 principal que vous désignez et gérez en interne. Assurez-vous simplement d'exécuter le maître masqué (c'est-à-dire sans enregistrement NS pointant vers lui), ou vous courez le risque qu'un attaquant le cible comme un point de défaillance unique.

Un mot d'avertissement lors de l'utilisation de fournisseurs DNS basés sur le cloud: la plupart vous facturent au moins en partie en fonction du nombre de requêtes que leurs serveurs de noms reçoivent pour des données dans vos zones. Dans une attaque DDoS, ces requêtes peuvent augmenter considérablement (complètement hors de votre contrôle et pas du tout à votre avantage), alors assurez-vous qu'elles ont une disposition pour faire face aux attaques DDoS sans vous répercuter le coût du trafic.

Comment éviter de devenir complice d'attaques DDoS

Vous savez maintenant comment configurer votre infrastructure DNS pour résister à une attaque DDoS. Cependant, il est presque aussi important de vous assurer que vous n'êtes pas complice d'une attaque DDoS contre quelqu'un d'autre.

Rappelez-vous la description de la façon dont les serveurs DNS peuvent amplifier le trafic? Les attaquants peuvent utiliser à la fois des serveurs de noms récursifs ouverts et des serveurs de noms faisant autorité comme amplificateurs, en envoyant des requêtes falsifiées qui amènent les serveurs de noms à envoyer des réponses plus de 100 fois plus volumineuses que la requête à des cibles arbitraires sur Internet. Maintenant, bien sûr, vous ne voulez pas être la cible d'une telle attaque, mais vous ne voulez pas non plus être 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, une fois l'attaque terminée, 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 existe très peu d’organisations qui justifient l’exécution d’un serveur de noms ouvert aux requêtes récursives. Google Public DNS et OpenDNS sont deux qui me viennent à l'esprit, mais si vous lisez ceci, je suppose que vous n'êtes probablement pas eux. 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 sur nos réseaux internes, ce qui est facile à faire sur toute implémentation de serveur de noms digne de ce nom. (Le serveur DNS Microsoft ne prend pas en charge les contrôles d'accès basés sur l'adresse IP sur les requêtes. Lisez ce que vous voulez en faire.)

Mais que faire si vous exécutez un serveur de noms faisant autorité? De toute évidence, vous ne pouvez pas limiter les adresses IP à partir desquelles vous accepterez les requêtes - ou pas beaucoup, de toute façon (vous pouvez 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» d'Internet de longue date, 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 à plusieurs reprises aux serveurs de noms la même requête à partir de la même adresse IP (ou bloc d'adresses) usurpée, en recherchant une amplification maximale. Aucun serveur de noms récursif bien comporté ne ferait cela. Il aurait mis en cache la réponse et ne serait plus demandé jusqu'à ce que le temps de vie des enregistrements de la réponse se soit écoulé.