DNSSec

From
Revision as of 14:25, 29 September 2011 by U9786 (talk | contribs) (→‎Quellen)
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 (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 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)
      • 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";
   ...
 };
  • 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

Unsere Konfigurationen

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?

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

  • TODO: bind administrator manual

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