Komplexe DNSSEC-Faktoren und Überlegungen

DNS ist in kleinere Teile aufgeteilt, die Zonen genannt werden. Eine Zone beginnt in der Regel mit einem Domain-Namen und enthält alle Einträge, die zu den Subdomains gehören. Jede Zone wird von einem einzigen Manager verwaltet. Zum Beispiel ist cloudflare.com eine Zone, die alle DNS-Einträge für cloudflare.com und seine Subdomains (z. B. www.cloudflare.com, api.cloudflare.com) umfasst.

Es gibt keinen Verzeichnisdienst für Subdomains im DNS. Wenn Sie also wissen wollen, ob api.cloudflare.com existiert, müssen Sie einen DNS-Server fragen, und dieser DNS-Server wird schließlich cloudflare.com fragen, ob api.cloudflare.com existiert. Dies ist bei DNSSEC nicht der Fall. In einigen Fällen kann die Aktivierung von DNSSEC dazu führen, dass ansonsten verdeckte Zoneninhalte offengelegt werden. Nicht jeder legt Wert auf die Geheimhaltung von Subdomains, und der Inhalt der Zone kann bereits leicht erraten werden, da die meisten Websites eine "www"-Subdomain haben; Subdomains werden jedoch manchmal als Anmeldeportale oder andere Dienste verwendet, die der Website-Besitzer geheim halten möchte. Ein Website-Besitzer möchte vielleicht nicht preisgeben, dass „secretbackdoor.example.com“ existiert, um diese Website vor Angreifern zu schützen.

Der Grund, warum DNSSEC Subdomains offenlegen kann, hat damit zu tun, wie Zonen signiert werden. In der Regel wird DNSSEC zum Signieren statischer Zonen verwendet. Eine statische Zone ist ein vollständiger Satz von Datensätzen für eine bestimmte Domain. Die DNSSEC-Signaturdatensätze werden unter Verwendung des Key Signing Key (KSK) und des Zone Signing Key (ZSK) an einem zentralen Ort erstellt und zur Veröffentlichung an den autoritativen Server gesendet. Dieser Satz von Datensätzen ermöglicht es einem autoritativen Server, jede Frage zu beantworten, die ihm gestellt wird, einschließlich Fragen zu Subdomains, die nicht existieren.

Im Gegensatz zum Standard-DNS, bei dem der Server eine unsignierte NXDOMAIN-Antwort (Non-Existent Domain) zurückgibt, wenn eine Subdomain nicht existiert, garantiert DNSSEC, dass jede Antwort signiert ist. Dies geschieht mit einem speziellen Datensatz, der als Nachweis der Nichtexistenz dient, dem NextSECure (NSEC)-Datensatz. Ein NSEC-Eintrag kann verwendet werden, um zu sagen: „Es gibt keine Subdomains zwischen Subdomain X und Subdomain Y“. Indem die Lücke zwischen den einzelnen Domains in der Zone gefüllt wird, bietet NSEC eine Möglichkeit, jede Anfrage mit einem statischen Eintrag zu beantworten. Der NSEC-Datensatz listet auch auf, welche Arten von Ressourcendatensätzen für jeden Namen existieren.

Für statisch signierte Zonen gibt es per Definition eine feste Anzahl von Datensätzen. Da jeder NSEC-Datensatz auf den nächsten verweist, ergibt sich ein endlicher „Ring“ von NSEC-Datensätzen, der alle Subdomains abdeckt. Jeder kann eine Zone „ablaufen“, indem er einem NSEC-Eintrag zum nächsten folgt, bis er alle Subdomains kennt. Diese Methode kann verwendet werden, um alle Namen in dieser Zone zu offenbaren – und damit möglicherweise interne Informationen preiszugeben.

Angenommen, es gibt eine DNSSEC-aktivierte Zone namens example.com mit den Subdomains public.example.com und secret.example.com. Durch das Hinzufügen von NSEC-Einträgen wird die Existenz aller Subdomains aufgedeckt.

Die Abfrage des NSEC-Eintrags von example.com ergibt folgendes:

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

Die Abfrage von public.example.com ergibt folgenden NSEC-Eintrag:

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

