Die Grundlagen von DNSSEC

Die Grundlagen von DNSSEC

Michael Schneider
von Michael Schneider
Lesezeit: 17 Minuten

Die Domain Name System Security Extensions (DNSSEC) ist eine Reihe von Erweiterungen, die dem DNS Protokoll weitere Sicherheitsmassnahmen hinzufügt und in den RFCs 4033, 4034 und 4035 spezifiziert wird. DNSSEC fügt DNS Origin Authority, Data Integrity und Authenticated Denial of Existence hinzu. Alle Antworten seitens DNSSEC-geschützten Zonen sind kryptographisch signed. Ein DNS Resolver kann den Public Key erhalten und validieren, dass die Antworten authentisch sind und nicht verändert worden sind.

DNS abzusichern ist essentiell, um das Internet sicherer zu Machen. Allerdings wird es Jahre dauern, bevor DNSSEC breite Anwendung finden wird. Google Public DNS unterstützt DNSSEC seit März 2013 und lediglich 7% aller Queries von Clients waren DNSSEC-enabled. 24% aller DNS-Queries aus der Schweiz haben die DNSSEC-Validierung in den vergangenen Monaten verwendet (Quelle: APNIC statistics). Im Februar 2013 hat SWITCH entschieden die Statistiken im Zusammenhang mit DNSSEC nicht zu publizieren, da lediglich 0.05% aller aktiven Domains DNSSEC verwendet haben. Daher sei die Veröffentlichung ungerechtfertigt, hiess es. Heute listet ICANNs Deploying DNSSEC list nur zwei Registrars, die End User DNSSEC Management für die Top Level Domain .ch unterstützen. Da diese Situation weit vom Ideal entfernt ist, versucht dieses Labs eine Übersicht über DNSSEC zu geben und darüber zu informieren, wie DNSSEC eingesetzt und gewartet werden kann. Ausserdem, seien wir ehrlich: Wie hart kann das sein?

DNSSEC Keys

DNSSEC funktioniert dadurch, dass es Datensätze mittels Public Key Kryptopgraphie für DNS Lookup signiert. Es gibt zweierlei Keys, um eine DNS-Zone zu signieren: den Key Signing Key (KSK) und den Zone Signing Key (ZSK).

Der KSK wird dazu verwendet, das DNSKEY Resource Record Set (RRSet) in einer Zone zu signieren. Sein Public Key muss im _Delegation Signer Record (DS) veröffentlicht werden. Dies kann geschehen, indem der KSK Public Key einem Registrar (und der Top Level Domain Zone) übermittelt wird. Dieser Schritt ist notwendig, um die DNSSEC Chain of Trust zu etablieren. Andererseits wird ein ZSK verwendet, der alle anderen RRSets in regelmässigen Abständen signiert. Diese Keys dürfen einem Registrar nicht übermittelt werden.

Aus Sicherheitsperspektive wird empfohlen, die Private Keys wie auch die Zone Master File nur offline und auf nicht mit dem Netzwerk verbundenen Maschinen, die auch noch physisch sicher sind, abzuspeichern und zu benutzen. Alle Signaturen sollten auf diesen Maschinen erstellt und dann auf alle Nameserver übertragen werden. Eine weitere Best Practice ist es, die DNSSEC Keys regelmässig auszutauschen. Je länger ein Key im Einsatz ist, desto grösser die Wahrscheinlichkeit, dass er durch Nachsicht, Unfall, Spionage oder Kryptoanalyse kompromittiert wird. Ein ZSK sollte vierteljährlich ausgewechselt werden. Dieser Key Rollover wird später erklärt.

DNSSEC Keys erstellen

Der Prozess zur Key Generation ist von Umgebung zu Umgebung unterschiedlich. In diesem Labs verwenden wir dnssec-keygen, um alle Keys zu erstellen. Der Prozess kann eine Weile dauern, da ein Server nicht genug Entropie generiert. Die Option -r in dnssec-keygen unterstützt die Nutzung einer Datei mit zufälligem Inhalt, wie /dev/random/. Ein weiterer Weg ist die Nutzung eines Random Number Generator Daemons wie haveged.

