Quels types de vulnérabilités de sécurité la fourniture de DNSSEC expose-t-elle?

J'avais l'intention de signer ma zone DNS avec DNSSEC. Ma zone, le registraire et mon serveur DNS (BIND9) prennent tous en charge DNSSEC. Le seul qui ne prend pas en charge DNSSEC est mon fournisseur de serveur de noms secondaire (à savoir buddyns.com ).

Sur leur site Web , ils déclarent ceci concernant DNSSEC:

BuddyNS ne prend pas en charge DNSSEC car il expose à certaines vulnérabilités inadaptées à un service DNS à haut volume.

Eh bien, je pensais que l'utilisation de DNSSEC est actuellement quelque peu discutable car la plupart des résolveurs ne vérifient pas si les enregistrements sont signés correctement. Ce que je ne savais pas, c'est que - selon leur déclaration - il semble que le fait de fournir exposerait des failles de sécurité d'une certaine sorte.

Quelles sont ces "vulnérabilités"?

DNSSEC comporte certains risques, mais ils ne sont pas directement liés à la réflexion ou à l'amplification. L'extension de la taille du message EDNS0 est un hareng rouge dans ce cas. Laissez-moi expliquer.

Tout échange de paquets qui ne dépend pas d'une preuve d'identité antérieure est soumis à des abus par des attaquants DDoS qui peuvent utiliser cet échange de paquets non authentifié comme réflecteur, et peut-être aussi comme amplificateur. Par exemple, ICMP (le protocole derrière "ping") peut être abusé de cette manière. Tout comme le paquet TCP SYN, qui sollicite jusqu'à 40 paquets SYN-ACK même si le SYN a été usurpé pour provenir d'une victime qui ne veut pas de ces paquets SYN-ACK. Et bien sûr, tous les services UDP sont vulnérables à cette attaque, y compris NTP, SSDP, uPNP, et comme indiqué par d'autres réponses ici, y compris DNS.

La plupart des appliances de détection d'intrusion, de prévention des intrusions et d'équilibreur de charge sont des goulots d'étranglement, incapables de suivre le trafic de "débit de ligne". De nombreux routeurs ne peuvent pas non plus fonctionner au débit de ligne et certains commutateurs. Ces goulots d'étranglement, en étant la plus petite chose "sur le chemin", et plus petits que les liens eux-mêmes, sont la cible réelle des attaques DDoS basées sur la congestion. Si vous pouvez garder le pare-feu de quelqu'un occupé par le trafic d'attaque, un bon trafic ne passera pas, même si les liens ne sont pas pleins. Et ce qui ralentit un pare-feu n'est pas le nombre total de bits par seconde (qui peut être augmenté en utilisant des messages plus gros, et EDNS0 et DNSSEC feront l'affaire), mais plutôt le nombre total de paquets par seconde.

Il y a beaucoup de légendes urbaines sur la façon dont DNSSEC aggrave les DDoS en raison de la plus grande taille des messages de DNSSEC, et bien que cela ait un sens intuitif et "sonne bien", c'est tout simplement faux. Mais s'il y avait un brin de vérité dans cette légende, la vraie réponse serait encore ailleurs - [parce que DNSSEC utilise toujours EDNS0, mais EDNS0 peut être utilisé sans DNSSEC], et de nombreuses réponses normales non DNSSEC sont aussi grandes qu'un DNSSEC réponse serait. Considérez les enregistrements TXT utilisés pour représenter les stratégies SPF ou les clés DKIM. Ou tout grand ensemble d'adresses ou d'enregistrements MX. En bref, aucune attaque ne nécessite DNSSEC, et donc toute focalisation sur DNSSEC en tant que risque DDoS est une énergie mal dépensée.

DNSSEC comporte des risques! Il est difficile à utiliser et plus difficile à utiliser correctement. Souvent, cela nécessite un nouveau flux de travail pour les modifications des données de zone, la gestion du bureau d'enregistrement, l'installation de nouvelles instances de serveur. Tout cela doit être testé et documenté, et chaque fois que quelque chose de cassé est lié au DNS, la technologie DNSSEC doit être étudiée comme une cause possible. Et si vous faites tout correctement, le résultat final sera qu'en tant que signataire de zone, vos propres contenus et systèmes en ligne seront plus fragiles pour vos clients. En tant qu'opérateur de serveur distant, le résultat sera que le contenu et les systèmes de tous les autres vous seront plus fragiles. Ces risques sont souvent considérés comme supérieurs aux avantages, car le seul avantage est de protéger les données DNS contre la modification ou la substitution en vol. Cette attaque est si rare qu'elle ne vaut pas tous ces efforts. Nous espérons tous que DNSSEC deviendra omniprésent un jour, en raison des nouvelles applications qu'il permettra. Mais la vérité est qu'aujourd'hui, DNSSEC est tout coût, aucun avantage, et avec des risques élevés.

Donc, si vous ne voulez pas utiliser DNSSEC, c'est votre prérogative, mais ne laissez personne vous confondre que le problème de DNSSEC est son rôle d'amplificateur DDoS. DNSSEC n'a aucun rôle nécessaire en tant qu'amplificateur DDoS; il existe d'autres façons moins chères d'utiliser DNS comme amplificateur DDoS. Si vous ne voulez pas utiliser DNSSEC, que ce soit parce que vous n'avez pas encore bu le Kool Aid et que vous voulez être un dernier (plus tard) pas un premier (maintenant).