Die Abfrage von secret.example.com ergibt folgenden NSEC-Eintrag:

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

Der erste Eintrag ist für die Zone top/apex und besagt, dass der Name „example.com“ existiert und der nächste Name „public.example.com“ ist. Der Eintrag public.example.com besagt, dass der nächste Name „secret.example.com“ ist, wodurch das Vorhandensein einer privaten Subdomain offenbart wird. Das „secret.example.com“ sagt, dass der nächste Datensatz „example.com“ ist, wodurch die Kette von Subdomains vervollständigt wird. Daher kann jeder mit einigen wenigen Abfragen den vollständigen Satz von Datensätzen in der Zone erfahren.

Technisch gesehen sind DNS-Einträge nicht geheim, aber in der Praxis werden sie manchmal als geheim angesehen. Subdomains werden schon seit einiger Zeit verwendet, um Dinge (wie z. B. die Anmeldeseite eines Unternehmens) geheim zu halten, und die plötzliche Offenlegung des Inhalts der Zonendatei kann unerwartet und unangenehm sein.

Vor DNSSEC bestand die einzige Möglichkeit, den Inhalt von Namen in einer Zone herauszufinden, darin, sie entweder abzufragen oder zu versuchen, eine Übertragung der Zone von einem der autoritativen Server durchzuführen. Zonentransfers (AXFR) werden häufig blockiert. Die Alternative zu NSEC, NSEC3, wurde eingeführt, um Probleme mit der Aufzählung von Zonen zu bekämpfen, aber auch NSEC3 kann verwendet werden, um die Existenz von Subdomains aufzudecken.

Mehrere Domains unter .ch nützen NSEC3

Der NSEC3-Datensatz ist wie ein NSEC-Datensatz, aber anstelle einer signierten Lücke von Domain-Namen, für die es keine Antworten auf die Frage gibt, bietet NSEC3 eine signierte Lücke von Hashes von Domain-Namen. Damit sollte die Aufzählung von Zonen verhindert werden. Die NSEC3-Kette für eine Zone mit „example.com“ und „www.example.com“ könnte also lauten (jeder NSEC3-Eintrag besteht der Übersichtlichkeit halber aus 3 Zeilen):

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

Dabei ist „231SPNAMH63428R68U7BV359PFPJI2FC“ der Salted Hash von „example.com“ und „NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM“ ist der Salted Hash von „www.example.com“. Dies erinnert an die Funktionsweise von Passwortdatenbanken.

Die erste Zeile des NSEC3-Datensatzes enthält den „Namen“ der Zone nach dem Hashing, die Anzahl der Hash-Runden und das beim Hashing verwendete Salt sind die beiden letzten Parameter in der ersten Zeile „3 ABCDEF“. Das „1 0“ steht für den Digest-Algorithmus (1 bedeutet SHA-1) und ob die Zone Opt-out verwendet (0 bedeutet nein). Die zweite Zeile ist der „nächste gehashte Name in der Zone“, die dritte Zeile listet die Typen an dem Namen auf. Sie können sehen, dass der „nächste Name“ im ersten NSEC3-Datensatz mit dem Namen im zweiten NSEC3-Datensatz übereinstimmt und der „nächste Name“ in diesem Datensatz die Kette vervollständigt.

Bei der NSEC-Aufzählung können Sie die vollständige Liste der Domains erstellen, indem Sie anfangen, mögliche Namen in der Domain zu erraten. Wenn die Zone etwa 100 Domain-Namen hat, werden etwa 100 Anfragen benötigt, um die gesamte Zone aufzulisten. Wenn Sie mit NSEC3 einen Datensatz anfordern, der nicht existiert, wird ein signierter NSEC3-Datensatz mit der nächsten vorhandenen Zone in alphabetischer Reihenfolge nach Hash zurückgegeben. Wenn man prüft, ob der nächste Abfragekandidat in eine der bekannten Lücken passt, kann man die gesamte Kette in etwa 100 Abfragen entdecken. Es gibt viele Tools, die diese Berechnung für Sie durchführen können, darunter ein Plug-in für nmap

