DNSSec: Difference between revisions

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


=== DNS - Domain Name System ===
zwei unterschiedliche ansaetze:
* Umwandlung von Hostnamen in IP-Adressen
* komplette chain-of-trust von root zu jeweiliger zone
* hierarchisches dezentralisiertes System
* "schatten-dns" ueber dlv.isc.org
* verschiedene Angriffsszenarien: z.B. DNS-Spoofing, Cache Poisoning


=== DNSSEC ===
benutzte tools:
* IETF (Internet Engineering Task Force)-Standard
bind 9.7.3
** DNSSEC Intro RFC (RFC 4033)
dig
** DNSSEC Records RFC (RFC 4034)
dnssec-tools validator (debianpaket in stable veraltet, selbst compilieren)
** 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 ===
beispiele:
* DNSSEC nutzt gleiche Zugriffsmechanismen wie klassisches DNS
* bisherige DNS-Einträge werden um kryptographische Signaturen erweitert
* das System ist abwärtskompatibel


* DNSKEY
- validierung klappt ueber dlv aber nicht ueber "normal"
** ö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
[[Image: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
[[Image:Islands.png]]

[[Image: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
[[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 ===
* 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 ===
* ISC BIND mit dig
** 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
** 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 ===
* DNSSEC Sichere Namensauflösung im Internet
** Marcus Obst, Heiko Schlittermann
** Chemnitzer Linux-Tage 2010
** http://www.schlittermann.de/doc/clt2010/

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

* Wikipedia-Eintrag zur Domain Name System Security Extensions
** 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

----

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

----

* 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

----

* http://dnsviz.net/d/heise.de/dnssec/

----

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

----

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