DNSSec: Difference between revisions

From
Jump to navigation Jump to search
Line 191: Line 191:


=== Unsere Konfigurationen ===
=== Unsere Konfigurationen ===

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.


=== Probleme ===
=== Probleme ===

Revision as of 14:23, 5 October 2011

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

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.

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

Weite Links

www.ukuug.org/events/spring2011/timetable/dnssec-signingtools.pdf


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


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

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