Frage Welche Arten von Sicherheitslücken bietet DNSSEC?


Ich plante, meine DNS-Zone mit DNSSEC zu unterzeichnen. Meine Zone, der Registrar und mein DNS-Server (BIND9) unterstützen alle DNSSEC. Der einzige, der DNSSEC nicht unterstützt, ist mein sekundärer Nameserver Provider (nämlich buddyns.com).

Auf ihrer Website, sagen sie das bezüglich DNSSEC:

BuddyNS unterstützt DNSSEC nicht, da es einigen Benutzern zugänglich ist   Sicherheitsanfälligkeiten, die für einen DNS-Dienst mit hohem Volumen ungeeignet sind.

Nun, ich dachte, dass die Verwendung von DNSSEC derzeit irgendwie fragwürdig ist, da die meisten Resolver nicht überprüfen, ob die Datensätze korrekt signiert sind. Was ich nicht wusste, war, dass es ihrer Aussage nach so aussieht, als würde es Sicherheitslücken offenlegen.

Was sind diese "Schwachstellen"?


27
2017-07-23 21:37


Ursprung


finde einen klügeren DNS-Anbieter - ihre Ausreden sind falsch. - Alnitak


Antworten:


DNSSEC hat einige Risiken, aber sie stehen nicht in direktem Zusammenhang mit Reflexion oder Verstärkung. Die EDNS0-Nachrichtengrößenerweiterung ist in diesem Fall ein Redhering. Lassen Sie mich erklären.

Jeder Austausch von Paketen, der nicht von einem vorherigen Identitätsnachweis abhängig ist, unterliegt einem Missbrauch durch DDoS-Angreifer, die diesen nicht authentifizierten Paketaustausch als Reflektor und vielleicht auch als Verstärker verwenden können. Zum Beispiel kann ICMP (das Protokoll hinter "Ping") auf diese Weise missbraucht werden. Ebenso wie das TCP-SYN-Paket, das bis zu 40 SYN-ACK-Pakete anfordert, selbst wenn das SYN gefälscht wurde, um von einem Opfer zu kommen, das diese SYN-ACK-Pakete nicht möchte. Und natürlich sind alle UDP-Dienste anfällig für diesen Angriff, einschließlich NTP, SSDP, uPNP, und wie von anderen Antworten hier erwähnt, einschließlich DNS.

Die meisten Intrusion Detection-, Intrusion Prevention- und Load Balancer-Appliances sind Engpässe, die nicht in der Lage sind, mit dem Datenverkehr über die "Zeilenrate" Schritt zu halten. Auch viele Router können nicht mit einer Zeilenrate und einige Switches laufen. Diese Engpässe sind das kleinste Ziel "im Pfad" und kleiner als die Links selbst. Sie sind das eigentliche Ziel stauungsbedingter DDoS-Angriffe. Wenn Sie die Firewall einer Person mit Angriffsdatenverkehr belasten können, kommt kein guter Datenverkehr zustande, auch wenn die Verbindungen nicht voll sind. Und was eine Firewall verlangsamt, ist nicht die Gesamtanzahl von Bits pro Sekunde (die durch Verwendung größerer Nachrichten erhöht werden kann, und EDNS0 und DNSSEC werden ausreichen), sondern die Gesamtanzahl von Paketen pro Sekunde.

Es gibt eine Menge urbaner Legenden darüber, wie DNSSEC DDoS aufgrund der größeren Nachrichtengröße von DNSSEC verschlimmert, und obwohl dies intuitiv Sinn macht und "gut klingt", ist es einfach falsch. Aber wenn diese Legende ein wenig Wahrheit wäre, würde die wirkliche Antwort immer noch woanders liegen [da DNSSEC immer EDNS0 verwendet, EDNS0 aber ohne DNSSEC verwendet werden kann], und viele normale Nicht-DNSSEC-Antworten sind so groß wie DNSSEC Antwort wäre. Berücksichtigen Sie die TXT-Datensätze, die SPF-Richtlinien oder DKIM-Schlüssel darstellen. Oder einfach jede große Menge von Adressen oder MX-Datensätzen. Kurz gesagt, kein Angriff erfordert DNSSEC, und daher ist jegliche Konzentration auf DNSSEC als DDoS-Risiko eine falsche Energie.

