Welche Arten von Sicherheitslücken deckt DNSSEC auf?

Ich hatte vor, meine DNS-Zone mit DNSSEC zu signieren. 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-Anbieter (nämlich buddyns.com ).

Auf ihrer Website stellen sie dies in Bezug auf DNSSEC fest:

BuddyNS unterstützt DNSSEC nicht, da es einige Schwachstellen aufweist, die für einen DNS-Dienst mit hohem Volumen ungeeignet sind.

Nun, ich dachte, die Verwendung von DNSSEC ist derzeit irgendwie fraglich, da die meisten Resolver nicht prü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 aufdecken.

Was sind diese "Schwachstellen"?

DNSSEC birgt einige Risiken, die jedoch nicht direkt mit der Reflexion oder Verstärkung zusammenhängen. Die Erweiterung der EDNS0-Nachrichtengröße ist in diesem Fall ein roter Hering. Lassen Sie mich erklären.

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

Die meisten Intrusion-Detection-, Intrusion-Prevention- und Load-Balancer-Appliances sind Engpässe, die nicht mit dem "Line-Rate" -Verkehr Schritt halten können. Außerdem können viele Router und einige Switches nicht mit Leitungsgeschwindigkeit betrieben werden. Diese Engpässe sind das kleinste "auf dem Weg" und kleiner als die Verbindungen selbst. Sie sind das eigentliche Ziel überlastungsbasierter DDoS-Angriffe. Wenn Sie die Firewall einer Person mit dem Angriffsverkehr beschäftigen können, wird kein guter Verkehr durchgelassen, auch wenn die Links nicht voll sind. Und was eine Firewall verlangsamt, ist nicht die Gesamtzahl der Bits pro Sekunde (die durch die Verwendung größerer Nachrichten und EDNS0 und DNSSEC erhöht werden kann), sondern die Gesamtzahl der Pakete pro Sekunde.

