DNSSec

From
Revision as of 02:29, 11 February 2012 by Fehr (talk | contribs)
Jump to navigation Jump to search

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 Rootservern 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
  • NSEC3
    • Problem von NSEC: Zone Walking
    • Lösung: NSEC3
    • statt Hostnamen im Klartext nur Hashes
 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
  • 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-Eintrag (RFC 5155) der anstelle von Hostnamen im Klartext nur gehashte Namen zurückliefert
    • 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: die Gesamtmenge der durch einen einzigen Schlüssel gesicherten Menge von 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 eigenen 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 Nameserver 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

Automatische Signierung

  • Schlüssel mit Ablaufdatum erzeugen
 dnssec-keygen -P now -A now+10mi -I now+1h -D now+2h -b 1024 -r /dev/random -K /etc/bind/example.org.keystore/ example.org
  • Neuen Schlüssel aktivieren
 $ rndc loadkeys example.org
 $ rndc sign example.org
  • DHCP: Autosign
  • Automatisierung: Cron

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, daß 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.
  • Welche Optionen sind wichtig?
    • +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 Konfigurationen

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 ;)


Für jede Zone sollte ein eigenes Verzeichnis zur Verfügung stehen. Empfohlener Ort für von Diensten veränderlichen 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

todo: werte geben anzahl der runden und salt an;

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.


Konfig ausgeben lassen ohne Kommentare: named-checkconf -p

Probleme

  • 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

Was gibt es noch?

  • Schlüsselrückzug
  • Chain of Trust aufbauen
  • Phreebird
  • Unbound

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

Temporäres Zeugs

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

rfcliste zu dns: http://www.bind9.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 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

drill stecker rausziehn reagiert anders als dig

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

dann drill -DS mitte.chaos.local -k trusted_chaos

CHASE SUCCESSFUL  :)

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/urandom -K /etc/bind/chaos.keystrore/ chaos.local #urandom dev ohne randomness (geht schnell bringt aber nicht viel)

dann rndc loadkeys chaos.local (sonst passiert nix)

dig +dnssec -t DNSKEY chaos.local @localhost

neue ip (leaseverlaengerung und dnsaktualisierung) auf mahrzahn - neumarzahn: 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

(urandom nur zum testen benutzen!) 

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


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 eintraege ebenfalls (?. nur stichproben gemacht, sieht aber so aus als sei hier ueberall nur nsec, sollte moeglich 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 ... annahme: nachprüfen)

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

Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=DNSSec&oldid=9794"