In diesem Labs verwenden wir eine Domain namens scip.example.com und wir erstellen den KSK mit einer Schlüssellänge von 4096 bit (Standard ist 2048 bit) und einen ZSK mit einer Schlüssellänge von 2048 bit (Standard ist 1024 bit). Der Algorithmus für beide Keys ist der NSEC3-fähige Algorithmus RSASHA256.

KSK:

# dnssec-keygen -3 -a RSASHA256 -b 4096 -n ZONE -f KSK scip.example.com

ZSK:

# dnssec-keygen -3 -a RSASHA256 -b 2048 -n ZONE scip.example.com

Nach der Ausführung dieser Befehle haben wir zwei Dateien pro Key. Eine Datei beinhaltet den Private Key (.private), der andere den Public Key (.key). Beide Public Keys müssen im Zone File enthalten sein. Dies kann mit dem Hinzufügen der folgenden zwei Zeilen am Ende des Zone File geschehen.

$INCLUDE <KSK_filename>.key
$INCLUDE <ZSK_filename>.key

Zone Signing und Zone Walking

Nutzen wir nun die Keys, um die Zone File von @scip.example.com# zu signieren. Wie erwähnt, signiert der KSK das DNSKEY RRSet und der ZSK alle anderen Datensätze. Die Signatur (RRSig) ist 30 Tage lang gültig, danach muss eine Zone neu signiert werden. Geschieht das nicht, kann ein Resolver keine Requests validieren und die Daten als Nonsense abstempeln. Somit würde es unmöglich werden, irgendwelche Daten aus der Zone aufzulösen.

Der Signaturprozess generiert einen NSEC Record pro Domainnname. Dieser listet alle existierenden Resource Record Types für einen Datensatz auf und leitet in den nächsten Datensatz über. Der letzte NSEC Record leitet zurück auf den ersten Record in der Datei. Das hat den Nebeneffekt, dass jeder alle Zonen-Records erhalten kann, wenn er der verlinkten Liste von NSEC Records folgt. Dies wird Zone Walking genannt.

Zum Beispiel: Wir haben unsere Zone File für scip.example.com, die zwei Domainnamen enthält.

$ORIGIN scip.example.com.
$TTL 1h

scip.example.com. IN SOA ns1.example.com. username.example.com. ( 2014072801 1d 2h 4w 1h ) scip.example.com. IN NS ns1.example.com. scip.example.com. IN NS ns2.example.com. scip.example.com. IN A 192.0.2.1 www IN A 192.0.2.2

Signieren wir diese nun mit den Standardoptionen.

# dnssec-signzone -N INCREMENT -o scip.example.com -t scip.example.com.zone

Überprüfen wir nun den NSEC Record für scip.example.com.: Er listet alle RR Types auf (A NS SOA RRSIG NSEC DNSKEY) und leitet auf den nächsten Eintrag der Liste weiter (in diesem Falle www). Entsprechend leitet der NSEC Record für www.scip.example.com. zurück auf scip.example.com., was ihn zum letzten Eintrag in der Zone File macht

scip.example.com.        3600    NSEC    www.scip.example.com. A NS SOA RRSIG NSEC DNSKEY
www.scip.example.com.    3600    NSEC    scip.example.com. A RRSIG NSEC

NSEC3 wurde veröffentlicht, um Zone Walking zu verhindern oder es zumindest schwieriger zu Machen. Wenn NSEC3 wird, werden Domain Name Records mit einem Salt Value gehasht. Dieser Salt kann mit dnssec-keygen und der Option -3 festgelegt werden. Daher nutzen wir einen zufälligen String, der 16 Zeichen lang ist als Salt Value und setzen die Option -H, um 50 Iterationen durchzuführen (Standard ist 10).

# dnssec-signzone -3 $(head -c 1024 /dev/random | sha1sum | cut -b 1-16) -H 50 -A -N INCREMENT -o scip.example.com -t scip.example.com.zone

Jetzt sind alle NSEC Records durch NSEC3 ersetzt und die Domainnamen in den Records gehasht.

