DNSSec: Difference between revisions

From
Jump to navigation Jump to search
(→‎Gesammeltes Zeugs: Link Folien: C. Strohtmann: Lesser known DNS tools and BIND tricks)
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:ITS-Workshop]] [[Category:ITS-Workshop2011]]

=== DNS - Domain Name System ===
=== DNS - Domain Name System ===
* Umwandlung von Hostnamen in IP-Adressen
* Umwandlung von Hostnamen in IP-Adressen
Line 12: Line 14:


=== Geschichte ===
=== Geschichte ===
* ursprüngliche DNSSEC-Version (RFC 2535) war auf Grund einer zu aufwändigen Schlüsselverwaltung für die Praxis untauglich
* ursprüngliche DNSSEC-Version von 1999 (RFC 2535) war auf Grund einer zu aufwändigen Schlüsselverwaltung für die Praxis untauglich
* 2005 wurde eine Neufassung veröffentlicht
* 2005 wurde eine Neufassung veröffentlicht
* 2005 wurde mit der schwedischen .se-Domain erstmals eine Top Level Domain signiert
* 2005 wurde mit der schwedischen .se-Domain erstmals eine Top Level Domain signiert
* 2010 wurde DNSSEC auf allen 13 Rootservern eingeführt
* 2010 wurde DNSSEC auf allen 13 Root-Servern eingeführt
* ab 2011 ist die .de-Zone signiert
* ab 2011 ist die .de-Zone signiert
* Aktuell
* Aktuell:
** TLDs .com, .net, .org, .eu, u.a. wurden bisher signiert
** TLDs .com, .net, .org, .eu, u.a. wurden bisher signiert
** TLD DNSSEC Report (27.09.2011) (http://stats.research.icann.org/dns/tld_report/)
** TLD DNSSEC Report (13.02.2012) (http://stats.research.icann.org/dns/tld_report/)
*** 310 TLDs in der Root-Zone insgesamt
*** 312 TLDs in der Root-Zone insgesamt
*** 76 TLDs sind signiert
*** 88 TLDs sind signiert
*** 72 TLDs haben Trust Anchors als DS Records in der Root-Zone
*** 84 TLDs haben Trust Anchors als DS Records in der Root-Zone
*** 3 TLDs haben Trust Anchors im ISC DLV
*** 3 TLDs haben Trust Anchors im ISC DLV


Line 34: Line 36:
** Flags Field definiert die Art des Schlüssels: 256 steht für ZSK, 257 für KSK
** Flags Field definiert die Art des Schlüssels: 256 steht für ZSK, 257 für KSK
** dritter Wert spezifiziert den benutzten Algorithmus: 5 steht für RSA/SHA-1
** dritter Wert spezifiziert den benutzten Algorithmus: 5 steht für RSA/SHA-1
bund.de. 12465 IN DNSKEY 256 3 5 AwEAAc/oWW3oNT[...]gm2j+T


* RRSIG (Resource Record Signature)
* RRSIG (Resource Record Signature)
** Signatur des übergeordneten Resource Records
** Signatur des übergeordneten Resource Records
bund.de. 19872 IN A 77.87.229.48
bund.de. 19872 IN RRSIG A 7 2 21600 20111009075801 20110929075801 20369 bund.de. ya[...]83YhKU1 RL4=


* NSEC/NSEC3 (Next Entry)
* NSEC (Next Entry)
** nächster Eintrag im Zonefile
** nächster Eintrag im Zonefile
** ist der letzte Eintrag erreicht, zeigt NSEC auf den ersten Eintrag
** ist der letzte Eintrag erreicht, zeigt NSEC auf den ersten Eintrag
** Realisierung von negativen Antworten
** Realisierung von negativen Antworten: Host existiert nicht
isc.org. 2842 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
fw-lab.isc.org. 2842 IN NSEC gctip.isc.org. A AAAA RRSIG NSEC


* DS (Delegation Signer)
* DS (Delegation Signer)
** Signierung eines Schlüssel einer untergeordneten Zone
** Signierung eines Schlüssel einer untergeordneten Zone
** erzeugt Chain of Trust
** erzeugt Chain of Trust
bund.de. 84457 IN DS 10923 7 2 9C621225960D5837BB1CFE49F421CF341422AB206414 E454245F055F 5581C75D


=== Nichtexistierende Namen ===
=== Nichtexistierende Namen ===
* NSEC Resource Record verweist auf den nächsten Eintrag im geordneten Zonefile
* NSEC Resource Record verweist auf den nächsten Eintrag im geordneten Zonefile
* dadurch ist es möglich zu erkennen, dass ein bestimmter Name nicht existiert
* dadurch ist es möglich zu erkennen, dass ein bestimmter Name nicht existiert
* Problem: Verkettung aller Records ermöglicht es, den gesamten Inhalt per Zone Walking auszulesen
* Problem
* Lösung: NSEC3
** Verkettung aller Records ermöglicht es, den gesamten Inhalt per Zone Walking auszulesen
* NSEC3-Eintrag (RFC 5155) der anstelle von Hostnamen im Klartext nur gehashte Namen zurückliefert
* Lösung
TBA6S17RFL1M8L1L06KF9DTAET7TKS2A.bund.de. 10193 IN NSEC3 1 0 10 37E096 TBUJFOEI8SCLRABJ8FQE0UVIG0A7RCCF MX RRSIG
** NSEC3-Eintrag (RFC 5155) der anstelle von Hostnamen im Klartext nur gehashte Namen zurückliefert
VHJQEUA1N2QUTMN6FNSK95HB0N1S6J5P.bund.de. 10193 IN NSEC3 1 0 10 37E096 VJ06QLCFP5E1HKLMC8O8HASDAC8CVFRA A NS SOA MX RRSIG DNSKEY NSEC3PARAM
** BIND unterstützt NSEC3 seit Version 9.6
* BIND unterstützt NSEC3 seit Version 9.6


=== Kryptographie ===
=== Kryptographie ===
Line 64: Line 73:
** Zone Signing Key (ZSK)
** Zone Signing Key (ZSK)
*** signiert die einzelnen Resource Records eines Zonefiles
*** signiert die einzelnen Resource Records eines Zonefiles
*** kürzer (z.B. 1024)
*** kürzer (z.B. 1024 Bit)
*** kurzlebiger (z.B. 30 Tage)
*** kurzlebiger (z.B. 30 Tage)
** Key Signing Key (KSK)
** Key Signing Key (KSK)
*** signiert den ZSK
*** signiert den ZSK
*** länger (z.B. 2048)
*** länger (z.B. 2048 Bit)
*** langlebiger (z.B. 2 Jahre)
*** langlebiger (z.B. 2 Jahre)


* von einer Parent- zu einer Child-Zone wird das Vertrauen über den DS RR hergestellt
* von einer Parent- zu einer Child-Zone wird das Vertrauen über den DS RR hergestellt
[[Image:Chain.png]]

* ganz oben in der Chain of Trust ist ein KSK (Secure Entry Point oder Trusted Anchor)
* ganz oben in der Chain of Trust ist ein KSK (Secure Entry Point oder Trusted Anchor)
* der darunter liegende Zonenbaum dient als Secure Island
* der darunter liegende Zonenbaum dient als Secure Island
* Island of Security: die Gesamtmenge der durch einen einzigen Schlüssel gesicherten Menge von Zonen
* Island of Security bezeichnet also die Gesamtmenge der durch einen einzigen Schlüssel gesicherten Zonen
[[Image:Islands.png]]

[[Image:Islands2.png]]


* ein Resource Record kann auch mit verschiedenen Schlüsseln signiert werden
* ein Resource Record kann auch mit verschiedenen Schlüsseln signiert werden
Line 82: Line 96:
* DNSSEC-fähiger Resolver nötig
* DNSSEC-fähiger Resolver nötig
** die meisten Stub-Resolver dazu nicht in der Lage (z.B. der in der Libc eingebaute)
** die meisten Stub-Resolver dazu nicht in der Lage (z.B. der in der Libc eingebaute)
** Lösung: Installation eines DNSSec-fähigen Nameservers im lokalen Netz (z.B. Bind ab Version 9.3)
** Workaround: Installation eines DNSSec-fähigen Nameservers im lokalen Netz (z.B. BIND ab Version 9.3)


* DNSSEC-fähiger Resolver validiert Signaturen auf den Resource Records
* DNSSEC-fähiger Resolver validiert Signaturen auf den Resource Records
Line 96: Line 110:
==== Manuelle Schlüsselpflege ====
==== Manuelle Schlüsselpflege ====
* lokale Whitelist
* lokale Whitelist
* Bind (named.conf):
* BIND (named.conf):


trusted­-keys {
trusted­-keys {
Line 113: Line 127:
** aktuell ist diese Voraussetzung nicht gegeben
** aktuell ist diese Voraussetzung nicht gegeben


* Bind (named.conf):
* BIND (named.conf):


trusted­-keys {
trusted­-keys {
Line 124: Line 138:
* ISC bestätigt die Glaubwürdigkeit
* ISC bestätigt die Glaubwürdigkeit
* je Zone eine DLV-Query zu zone.dlv.isc.org
* je Zone eine DLV-Query zu zone.dlv.isc.org
[[Image:DLV.png]]

* Resolver muss den DNSKEY von dlv.isc.org kennen
* Resolver muss den DNSKEY von dlv.isc.org kennen
* Bind (named.conf):
* BIND (named.conf):


options {
options {
...
dnssec-­lookaside
dnssec-­lookaside
. trust-­anchor dlv.isc.org.;
. trust-­anchor dlv.isc.org.;
Line 137: Line 152:
};
};


=== DNSSEC für eigenen Zone (Bind) ===
=== DNSSEC für eigene Zone (BIND) ===
* Schlüssel für Zone erzeugen (ZSK und KSK)
* Schlüssel für Zone erzeugen (ZSK und KSK)
$ dnssec­-keygen ­-a RSASHA1 ­-b 1024 ­-n ZONE example.org
$ dnssec­-keygen ­-a RSASHA1 ­-b 1024 ­-n ZONE example.org
Line 145: Line 160:
$ dnssec-­signzone example.org
$ dnssec-­signzone example.org


* DNSSEC-Unterstützung im Bind Nameserver einschalten
* DNSSEC-Unterstützung im BIND einschalten (named.conf)


options {
options {
...
dnssec-­enable yes;
dnssec-­enable yes;
};
};

zone "example.org" {
zone "example.org" {
file "example.org.signed";
file "example.org.signed";
...
};
};


* Eventuell: Anmelden bei http://dlv.isc.org
* Eventuell: Anmeldung bei http://dlv.isc.org


* Maintenance
* Maintenance
** regelmäßig Re-Signieren
** regelmäßig Re-Signieren
** regelmäßige Wechsel des ZSK (KSK)
** regelmäßige Wechsel des ZSK (KSK)

=== Automatische Signierung ===
* BIND ermöglicht auch eine automatische Signierung
* Schlüssel mit Ablaufdatum erzeugen
dnssec-keygen -P now -A now+10mi -I now+1h -D now+2h -b 1024 -K /etc/bind/example.org.keystore/ example.org

* Neuen Schlüssel aktivieren
$ rndc loadkeys example.org
$ rndc sign example.org


=== Anfragen ===
=== Anfragen ===
* Bei einer Anfrage muss das DNSSEC OK Flag (DO) gesetzt sein, um DNSSEC-Einträge zu erhalten
* Bei einer Anfrage muss das DNSSEC OK Flag (DO) gesetzt sein, um DNSSEC-Einträge zu erhalten
* Antwort mit dem AUTHENTICATED DATA Flag (AD), damit wird dem Client mitgeteilt, daß auf dem angefragten Resolver die Prüfung erfolgreich war
* Antwort mit dem AUTHENTICATED DATA Flag (AD), damit wird dem Client mitgeteilt, dass auf dem angefragten Resolver die Prüfung erfolgreich war
* das Setzen des DO-Flags ist nur im Rahmen der DNS-Erweiterung EDNS möglich
* das Setzen des DO-Flags ist nur im Rahmen der DNS-Erweiterung EDNS möglich
* EDNS ist für die größeren Pakete (UDP bis 4k statt 512B) erforderlich, welche bei der Übertragung von Schlüsseln und Signaturen nötig sind
* EDNS ist für die größeren Pakete (UDP bis 4k statt 512B) erforderlich, welche bei der Übertragung von Schlüsseln und Signaturen nötig sind
Line 181: Line 203:
$ dig +topdown +sigchase +multiline +trusted-key=./trusted-key.key -t A www.ripe.net.
$ dig +topdown +sigchase +multiline +trusted-key=./trusted-key.key -t A www.ripe.net.


* Welche Optionen sind wichtig?
* Weitere wichtige Optionen:
** +search: Einträge in der /etc/resolv.conf benutzen
** +search: Einträge in der /etc/resolv.conf benutzen
** @141.20.20.50: der zu befragende Nameserver
** @141.20.20.50: der zu befragende Nameserver

* Beispiele
* Beispiele:
$ dig +search bund.de @141.20.20.50

$ dig +dnssec hu-berlin.de
; <<>> DiG 9.7.3 <<>> '''+dnssec''' hu-berlin.de.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16370
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;hu-berlin.de. IN A
;; ANSWER SECTION:
hu-berlin.de. 172264 IN A 141.20.1.139
;; AUTHORITY SECTION:
de. 85387 IN NS a.nic.de.
[...]
de. 85387 IN RRSIG NS 8 1 86400 20119[...]000 22248 de. GAM[...]8X xGs=
;; Query time: 0 msec
;; SERVER: 192.168.2.10#53(192.168.2.10)
;; WHEN: Thu Sep 29 15:14:35 2011
;; MSG SIZE rcvd: 309

$ dig +dnssec bund.de
$ dig +dnssec bund.de
; <<>> DiG 9.7.3 <<>> '''+dnssec''' bund.de.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21275
;; flags: qr rd ra '''ad'''; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bund.de. IN A
;; ANSWER SECTION:
bund.de. 19872 IN A 77.87.229.48
bund.de. 19872 IN '''RRSIG''' A 7 2 21600 20111009[...]01 20369 bund.de. ya[...]RL4=
;; AUTHORITY SECTION:
bund.de. 3521 IN NS xenon.bund.de.
bund.de. 3521 IN RRSIG NS 7 2 21600 2011100[...]1 20369 bund.de. s5z[...]us=
[...]
;; Query time: 0 msec
;; SERVER: 192.168.2.10#53(192.168.2.10)
;; WHEN: Thu Sep 29 15:14:19 2011
;; MSG SIZE rcvd: 496

$ dig +search bund.de @141.20.20.50
$ dig +dnssec -t DNSKEY bund.de
$ dig +dnssec -t DNSKEY bund.de
$ dig +dnssec a.xxx.schlittermann.de
$ dig +dnssec a.xxx.schlittermann.de


=== Unsere Konfigurationen ===
=== Unsere Konfiguration ===


=== Probleme ===
==== Benutzte Software ====
* Debian Linux 6.0
* ISC BIND 9.7.3
* ISC DHCPD
* dig, nslookup, tcpdump, wireshark
* dnssec-tools (validator)
* ldnsutils (drill)
* DNSSec Validator (Firefox Extension)
* Vim ;)

==== Anmerkungen ====
* Für jede Zone sollte ein eigenes Verzeichnis zur Verfügung stehen
* Empfohlener Ort für von Diensten veränderlicher Dateien auf Debian Systemen: /var/lib/$dienst/
* daher sollten alle Zonendateien dort in jeweils eigenen Verzeichnissen untergebracht sein
* Beispiel:
/var/lib/bind/chaos.local/
/var/lib/bind/chaos.local/keystore/
/var/lib/bind/chaos.local/temp/
* Wichtig ist es, hier auf die Berechtigungen zu achten: insbesondere bei dynamischer Aktualisierung, bzw. bei autosign, sind Schreibberechtigungen auf einigen dieser Dateien/Verzeichnisse für den named, bzw den Account unter dem er läuft (bei Debian "bind"), nötig

* Will man NSEC3 benutzen muss ein zu folgendem ähnlicher NSEC3PARAM RR eingefügt werden:
NS kudamm.chaos.local.
A 192.168.2.13
MX 10 chaos.local.
NSEC3PARAM 1 0 10 1234567890
* Ist autosign aktiviert und der NSEC3PARAM Eintrag in der Zonendatei wird so automatisch mit NSEC3 gearbeitet, fehlt der Eintrag in der Zonendatei wird NSEC verwendet

* Config ausgeben lassen ohne Kommentare:
$ named-checkconf -p

=== Mögliche Probleme mit DNSSec ===
* ungültige, veraltete Signaturen: Nichtereichbarkeit eines DNS-Teilbaums
* ungültige, veraltete Signaturen: Nichtereichbarkeit eines DNS-Teilbaums
* mehr Traffic (EDNS)
* mehr Traffic (EDNS)
Line 204: Line 308:
** Angriffsmöglichkeiten auf die Vertrauensketten
** Angriffsmöglichkeiten auf die Vertrauensketten
** Lösung: öffentlichen Schlüssel des Vertrauensursprungs auf anderem Weg verteilen
** Lösung: öffentlichen Schlüssel des Vertrauensursprungs auf anderem Weg verteilen

=== Was gibt es noch? ===


=== Beispieldomains ===
=== Beispieldomains ===
Line 223: Line 325:
** http://www.dnssec-tools.org/
** http://www.dnssec-tools.org/


* DNSSEC Validator
* DNSSEC Validator (teils fehlerhafte Anzeige, wahrscheinlich auf Cache zurueckzufuehren)
** Firefox-Extension
** Firefox-Extension
** http://www.dnssec-validator.cz/setlang/?language=en
** http://www.dnssec-validator.cz/setlang/?language=en)

* drill extension (nicht getestet)
** Firefox-Extension
** http://nlnetlabs.nl/projects/drill/drill_extension.html

* Dnssec-Trigger (nicht getestet)
** http://www.nlnetlabs.nl/projects/dnssec-trigger/


=== Quellen ===
=== Quellen ===
Line 241: Line 350:
** http://de.wikipedia.org/wiki/DNSSEC
** http://de.wikipedia.org/wiki/DNSSEC


* BIND 9 Administrator Reference Manual
=== Struktur Vortrag ===
** Internet Systems Consortium
* Einführung DNS
** http://www.bind9.net/arm97.pdf
** was ist das und wie funktioniert es?
** Wireshark Bild: DNS-Pakete
** Angriffsmöglichkeiten
* DNSSec
** Einführung
** RFCs
** Geschichte
** neue RRs
** Stand heute
*** root-Zone, TLDs
*** Software-Unterstützung: Resolver, Firefox-Plugin
** DLV
** Wireshark Bild: DNSSec-Pakete
* Unsere Konfiguration
** Netztopologie, Installation, Versionen
** Konfigurationsdateien mit DNSSec-Optionen: named.conf, ...
** Dig, Drill: Parameter, Ausgaben
** Einzelne Konfigstufen:
*** statische IPs, manuelle Signierung, ein DNS-Server
*** statische IPs, manuelle Signierung, zwei DNS-Server (1. Zone, 2. Validierung)
*** dynamische IPs (DHCP), automatische Signierung, Schlüsselupdates
*** (zweistufige Hierarchie)


=== ToDo ===
=== Gesammeltes Zeugs ===
* Client Tools, Bibliotheken und Hardware DNSSec Unterstützung?
* Domain bei DLV anmelden
** Screenshots sind gemacht
** der Key der dort hochgeladen werden muss ist der 257er: "The record you want to paste should be the entire record, which would start with your domain name and end with a rather long text string. For example: isc.org. 7200 IN DNSKEY 257 3 5 BEAAAAOhHQDBr...yBNsO70aEFTd"
* zweistufige DNS Hierarchie aufbauen -> Chain of Trust
* Empfehlungen für KSK, ZSK (Algorithmus, Länge, Haltbarkeit, Schlüsseltausch, ...)
* alte Resolver ohne DNSSec: Probleme?
* wie Schlüssel zurückziehen (TTL, ...)?
* Reverse Zone signieren
* Zertifikate bei AutoSign wo speichern, müssen die immer da sein?
* Unbound
* Phreebird
* Demo?
* alles ordentlich dokumentieren
** Beispiele RRs
** Beispiele Anfragen
** Wireshark Bilder
* Vortragsfolien vorbereiten


* Weitere Links
=== Temporäres Zeugs ===
** http://strotmann.de/~cas/bind-tricks-talk/ Folien zum Vortag "Lesser known DNS tools and BIND tricks" von Carsten Strotmann, GUUG, August 2012
** http://www.ukuug.org/events/spring2011/timetable/dnssec-signingtools.pdf
** http://ripe60.ripe.net/presentations/Damas-BIND_9.7_-_DNSSE_for_humans.pdf


----
rfcliste zu dnssec: http://www.dnssec.net/rfc


rfcliste zu dns: http://www.bind9.net/rfc
* RFC-Liste zu DNS: http://www.bind9.net/rfc
* RFC-Liste zu DNSSec: http://www.dnssec.net/rfc


----
----


Benutzte Tools:
* ISC Bind 9.7.3
* dig
* dnssec-tools validator (Debianpaket in stable veraltet, selbst compilieren)
* drill
* drill
* trust key erstellen:
dig +dnssec -t DNSKEY dlv.isc.org >> dlv.trusted.key
* alles rauslöschen ausser: "dlv.isc.org. IN DNSKEY 257 ....." (die zahl zwischen dlv.isc.org und IN muss auch weg)
drill -DS dlv.isc.org -k dlv.trusted.key


----
----


openssl base64 -e -in dateimitgeheimnis >> dateimitgeheimnisbase64
drill:
trust key erstellen:
dig +dnssec -t DNSKEY dlv.isc.org >> dlv.trusted.key
alles rausloeschen ausser: "dlv.isc.org. IN DNSKEY 257 ....."
(die zahl zwischen dlv.isc.org und IN muss auch weg)
drill -DS dlv.isc.org -k dlv.trusted.key


dnssec-keygen -a HMAC-MD5 -b 128 -n HOST kudamm.chaos.local
drill stecker rausziehn reagiert anders als dig


----
----


* http://dnsviz.net/d/heise.de/dnssec/
openssl base64 -e -in dateimitgeheimnis >> dateimitgeheimnisbase64


----
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST kudamm.chaos.local

dig +dnssec -t DNSKEY chaos.local |grep 257 > trusted_chaos

* trusted chaos bearbeiten

drill -DS mitte.chaos.local -k trusted_chaos


----
----


* Updatedienst mit Key versorgen
http://dnsviz.net/d/heise.de/dnssec/
rndc -s localhost -k /etc/bind/rndc.key reload

* falls "forward map from ... FAILED: Has an address record but no DHCID, not mine."
* in dhcpd.conf hinzufuegen:
update-conflict-detection false;


----
----


dnssec-keygen -P now -A now+10mi -I now+1h -D now+2h -b 512 -r /dev/random -K /etc/bind/chaos.keystrore/ chaos.local
dig +dnssec -t DNSKEY chaos.local |grep 257 > trusted_chaos


rndc loadkeys chaos.local (sonst passiert nix)
trusted chaos bearbeiten


dann drill -DS mitte.chaos.local -k trusted_chaos
dig +dnssec -t DNSKEY chaos.local @localhost


----
CHASE SUCCESSFUL :)

* neue IP (Leaseverlaengerung und DNS-Aktualisierung):
dhclient -i eth0
* in der dhcpclientconfig muss senthostname gesetzt sein (nur hostname, nicht fqdn)


----
----


http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-bind-rndc.html
updatedienst mit key versorgen
rndc -s localhost -k /etc/bind/rndc.key reload


----
falls "forward map from ... FAILED: Has an address record but no DHCID, not mine."

in dhcpd.conf hinzufuegen:
* Cron:
update-conflict-detection false;

*/10 * * * * bind ( dnssec-keygen -P now -A now+2mi -I now+4mi -D now+6mi -b 512 -r /dev/urandom -K /etc/bind/chaos.keystore/ chaos.local & rndc loadkeys chaos.local & rndc sign chaos.local)
*/1 * * * * root ( dig +dnssec -t DNSKEY chaos.local @localhost >> /tmp/`date +\%s` )
*/1 * * * * root ( dig +dnssec mitte.chaos.local @localhost >> /tmp/`date +\%s` )

* Achtung: urandom nur zum testen benutzen!


----
----


* Serial
dnssec-keygen -P now -A now+10mi -I now+1h -D now+2h -b 512 -r /dev/urandom -K /etc/bind/chaos.keystrore/ chaos.local #urandom dev ohne randomness (geht schnell bringt aber nicht viel)
* wenn man statt dem ueblichen format "yyyymmtt..." "yymmtt..." nimmt, hat man auch mehr als genug
* Beispiel:
** alt: 2011093000-2011093099 : 100 pro tag
** neu: 1109030000-1109309999: 10000 pro tag, reicht fuer mehrere Aktualisierungen pro Minute und die naechsten 80+ Jahre


----
dann rndc loadkeys chaos.local (sonst passiert nix)


* Code fuers zonewalking wip
dig +dnssec -t DNSKEY chaos.local @localhost
* dlv.isc.org nur NSEC
* unterliegende Einträge ebenfalls
** nur Stichproben gemacht, sieht aber so aus als sei hier überall nur NSEC
** sollte möglich sein Zonenverwaltenden DNS dann auf NSEC3 einzustellen
** allerdings bleiben die Zonen sichtbar, da scheinbar alles was von dlv.isc.org signiert ist nur NSEC kann


----
----


* NSEC3 is not recommended unless there is a pressing need for the features NSEC3 provides. It is expensive for both the server and the client. Most zones do not need the addition expense incured by the use of NSEC3. (http://www.isc.org/software/bind/new-features/9.6)
neue ip (leaseverlaengerung und dnsaktualisierung) auf mahrzahn - neumarzahn:
dhclient -i eth0
(in der dhcpclientconfig muss senthostname gesetzt sein (nur hostname, nicht fqdn)


----
----


* named-journalprint
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-bind-rndc.html
/var/lib/bind/chaos.local.jnl

----

dnssec-keygen -3 -r /dev/urandom chaos.local
dnssec-keygen -3 -r /dev/urandom -fk chaos.local
mv K* keystore_chaoslocal
chown bind keystore_chaoslocal/*
dnssec-signzone -u -K keystore_chaoslocal/ chaos.local


----
----


* TYPE65534: Eintrag der Stand der laufenden Signierung angibt
(urandom nur zum testen benutzen!)
* http://svsf40.icann.org/bitcache/60a3f222cee51eb3411c6cdf3829814a552ad0b8?vid=22999&disposition=attachment&op=download
*/10 * * * * bind ( dnssec-keygen -P now -A now+2mi -I now+4mi -D now+6mi -b 512 -r /dev/urandom -K /etc/bind/chaos.keystore/ chaos.local & rndc loadkeys chaos.local & rndc sign chaos.local)
*/1 * * * * root ( dig +dnssec -t DNSKEY chaos.local @localhost >> /tmp/`date +\%s` )
*/1 * * * * root ( dig +dnssec mitte.chaos.local @localhost >> /tmp/`date +\%s` )

Latest revision as of 09:44, 4 August 2012


DNS - Domain Name System

  • Umwandlung von Hostnamen in IP-Adressen
  • hierarchisches dezentralisiertes System
  • verschiedene Angriffsszenarien: z.B. DNS-Spoofing, Cache Poisoning

DNSSEC

  • IETF (Internet Engineering Task Force)-Standard
    • DNSSEC Intro RFC (RFC 4033)
    • DNSSEC Records RFC (RFC 4034)
    • DNSSEC Protocol RFC (RFC 4035)
  • Sicherstellung der Authentizität und Integrität von DNS-Abfragen

Geschichte

  • ursprüngliche DNSSEC-Version von 1999 (RFC 2535) war auf Grund einer zu aufwändigen Schlüsselverwaltung für die Praxis untauglich
  • 2005 wurde eine Neufassung veröffentlicht
  • 2005 wurde mit der schwedischen .se-Domain erstmals eine Top Level Domain signiert
  • 2010 wurde DNSSEC auf allen 13 Root-Servern eingeführt
  • ab 2011 ist die .de-Zone signiert
  • Aktuell:
    • TLDs .com, .net, .org, .eu, u.a. wurden bisher signiert
    • TLD DNSSEC Report (13.02.2012) (http://stats.research.icann.org/dns/tld_report/)
      • 312 TLDs in der Root-Zone insgesamt
      • 88 TLDs sind signiert
      • 84 TLDs haben Trust Anchors als DS Records in der Root-Zone
      • 3 TLDs haben Trust Anchors im ISC DLV

Neue DNS Resource Records

  • DNSSEC nutzt gleiche Zugriffsmechanismen wie klassisches DNS
  • bisherige DNS-Einträge werden um kryptographische Signaturen erweitert
  • das System ist abwärtskompatibel
  • DNSKEY
    • öffentlicher Schlüssel einer Zone
    • Flags Field definiert die Art des Schlüssels: 256 steht für ZSK, 257 für KSK
    • dritter Wert spezifiziert den benutzten Algorithmus: 5 steht für RSA/SHA-1
 bund.de. 12465 IN DNSKEY 256 3 5 AwEAAc/oWW3oNT[...]gm2j+T
  • RRSIG (Resource Record Signature)
    • Signatur des übergeordneten Resource Records
 bund.de. 19872 IN A 77.87.229.48
 bund.de. 19872 IN RRSIG A 7 2 21600 20111009075801 20110929075801 20369 bund.de. ya[...]83YhKU1 RL4=
  • NSEC (Next Entry)
    • nächster Eintrag im Zonefile
    • ist der letzte Eintrag erreicht, zeigt NSEC auf den ersten Eintrag
    • Realisierung von negativen Antworten: Host existiert nicht
 isc.org. 2842 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
 fw-lab.isc.org. 2842 IN NSEC gctip.isc.org. A AAAA RRSIG NSEC
  • DS (Delegation Signer)
    • Signierung eines Schlüssel einer untergeordneten Zone
    • erzeugt Chain of Trust
 bund.de. 84457 IN DS 10923 7 2 9C621225960D5837BB1CFE49F421CF341422AB206414 E454245F055F 5581C75D

Nichtexistierende Namen

  • NSEC Resource Record verweist auf den nächsten Eintrag im geordneten Zonefile
  • dadurch ist es möglich zu erkennen, dass ein bestimmter Name nicht existiert
  • Problem: Verkettung aller Records ermöglicht es, den gesamten Inhalt per Zone Walking auszulesen
  • Lösung: NSEC3
  • NSEC3-Eintrag (RFC 5155) der anstelle von Hostnamen im Klartext nur gehashte Namen zurückliefert
 TBA6S17RFL1M8L1L06KF9DTAET7TKS2A.bund.de. 10193 IN NSEC3 1 0 10 37E096 TBUJFOEI8SCLRABJ8FQE0UVIG0A7RCCF MX RRSIG
 VHJQEUA1N2QUTMN6FNSK95HB0N1S6J5P.bund.de. 10193 IN NSEC3 1 0 10 37E096 VJ06QLCFP5E1HKLMC8O8HASDAC8CVFRA A NS SOA MX RRSIG DNSKEY NSEC3PARAM
  • BIND unterstützt NSEC3 seit Version 9.6

Kryptographie

  • Verwendung von asymmetrischer Kryptographie
    • Signieren der zu schützenden DNS-Einträge mit privatem Schlüssel
    • mit zugehörigem öffentlichen Schlüssel kann diese Signatur geprüft werden
  • pro Zone gibt es zwei Schlüssel
    • Zone Signing Key (ZSK)
      • signiert die einzelnen Resource Records eines Zonefiles
      • kürzer (z.B. 1024 Bit)
      • kurzlebiger (z.B. 30 Tage)
    • Key Signing Key (KSK)
      • signiert den ZSK
      • länger (z.B. 2048 Bit)
      • langlebiger (z.B. 2 Jahre)
  • von einer Parent- zu einer Child-Zone wird das Vertrauen über den DS RR hergestellt

Chain.png

  • ganz oben in der Chain of Trust ist ein KSK (Secure Entry Point oder Trusted Anchor)
  • der darunter liegende Zonenbaum dient als Secure Island
  • Island of Security bezeichnet also die Gesamtmenge der durch einen einzigen Schlüssel gesicherten Zonen

Islands.png

Islands2.png

  • ein Resource Record kann auch mit verschiedenen Schlüsseln signiert werden
  • sinnvoll für Übergangsphase bei Schlüsseltausch

Validierung

  • DNSSEC-fähiger Resolver nötig
    • die meisten Stub-Resolver dazu nicht in der Lage (z.B. der in der Libc eingebaute)
    • Workaround: Installation eines DNSSec-fähigen Nameservers im lokalen Netz (z.B. BIND ab Version 9.3)
  • DNSSEC-fähiger Resolver validiert Signaturen auf den Resource Records
    • Prüfung der Integrität (RRSIG)
    • ist eine Antwort nicht korrekt signiert, wird sie verworfen
    • liegt die Anfrage nicht innerhalb eines Secure Island, löst der Resolver die Anfrage mit herkömmlichen Methoden auf
  • Methoden zur Prüfung der Authentizität des öffentlichen Schlüssels
    • Manuelle Schlüsselpflege
    • Chain of Trust
    • Domain Lookaside Validation

Manuelle Schlüsselpflege

  • lokale Whitelist
  • BIND (named.conf):
 trusted­-keys {
   xxx.schlittermann.de. 257 3 5 ...
 };
  • skaliert nicht gut

Chain of Trust

  • eine Zone enthält die Public Keys ihrer Subzonen und signiert diese
  • die Bildung von Vertrauensketten erleichtert das Keymanagement
  • Langfristig
    • komplette DNSSEC-Infrastruktur vom Root-Nameserver über die TLD bis hin zur angefragten Adresse
    • nur noch der Public Key der Root-Zone nötig
    • aktuell ist diese Voraussetzung nicht gegeben
  • BIND (named.conf):
 trusted­-keys {
   . 257 3 5 ...
 };

DLV - Domain Lookaside Validation

  • künstlicher Einstiegspunkt: dlv.isc.org
  • KSK der jeweiligen Zone wird beim ISC (Internet Systems Consortium) hinterlegt
  • ISC bestätigt die Glaubwürdigkeit
  • je Zone eine DLV-Query zu zone.dlv.isc.org

DLV.png

  • Resolver muss den DNSKEY von dlv.isc.org kennen
  • BIND (named.conf):
 options {
   dnssec-­lookaside
     .  trust-­anchor dlv.isc.org.;
 };
 
 trusted-­keys {
   dlv.isc.org. 257 3 5 ...
 };

DNSSEC für eigene Zone (BIND)

  • Schlüssel für Zone erzeugen (ZSK und KSK)
 $ dnssec­-keygen ­-a RSASHA1 ­-b 1024 ­-n ZONE        example.org
 $ dnssec­-keygen ­-a RSASHA1 ­-b 2048 ­-n ZONE -­f KSK example.org
  • Zone signieren
 $ dnssec-­signzone example.org
  • DNSSEC-Unterstützung im BIND einschalten (named.conf)
 options {
   dnssec-­enable yes;
 };
 
 zone "example.org" {
   file "example.org.signed";
 };
  • Maintenance
    • regelmäßig Re-Signieren
    • regelmäßige Wechsel des ZSK (KSK)

Automatische Signierung

  • BIND ermöglicht auch eine automatische Signierung
  • Schlüssel mit Ablaufdatum erzeugen
 dnssec-keygen -P now -A now+10mi -I now+1h -D now+2h -b 1024 -K /etc/bind/example.org.keystore/ example.org
  • Neuen Schlüssel aktivieren
 $ rndc loadkeys example.org
 $ rndc sign example.org

Anfragen

  • Bei einer Anfrage muss das DNSSEC OK Flag (DO) gesetzt sein, um DNSSEC-Einträge zu erhalten
  • Antwort mit dem AUTHENTICATED DATA Flag (AD), damit wird dem Client mitgeteilt, dass auf dem angefragten Resolver die Prüfung erfolgreich war
  • das Setzen des DO-Flags ist nur im Rahmen der DNS-Erweiterung EDNS möglich
  • EDNS ist für die größeren Pakete (UDP bis 4k statt 512B) erforderlich, welche bei der Übertragung von Schlüsseln und Signaturen nötig sind

dig

  • mit dem DNS-Werkzeug dig kann eine Authentifizierung von Recource Records durchgeführt werden
  • die Angabe des Parameters +dnssec weist dig an, zusätzliche DNSSEC-Einträge abzufragen
  • Speichern des öffentlichen Schlüssel der Rootzone in eine Datei:
 $ dig +nocomments +nostats +nocmd +noquestion -t DNSKEY . > trusted-key.key
  • Durchlaufen der Trust of Chain unter Verwendung des gespeicherten Schlüssels:
 $ dig +topdown +sigchase +multiline +trusted-key=./trusted-key.key -t A www.ripe.net.
  • Weitere wichtige Optionen:
    • +search: Einträge in der /etc/resolv.conf benutzen
    • @141.20.20.50: der zu befragende Nameserver
  • Beispiele:
 $ dig +dnssec hu-berlin.de
 
 ; <<>> DiG 9.7.3 <<>> +dnssec hu-berlin.de.
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16370
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;hu-berlin.de. IN A
 
 ;; ANSWER SECTION:
 hu-berlin.de. 172264 IN A 141.20.1.139
 
 ;; AUTHORITY SECTION:
 de. 85387 IN NS a.nic.de.
 [...]
 de. 85387 IN RRSIG NS 8 1 86400 20119[...]000 22248 de. GAM[...]8X xGs=
 ;; Query time: 0 msec
 ;; SERVER: 192.168.2.10#53(192.168.2.10)
 ;; WHEN: Thu Sep 29 15:14:35 2011
 ;; MSG SIZE rcvd: 309
 $ dig +dnssec bund.de
 
 ; <<>> DiG 9.7.3 <<>> +dnssec bund.de.
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21275
 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;bund.de. IN A
 
 ;; ANSWER SECTION:
 bund.de. 19872 IN A 77.87.229.48
 bund.de. 19872 IN RRSIG A 7 2 21600 20111009[...]01 20369 bund.de. ya[...]RL4=
 
 ;; AUTHORITY SECTION:
 bund.de. 3521 IN NS xenon.bund.de.
 bund.de. 3521 IN RRSIG NS 7 2 21600 2011100[...]1 20369 bund.de. s5z[...]us=
 [...]
 ;; Query time: 0 msec
 ;; SERVER: 192.168.2.10#53(192.168.2.10)
 ;; WHEN: Thu Sep 29 15:14:19 2011
 ;; MSG SIZE rcvd: 496
 $ dig +search bund.de @141.20.20.50
 $ dig +dnssec -t DNSKEY bund.de
 $ dig +dnssec a.xxx.schlittermann.de

Unsere Konfiguration

Benutzte Software

  • Debian Linux 6.0
  • ISC BIND 9.7.3
  • ISC DHCPD
  • dig, nslookup, tcpdump, wireshark
  • dnssec-tools (validator)
  • ldnsutils (drill)
  • DNSSec Validator (Firefox Extension)
  • Vim ;)

Anmerkungen

  • Für jede Zone sollte ein eigenes Verzeichnis zur Verfügung stehen
  • Empfohlener Ort für von Diensten veränderlicher Dateien auf Debian Systemen: /var/lib/$dienst/
  • daher sollten alle Zonendateien dort in jeweils eigenen Verzeichnissen untergebracht sein
  • Beispiel:
 /var/lib/bind/chaos.local/
 /var/lib/bind/chaos.local/keystore/
 /var/lib/bind/chaos.local/temp/
  • Wichtig ist es, hier auf die Berechtigungen zu achten: insbesondere bei dynamischer Aktualisierung, bzw. bei autosign, sind Schreibberechtigungen auf einigen dieser Dateien/Verzeichnisse für den named, bzw den Account unter dem er läuft (bei Debian "bind"), nötig
  • Will man NSEC3 benutzen muss ein zu folgendem ähnlicher NSEC3PARAM RR eingefügt werden:
 NS      kudamm.chaos.local.
 A       192.168.2.13
 MX      10 chaos.local.
 NSEC3PARAM 1 0 10 1234567890
  • Ist autosign aktiviert und der NSEC3PARAM Eintrag in der Zonendatei wird so automatisch mit NSEC3 gearbeitet, fehlt der Eintrag in der Zonendatei wird NSEC verwendet
  • Config ausgeben lassen ohne Kommentare:
 $ named-checkconf -p

Mögliche Probleme mit DNSSec

  • ungültige, veraltete Signaturen: Nichtereichbarkeit eines DNS-Teilbaums
  • mehr Traffic (EDNS)
  • durch Kryptografie höheres Risiko für Denial-of-Service-Attacken
  • Weg zwischen Stub-Resolver und Resolver bleibt ungesichert
    • Alternative: eigener Resolver für jeden (z.B. unbound)
  • NSEC Resource Record ermöglicht Zone Walking
    • gelöst durch NSEC3
  • keine Gewähr, dass die Kommunikation mit der so ermittelten IP-Adresse unverfälscht ist
  • öffentliche Schlüssel werden ebenfalls über das DNS-System verteilt
    • Angriffsmöglichkeiten auf die Vertrauensketten
    • Lösung: öffentlichen Schlüssel des Vertrauensursprungs auf anderem Weg verteilen

Beispieldomains

  • Chain of Trust: bund.de
  • DLV: a.xxx.schlittermann.de
  • ungültige Signatur: c.xxx.schlittermann.de

Software

  • dnssec-tools
    • Sammlung von Tools zu DNSSec
    • Besonders nützlich: validator
      • validator ist leider nicht im Debianpaket enthalten, selbst compilieren
    • http://www.dnssec-tools.org/

Quellen

Gesammeltes Zeugs



  • drill
  • trust key erstellen:
 dig +dnssec -t DNSKEY dlv.isc.org  >> dlv.trusted.key
  • alles rauslöschen ausser: "dlv.isc.org. IN DNSKEY 257 ....." (die zahl zwischen dlv.isc.org und IN muss auch weg)
 drill -DS dlv.isc.org -k dlv.trusted.key

 openssl base64 -e -in dateimitgeheimnis >> dateimitgeheimnisbase64
 dnssec-keygen -a HMAC-MD5 -b 128 -n HOST kudamm.chaos.local


 dig +dnssec -t DNSKEY chaos.local |grep 257 > trusted_chaos
  • trusted chaos bearbeiten
 drill -DS mitte.chaos.local -k trusted_chaos

  • Updatedienst mit Key versorgen
 rndc -s localhost -k /etc/bind/rndc.key reload
  • falls "forward map from ... FAILED: Has an address record but no DHCID, not mine."
  • in dhcpd.conf hinzufuegen:
 update-conflict-detection false;

 dnssec-keygen  -P now -A now+10mi -I now+1h -D now+2h -b 512 -r /dev/random -K /etc/bind/chaos.keystrore/ chaos.local
 rndc loadkeys chaos.local (sonst passiert nix)
 dig +dnssec  -t DNSKEY chaos.local @localhost

  • neue IP (Leaseverlaengerung und DNS-Aktualisierung):
 dhclient -i eth0 
  • in der dhcpclientconfig muss senthostname gesetzt sein (nur hostname, nicht fqdn)

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-bind-rndc.html


  • Cron:
 */10 *    * * *   bind    ( dnssec-keygen -P now -A now+2mi -I now+4mi -D now+6mi -b 512 -r /dev/urandom -K /etc/bind/chaos.keystore/ chaos.local & rndc loadkeys chaos.local & rndc sign chaos.local)
 */1 *    * * *   root ( dig +dnssec -t DNSKEY chaos.local  @localhost >> /tmp/`date +\%s` )
 */1 *    * * *   root ( dig +dnssec mitte.chaos.local  @localhost >> /tmp/`date +\%s` )
  • Achtung: urandom nur zum testen benutzen!

  • Serial
  • wenn man statt dem ueblichen format "yyyymmtt..." "yymmtt..." nimmt, hat man auch mehr als genug
  • Beispiel:
    • alt: 2011093000-2011093099 : 100 pro tag
    • neu: 1109030000-1109309999: 10000 pro tag, reicht fuer mehrere Aktualisierungen pro Minute und die naechsten 80+ Jahre

  • Code fuers zonewalking wip
  • dlv.isc.org nur NSEC
  • unterliegende Einträge ebenfalls
    • nur Stichproben gemacht, sieht aber so aus als sei hier überall nur NSEC
    • sollte möglich sein Zonenverwaltenden DNS dann auf NSEC3 einzustellen
    • allerdings bleiben die Zonen sichtbar, da scheinbar alles was von dlv.isc.org signiert ist nur NSEC kann

  • NSEC3 is not recommended unless there is a pressing need for the features NSEC3 provides. It is expensive for both the server and the client. Most zones do not need the addition expense incured by the use of NSEC3. (http://www.isc.org/software/bind/new-features/9.6)

  • named-journalprint
 /var/lib/bind/chaos.local.jnl

 dnssec-keygen -3 -r /dev/urandom  chaos.local
 dnssec-keygen -3 -r /dev/urandom -fk chaos.local
 mv K* keystore_chaoslocal
 chown bind keystore_chaoslocal/*
 dnssec-signzone -u -K keystore_chaoslocal/ chaos.local