DNSSEC im (Münchner) Wissenschaftsnetz

Transkript

1 DNSSEC im (Münchner) Wissenschaftsnetz Bernhard Schmidt 3. März 2015 Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

2 Agenda Einleitung Motivation, was ist DNS-Spoofing? DNSSEC Rekursive Seite Authoritative Seite Monitoring Goodies SSHFP TLSA/DANE Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

3 Einleitung Eigenvorstellung wir sind nicht die Einzigen, wir sind nicht die Ersten, wir sind vielleicht die größten (Hochschulen mit DNSSEC) keine Erklärung der technischen Details LRZ-interne Präsentation unter Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

4 Motivation DNS Spoofing DNS Spoofing - wie? DNS hauptsächlich über (verbindungsloses) UDP Zuordnung von Anfrage und Antwort über Matching verschiedener Protokollfelder IP-Adresse beider Seiten (2-3 Bit Zufall) Quellport Anfrage bzw. Zielport Antwort (15-16 Bit Zufall) Anfrage (kein Zufall) DNS Transaction-ID (16 Bit Zufall) im besten Fall etwa 2 34 Möglichkeiten mit heutigen Bandbreiten ist Brute-Force Spoofing realistisch Implementierungs- und Konfigurationsfehler reduzieren Zufall oder ermöglichen neue Angriffe (Kaminsky-Attacke, out-of-bailiwick) wenn ein Angreifer Anfragen (passiv) mithört kann er fast immer schneller antworten als der richtige Server Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

5 Motivation DNS Spoofing DNS Spoofing - warum? Platzieren falscher Einträge in Resolvercache, zum Teil für ganze TLDs kein Selbstzweck, sondern Vorbereitung für Man-in-the-Middle Angriffen (Lenovo Superfish, älter: Apple Updates) Advertisement Fraud Drive-by Angriffe von Malware Hijacking von SMTP, dann Abgreifen von Passwortresetmails... schwer zu erkennen, noch schwerer zu verhindern (BCP-38?) betrifft unter Umständen tausende von Nutzern auf einen Schlag Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

6 Technik DNSSEC DNSSEC DNSSEC signiert DNS-Inhalte durch Public/Private-Keyverfahren DNSSEC bietet dadurch Authentizität und Integrität DNSSEC bietet keine Vertraulichkeit! neue RTYPEs im DNS DNSKEY - Public Key RRSIG - Signatur NSEC - Verkettung für Beweis der (Nicht-)Existenz NSEC3 - Verkettung für Beweis der (Nicht-)Existenz DS - Sichere Delegation Vertrauen in einen einzigen Schlüssel (Root-Zone), der Rest wird durch sichere Delegationen abgesichert (vgl. Root-CA, Intermediate-CA,...) Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

7 Technik Rekursive Seite Rekursive Seite relativ trivial in modernen Versionen von BIND und Unbound standardmäßig aktiv DNSSEC wird validiert, Domains mit DNSSEC-Fehlern können nicht aufgelöst werden (SERVFAIL) Resolver gibt Validierungsstatus im ad-flag zurück Zwei Probleme BIND validiert keine Slave-Zonen keine Authentifizierung zwischen Client und Resolver, Spoofing möglich Client Stub-Resolver 1 6 rekursiv validierender Resolver iterativ 3 Nameserver. Nameserver de. Authoritativ unsicher sicher Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

8 sicher Technik Rekursive Seite Rekursive Seite Lösung: lokal validierende Resolver (z.b. Unbound) 8 Client, validierender "Stub"-Resolver rekursiv 1 Client Stub-Resolver 2 7 validierender Resolver iterativ Nameserver. Nameserver de. Authoritativ sicher am LRZ im Aufbau (Mailsystem, ausgewählte Mitarbeiter,...) Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

9 Technik Rekursive Seite Rekursive Seite resolver1.lrz.de validierend seit 2008 Teilnahme am DENIC-DNSSEC-Testbed, DLV, IANA ITAR resolver2.lrz.de validierend seit März 2014 seitdem keine Auflösung von Domains mit kaputtem DNSSEC mehr! <5 Incidents die periphär durch DNSSEC hervorgerufen wurden weltweit etwa 12% der DNS-Anfragen mit DNSSEC gesichert 1 Comcast (größter Privatkundenprovider der Welt) seit Anfang Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