DNSSEC hat Risiken! Es ist schwer zu verwenden und schwieriger zu verwenden. Häufig ist ein neuer Arbeitsablauf für die Änderung von Zonendaten, die Verwaltung von Registratoren und die Installation neuer Serverinstanzen erforderlich. All das muss getestet und dokumentiert werden, und wenn etwas mit DNS zu tun hat, muss die DNSSEC-Technologie als mögliche Ursache untersucht werden. Und das Endergebnis, wenn Sie alles richtig machen, ist, dass Ihre eigenen Online-Inhalte und -Systeme als Zonensignierer für Ihre Kunden empfindlicher werden. Als Far-End-Server-Betreiber wird das Ergebnis sein, dass die Inhalte und Systeme aller anderen für Sie empfindlicher werden. Diese Risiken überwiegen oft die Vorteile, da der einzige Vorteil darin besteht, DNS-Daten vor Veränderungen oder Substitutionen während des Fluges zu schützen. Dieser Angriff ist so selten, dass er sich nicht lohnt. Wir alle hoffen, dass DNSSEC eines Tages allgegenwärtig wird, weil es neue Anwendungen ermöglicht. Aber die Wahrheit ist, dass DNSSEC heute alle Kosten, kein Nutzen und mit hohen Risiken ist.

Wenn Sie also nicht DNSSEC verwenden wollen, ist das Ihr Vorrecht, aber lassen Sie sich von niemandem verwirren, dass das DNSSEC-Problem seine Rolle als DDoS-Verstärker ist. DNSSEC hat keine notwendige Rolle als DDoS-Verstärker; Es gibt andere billigere bessere Möglichkeiten, DNS als DDoS-Verstärker zu verwenden. Wenn du DNSSEC nicht verwenden willst, lass es geschehen, weil du Kool Aid noch nicht getrunken hast und du ein Last-Mover (später) sein willst, kein First-Mover (jetzt).

DNS-Inhaltsserver, die manchmal als "Berechtigungsserver" bezeichnet werden, müssen daran gehindert werden, als DNS-reflektierende Verstärker missbraucht zu werden, da DNS UDP verwendet und weil UDP durch gefälschte Quellpakete nicht verwendbar ist. Die Art und Weise, wie Sie Ihren DNS-Inhaltsserver gegen diese Art von Missbrauch absichern, besteht weder darin, UDP zu blockieren, TCP zu erzwingen (mit dem Trick TC = 1) noch die ANY-Abfrage zu blockieren oder DNSSEC zu deaktivieren. Keines dieser Dinge wird dir helfen. Du brauchst DNS-Antwortratenbegrenzung (DNS RRL), eine völlig kostenlose Technologie, die jetzt in mehreren Open-Source-Nameservern wie BIND, Knot und NSD vorhanden ist. Sie können das DNS-Reflektionsproblem nicht mit Ihrer Firewall beheben, da nur eine content-fähige Middlebox wie der DNS-Server selbst (mit RRL hinzugefügt) genug über die Anfrage weiß, um genau abschätzen zu können, was ein Angriff ist und was nicht. Ich möchte noch einmal betonen: DNS RRL ist kostenlos, und jeder Autorisierungsserver sollte es ausführen.

Abschließend möchte ich meine Vorurteile entlarven. Ich habe den Großteil von BIND8 geschrieben, ich habe EDNS0 erfunden und DNS RRL erfunden. Ich arbeite seit 1988 an DNS als 20er-Sache, und ich bin jetzt mürrisch 50-etwas, mit immer weniger Geduld für unausgereifte Lösungen zu missverstandenen Problemen. Bitte akzeptieren Sie meine Entschuldigung, wenn diese Nachricht zu sehr wie "Hey Kinder, geh aus meinem Rasen!"


101
2018-01-06 20:42



Bestätigen, dass dies der wahre Paul ist. - Andrew B
@AndrewB das kann nicht der echte Paul sein, da sind Großbuchstaben in seinem Beitrag! ;-) - Alnitak
@ Kasperd siehe "draft-ietf-dnsop-cookies", die derzeit durch die IETF fortschreitet. - Alnitak
kasperd: [Ein DNS-Server, der die Rate limitiert, wird selbst zu einem leichteren Ziel für DDoS-Attacken.] Ich weiß, dass ich ein Idiot bin, aber ich bin nicht dieser Idiot. dns rrl macht dich in keiner Weise weniger sicher. Es ist keine Verteidigung gegen alle bekannten Angriffe, aber es schafft keine neuen Angriffe. - Paul Vixie
@ Kasperd die installierte Basis ist immer ein Problem - es gibt keine Lösung, die sogar auf der konformen installierten Basis funktioniert, geschweige denn die nicht-konformen Systeme da draußen. Die gute Nachricht ist, dass EDNS-Cookie-Unterstützung bereits in der Codebasis für BIND 9.11 ist und (AIUI) standardmäßig aktiviert wird. - Alnitak


Ich kenne zwei spezifische Sicherheitslücken. Es gibt die von Håkan erwähnte Reflexion / Verstärkung. Und es gibt die Möglichkeit der Zonenaufzählung.

Reflexion / Verstärkung

Reflection bedeutet Angriffe, bei denen Anfragen mit einer gefälschten Quell-IP an einen DNS-Server gesendet werden. Der Host, der gefälscht wird, ist das primäre Opfer des Angriffs. Der DNS-Server sendet die Antwort unwissentlich an einen Host, der nie danach gefragt hat.

