Die Domain Name System Security Extensions (DNSSEC) sind eine Erweiterung des DNS, mit der Authentizität und Datenintegrität von DNS-Transaktionen gewährleistet werden. Ein DNS-Teilnehmer kann damit verifizieren, dass die durch den Server, mit dem er kommuniziert, gelieferten Zonendaten auch tatsächlich identisch mit denen sind, die der für die Zone autorisierte und die Zone signierende Server ausliefert. DNSSEC wurde als Mittel gegen Cache-Poisoning entwickelt, Serverauthentifizierung findet nicht statt. Wer jetzt noch genauere Informationen dazu haben möchte beginnt am besten >>hier<<….
Was mich beim ersten Lesen eines Artikels zu DNSSEC etwas durcheinander gebracht hat, war dieses Umhergewerfe mit den Begriffen: KSK, ZSK, SEP, DNSKEY, RRSIG und DS… Daher versuche ich das mal kurz verständlich zu erklären, den im Grunde ist das alles total einfach!
Der KSK (Key signing Key) hat grob gesehen nur eine einzige Aufgabe. Er muss den ZSK (Zone signing Key) unterschreiben. Der KSK ist nämlich immer in der übergeordneten Zone hinterlegt (von kernel-error.org ist die übergeordnete Zone z.B.: org). Der ZSK hat auch nur eine Aufgabe, das unterschreiben der Zone…..
Es beginnt also alles mit dem KSK der Rootzone. Die Rootzone ist „.“! Mal angenommen wir wollen nach www.kernel-error.org fragen. Dann geht es ganz oben los. Die Nameserver der Rootzone wissen welche Nameserver für die einzelnen TLDs (Top level domains) zuständig sind. Die Nameserver der TLDs wissen welche Nameserver für die einzelnen Unterdomains (z.B.: kernel-error.org) zuständig sind. Der Nameserver der Unterdomain kennt nun selbst die Adresse für www.kernel-error.org oder kann zumindest sagen welcher Nameserver für die Unterdomain „www“ zuständig ist. Will ein Angreifer nun also dafür sorgen dass man mit seinem Browser beim Aufruf von www.kernel-error.org nicht auf meinem Webserver landet, sondern auf seinem (bei Banken hätte das ja was, oder?), dann hat er zwei einfache Möglichkeiten.
- Er antwortet auf die Anfrage des Clients (wer ist denn der für die Domain kernel-error.org zuständige Nameserver) mit seinem eigenen Nameserver. Somit fragt der Client immer den Nameserver des Angreifers, welcher mit den falschen Adressen antwortet.
- Er antwortet auf jede Anfrage des Clients (mit gefälschter Absenderkennung) schneller als der eigentlich zuständige DNS-Server und kann so falsche Informationen übermitteln.
Mal angenommen man würde nun auf DNSSEC setzten und jeder Nameserver würde seine Zone signieren. Woher wüsste man dann, dass die Antwort korrekt ist? Angreifer können genau so signierte Antworten schicken. Genau, man muss die Gültigkeit der Signatur prüfen. Genau dafür ist nun der KSK. Der KSK signiert die Zone und zusätzlich wird der KSK jeweils in der übergeordneten Zone bekannt gemacht. Die übergeordnete Zone wird mit dem ZSK signiert, welcher mit dem KSK der übergeordneten Zone unterschrieben wurde, dieser KSK ist natürlich wieder der Zone darüber bekannt…. Man kann also Stück für Stück nach oben gehen. Am Ende steht dann der KSK der Root-Zone. Die folgende Zeichnung soll das ganze noch verständlicher darstellen.
Sollte es jemandem denn noch nicht klar sein, helfe ich gerne weiter. >>Einfach fragen<<
Es sind leider noch lange nicht alle TLDs signiert bzw. haben DS-Records in den Root-Servern. Eine ganz nette Liste über bereits signierte TLDs findet sich hier: https://www.tldwithdnssec.se/
Unsere DENIC hat ein .de testbed eingerichtet. Die Jungs wollen Anfang 2011 aber auch loslegen. Infos zum DENIC DNSSEC testbed gibt es hier.
Möchte man seine Domain per DNSSEC schützen muss natürlich als erstes der für die Domain zuständige DNS-Server DNSSEC unterstützen und es muss aktiviert sein. Klingt logisch, oder? Ich bin, unter anderem, ein Freund von Bind. Daher beschränke ich mich hier einfach mal auf diesen…. Ab ISC Bind 9.6.2 sind alle Tools und Funktionen wohl soweit ausgereift dass man es im Zusammenhang mit DNSSEC sauber nutzen kann!
DNSSEC schaltet man recht einfach im options-Block ein:
options {
........
dnssec-enable yes;
dnssec-validation yes;
........
};
Recursive DNS-Server benötigen natürlich noch den KSK der Rootzone. Diesen muss man als vertrauenswürdig einstufen. Am einfachsten bekommt man diesen mit folgendem Aufruf:
$ dig . dnskey | grep -w 257 > dnssec_root.key
Diesen legt man jetzt im trusted-keys Block ab:
trusted-keys {
. 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";<br />};</div> <p>Um sicherzustellen das man auch den richtigen bekommen hat, erstellt man kurzerhand daraus einen DS-Record und vergleicht diesen...</p> <div style="padding: 7pt; width: 100%; background-color: #7e0000;"># dnssec-dsfromkey -2 dnssec_root.key
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32 F24E8FB5
Für die Integritätsprüfung dieses Schlüssels hat die ICANN mehrere Methoden spezifiziert. Dieses liest sich sehr gut >>hier<<.
Nun sollte man Bind neu starten, damit er die Änderungen übernimmt. Theoretisch ist Bind nun schon in der Lage mit DNSSEC umzugehen.
Frage ich z.B.: meinen DNS-Server zuhause nach einer signierten Domain (www.cacert.org), das Flag +ad fordert den Nameserver auf die Antwort per DNSSEC zu validieren:
$ dig +ad www.cacert.org SOA @2a01:198:6ce::1
Dann bekomme ich die folgende Antwort.
Möchte man wissen ob sein DNS-Server überhaupt DNSSEC beherrscht, setzt man bei seiner Anfrage einfach das Flag +dnssec
Beherrscht der gefragte Nameserver DNSSEC erhält man signierte Records….
$ dig +dnssec www.cacert.org SOA @2a01:198:6ce::1
Gehen einem die, gleich erstellten, Schlüssel verloren, oder die signierte Zonendatei brennt ab, hat mein ein Problem. Genau wie bei der eigentlichen Einrichtung oder Aktualisierung ist die Reihenfolge sehr wichtig und einzuhalten. Denn die rekursiven DNS-Server halten ja für die Zeit der TTL die Abfrage im Cache…. Somit könnte man, bei falschem Vorgehen, für die Zeit der längsten TTL ~nicht~ erreichbar sein!
Ich habe mir folgenden Masterplan fürs DNSSEC aufgestellt. Im Grunde nichts weiter also vor jeder „großen“ Änderung immer die längste TTL der Zone abzuwarten und fertig! Dieses habe ich mir mal irgendwann aufgemalt (nicht schön aber extrem selten). Hier also dieses ~analoge~ Bild!
Nun könnte man schon beginnen seine Zonen zu signieren. Dazu muss natürlich erstmal ein neuer Schlüssel erzeugt werden. In meinem Fall dreht sich alles um die Domain kernel-errror.org
Um für diese ZONE nun einen 4096 Bit langen KSK zu erzeugen gibt man folgendes ein:
$ dnssec-keygen -r /dev/urandom -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE kernel-error.org Kkernel-error.org.+007+55836
Den ZSK für die ZONE erstellt man mit:
$ dnssec-keygen -r /dev/urandom -a NSEC3RSASHA1 -b 4096 -n ZONE kernel-error.org Kkernel-error.org.+007+25685
Nun finden sich im Verzeichnis vier neue Dateien. Kkernel-error.org ist die Domain, +007 ist der Schlüsseltyp und +55836 bzw. +25685 ist die ID des Schlüssels. Die Endung .key bezeichnet jeweils den öffentlichen Teil, .privat steht für den privaten Teil. Den privaten Teil sollte keiner in die Finger bekommen
Den öffentlichen Teil des KSK und des ZSK müssen nun noch in der Zone hinzugefügt werden.
$ cat *.key >> kernel-error.org
Der öffentliche Teil des KSK ist zusätzlich der Teil, welcher in der übergeordneten Zone publiziert werden muss. In diesem Fall müssen also die Jungs an den Root-Servern der TLD .org einen DS aus unserem öffentlichen KSK erstellen und ihn neben die NS-Records klatschen! Das läuft überall etwas anders. Die Vorgehensweise von der DENIC und EURID schaut so aus, dass man seinen öffentlichen KSK dort hinschickt die Jungs basteln daraus einen DS-Record (sie trauen es einem wohl nicht selbst zu) und veröffentlichen diesen daraufhin.
Somit kann man nun das eigentliche Zonenfile signieren 🙂 Folgender Aufruf erledigt dieses:
dnssec-signzone -r /dev/urandom -e +31104000 -k Kkernel-error.org.+007+55836 -f kernel-error.org.signed kernel-error.org Kkernel-error.org.+007+25685 Verifying the zone using the following algorithms: NSEC3RSASHA1. Zone signing complete: Algorithm: NSEC3RSASHA1: ZSKs: 1, KSKs: 1 active, 0 revoked, 0 stand-by kernel-error.org.signed
+31104000 
ist hier etwas besonders. Denn das ist die Zeit in Sekunden, welche die Signatur gültig ist. In diesem Fall 360 Tage….
Nun teilt man Bind noch mit dass er anstelle der Zonendatei kernel-error.org die Datei kernel-error.org.signed >>laden<< soll, restart und schon ist die Arbeit fast beendet… Änderungen an der Zone nimmt man nun weiterhin wie gewohnt in der kernel-error.org vor, muss nach diesen Änderungen nur jeweils die Zone neu signieren. Ist ja klar, oder?
Man darf natürlich nicht vergessen den KSK in der übergeordneten Zone bekannt zu machen. Für die Publikation des KSK haben die meisten Registries ein Webinterface (meiner leider nicht :-/). Am Ende sind dann neben den NS-Records auch die nötigen DS-Records. Ob diese gesetzt sind findet man am besten heraus, indem man die DNS-Server der übergeordneten Zone (hier also die der TLD .org) danach fragt…..
$ dig org. in NS
Wirft uns die zuständigen DNS-Server für die TLD .org entgegen. Von diesen fischt man sich einfach einen heraus und fragt nach dem DS-Record der gewünschten Domain (ich frage einfach mal wieder nach cacert.org)!
$ dig +short @b2.org.afilias-nst.org cacert.org in DS cacert.org. 86400 IN DS 59365 3 1 DA0668FAF7F726EF64284FC8D1393CF3DD0A39C5 cacert.org. 86400 IN DS 59365 7 2 3A4F6F9F8CFB0FABB508CDE5E874206F159B8A893938A8792C091613 6CF499BD
Vom feinsten, oder?
Gibt es etwas besonders zu beachten, gibt es Probleme?
Ja, die gibt es :-/
Normalerweise läuft die Kommunikation mit den Nameservern über das UDP Protokoll, schlägt dieses fehl kommt der Fallback auf TCP. Das UDP Protokoll hat aber ein Größenlimit von 512 Bytes pro Paket. Die Schlüssel bei DNSSEC sind dafür einfach zu groß. Vor allem bei NSEC3 Schlüsseln! EDNS (Extension Mechanisms for DNS) heben dieses auf. EDNS (RFC 2671) erlaubt nämlich unter anderem größere Pakete. Dieses wurde alles schon 1999 festgelegt. Na ja, wie bei so vielen schönen Dingen hängt, wie z.B. bei IPv6, die Umsetzung leider etwas durch . Somit hat die ein oder andere Firewall, security appliance und vor allem einige plaste DSL-Router damit Probleme. Einige lösen einfach nichts mehr auf und andere erschrecken sich bei einer signierten Antwort so sehr, dass sie erstmal abstürzen!
Ich als Freund vom Firefox habe da noch ein Addon gefunden. Dieses Firefox Plugin, der DNSSEC Validator zeigt einem jeweils den Status der aktuellen Seite an: https://addons.mozilla.org/de/firefox/addon/64247/
* UPDATES 08.02.2011 *
Heute gibt es zwei schöne Updates….
1. DeNIC will die de-Domain bald signieren
2. Mein Registrar hat es endlich geschafft meinen DS-Record in der ORG-Zone zu veröffentlichen 🙂
Ich habe mir natürlich auch mal angeschaut in wie weit Microsofts Serverbetriebssystem hier mitspielt. Windows Server 2008 R2 SP1…. Der mitgelieferte DNS-Server soll/kann DNSSEC. Leider frisst der DNS-Server aus den Windows Sever 2008 R2 SP1 Boardmitteln nur Schlüssel vom Type SHA1. Das kommt daher, weil zuerst geplant war die ROOT-Zone so zu signieren. Später ist es dann aber doch SHA256 geworden. Daher lässt sich mit dem Systemeigenen DNS-Server nicht viel anfangen. Im SP2rc habe ich auch keine Verbessungen dazu gesehen. Wann dazu ein Update kommt, keine Ahnung 🙂
Davon mal abgesehen…. So geht es!
Klickt man im DNS-Manager mit der rechten Maustaste auf den gewünschten DNS-Server und geht dort in die Eigenschaften öffnen sich diese auch in einem neuen Fenster. Hier findet sich nun der Reiter: „Anchors für Vertrauensstellung“. Hier werden nun alle als vertrauenswürdig eingestuften Schlüssel aufgelistet. Die DNSKEYs der TLD se sind schon seit (ich glaube) 2007 signiert. Die Jungs haben Schlüssel vom Type SHA1… Diese lassen sich also importieren. Die Schlüssel besorgt man sich am einfachsten wieder mit dig:
$ dig se. dnsskey
Nun ist es wohl am Einfachsten die Schlüssel in einen Texteditor zu werfern und dort schnell die Leerzeichen zu entfernen, sonst firsst der Windows Server 2008RC2 SP1 DNS-Server die Schlüssel nicht!
Dann schnell die Eingabeaufforderung des Admins öffnen und mit dem Befehl:
c:\>dnscmd /TrustAnchorADD se ##Schlüssel##
Den DNSKEY In den lokalen DNS-Server werfen…..
Und schon ist der Schlüssel in der Liste 🙂 Auch wenn man damit keine vollständige Vertrauenskette bilden kann.
Wir warten also alle mal auf ein Update!
Was der Microsoft Server 2011 da kann, werde ich in den nächsten Tagen mal testen.
Ok, habe mir dann mal den Microsoft Windows Server 2011 SBS in den ESX4-Cluster geworfen…. Was soll ich sagen? Laut GUI kann der 2011 SBS Standard DNS-Server das auch ~noch~ nicht 🙁
Wer mit Microsoft Systemen und deren Boardmitteln arbeiten will, dem bleibt nichts weiter übrig als zu warten….
* UPDATES 22.02.2011 *
Ich habe gerade meine kernel-error.de Domain auch signiert. Mein Registrar hat den DNSKEY freundlicherweise direkt veröffentlicht. Das bringt zwar erst etwas, wenn die TLD de. offiziell signiert ist…. Denn noch fängt der frühe Vogel den Wurm (oder so ähnlich)!
Über die Resolver aus dem DeNIC Testbed kann natürlich auch jetzt schon sauber abgefragt werden!
* UPDATE 08.06.2011 *
Wooohoooo DeNIC hat ja inzwischen die TLD de sauber signiert. Inzwischen sind die DS-RR auch in der Root-Zone angekommen und nutzbar 🙂 Damit ist die TLD .de. fertig signiert und voll nutzbar *freu*
* UPDATE 28.02.2012 *
Ich habe gerade alles in die Wege geleitet um die Domain: kernel-error.com zu schützen.
Zusätzlich habe ich eine ganz nette Möglichkeit gefunden sich alles nett grafisch darstellen zu lassen. Für meine Domains wären es folgende Links:
Wer sich den Link anschaut, wird erkennen wie er schnell „seine“ Domain dort eintragen kann.
Um zu testen ob sein eigener Rechner derzeit überhaupt die Möglichkeit hat mit DNSSEC zu arbeiten klickt am besten kurz hier:
* UPDATE 27.05.2012 *
Wenn man schon eine so geschützten DNS-Server hat, dann lassen sich natürlich sehr gut darüber weitere Informationen als nur A-RECORDS oder ähnliches verteilen.
Ich habe hier https://www.kernel-error.de/dnssec/gpg-im-dns beschrieben wie sich die eigenen GPG Schlüssel über den DNS Server verteilen lassen und hier https://www.kernel-error.de/dnssec/ssh-key-im-dns ist beschrieben wie sich mit OpenSSH die Fingerprints einzelner Hosts mit dem DNS Server abgleichen lassen.
* UPDATE 12.10.2012 *
Ich glaub es nicht der geht… nö der geööööhhht!
Der Microsoft Windows Server 8 also öhm der Microsoft Windows Server 2012 kann es. Komplett sauber und ganz Microsoft in klickibunti… Ich habe sogar sinnige und nutzbare Informationen zu dem Thema bei Microsoft selbst gefunden.
Es lässt sich wirklich fast alles mit der Maus erledigen, vom Zonen signieren bis im Im- und Export von allem möglichen Zeugs. Auch eine Schritt für Schritt Anleitung habe ich gefunden. https://technet.microsoft.com/en-us/library/hh831411.aspx
Ich habe hier auch noch ein paar Bilder zum gucken!
* UPDATE 10.08.2013 *
Jetzt sind zusätzlich die TLS/SSL Schlüssel meiner Dienste per DANE mit dem DNS abgleichbar 🙂
* UPDATE 14.11.2012 *
Ich habe dann mal die Schlüssellänge auf 4096bit angepasst 😀
Schreibe einen Kommentar