ILMFC5R61RDV7BLGMA4FM0K5BMJ2USGE.scip.example.com. 3600 IN NSEC3 1 1 10 BECEC0C7ED27D96A TASH4704H4T65N9E4I61B0C57EDQ9RP4 A NS SOA MX RRSIG DNSKEY NSEC3PARAM
TASH4704H4T65N9E4I61B0C57EDQ9RP4.scip.example.com. 3600 IN NSEC3 1 1 10 BECEC0C7ED27D96A ILMFC5R61RDV7BLGMA4FM0K5BMJ2USGE A RRSIG

Ein entschlossener Angreifer kann immer noch den Salt Value (query dig NSEC3PARAM <domain>) herausfinden und ihn zur Erstellung einer Rainbow Table nutzen, damit er alle gehashten Werte entschlüsseln kann. Dies dauert aber eine lange Zeit und der Angreifer muss jedes Mal von Vorne beginnen, wenn der Salt Value ändert. Daher ist es Good Practice, einen neuen Salt Value für jede neu signierte Zone zu verwenden.

Um das zusammenzufassen: Die Key-Generierung und das Signieren der Zonen kann vollständig offline geschehen. Ein Nameserver benötigt nur ein signiertes Zone File. Nachdem wir also das Zone File signiert haben, transferieren wir dieses auf den Nameserver. Wenn der KSK zum ersten Mal verwendet wird, müssen wir seinen Public Key dem Registrar (DS Record) übermitteln. Alle Informationen, die dazu benötigt werden, sind in der Datei dsset-scip.example.com abgelegt.

Key Rollover

DNSSEC Keys müssen regelmässig gewechselt werden: Ein ZSK sollte nach 90 Tagen ausgetauscht werden und ein KSK sollte einmal pro Jahr ein Rollover erfahren. Der Unterschied zwischen einem ZSK und einem KSK Rollover ist, dass ein KSK Rollover Interaktion mit dem Registrar benötigt.

Ein Key Rollover ist nicht einfach nur Entferne alten Key, nutze neuen Key aufgrund des DNS Caching. DNS Zone Data und Public Keys sind unabhängig voneinander in den DNS Resolvern gecached. Der DNS-Validationsprozess scheitert, wenn ein Resolver der den alten Key nicht gechached hat oder er andersherum versucht, Daten zu validieren, die mit einem neuen Key signiert wurden, der Resolver aber nur einen alten Key lokal gecached hat. Ein Zonenadministrator muss daher sicherstellen, dass gecachte Daten während des Rollovers immer noch validiert werden können. RFC 4641 beschreibt zwei Prozesse, die einen Key Rollover sauber abwickeln: Pre-Publish (Vorpublikation) und Double Signature (Doppelsignatur).

Double Signature

Im Prozess Double Signature wird eine Zone während des Rollovers von zwei Signaturen signiert. In der initialen Phase wird die Zone von Key K1 signiert. In der Phase new DNSKEY wird Key K2 eingeführt und K1 wie auch K2 signieren. Diese Rolloverphase dauert dann an, bis alle Daten im Cache des Resolvers abgelaufen sind. Das ist zu Beginn minimal die Zeit der maximalen TTL der Zone. Nach dieser Phase folgt die Phase DNSKEY Removal während der K1 aus dem Keyset entfernt wird und die Zone nur von K2 signiert wird.

Beispiel eines Double Signature Befehls:

dnssec-signzone -3 $(head -c 1024 /dev/random | sha1sum | cut -b 1-16) -H 50 -A -k KSK/Kscip.example.com.+008+61219.key -k KSK/Kscip.example.com.+008+49831.key -N INCREMENT -o scip.example.com -t scip.example.com.zone ZSK/Kscip.example.com.+008+63084.key

Pre-Publish

Der pre-publish Prozess läuft in vier Schritten ab. In der initialen Phase wird K1 dazu verwendet, das Zone File zu signieren. Während new DNSKEY wird K2 ins Keyset eingeführt, aber K1 signiert die Zone weiterhin. Die minimale Laufzeit dieser pre-roll_-Phase ist die Zeit, die DNS-Daten benötigen, um zum _authoritative Server zu propagieren plus die TTL des Keysets. In der Phase new RRSIG ist es nur K2, der die Zone signiert. K1 bleibt aber im Keyset enthalten. Diese Zone muss ebenfalls andauern, bis alle Daten in den Caches der Resolver aus der initialen Phase abgelaufen sind. K1 wird dann in der Phase DNSKEY removal entfernt. Dieser Prozess kann vereinfacht werden, indem der zukünftige Key gleich nach dem Rollover publiziert wird.

