DNSSec: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
(→‎Gesammeltes Zeugs: Link Folien: C. Strohtmann: Lesser known DNS tools and BIND tricks)
 
(34 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 4: Line 6:
* verschiedene Angriffsszenarien: z.B. DNS-Spoofing, Cache Poisoning
* verschiedene Angriffsszenarien: z.B. DNS-Spoofing, Cache Poisoning


=== DNSSEC - DNS Security Extension ===
=== DNSSEC ===
* IETF (Internet Engineering Task Force)-Standard
* 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
* Sicherstellung der Authentizität und Integrität von DNS-Abfragen

<br>
=== Geschichte ===
* 2005 erste Top Level Domain .se signiert
* ursprüngliche DNSSEC-Version von 1999 (RFC 2535) war auf Grund einer zu aufwändigen Schlüsselverwaltung für die Praxis untauglich
* später noch andere TLD (z.B. .cz, .bg, ...)
* 2005 wurde eine Neufassung veröffentlicht
* 2010 root-Zone
* 2005 wurde mit der schwedischen .se-Domain erstmals eine Top Level Domain signiert
* 2011 .de-Zone
* 2010 wurde DNSSEC auf allen 13 Root-Servern eingeführt
<br>
* 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
* Verwendung von asymmetrischer Kryptographie
* Signieren der zu schützenden DNS-Einträge mit privatem Schlüssel
** Signieren der zu schützenden DNS-Einträge mit privatem Schlüssel
* Client kann mit zugehörigem öffentlichen Schlüssel diese Signatur entschlüsseln
** mit zugehörigem öffentlichen Schlüssel kann diese Signatur geprüft werden
* Privater und öffentlicher Schlüssel sind pro DNS-Zone einzigartig
* Vertrauenswürdigkeit der öffentlichen Schlüssel wird über Vertrauensketten (Chain of Trust) sichergestellt


* pro Zone gibt es zwei Schlüssel
=== Neue DNS-Records ===
** Zone Signing Key (ZSK)
* '''DNSKEY''' - öffentlicher Schlüssel einer Zone
*** signiert die einzelnen Resource Records eines Zonefiles
* '''RRSIG''' - Signatur eines DNS-Eintrages
*** kürzer (z.B. 1024 Bit)
* '''NSEC''' - nächster Eintrag im Zonefile (Realisierung von negativen Antworten)
*** kurzlebiger (z.B. 30 Tage)
* '''DS''' - Signierung eines Validierungsschlüssel einer untergeordneten Zone (Chain of Trust)
** 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 of Trust ===
[[Image:Chain.png]]
* komplette DNSSEC-Infrastruktur von der TLD bis hin zum Root-Nameserver notwendig
* Aktuell ist diese Voraussetzung nicht gegeben
* Alternativ kann man eine Liste mit vertrauenswürdigen DNSKEY-Einträgen konfigurieren


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


[[Image:Islands2.png]]
=== BIND-Konfiguration ===
* DNSSEC-Unterstützung im Bind Nameserver einschalten:


* ein Resource Record kann auch mit verschiedenen Schlüsseln signiert werden
: options {
* sinnvoll für Übergangsphase bei Schlüsseltausch
:: dnssec-enable yes;

:: dnssec-validation yes;
=== 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
[[Image: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";
};

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

* 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 ===
=== 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, dass auf dem angefragten Resolver die Prüfung erfolgreich war
* Die Angabe des Parameters +dnssec weist dig an, zusätzliche DNSSEC-Einträge abzufragen
* das Setzen des DO-Flags ist nur im Rahmen der DNS-Erweiterung EDNS möglich
* Antwort mit dem AUTHENTICATED DATA Flag (AD), damit wird dem Client mitgeteilt, daß auf dem angefragten Resolver die Prüfung erfolgreich war
* 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 ===
=== Software ===
* ISC BIND mit dig
* DNSSEC Validator
** Nameserver und Abfragetool
** http://www.isc.org/software/bind

* 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/

* DNSSEC Validator (teils fehlerhafte Anzeige, wahrscheinlich auf Cache zurueckzufuehren)
** Firefox-Extension
** Firefox-Extension
** [http://www.dnssec-validator.cz/]
** 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 54: Line 340:
** Marcus Obst, Heiko Schlittermann
** Marcus Obst, Heiko Schlittermann
** Chemnitzer Linux-Tage 2010
** Chemnitzer Linux-Tage 2010
** [http://www.schlittermann.de/doc/clt2010/]
** http://www.schlittermann.de/doc/clt2010/


* Beglaubigte Adressen - DNSSEC verheiratet Namensauflösung und PKI
* Beglaubigte Adressen - DNSSEC verheiratet Namensauflösung und PKI
** Eric Amberg
** Eric Amberg
** Linux-Magazin 2008/05
** Linux-Magazin 2008/05
** [http://www.linux-magazin.de/Heft-Abo/Ausgaben/2008/05/Beglaubigte-Adressen]
** http://www.linux-magazin.de/Heft-Abo/Ausgaben/2008/05/Beglaubigte-Adressen


* Wikipedia-Eintrag zur Domain Name System Security Extensions
* Wikipedia-Eintrag zur Domain Name System Security Extensions
** [http://de.wikipedia.org/wiki/DNSSEC]
** http://de.wikipedia.org/wiki/DNSSEC


* BIND 9 Administrator Reference Manual
** Internet Systems Consortium
** http://www.bind9.net/arm97.pdf


=== Gesammeltes Zeugs ===


* Weitere Links
** 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
----------------------------
DNSSEC:


* RFC-Liste zu DNS: http://www.bind9.net/rfc
zwei unterschiedliche ansaetze:
* RFC-Liste zu DNSSec: http://www.dnssec.net/rfc
* komplette chain-of-trust von root zu jeweiliger zone
* "schatten-dns" ueber dlv.isc.org


----
benutzte tools:
bind 9.7.3
dig
dnssec-tools validator (debianpaket in stable veraltet, selbst compilieren)


* 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


----
beispiele:


openssl base64 -e -in dateimitgeheimnis >> dateimitgeheimnisbase64
- validierung klappt ueber dlv aber nicht ueber "normal"


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


----


* http://dnsviz.net/d/heise.de/dnssec/
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


dig +dnssec -t DNSKEY chaos.local |grep 257 > trusted_chaos
drill stecker rausziehn reagiert anders als dig


* trusted chaos bearbeiten


drill -DS mitte.chaos.local -k trusted_chaos
a.xxx.schlittmann.de :lookaside example


----


* Updatedienst mit Key versorgen
pro zone 1 oder mehr keys - darf zur zeit nur RSASHA1 sein: bind 9.7 manual 4.8.1:
rndc -s localhost -k /etc/bind/rndc.key reload
It is recommended that zone keys use a cryptographic algorithm designated as ”mandatory to implement” by the IETF; currently the only one is RSASHA1.
The following command will generate a 768-bit RSASHA1 key for the child.example zone:
dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.


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


----
openssl base64 -e -in dateimitgeheimnis >> dateimitgeheimnisbase64


dnssec-keygen -a HMAC-MD5 -b 128 -n HOST kudamm.chaos.local
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
-----------------------
http://dnsviz.net/d/heise.de/dnssec/
-----------------------


rndc loadkeys chaos.local (sonst passiert nix)
erste config wieder zurueck gespielt


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


----
trusted chaos bearbeiten


* neue IP (Leaseverlaengerung und DNS-Aktualisierung):
dann drill -DS mitte.chaos.local -k trusted_chaos
dhclient -i eth0
* in der dhcpclientconfig muss senthostname gesetzt sein (nur hostname, nicht fqdn)


----
CHASE SUCCESSFUL :)
-------


http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-bind-rndc.html
dhcpd laeuft, verteilt eine ip .2.101 ... marzahn kabel umgesteckt, per dhclient eht0 die ,2.101 holen lassen, leasetime 60 sek, ip bekommen geht, dnsupdate klappt noch nicht, key und acl muessen noch angepasst werden


----
eigene zone fuer .2.101: "dyn.chaos.local", reverse muss noch angepasst werden


* 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)
updatedienst mit key versorgen
*/1 * * * * root ( dig +dnssec -t DNSKEY chaos.local @localhost >> /tmp/`date +\%s` )
rndc -s localhost -k /etc/bind/rndc.key reload
*/1 * * * * root ( dig +dnssec mitte.chaos.local @localhost >> /tmp/`date +\%s` )


* Achtung: urandom nur zum testen benutzen!
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/urandom -K /etc/bind/chaos.keystrore/ chaos.local #urandom dev ohne randomness (geht schnell bringt aber nicht viel)


* Serial
dann rndc loadkeys chaos.local (sonst passiert nix)
* 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
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)
-----
=== Struktur Vortrag ===
* Einführung DNS
** was ist das und wie funktioniert es?
** Wireshark Bild: DNS-Pakete
** Angriffsmöglichkeiten
* DNSSec
** Einführung
** Historie
** RFCs
** 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 ===
* named-journalprint
* Client Tools und Bibliotheken DNSSec Unterstützung?
/var/lib/bind/chaos.local.jnl
Firefox Plugin: http://www.dnssec-validator.cz/setlang/?language=en

** Beispiel: OpenSSH patchen
* Schlüsseltausch, neuen Schlüssel einfügen, Schlüssel deaktivieren testen
* 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"
* Beispiele für DNSSec Domains, DLV Domains
http://www.heise.de/netze/meldung/Bund-de-erprobt-DNSSEC-Signierung-992351.html
DNSSec: dig +dnssec -t DNSKEY bund.de
DLV: a.xxx.schlittermann.de
* 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, ...)?
* alles ordentlich dokumentieren
* Vortragsfolien vorbereiten
----
----

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
* http://svsf40.icann.org/bitcache/60a3f222cee51eb3411c6cdf3829814a552ad0b8?vid=22999&disposition=attachment&op=download

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
Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=DNSSec&oldid=9975"