DNSSEC im (MÃ¼nchner) Wissenschaftsnetz

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


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


http://ping.lrz.de/~bschmidt/dnssec.pdf

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


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


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, ...)


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



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, ...)



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


http://stats.labs.apnic.net/dnssec/XA

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)



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



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




dns1

dns2

dns3

resolver1

resolver2

WebDNS

BIND

HTTP

CMDB




dns1

dns2

dns3

resolver1

resolver2

WebDNS

BIND

HTTP

DNSSECProxy

CMDB



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/


http://scoreboard.verisignlabs.com/


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


http://www.nlnetlabs.nl/projects/ldns/

https://www.dns-oarc.net/oarc/services/odvr

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


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


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, ...




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, ...




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


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


https://www.dnssec-validator.cz

https://code.google.com/p/chromium/issues/detail?id=50874

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/


https://mailbox.org/e-mail-made-in-germany-verhindert-systematisch-teilnahme-anderer-provider/

Goodies TLSA DANE


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


Goodies TLSA DANE


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, ...


Goodies TLSA DANE


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


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


Status und Ausblick

Vielen Dank!

Bernhard [email protected]


Date post:	14-Feb-2017
Category:	Documents
Upload:	hoangtuyen
View:	234 times
Download:	1 times

DNSSEC im (MÃ¼nchner) Wissenschaftsnetz

Documents