Beispiel eines pre-publish Befehls:

dnssec-signzone -3 $(head -c 1024 /dev/random | sha1sum | cut -b 1-16) -H 50 -A -k KSK/Kscip.example.com.+008+61219.key -N INCREMENT -o scip.example.com -t scip.example.com.zone ZSK/Kscip.example.com.+008+63084.key

Der Nachteil des Double Signature Prozesses ist, dass während dem Rollover die doppelte Anzahl Signaturen in einer Zone vorhanden sind. Die könnte sich auf die Performance von grossen Zonen auswirken. Von Vorteil ist aber, dass der gesamte Prozess in nur drei Schritten bewältigt werden kann. Die Best Practice in der Praxis ist es, Double Signature für den KSK zu verwenden und Pre-Publish für den ZSK Key Rollover.

Als Beispiel verwenden wir Pre-Publish für ein ZSK Rollover, der alle drei Monate stattfindet:

Ein einfacher ZSK Rollover nach dem Pre-Publish Modell

Wenn wir das selbe Beispiel in der vereinfachten Version ansehen, dann wird der zukünftige Key unmittelbar nach dem Rollover publiziert.

Ein vereinfachter ZSK Rollover nach dem Pre-Publish Modell

Ein Key Rollover kann manuell oder voll automatisiert stattfinden. Daher speichern will alle Keys offline. Auch die Key Generation und das Signieren der Zonen geschieht offline, die signierte Zone muss jedes Mal dem Nameserver übermittelt werden.

DNSSEC validieren

Nachdem wir nun wissen, wie eine DNSSEC-gesicherte Zone aufgesetzt wird, ist es an der Zeit, DNSSEC Antworten zu validieren. Alles was wir dazu brauchen, ist das Tool dig. Einige DNS Resolver wie Google unterstützen DNSSEC-Validierung. Wenn wir einen Request für nic.ch (ein Record mit DNSSEC) an einen Google Nameserver senden, (dig nic.ch A +dnssec +multi \<notextile>8.8.8.8@), taucht die Flag Authenticated Data (AD) im Response Header auf. Sie zeigt an, dass der Request validiert wurde. Wir können dig verwenden, um eine Chain of Trust in einer Domain zu validieren. Dazu benötigen wir die folgenden Befehle:

dig . DNSKEY | grep -Ev '^($|;)' > root.key
dig +multiline +sigchase +trusted-key=./root.key www.nic.ch. A

Eine DNS Response enthält nützliche Informationen, die uns helfen, ein DNSSEC-Setup selbst zu validieren. Zuerst fordern wir alle DNSKEY_-Records für _statdns.net an, indem wir die Query dig +dnssec +multiline statdns.net dnskey senden. In der Antwort finden wir alle DNSSEC-Keys der Zone, deren Key ID und den Public Key Algorithmus wie auch den Public Key.

DNSKEY von statdns.net

Diese Informationen werden dazu verwendet, einen DNS Record wie www.statdns.net zu validieren. Die Antwort enthält ein Key Tag, das den verwendeten Key wie auch dessen Einführung und Ablaufdatum anzeigt.

Ein Record von www.statdns.net

Tip für Profis: Wenn ein DNSSEC Resolver keine Daten anzeigt, da die Zonendaten invalid sind (zum Beispiel durch das Ablaufen der Signatur), dann fügen sie der DNS Query die Flag Checking Disabled hinzu. Sie erhalten die Daten dann.

Zudem gibt es zwei DNSSEC Analysetools, die online verfügbar sind. Das eine stammt von Verisign Labs Das andere von Sandia National Laboratories.

Verweise

Über den Autor

Michael Schneider

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschrieber Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

×
HardeningKitty

HardeningKitty

Michael Schneider

KleptoKitty

KleptoKitty

Michael Schneider

Linux Hardening

Linux Hardening

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv