DNSSec

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 (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 (27.09.2011) (http://stats.research.icann.org/dns/tld_report/)
    • 310 TLDs in der Root-Zone insgesamt
    • 76 TLDs sind signiert
    • 72 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

• RRSIG (Resource Record Signature)
  • Signatur des übergeordneten Resource Records

• NSEC/NSEC3 (Next Entry)
  • nächster Eintrag im Zonefile
  • ist der letzte Eintrag erreicht, zeigt NSEC auf den ersten Eintrag
  • Realisierung von negativen Antworten

• DS (Delegation Signer)
  • Signierung eines Schlüssel einer untergeordneten Zone
  • erzeugt Chain of Trust

Nichtexistierende Namen

• NSEC Resource Record verweist auf den 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 (RFC5155) 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)
    • kurzlebiger (z.B. 30 Tage)
  • Key Signing Key (KSK)
    • signiert den ZSK
    • länger (z.B. 2048)
    • langlebiger (z.B. 2 Jahre)

• von einer Parent- zu einer Child-Zone wird das Vertrauen über den DS RR hergestellt
• 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

• 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)
  • Lösung: 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
• 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

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

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

• Eventuell: Anmelden bei http://dlv.isc.org

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

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 +search bund.de @141.20.20.50
 $ dig +dnssec bund.de
 $ dig +dnssec -t DNSKEY bund.de
 $ dig +dnssec a.xxx.schlittermann.de

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

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
  • Firefox-Extension
  • http://www.dnssec-validator.cz/setlang/?language=en

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

Struktur Vortrag

• Einführung DNS
  • 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

• 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

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