10 Technik Authoritative Seite Authoritative Seite stellt signierte Zone für eigene Domains bereit grober Ablauf: Generieren von Key-Signing-Key (KSK) und Zone-Signing-Key (ZSK) Signieren der Zone mit dem ZSK Signieren des ZSK mit dem KSK Einfügen des Hashs des KSK in die Parent-Zone (DS-Record) Signieren muss bei jeder Änderung der Zone gemacht werden manueller Aufruf von dnssec-signzone fehleranfällig! muss auch ohne Änderung der Zone periodisch durchgeführt werden (RRSIG Validity Period) Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

11 Technik Authoritative Seite Authoritative Seite BIND auto-dnssec maintain Feature Key in Key-Directory anlegen BIND kümmert sich automatisch um Resigning Änderungen an der Zone mit rndc freeze/thaw oder nsupdate BIND inline-signing Feature siehe oben Input nicht mehr Zonenfile, sondern AXFR ermöglicht die Einrichtung eines Signing Proxies OpenDNSSEC automatisiert mehr (z.b. Keyrollover) komplexere Installation (benötigt MySQL und SoftHSM) unterstützt ebenfalls Inline Signing Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

12 Technik Authoritative Seite Authoritative Seite am LRZ Weboberfläche für Kunden (Nixu Namesurfer) kann prinzipiell DNSSEC, aber ein paar dubiose Probleme in den Anfängen wir wollen evtl. auch in der Lage sein <hipster>signing-as-a-service</hipster> anzubieten Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

13 Technik Authoritative Seite Authoritative Seite am LRZ CMDB dns1 dns2 WebDNS HTTP dns3 resolver1 resolver2 BIND Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

14 Technik Authoritative Seite Authoritative Seite am LRZ CMDB dns1 DNSSEC Proxy dns2 WebDNS HTTP dns3 resolver1 resolver2 BIND Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

15 Technik Authoritative Seite Authoritative Seite Große Hauptdomains mit Infrastruktur signiert (wenn s kracht dann richtig) lrz.de tum.de lmu.de einige kleinere Domains ebenfalls, zum Teil schon länger badw-muenchen.de - Dezember 2010 Weitere DNSSEC-Nutzer: bund.de, bayern.de ruhr-uni-bochum.de, tuhh.de, uni-kl.de, hs-owl.de, uni-rostock.de, uni-stuttgart.de > in.com/.net/.edu 2 Pflicht für US Regierungsstellen (.gov) 2 Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

16 Technik Authoritative Seite Monitoring DNSSEC-Signierungsfehler sind tödlich fallen je nach lokaler Resolverstruktur gar nicht auf Tägliche Prüfung am LRZ für jede DNSSEC-Zone Prüfen der signierten Zone durch ldns-verify-zone (ldns 3 ) prüft NSEC-Chaining, Keys, RRSIG-Validity (>30 Tage) Prüfen der signierten Zone durch dnssec-verify (BIND) prüft NSEC-Chaining, Keys Abfrage des SOA-Records bei Google DNS, DNS-OARC ODVR 4 prüft sichere Delegation (ad-flag) prüft Funktionsfähigkeit aus Nutzersicht Nutzung lokaler validierender Resolver auf wichtigen Servern Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

17 Goodies DNSSEC Goodies DNSSEC verhindert zuverlässig Spoofing aber: die Wenigsten von uns haben DNS-Spoofingprobleme DNSSEC ermöglicht Authentifikation von allen DNS-Inhalten einer signierten Domain, nicht nur der bekannten A/AAAA/MX/...-Records) zusätzliche RTYPEs mit Zusatznutzen durch DNSSEC erinnert sich jemand an opportunistisches IPsec (IPSECKEY RR)? Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

18 Goodies SSHFP SSHFP (RFC 4255) wer prüft SSH Fingerprint bei Connect? Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

19 Goodies SSHFP SSHFP (RFC 4255) wer prüft SSH Fingerprint bei Connect? Fingerprint des Hostkeys kann in SSHFP RR hinterlegt werden Client kann Key via DNSSEC-gesichertem DNS verifizieren ideal für Gateways, Supercomputing, git,... $ ssh -v -o UserKnownHostsFile=/dev/null git@gitlab.lrz.de [...] debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:ba debug1: found 6 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