Mit den Hashes, die allen gültigen Namen in der Zone entsprechen, kann ein Wörterbuchangriff verwendet werden, um die echten Namen herauszufinden. Kurze Namen sind leicht zu erraten, und durch die Verwendung eines Wörterbuchs können längere Namen als existent entlarvt werden, ohne dass die maßgeblichen Nameserver mit Vermutungen überflutet werden müssen. Mit Tools wie HashCat lässt sich dies leicht in Software umsetzen, und die Popularität von Bitcoin hat den Preis für Hashing-spezifische Hardware drastisch gesenkt. Es gibt eine rasant wachsende Branche von Geräten, die kryptografische Hashes berechnen können. Der Tesla Password Cracker (unten) ist nur ein Beispiel für ein solches sofort einsetzbares Tool.

Der Tesla Cracker

Da Hashing billig ist, wird die Zonensicherheit nur geringfügig verbessert, wenn NSEC3 wie vorgesehen verwendet wird; der Schutz, den ein Name erhält, ist proportional zu seiner Unverwechselbarkeit.

Kurz gesagt, NSEC ist wie die Offenlegung von Klartext-Passwörtern, und NSEC3 ist wie die Offenlegung einer Unix-ähnlichen Passwortdatei. Beide Techniken sind nicht sehr sicher. Mit NSEC3 ist eine Subdomain nur so privat, wie sie schwer zu erraten ist.