Es gibt viele urbane Legenden darüber, wie DNSSEC DDoS aufgrund der größeren Nachrichtengröße von DNSSEC verschlimmert, und obwohl dies intuitiv sinnvoll ist und "gut klingt", ist es einfach falsch. Aber wenn diese Legende ein bisschen wahr wäre, würde die wahre Antwort immer noch an anderer Stelle liegen - [da DNSSEC immer EDNS0 verwendet, aber EDNS0 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 zur Darstellung von SPF-Richtlinien oder DKIM-Schlüsseln verwendet werden. Oder einfach eine große Anzahl von Adress- oder MX-Einträgen. Kurz gesagt, für keinen Angriff ist DNSSEC erforderlich, und daher ist jede Konzentration auf DNSSEC als DDoS-Risiko eine Fehlleistung.

DNSSEC hat Risiken! Es ist schwer zu benutzen und schwieriger, es richtig zu benutzen. Häufig ist ein neuer Arbeitsablauf für die Änderung von Zonendaten, die Registrierung und die Installation neuer Serverinstanzen erforderlich. All dies muss getestet und dokumentiert werden, und wenn etwas im Zusammenhang mit DNS kaputt geht, 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 anfälliger sind. Als Server-Betreiber am fernen Ende wird das Ergebnis sein, dass die Inhalte und Systeme aller anderen für Sie anfälliger sind. Diese Risiken überwiegen häufig die Vorteile, da der einzige Vorteil darin besteht, DNS-Daten vor Änderungen oder Ersetzungen während des Flugs zu schützen. Dieser Angriff ist so selten, dass er diese Mühe nicht wert ist. Wir alle hoffen, dass DNSSEC eines Tages aufgrund der neuen Anwendungen, die es ermöglichen wird, allgegenwärtig wird. Die Wahrheit ist jedoch, dass DNSSEC heute nur noch Kosten, keinen Nutzen und hohe Risiken birgt.

Wenn Sie also DNSSEC nicht verwenden möchten, ist dies Ihr Vorrecht, aber lassen Sie sich nicht verwirren, dass das Problem von DNSSEC seine Rolle als DDoS-Verstärker ist. DNSSEC spielt keine notwendige Rolle als DDoS-Verstärker. Es gibt andere günstigere und bessere Möglichkeiten, DNS als DDoS-Verstärker zu verwenden. Wenn Sie DNSSEC nicht verwenden möchten, lassen Sie es sein, weil Sie die Kool Aid noch nicht getrunken haben und ein Last-Mover (später) und kein First-Mover (jetzt) ​​sein möchten.

DNS-Inhaltsserver, die manchmal als "Autoritätsserver" bezeichnet werden, müssen daran gehindert werden, als DNS-reflektierende Verstärker missbraucht zu werden, da DNS UDP verwendet und UDP durch gefälschte Quellpakete missbraucht werden kann. Sie können Ihren DNS-Inhaltsserver nicht vor dieser Art von Missbrauch schützen, indem Sie UDP blockieren, TCP erzwingen (mit dem TC = 1-Trick), die ANY-Abfrage blockieren oder DNSSEC deaktivieren. Keines dieser Dinge wird dir helfen. Sie benötigen eine Begrenzung der DNS-Antwortrate(DNS RRL), eine völlig kostenlose Technologie, die jetzt auf mehreren Open-Source-Nameservern wie BIND, Knot und NSD verfügbar ist. Sie können das Problem mit der DNS-Reflektion mit Ihrer Firewall nicht beheben, da nur eine inhaltsbezogene Middlebox wie der DNS-Server selbst (mit RRL) über die Anforderung ausreichend Bescheid weiß, um genau zu erraten, was ein Angriff ist und was nicht. Ich möchte noch einmal betonen: DNS RRL ist kostenlos, und jeder Autoritätsserver sollte es ausführen.

Abschließend möchte ich meine Vorurteile aufdecken. Ich habe den größten Teil von BIND8 geschrieben, EDNS0 erfunden und DNS RRL miterfunden. Ich arbeite seit 1988 als 20-Jähriger an DNS, und jetzt bin ich ein mürrischer 50-Jähriger, mit immer weniger Geduld für halbherzige Lösungen für missverstandene Probleme. Bitte nehmen Sie meine Entschuldigung an, wenn diese Nachricht zu sehr nach "Hey, Kinder, verschwinde von meinem Rasen!" Klingt.

Ich kenne zwei spezifische Schwachstellen. Da ist die von Håkan erwähnte Reflexion / Verstärkung. Und es besteht die Möglichkeit der Zonenzählung.

Reflexion / Verstärkung

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

Die 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-Verstärkung konnten auf diese Weise nur bis zu 512 Bytes gesendet werden. Mit DNSSEC + EDNS0 können 4096 Bytes gesendet werden, die normalerweise 3-4 Pakete umfassen.

Es gibt mögliche Abhilfemaßnahmen 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 gekürzte Antwort kann so kurz sein wie die Anforderung (oder kürzer, wenn der Client EDNS0 verwendet und die Antwort nicht), wodurch die Verstärkung beseitigt wird.

Jede Client-IP, die einen TCP-Handshake durchführt und eine DNS-Anfrage für die Verbindung sendet, kann vorübergehend in die Whitelist aufgenommen werden. Sobald diese IP-Adresse auf die Whitelist gesetzt wurde, kann sie UDP-Anfragen senden und UDP-Antworten mit bis zu 512 Bytes empfangen (4096 Bytes bei Verwendung von EDNS0). Wenn eine UDP-Antwort eine ICMP-Fehlermeldung auslöst, wird die IP erneut aus der Whitelist entfernt.

Die Methode kann auch mithilfe einer Blacklist umgekehrt werden. Dies bedeutet lediglich, dass Client-IPs standardmäßig über UDP abfragen dürfen. Jede ICMP-Fehlermeldung führt jedoch dazu, dass die IP auf die Blacklist gesetzt wird und eine TCP-Abfrage erforderlich ist, um von der Blacklist gestrichen zu werden.

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

Zonenaufzählung

Ob die Zonenzählung überhaupt eine Sicherheitslücke darstellt, ist umstritten. 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 Zonenzählung kann größtenteils durch die Verwendung von NSEC3-Datensätzen verringert werden.

Das Problem, das auch bei Verwendung von NSEC3 weiterhin 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 durchgeführt werden.

Für eine ordnungsgemäße Verteidigung gegen die Zonenzählung muss ein Angreifer für jede Vermutung eine Abfrage an den autorisierenden Server senden. In DNSSEC gibt es jedoch keine solche Verteidigung.

Das, woran ich denke, ist nicht DNSSEC-spezifisch, sondern betrifft 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-Attacken ermöglichen.

Ich weiß nicht, wie viel Prozent der Resolver validiert werden, aber die gängige Nameserver-Software wird anscheinend standardmäßig mit aktivierter Validierung ausgeliefert, und es ist leicht, einige namhafte Dienstleister zu finden, die sich mit der Validierung befassen, 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.