DNSSEC (Domain Name System Security Extensions) schützt DNS-Antworten vor Fälschung. Ein anfragender Resolver kann damit prüfen, ob die gelieferten Zonendaten tatsächlich vom autorisierten Nameserver stammen und unterwegs nicht verändert wurden. DNSSEC wurde als Mittel gegen Cache Poisoning entwickelt — Serverauthentifizierung findet nicht statt.
Die Vertrauenskette
Was mich beim ersten Lesen zu DNSSEC durcheinandergebracht hat, war das Umherwerfen mit Begriffen: KSK, ZSK, DNSKEY, RRSIG, DS. Im Grunde ist es einfach:
Der KSK (Key Signing Key) hat eine Aufgabe: den ZSK unterschreiben. Der KSK wird als DS-Record in der übergeordneten Zone hinterlegt. Der ZSK (Zone Signing Key) hat auch nur eine Aufgabe: die eigentlichen Zonendaten unterschreiben.
Es beginnt bei der Root-Zone. Die Root-Server wissen, welche Nameserver für die TLDs zuständig sind. Die TLD-Server wissen, welche Nameserver für die einzelnen Domains zuständig sind. Jede Ebene signiert ihre Zone und veröffentlicht den DS-Record der Ebene darunter. So entsteht eine durchgehende Kette vom Root-KSK bis zu meiner Zone.
Will ein Angreifer dafür sorgen, dass www.kernel-error.org auf seinen Server zeigt, hat er zwei Möglichkeiten:
- Er antwortet auf die Delegation-Anfrage mit seinem eigenen Nameserver.
- Er antwortet mit gefälschter Absenderadresse schneller als der echte Server.
Mit DNSSEC kann der Resolver beide Angriffe erkennen — die gefälschte Antwort hat keine gültige Signatur.
DNSSEC in BIND aktivieren
Auf dem autoritativen Nameserver muss DNSSEC-Validierung aktiv sein. In modernen BIND-Versionen (ab 9.16) reicht im options-Block:
options {
dnssec-validation auto;
};
auto bedeutet, dass BIND den eingebauten Root-Trust-Anchor nutzt und diesen bei KSK-Rollovers automatisch aktualisiert (RFC 5011). Der alte dnssec-enable yes wurde in BIND 9.18 entfernt — DNSSEC ist seitdem immer aktiv.
Zone signieren — der moderne Weg
Seit BIND 9.16 gibt es dnssec-policy. Damit übernimmt BIND die Schlüsselerzeugung, das Signieren und den Key-Rollover vollautomatisch:
zone "kernel-error.org" {
type primary;
file "kernel-error.org";
dnssec-policy default;
inline-signing yes;
};
Die default-Policy verwendet ECDSAP256SHA256 (Algorithmus 13) — schneller und sicherer als das früher übliche NSEC3RSASHA1 mit 4096-Bit-Schlüsseln. inline-signing yes bedeutet: BIND signiert die Zone im Speicher, die Zonendatei auf der Platte bleibt unsigniert und lässt sich wie gewohnt bearbeiten.
Zone manuell signieren
Wer mehr Kontrolle will oder eine ältere BIND-Version hat, kann die Schlüssel von Hand erzeugen. KSK erstellen:
$ dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE kernel-error.org Kkernel-error.org.+013+12345
ZSK erstellen:
$ dnssec-keygen -a ECDSAP256SHA256 -n ZONE kernel-error.org Kkernel-error.org.+013+67890
Die öffentlichen Teile (*.key) in die Zonendatei einbinden und signieren:
$ cat Kkernel-error.org.+013+*.key >> kernel-error.org $ dnssec-signzone -S -K /pfad/zu/keys -o kernel-error.org kernel-error.org Verifying the zone using the following algorithms: ECDSAP256SHA256. Zone signing complete: Algorithm: ECDSAP256SHA256: ZSKs: 1, KSKs: 1 active, 0 stand-by kernel-error.org.signed
Dann BIND anweisen, die signierte Zonendatei zu laden. Nach jeder Änderung an der Zone muss neu signiert werden — oder man nutzt inline-signing, dann entfällt das.
DS-Record beim Registrar einreichen
Der öffentliche KSK muss als DS-Record in der übergeordneten Zone landen. Bei der DENIC (.de) und den meisten TLD-Registries gibt es dafür ein Webinterface beim Registrar. Man schickt den öffentlichen KSK hin, der Registrar erstellt daraus einen DS-Record und veröffentlicht ihn neben den NS-Records.
Ob der DS-Record gesetzt ist, lässt sich prüfen, indem man die TLD-Nameserver direkt fragt:
$ dig +short kernel-error.org DS @a0.org.afilias-nst.info 12345 13 2 A1B2C3D4...
Prüfen ob alles funktioniert
Mit dig +dnssec eine signierte Domain abfragen. Das ad-Flag (Authenticated Data) in der Antwort zeigt, dass die DNSSEC-Validierung erfolgreich war:
$ dig +dnssec kernel-error.org @8.8.8.8 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
Grafisch lässt sich die gesamte Vertrauenskette mit DNSviz darstellen — einfach die eigene Domain einsetzen:
Stolpersteine
DNSSEC-Signaturen machen DNS-Antworten deutlich größer als die 512 Bytes, die klassisches DNS über UDP erlaubt. EDNS (RFC 6891) hebt dieses Limit auf. Das ist seit 1999 spezifiziert, aber manche Firewalls und Billig-Router haben damit immer noch Probleme — sie filtern große UDP-Pakete oder EDNS-Optionen.
Wichtig: Gehen die Schlüssel verloren oder die signierte Zonendatei brennt ab, hat man ein Problem. Vor jeder großen Änderung (Key-Rollover, Algorithmus-Wechsel) immer die längste TTL der Zone abwarten. Sonst sind gecachte Antworten mit der alten Signatur noch gültig, während die neue Signatur schon aktiv ist — die Zone wird temporär nicht validierbar.
Meinen „analogen“ DNSSEC-Masterplan dazu habe ich mir damals aufgezeichnet:
Was man auf DNSSEC aufbauen kann
Wenn die Zone signiert ist, lassen sich darüber weitere Sicherheitsmechanismen verteilen:
- DANE/TLSA — TLS-Zertifikate per DNS verifizieren, unabhängig von CAs.
- SSHFP — SSH-Hostkey-Fingerprints im DNS hinterlegen. Siehe auch: DNSSEC und SSHFP unter Linux Mint zum Laufen bringen.
- GPG-Keys im DNS — öffentliche Schlüssel über DNS verteilen.
Wer einen DNSSEC-validierenden Resolver sucht — dns.kernel-error.de bietet DNS over TLS und DNS over HTTPS mit DNSSEC-Validierung., DNSSEC: KSK auf 4096 Bit aktualisieren und SHA-512 vorbereiten, OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen
Chronik
Dieser Beitrag wurde 2010 veröffentlicht und dokumentiert meine DNSSEC-Einführung über mehrere Jahre:
- November 2010 — Erste Signierung von kernel-error.org (NSEC3RSASHA1, 4096 Bit).
- Februar 2011 — DS-Record für kernel-error.org endlich in der .org-Zone veröffentlicht. DENIC kündigt Signierung der .de-TLD an.
- Februar 2011 — kernel-error.de signiert, über DENIC-Testbed validierbar.
- Juni 2011 — DENIC signiert .de offiziell, DS-Records in der Root-Zone.
- Februar 2012 — kernel-error.com ebenfalls signiert. Alle drei Domains komplett.
- Mai 2012 — GPG-Keys und SSHFP-Records im DNS hinterlegt.
- August 2013 — DANE/TLSA-Records für alle TLS-Dienste eingerichtet.
- 2024 — Algorithmus-Wechsel auf ECDSAP256SHA256 (Algorithmus 13). Anleitung oben entsprechend aktualisiert.
Siehe auch: DNSSEC und DANE
Fragen? Einfach melden.
Links ist ein Standfuss mit Magnet. Dieser hält auch bei 50km/h noch auf dem Autodach.
Auf diesen wird nun die Antenne (Mitte) geschraubt. Dieses kann man nun ohne Probleme in die
Orinoco Gold PCMCIA-Karte (rechts) stecken, hier ist auch ein Prism II Chip verbaut.
Fertig….. Der Empfang ist einfach nur geil. Egal
wo man nun genau sitzt!
Jetzt fehlt nur noch ein Notebook.
Ich nutze ein Fujitsu Siemens LifeBook E 7110! Linux arbeiten mit
allen Komponenten in diesem Notebook ohne Probleme und gebastel zusammen.
Um Funknetzwerke zu finden, muss die Wlan-Karte in den Monitor Mode gesetzt werden.
Im Monitor Mode nimmt die Karte alle Packet an. Egal aus welchem Netz sie kommen und egal
für wen sie bestimmt sind.
Der Standart Linux-Kernel kann die Karte nicht in den Monitor Mode setzen. Dieser muss also gepatch
werden oder es muss ein passendes Kernelmodul erstellt werden. Am einfachsten geht es so:
0. Mit iwpriv schauen ob der eigene Kernel vielleicht schon gepatcht wurde!
1. Quellen des aktuellen Kernels installieren.
2. gcc installieren.
3. Die aktuelle Konfiguration des Kernels ins root der Kernelquellen legen.
Unter Suse: zcat /proc/config.gz > .config
Als Root unter /usr/src/linux
4. Saug dir 
Dieses sollte vorher noch konfigurieren werden;-). Es gibt unter /etc/kismet/ die Datei:
kismet.conf.
In dieser müssen wir zwei Änderungen vornehmen.
Beim Punkt „suiduser=“ tragen wir hinter dem = unseren Usernamen ein mit dem wir auf der Linux
Kiste arbeiten.
Am Punkt „source=“ tragen wir hinter dem = folgendes ein: orinoco,eth1,orinocosource
Wobei wir eth1 natürlich gegebenenfalls gegen unsere Wlan-Karte austauschen!
Ein „sudo kismet“ in der Userkonsole sollte nun das Programm starten und sogleich nach Netzen
suchen.
Haben wir eines gefunden und wollen erst einmal nachschauen, was genau dort durch die Gegend fliegt.
Brauchen wir dazu ein Programm mit dessen Hilfe wir den Datenstrom auslesen können. Dieses erledigt Ethereal
super. Später ist es auch drin, mit diesem Programm sehr komplexe Filterungen auf den Datenstrom anzuwenden.
Da wir aber nur die Daten annehmen können welche auf unserem Channel gesendet werden.
Betreibt Kismet Channelhopping. D.h.: Kismet springt im ms. Takt vom Einen in den Anderen Channel.
Wenn wir einen konstanten Datenstrom mitlesen wollen, ist das scheisse! Wir können dann ja nur die Daten
mitlesen, wenn wir auch gerade im passenden Channel sind. Daher beenden wir Kismet und setzen die Karte von Hand
in den Monitor Mode und den passenden Channel. Dieses geht als User-Root so:
iwpriv eth1 monitor 1 1
eth1 ist in diesem Fall die Wlan-Karte, mit monitor 1 sagen wir das der Monitor Mode gestartet werden soll
(mit iwpriv eth1 monitor 0 würden wir ihn also wieder beenden) und die letzte 1 gibt den Channel an, in
welchem die Karte gesetzt werden soll.
Ethereal kann nun mit den im Bild angezeitgen Optionen gestartet werden.
Nun würde Ethereal JEDES Datenpaket welches im Channel 1 durch die Gegend fliegt
auffangen und speichern.
Sollte auf dem AccessPoint eine Mac-Adressenfilterung eingerichtet sein, so müssen wir uns um
diese nicht weiter kümmern. Wir versuchen uns ja nicht am AP anzumelden, sondern hören ja einfach
nur zu. Interessant wird es erst, wenn das Netzwerk die Daten verschlüsselt überträgt.
Wir bekommen zwar immer noch alles, können damit aber nichts mehr anfangen.
Es ist aber Möglich WEP-Verschlüsselungen aufzubrechen, den Schlüssel zu errechnen.
AirSnort ist ein Programm welches genau das macht. Es kann die Karte in den Monitor-Mode
packen. Wenn vom User gewünscht auch gleich noch in den passenden Channel. Ab diesem Zeitpunkt
sammelt Airsnort die verschlüsselten Packete. Bei einer 128 Bit WEP Verschlüsselung muss es ca.
6 Millionen Pakete sammeln.
Das liegt daran, dass für die WEP Verschlüsselung nur ein begrenzter
Zufallszahlenraum zur Verfühgung steht. Nach ca. 6 Millionen Paketen wiederholen sich in jedem Fall Teile.
Mit diesen kann AirSnort nun rechnen.
Hat AirSnort den Schlüssel erfolgreich errechnet, tragen wir ihn einfach mit iwpriv bei unserer Wlan-Karte
ein und schon kann es weiter gehen!
WEP Verschlüsselungen mit einer Stärke von 256 Bit sind im Vergleich noch sehr sicher. Es würde
eine sehr lange Zeit dauern die notwendigen Pakete zu sammeln. Leider arbeiten kaum Karten mit 256 Bit WEP
Schlüsseln. Es gibt auch eine neue Methode: WPA… WPA gilt bisher als sicher.
Ich stufe mein Wlan immer noch als ein feindliches Netz ein. So behandelt es auch meine Firewall und so sollte es
jeder Admin behandeln. Es ist und bleibt wohl noch über lange Zeit ein grosses Sicherheitsproblem.
Genauere Fragen zu diesem Thema beantworte ich gerne per E-Mail!
Solltest du Fragen stellen achte bitte darauf deine Frage so genau wie irgend
möglich zu stellen. Beschreibe kurz dein Problem, haue mich nicht mit log und
configs zu und habe etwas Geduld. Ich bekomme nicht nur eine E-Mail am Tag. Darum
werde ich ganz sicher nicht auf unfreundliche und ungenaue Fragen antworten. KEINER
hat ein Recht drauf von mir Support zu bekommen!!