Diese Schwachstelle kann durch eine Technik entschärft werden, die in den RFCs 4470 und 4471 (https://tools.ietf.org/html/rfc4470 und https://tools.ietf.org/html/rfc4471) „DNSSEC white lies“ („Notlügen“) genannt wird; sie wurde von Dan Kaminsky zu Demonstrationszwecken implementiert. Wenn eine Anfrage für eine nicht vorhandene Domain eingeht, wird statt eines NSEC3-Datensatzes für die nächste echte Domain ein NSEC3-Datensatz für den nächsten Hash in alphabetischer Reihenfolge angezeigt. Dies verhindert die Aufhebung der NSEC3-Garantie, gemäß der es keine Domain gibt, deren Hash lexikografisch zwischen der NSEC3-Antwort und der Frage liegt.

Sie können NSEC3 oder NSEC-„Notlügen“ nur implementieren, wenn die Signaturen in Echtzeit als Antwort auf Fragen berechnet werden können. Traditionell werden statische Zoneneinträge für die DNS-Auflösung offline erstellt und alle Einträge mit Signaturen in einer Zonendatei gespeichert. Diese Datei wird dann von einem Live-DNS-Server gelesen, so dass er Fragen zu der Zone beantworten kann.

Cloudflare's DNSSEC-Implementierung nutzt ECDSA's effiziente Signaturerstellung, um DNSSEC-Einträge im laufenden Betrieb zu signieren.

DNSSEC wurde für den Betrieb in verschiedenen Modi konzipiert, die jeweils unterschiedliche Kompromisse in Bezug auf Sicherheit, Performance und Komfort bieten. Die Live-Signierung löst das Problem der Offenlegung von Zoneninhalten im Austausch für eine weniger sichere Schlüsselverwaltung.

Der häufigste DNSSEC-Modus ist die Offline-Signierung statischer Zonen. Auf diese Weise kann das Signiersystem in hohem Maße vor externen Bedrohungen geschützt werden, da sich die privaten Schlüssel auf einem Rechner befinden, der nicht mit dem Netz verbunden ist. Dieses Betriebsmodell funktioniert gut, wenn sich die DNS-Informationen nicht oft ändern.

Eine weitere gängige Betriebsart ist die zentralisierte Online-Signatur. Wenn Sie Daten in speziellen DNS-Signatursystemen mit beschränktem Zugang signieren, können DNS-Daten schnell geändert und veröffentlicht werden. Einige Betreiber führen die DNS-Signierung auf ihren Haupt-DNS-Servern durch. Genau wie bei der Offline-Signierung statischer Zonen folgt dieser Modus dem Modell der zentralen Signierung, d. h. ein einziger (oder replizierter) zentraler Unterzeichner (Signer) führt die gesamte Signierung durch, und die Daten werden von ihm an die tatsächlichen autoritativen DNS-Server verteilt.

Ein radikalerer Modus besteht darin, den eigentlichen autoritativen DNS-Servern die Möglichkeit zu geben, Daten bei Bedarf zu signieren, was eine Reihe neuer Funktionen ermöglicht, einschließlich geografisch abhängiger Informationen, die dort signiert werden, wo die Antwort generiert wird. Der Nachteil ist, dass sich das Schlüsselmaterial jetzt auf vielen verschiedenen Rechnern befindet, die direkten Zugang zum Internet haben. Die Live-Signierung an der Edge führt zu neuen Problemen wie der Schlüsselverteilung und stellt zusätzliche Rechenanforderungen an die Knoten.

Vor kurzem wurde ein Fehler gefunden, der als Heartbleed bekannt ist und eine große Sicherheitslücke in Serveranwendungen öffnet. Er wurde durch einen Programmierfehler in OpenSSL verursacht, der eine Sicherheitslücke für die Offenlegung von Remote-Speicherplatz geschaffen hat. Dieser Fehler ermöglichte Angreifern aus der Ferne die Extraktion von kryptographischen Schlüsseln von Servern, die mit dem Internet verbunden sind. Bugs hinsichtlich der Offenlegung von Remote-Speicherplatz sind nur eine der vielen Bedrohungen für die Sicherheit privater Schlüssel, wenn der Schlüssel in einem aktiven Prozess wie der DNSSEC-Live-Signierung verwendet wird. Je mehr ein Rechner dem Internet ausgesetzt ist, desto mehr Angriffsmöglichkeiten gibt es. Offline signierende Rechner sind solchen Bedrohungen in einem viel kleineren Zeitfenster ausgesetzt.

Eine Möglichkeit, Schlüssel sicher zu halten, ist die Verwendung einer hardwaregestützten Lösung wie einem Hardware-Sicherheitsmodul (HSM). Der größte Nachteil dabei sind die Kosten – HSMs sind sehr teuer (und langsam). Dies ist eines der größten Probleme beim Betrieb von DNS-Servern, die geografisch verstreut sind, um in der Nähe ihrer Kunden zu sein. Der Betrieb eines HSM an jedem Serverstandort kann nicht nur teuer sein, sondern auch zu rechtlichen Komplikationen führen.

Eine weitere Lösung, mit der man verhindert, dass Schlüssel aus der Ferne offengelegt werden können, besteht darin, kryptografische Vorgänge in vertrauenswürdige Komponenten des Systems auszulagern. Hier kann ein benutzerdefinierter DNS-Server, der die Kryptographie auslagern kann, sehr hilfreich sein.

Die Schlüsselverwaltung für DNSSEC ähnelt der Schlüsselverwaltung für TLS und bringt ähnliche Probleme mit sich. Anfang des Jahres haben wir Keyless SSL eingeführt, um die Schlüsselsicherheit für TLS zu verbessern. Wir prüfen die Möglichkeit, Keyless SSL zu erweitern, um die Vorteile von entfernten Schlüsselservern für die DNSSEC-Live-Signierung zu nutzen.

Betreiber, die einen autoritativen DNS-Server betreiben, befürchten oft, dass ihr Server als Kanal für böswillige Distributed-Denial-of-Service-Angriffe (DDoS) genutzt wird. Dies ist darauf zurückzuführen, dass DNS UDP, ein zustandsloses Protokoll, verwendet.

Bei TCP beginnt jede Verbindung mit einem dreifachen Handshake. Dadurch wird sichergestellt, dass die IP-Adresse beider Parteien bekannt und korrekt ist, bevor eine Verbindung hergestellt wird. Bei UDP gibt es keinen solchen Handshake: Die Nachrichten werden einfach direkt an eine IP-Adresse mit einer nicht verifizierten „from“-IP-Adresse gesendet. Wenn ein Angreifer ein UDP-Paket mit den Worten „Hallo, von IP X“ an einen Server senden kann, antwortet der Server in der Regel mit einem UDP-Paket an X. Die Wahl von X als IP-Adresse des Opfers anstelle der des Absenders wird als UDP-„Spoofing“ bezeichnet. Durch Spoofing eines Opfers kann ein Angreifer einen Server, der auf UDP-Anfragen antwortet, dazu bringen, das Opfer mit „reflektiertem“ Datenverkehr zu überfluten. Dies gilt sowohl für autoritative Server als auch für offene rekursive Resolver.

DNSSEC funktioniert auch über UDP, und die Antworten auf DNS-Anfragen können sehr lang sein und mehrere DNSKEY- und RRSIG-Einträge enthalten. Dies ist ein attraktives Ziel für Angreifer, da sie damit ihre Reflection-Angriffe „verstärken“ können. Wenn eine kleine Menge an gefälschten UDP DNSSEC-Anfragen an Nameserver gesendet wird, erhält das Opfer eine große Menge an reflektiertem Traffic. Manchmal reicht dies aus, um den Server des Opfers zu überlasten und eine Dienstverweigerung (Denial of Service) auszulösen.

Eine von einem Root-Server ausgehende Anfrage nach einer TLD, die nicht existiert, ergibt eine Antwort von etwa 100 Byte. Die signierte Antwort für dieselbe Frage beträgt etwa 650 Byte oder einen Amplification-Faktor von 6,5. Das Stammverzeichnis wird mit einem 1.024-Bit-RSA-Schlüssel signiert und verwendet NSEC für negative Antworten. Eine mit NSEC3 signierte und mit einem 1.024-Bit-Schlüssel signierte Anfrage nach einer Domain, die nicht in einer TLD existiert, ergibt einen Amplification-Faktor von etwa 10. Es gibt andere Abfragen, die noch höhere Amplification-Faktoren ergeben können, wobei die Abfrage „ANY“ am effektivsten ist.

Wie viele andere Dienste kann auch DNS über TCP funktionieren. Es gibt ein „Truncation“-Flag, das an einen Resolver zurückgeschickt werden kann, um anzuzeigen, dass TCP erforderlich ist. Dies würde das Problem der DNS-Reflection auf Kosten langsamerer DNS-Anfragen lösen. Diese Lösung ist derzeit nicht praktikabel, da 16 % der Resolver das TCP-„Truncation“-Flag nicht beachten und 4 % keinen zweiten Server versuchen.

Eine weitere Möglichkeit, die Größe der Antworten zu reduzieren, ist die Verwendung von Elliptic Curve Digital Signature Algorithm (ECDSA) Schlüsseln anstelle von herkömmlichen RSA-Schlüsseln. ECDSA-Schlüssel sind viel kleiner als RSA-Schlüssel gleicher Stärke und erzeugen kleinere Signaturen, wodurch DNSSEC-Antworten viel kleiner ausfallen und der Amplification-Faktor reduziert wird. Google Public DNS fügte Ende 2014 Unterstützung für ECDSA hinzu, und mehrere andere Anbieter haben seitdem nachgezogen.

Die Unterstützung für TCP und ECDSA hinkt der allgemeinen Unterstützung von DNSSEC noch hinterher, so dass stattdessen herkömmliche Methoden zum Schutz vor Missbrauch verwendet werden können. Dazu gehören Resource Rate Limiting (RRL) und andere Heuristiken.

Um sich gegen Reflection-Angriffe zu schützen, arbeitet Cloudflare an einem mehrgleisigen Ansatz. Erstens durch die Verwendung von Heuristiken zur Identifizierung von Angriffen und Techniken zur Missbrauchsbekämpfung, die wir derzeit in unserem DNS-Server einsetzen, und zweitens durch die Reduzierung des Amplification-Faktor von DNSSEC-Antworten. Zu den Möglichkeiten, den maximalen Amplification-Faktor zu verringern, gehören die ausschließliche Beantwortung von „ANY“-Anfragen über TCP, die Verwendung kleinerer ECDSA-Schlüssel, wenn dies möglich ist, und die Verringerung der Häufigkeit von Schlüsselwechseln.

Cloudflare ist sich der Komplexität bewusst, die DNSSEC in Bezug auf Datenschutz von Zonen, Schlüsselverwaltung und Reflection/Amplification-Risiko mit sich bringt. Mit klugen technischen Entscheidungen und betrieblichen Kontrollen können die Gefahren von DNSSEC verhindert werden.