DNSSEC im (Münchner) Wissenschaftsnetz
Bernhard Schmidt
3. März 2015
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 1 / 26
Agenda
EinleitungMotivation, was ist DNS-Spoofing?DNSSEC
Rekursive SeiteAuthoritative SeiteMonitoring
GoodiesSSHFPTLSA/DANE
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 2 / 26
Einleitung
Eigenvorstellungwir sind nicht die Einzigen, wir sind nicht die Ersten, wir sindvielleicht die größten (Hochschulen mit DNSSEC)keine Erklärung der technischen Details — LRZ-interne Präsentationunter http://ping.lrz.de/~bschmidt/dnssec.pdf
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 3 / 26
Motivation DNS Spoofing
DNS Spoofing - wie?
DNS hauptsächlich über (verbindungsloses) UDPZuordnung von Anfrage und Antwort über Matching verschiedenerProtokollfelder
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 234 Möglichkeitenmit heutigen Bandbreiten ist Brute-Force Spoofing realistischImplementierungs- und Konfigurationsfehler reduzieren Zufall oderermöglichen neue Angriffe (Kaminsky-Attacke, out-of-bailiwick)wenn ein Angreifer Anfragen (passiv) mithört kann er fast immerschneller antworten als der richtige Server
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 4 / 26
Motivation DNS Spoofing
DNS Spoofing - warum?
Platzieren falscher Einträge in Resolvercache, zum Teil für ganzeTLDskein Selbstzweck, sondern Vorbereitung für
Man-in-the-Middle Angriffen (Lenovo Superfish, älter: Apple Updates)Advertisement FraudDrive-by Angriffe von MalwareHijacking 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 2015 5 / 26
Technik DNSSEC
DNSSEC
DNSSEC signiert DNS-Inhalte durch Public/Private-KeyverfahrenDNSSEC bietet dadurch Authentizität und IntegritätDNSSEC bietet keine Vertraulichkeit!neue RTYPEs im DNS
DNSKEY - Public KeyRRSIG - SignaturNSEC - Verkettung für Beweis der (Nicht-)ExistenzNSEC3 - Verkettung für Beweis der (Nicht-)ExistenzDS - Sichere Delegation
Vertrauen in einen einzigen Schlüssel (Root-Zone), der Rest wirddurch sichere Delegationen abgesichert (vgl. Root-CA,Intermediate-CA, ...)
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 6 / 26
Technik Rekursive Seite
Rekursive Seite
relativ trivialin modernen Versionen von BIND und Unbound standardmäßig aktivDNSSEC wird validiert, Domains mit DNSSEC-Fehlern können nichtaufgelöst werden (SERVFAIL)Resolver gibt Validierungsstatus im ad-Flag zurückZwei Probleme
BIND validiert keine Slave-Zonenkeine Authentifizierung zwischen Client und Resolver, Spoofing möglich
ClientStub-Resolver
validierenderResolver Authoritativ
Nameserver .
Nameserver de.
rekursiv iterativ
21
34
5
6
sicherunsicher
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 7 / 26
Technik Rekursive Seite
Rekursive Seite
Lösung: lokal validierende Resolver (z.B. Unbound)
Client, validierender"Stub"-Resolver
validierenderResolver Authoritativ
Nameserver .
Nameserver de.
rekursiv iterativ
23
45
6
sic
her
ClientStub-Resolver
1
7
8
sicher
am LRZ im Aufbau (Mailsystem, ausgewählte Mitarbeiter, ...)
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 8 / 26
Technik Rekursive Seite
Rekursive Seite
resolver1.lrz.de validierend seit 2008Teilnahme am DENIC-DNSSEC-Testbed, DLV, IANA ITARresolver2.lrz.de validierend seit März 2014seitdem 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 gesichert1
Comcast (größter Privatkundenprovider der Welt) seit Anfang 2012
1http://stats.labs.apnic.net/dnssec/XA
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 9 / 26
Technik Authoritative Seite
Authoritative Seite
stellt signierte Zone für eigene Domains bereitgrober Ablauf:
Generieren von Key-Signing-Key (KSK) und Zone-Signing-Key (ZSK)Signieren der Zone mit dem ZSKSignieren des ZSK mit dem KSKEinfügen des Hashs des KSK in die Parent-Zone (DS-Record)
Signieren muss bei jeder Änderung der Zone gemacht werdenmanueller 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 2015 10 / 26
Technik Authoritative Seite
Authoritative Seite
BIND 9.8 - ”auto-dnssec maintain“ FeatureKey in Key-Directory anlegenBIND kümmert sich automatisch um ResigningÄnderungen an der Zone mit rndc freeze/thaw oder nsupdate
BIND 9.9 - ”inline-signing“ Featuresiehe obenInput nicht mehr Zonenfile, sondern AXFRermöglicht die Einrichtung eines Signing Proxies
OpenDNSSECautomatisiert 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 2015 11 / 26
Technik Authoritative Seite
Authoritative Seite am LRZ
Weboberfläche für Kunden (Nixu Namesurfer)kann prinzipiell DNSSEC, aber ein paar dubiose Probleme in denAnfängenwir wollen evtl. auch in der Lage sein<hipster>Signing-as-a-Service</hipster> anzubieten
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 12 / 26
Technik Authoritative Seite
Authoritative Seite am LRZ
dns1
dns2
dns3
resolver1
resolver2
WebDNS
BIND
HTTP
CMDB
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 13 / 26
Technik Authoritative Seite
Authoritative Seite am LRZ
dns1
dns2
dns3
resolver1
resolver2
WebDNS
BIND
HTTP
DNSSECProxy
CMDB
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 14 / 26
Technik Authoritative Seite
Authoritative Seite
Große Hauptdomains mit Infrastruktur signiert (wenn’s kracht dannrichtig)
lrz.de - 28.10.2014tum.de - 10.12.2014lmu.de - 12.01.2015
einige kleinere Domains ebenfalls, zum Teil schon längerbadw-muenchen.de - Dezember 2010
Weitere DNSSEC-Nutzer:bund.de, bayern.deruhr-uni-bochum.de, tuhh.de, uni-kl.de, hs-owl.de, uni-rostock.de,uni-stuttgart.de>500.000 in .com/.net/.edu 2
”Pflicht“ für US Regierungsstellen (.gov)
2http://scoreboard.verisignlabs.com/
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 15 / 26
Technik Authoritative Seite
Monitoring
DNSSEC-Signierungsfehler sind tödlichfallen je nach lokaler Resolverstruktur gar nicht auf
Tägliche Prüfung am LRZ für jede DNSSEC-ZonePrüfen der signierten Zone durch ldns-verify-zone (ldns3)
prüft NSEC-Chaining, Keys, RRSIG-Validity (>30 Tage)Prüfen der signierten Zone durch dnssec-verify (BIND)
prüft NSEC-Chaining, KeysAbfrage des SOA-Records bei Google DNS, DNS-OARC ODVR4
prüft sichere Delegation (ad-Flag)prüft Funktionsfähigkeit aus Nutzersicht
Nutzung lokaler validierender Resolver auf wichtigen Servern
3http://www.nlnetlabs.nl/projects/ldns/
4https://www.dns-oarc.net/oarc/services/odvr
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 16 / 26
Goodies
DNSSEC Goodies
DNSSEC verhindert zuverlässig Spoofingaber: die Wenigsten von uns haben DNS-SpoofingproblemeDNSSEC ermöglicht Authentifikation von allen DNS-Inhalten einersignierten Domain, nicht nur der bekanntenA/AAAA/MX/....-Records)zusätzliche RTYPEs mit Zusatznutzen durch DNSSECerinnert sich jemand an opportunistisches IPsec (IPSECKEY RR)?
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 17 / 26
Goodies SSHFP
SSHFP (RFC 4255)
wer prüft SSH Fingerprint bei Connect?
Fingerprint des Hostkeys kann in SSHFP RR hinterlegt werdenClient kann Key via DNSSEC-gesichertem DNS verifizierenideal für Gateways, Supercomputing, git, ...
$ ssh -v -o UserKnownHostsFile=/dev/null [email protected][...]debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:badebug1: found 6 secure fingerprints in DNSdebug1: matching host key fingerprint found in DNS
funktioniert auch ohne DNSSEC, dann aber immer mit Nachfrage$ ssh -v -o UserKnownHostsFile=/dev/null [email protected][...]debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:badebug1: found 6 insecure fingerprints in DNSdebug1: matching host key fingerprint found in DNSThe 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 2015 18 / 26
Goodies SSHFP
SSHFP (RFC 4255)
wer prüft SSH Fingerprint bei Connect?Fingerprint des Hostkeys kann in SSHFP RR hinterlegt werdenClient kann Key via DNSSEC-gesichertem DNS verifizierenideal für Gateways, Supercomputing, git, ...
$ ssh -v -o UserKnownHostsFile=/dev/null [email protected][...]debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:badebug1: found 6 secure fingerprints in DNSdebug1: matching host key fingerprint found in DNS
funktioniert auch ohne DNSSEC, dann aber immer mit Nachfrage$ ssh -v -o UserKnownHostsFile=/dev/null [email protected][...]debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:badebug1: found 6 insecure fingerprints in DNSdebug1: matching host key fingerprint found in DNSThe 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 2015 18 / 26
Goodies SSHFP
SSHFP (RFC 4255)
wer prüft SSH Fingerprint bei Connect?Fingerprint des Hostkeys kann in SSHFP RR hinterlegt werdenClient kann Key via DNSSEC-gesichertem DNS verifizierenideal für Gateways, Supercomputing, git, ...
$ ssh -v -o UserKnownHostsFile=/dev/null [email protected][...]debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:badebug1: found 6 secure fingerprints in DNSdebug1: matching host key fingerprint found in DNS
funktioniert auch ohne DNSSEC, dann aber immer mit Nachfrage$ ssh -v -o UserKnownHostsFile=/dev/null [email protected][...]debug1: Server host key: ECDSA cf:39:97:8e:60:18:ce:45:3f:7e:86:91:76:39:4a:badebug1: found 6 insecure fingerprints in DNSdebug1: matching host key fingerprint found in DNSThe 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 2015 18 / 26
Goodies TLSA DANE
TLSA/DANE (RFC 6698)
DNS-Based Authentication of Named Entitiesverö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.www.bund.de. 900 IN TLSA 3 0 17220022A1CDA213DA1124EA1AB461DC9F99A0F4A4C4A37DE21140960 B00E2330
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 19 / 26
Goodies TLSA DANE
TLSA/DANE im Web
TLSA hätte das Potential, SSL-CAs überflüssig zu machenValidatorplugins für alle gängigen Browser und Plattformen unterhttps://www.dnssec-validator.cz
aber: kein großes Interesse der BrowserherstellerMozilla: Bug 672239 (kaum Aktivität seit 2013)Chromium: Issue 50874 (WONTFIX)
Chrome und Mozilla setzen auf Zertifikatspinning im Browserbundle
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 20 / 26
Goodies TLSA DANE
TLSA/DANE bei E-Mail
Transportverschlüsselung über (STARTTLS) nachträglich auf SMTPaufgesetztVerschlü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“
”E-Mail Made in Germany“5
5https://mailbox.org/e-mail-made-in-germany-verhindert-systematisch-teilnahme-anderer-provider/
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 21 / 26
Goodies TLSA DANE
TLSA/DANE bei E-Mail
Echte Lösung:Zieldomain signieren (Domain -> Mailserver)TLSA-Record für Mailserver (Mailserver -> Zertifikat)beides in DNSSEC-signierten ZonenTLSA-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 2015 22 / 26
Goodies TLSA DANE
TLSA/DANE bei E-Mail
Outbound:DNSSEC-validierender ResolverPostfix >= 2.11
smtp_tls_security_level = danesmtp_dns_support_level = dnssecVerified 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)
Exim??
Statistik am LRZ (12.2. - 19.2.):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 2015 23 / 26
Goodies TLSA DANE
TLSA/DANE bei E-Mail
Inbound:kein Support des lokalen MTA nötig, STARTTLS genügtZonen DNSSEC-signieren und Zertifikat im TLSA-Record hinterlegenkeine Signalisierung der TLSA-Nutzung durch den Sender -> keineStatistik
Statistik am LRZ (12.2. - 19.2.):<1% der Zonen signiert>50% des Mailverkehrs über DANE abgesichert
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 24 / 26
Status und Ausblick
Langsame Zunahme von DNSSEC-Zonen am LRZwir arbeiten noch an Automatisierung, Dokumentation, Erfahrung, ...
Wünsche an andere Mitglieder/DFNDNSSEC-Validierung auf ResolvernDNSSEC-Signierung von eigenen ZonenDANE/TLSA für ausgehenden MailverkehrDANE/TLSA für eingehenden Mailverkehr (DFN-Mailsupport!)
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 25 / 26
Status und Ausblick
Vielen Dank!
Bernhard [email protected]
Bernhard Schmidt DNSSEC im (Münchner) Wissenschaftsnetz 3. März 2015 26 / 26