20 Goodies SSHFP SSHFP (RFC 4255) wer prüft SSH Fingerprint bei Connect? Fingerprint des Hostkeys kann in SSHFP RR hinterlegt werden Client kann Key via DNSSEC-gesichertem DNS verifizieren ideal für Gateways, Supercomputing, git,... $ ssh -v -o UserKnownHostsFile=/dev/null git@gitlab.lrz.de [...] debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:ba debug1: found 6 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS funktioniert auch ohne DNSSEC, dann aber immer mit Nachfrage $ ssh -v -o UserKnownHostsFile=/dev/null git@gitlab.lrz.de [...] debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:ba debug1: found 6 insecure fingerprints in DNS debug1: matching host key fingerprint found in DNS The authenticity of host 'gitlab.lrz.de (2001:4ca0:0:103::81bb:fe47)' can't be established. ECDSA key fingerprint is cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:ba. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

21 Goodies TLSA DANE TLSA/DANE (RFC 6698) DNS-Based Authentication of Named Entities veröffentlicht Zertifikatsinformationen für Verbindung zu Dienst (Hostname + Port) kann zu benutzende CA (Trust-Anchor) oder End-Entity (Serverzertifikat) vorgeben... dabei auch Validierung über PKIX übergehen... der Todeskuss für die etablierte SSL-CA Infrastruktur? _443._tcp IN TLSA A1CDA213DA1124EA1AB461DC9F99A0F4A4C4A37DE B00E2330 Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

22 Goodies TLSA DANE TLSA/DANE im Web TLSA hätte das Potential, SSL-CAs überflüssig zu machen Validatorplugins für alle gängigen Browser und Plattformen unter aber: kein großes Interesse der Browserhersteller Mozilla: Bug (kaum Aktivität seit 2013) Chromium: Issue (WONTFIX) Chrome und Mozilla setzen auf Zertifikatspinning im Browserbundle Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

23 Goodies TLSA DANE TLSA/DANE bei Transportverschlüsselung über (STARTTLS) nachträglich auf SMTP aufgesetzt Verschlüsselung nicht erzwungen, Signalisierung über Plaintext (Downgrade-Attacke) Validierung des Peer-Zertifikats nicht praktikabel 50% der Serverzertifikate validieren nicht einmal ohne Checks des CN (Self-Signed, Expired,...) kein Administratorprompt möglich Lösung : Marketing Schengen-Routing Made in Germany Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

24 Goodies TLSA DANE TLSA/DANE bei Echte Lösung: Zieldomain signieren (Domain -> Mailserver) TLSA-Record für Mailserver (Mailserver -> Zertifikat) beides in DNSSEC-signierten Zonen TLSA-Lookup beim Versand, implizites Zertifikatspinning Verschlüsselung muss erfolgen (kein Downgrade) DNSSEC-verifiziertes Zertifikat muss präsentiert werden Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

25 Goodies TLSA DANE TLSA/DANE bei Outbound: DNSSEC-validierender Resolver Postfix >= 2.11 smtp_tls_security_level = dane smtp_dns_support_level = dnssec Exim?? Verified TLS connection established to mx2.uni-kl.de[2001:638:208:120::209]:25: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) Statistik am LRZ ( ): 2% der ausgehenden TLS-Verbindungen mit DANE gesichert unter anderem zu bund.de, bayern.de, uni-kl.de, med.uni-rostock.de, posteo.de, mailbox.org,... Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

26 Goodies TLSA DANE TLSA/DANE bei Inbound: kein Support des lokalen MTA nötig, STARTTLS genügt Zonen DNSSEC-signieren und Zertifikat im TLSA-Record hinterlegen keine Signalisierung der TLSA-Nutzung durch den Sender -> keine Statistik Statistik am LRZ ( ): <1% der Zonen signiert >50% des Mailverkehrs über DANE abgesichert Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

27 Status und Ausblick Langsame Zunahme von DNSSEC-Zonen am LRZ wir arbeiten noch an Automatisierung, Dokumentation, Erfahrung,... Wünsche an andere Mitglieder/DFN DNSSEC-Validierung auf Resolvern DNSSEC-Signierung von eigenen Zonen DANE/TLSA für ausgehenden Mailverkehr DANE/TLSA für eingehenden Mailverkehr (DFN-Mailsupport!) Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26

28 Status und Ausblick Vielen Dank! Bernhard Schmidt Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März / 26