Les serveurs de contenu DNS, parfois appelés «serveurs d'autorité», doivent être empêchés d'être utilisés comme amplificateurs réfléchissant DNS, car DNS utilise UDP et parce que UDP est exploitable par des paquets de source falsifiée. Le moyen de sécuriser votre serveur de contenu DNS contre ce type d'abus n'est pas de bloquer UDP, ni de forcer TCP (en utilisant l'astuce TC = 1), ni de bloquer la requête ANY, ni de désactiver DNSSEC. Aucune de ces choses ne vous aidera. Vous avez besoin d'une limitation du taux de réponse DNS(DNS RRL), une technologie entièrement gratuite qui est maintenant présente dans plusieurs serveurs de noms open source, notamment BIND, Knot et NSD. Vous ne pouvez pas résoudre le problème de réflexion DNS avec votre pare-feu, car seul un boîtier de médiation sensible au contenu tel que le serveur DNS lui-même (avec RRL ajouté) en sait suffisamment sur la demande pour pouvoir deviner avec précision ce qui est une attaque et ce qui ne l'est pas. Je tiens à souligner, encore une fois: DNS RRL est gratuit, et chaque serveur d'autorité doit l'exécuter.

En terminant, je veux exposer mes préjugés. J'ai écrit la plupart de BIND8, j'ai inventé EDNS0 et j'ai co-inventé DNS RRL. Je travaille sur DNS depuis 1988 en tant que 20-quelque chose, et je suis maintenant grincheux 50-quelque chose, avec de moins en moins de patience pour des solutions à moitié cuites à des problèmes mal compris. Veuillez accepter mes excuses si ce message ressemble trop à "hé les enfants, descendez de ma pelouse!"

Je connais deux vulnérabilités spécifiques. Il y a la réflexion / amplification mentionnée par Håkan. Et il y a la possibilité d'un dénombrement de zone.

Réflexion / amplification

La réflexion signifie des attaques dans lesquelles des requêtes avec une IP source usurpée sont envoyées à un serveur DNS. L'hôte usurpé est la principale victime de l'attaque. Le serveur DNS enverra sans le savoir la réponse à un hôte qui ne l'a jamais demandé.

L'amplification fait référence à toute attaque de réflexion dans laquelle la réponse réfléchie consiste en plus d'octets ou de paquets que la demande d'origine. Avant une amplification DNSSEC + EDNS0 de cette manière, cela ne permettrait d'envoyer que 512 octets. Avec DNSSEC + EDNS0, il est possible d'envoyer 4096 octets, qui s'étendent généralement sur 3 à 4 paquets.

Il existe des atténuations possibles pour ces attaques, mais je ne connais aucun serveur DNS les mettant en œuvre.

Lorsque l'adresse IP du client n'a pas été confirmée, le serveur DNS peut envoyer une réponse tronquée pour forcer le client à basculer vers TCP. La réponse tronquée peut être aussi courte que la demande (ou plus courte si le client utilise EDNS0 et la réponse ne le fait pas), ce qui élimine l'amplification.

Toute adresse IP client qui termine une négociation TCP et envoie une demande DNS sur la connexion peut être temporairement mise sur liste blanche. Une fois sur liste blanche, IP peut envoyer des requêtes UDP et recevoir des réponses UDP jusqu'à 512 octets (4096 octets si vous utilisez EDNS0). Si une réponse UDP déclenche un message d'erreur ICMP, l'adresse IP est à nouveau supprimée de la liste blanche.

La méthode peut également être inversée à l'aide d'une liste noire, ce qui signifie simplement que les adresses IP des clients sont autorisées à interroger UDP par défaut, mais tout message d'erreur ICMP entraîne la liste noire de l'IP, nécessitant une requête TCP pour sortir de la liste noire.

Un bitmap couvrant toutes les adresses IPv4 pertinentes pourrait être stocké dans 444 Mo de mémoire. Les adresses IPv6 devraient être stockées d'une autre manière.

Énumération de zone

La question de savoir si l'énumération des zones est une vulnérabilité en premier lieu fait l'objet d'un débat. Mais si vous ne voulez pas que tous les noms de votre zone soient connus du public, vous le considérerez probablement comme une vulnérabilité. Le dénombrement des zones peut principalement être atténué grâce à l'utilisation des enregistrements NSEC3.

Le problème qui persiste même en utilisant NSEC3 est qu'un attaquant peut trouver le hachage de chaque étiquette en interrogeant simplement des noms aléatoires. Une fois que l'attaquant a tous les hachages, une attaque par force brute hors ligne peut être effectuée sur ces hachages.

Une défense appropriée contre l'énumération de zone nécessiterait qu'un attaquant effectue une requête sur le serveur faisant autorité pour chaque supposition. Cependant, aucune telle défense n'existe dans DNSSEC.

La chose qui me vient à l'esprit n'est pas réellement spécifique à DNSSEC mais plutôt à l'extension EDNS0, sur laquelle DNSSEC s'appuie.

EDNS0 autorise des charges utiles UDP plus importantes et des charges utiles UDP plus importantes peuvent permettre d'aggraver les attaques de réflexion / amplification du trafic.

Je ne sais pas quel est le pourcentage de résolveurs de validation, mais les logiciels de serveurs de noms populaires semblent être livrés avec la validation par défaut et on trouvera facilement des fournisseurs de services notables qui sont ouverts à leur sujet, tels que Comcast et les résolveurs publics de Google.

Sur cette base, je pense que le pourcentage de résolveurs de validation est probablement en bien meilleure forme que le pourcentage de zones signées.