Verstärkung bezieht sich auf jeden Reflexionsangriff, bei dem die reflektierte Antwort aus mehr Bytes oder mehr Paketen besteht als die ursprüngliche Anforderung. Vor der DNSSEC + EDNS0-Amplifikation würden auf diese Weise nur bis zu 512 Bytes gesendet werden. Mit DNSSEC + EDNS0 können 4096 Bytes gesendet werden, die typischerweise 3-4 Pakete umfassen.

Es gibt mögliche Abschwächungen für diese Angriffe, aber ich kenne keinen DNS-Server, der sie implementiert.

Wenn die Client-IP nicht bestätigt wurde, kann der DNS-Server eine abgeschnittene Antwort senden, um den Client zu zwingen, zu TCP zu wechseln. Die abgeschnittene Antwort kann so kurz sein wie die Anfrage (oder kürzer, wenn der Client EDNS0 verwendet und die Antwort nicht), wodurch die Verstärkung eliminiert wird.

Jede Client-IP, die einen TCP-Handshake abschließt und eine DNS-Anforderung für die Verbindung sendet, kann vorübergehend auf die weiße Liste gesetzt werden. Einmal auf die weiße Liste gesetzt, sendet die IP UDP-Anfragen und empfängt UDP-Antworten von bis zu 512 Bytes (4096 Bytes bei Verwendung von EDNS0). Wenn eine UDP-Antwort eine ICMP-Fehlermeldung auslöst, wird die IP wieder von der Whitelist entfernt.

Die Methode kann auch umgekehrt werden, indem eine Blacklist verwendet wird, was bedeutet, dass Client-IPs standardmäßig über UDP abfragen dürfen. Eine ICMP-Fehlermeldung führt jedoch dazu, dass die IP-Adresse auf der schwarzen Liste steht und eine TCP-Abfrage benötigt wird.

Eine Bitmap, die alle relevanten IPv4-Adressen abdeckt, könnte in 444 MB Arbeitsspeicher gespeichert werden. IPv6-Adressen müssten auf andere Weise gespeichert werden.

Zonenaufzählung

Ob die Zonenaufzählung überhaupt eine Schwachstelle ist, ist Gegenstand einer Debatte. Wenn Sie jedoch nicht möchten, dass alle Namen in Ihrer Zone öffentlich bekannt sind, würden Sie dies wahrscheinlich als Sicherheitslücke betrachten. Die Zonenaufzählung kann hauptsächlich durch die Verwendung von NSEC3-Datensätzen gemildert werden.

Das Problem, das auch bei Verwendung von NSEC3 immer noch besteht, besteht darin, dass ein Angreifer den Hash jedes Labels finden kann, indem er einfach nach zufälligen Namen fragt. Sobald der Angreifer alle Hashes hat, kann ein Offline-Brute-Force-Angriff auf diese Hashes ausgeführt werden.

Eine ordnungsgemäße Verteidigung gegen die Zonenaufzählung würde erfordern, dass ein Angreifer für jede Schätzung eine Abfrage an den autorisierenden Server ausführt. Eine solche Verteidigung existiert jedoch nicht in DNSSEC.


7
2017-07-24 07:00



Die Zonenaufzählung scheint jedoch für den Diensteanbieter kein Problem zu sein. (Eher eine mögliche Sorge für die Zone "Besitzer", abhängig von ihren Ansichten und Vorlieben.) - Håkan Lindqvist
@ HåkanLindqvist Das ist richtig. Vielleicht war meine Frage spezifischer, als ich es wollte. Ich habe diese Information sehr interessant gefunden. - Johann Bauer
Die Idee, einen Client, der TCP ausprobiert hat, auf die weiße Liste zu setzen, wurde in Betracht gezogen, ist aber anscheinend patentiert. - Alnitak


Was mir in den Sinn kommt, ist nicht DNSSEC-spezifisch, sondern die EDNS0-Erweiterung, auf die sich DNSSEC stützt.

EDNS0 ermöglicht größere UDP-Payloads und größere UDP-Payloads können schlechtere Traffic-Reflection / Amplification-Angriffe ermöglichen.


Ich weiß nicht, wie hoch der Prozentsatz der validierenden Resolver ist, aber populäre Nameserver-Software scheint standardmäßig mit Validierung ausgeliefert zu werden und man wird leicht einige bemerkenswerte Service Provider finden, die offen über sie sind, wie Comcast und die öffentlichen Resolver von Google.

Auf dieser Grundlage würde ich meinen, dass der Prozentsatz der validierenden Resolver wahrscheinlich wesentlich besser ist als der Prozentsatz der signierten Zonen.


4
2017-07-23 23:36



Ja, ich dachte, dass das Rindfleisch vielleicht auch bei EDNS sein könnte. Es ist furchtbar komisch, den Knochen mit DNSSEC zu ersetzen. - Andrew B