DNS-Sicherheit

Carsten Strotmann, dnsworkshop.de

IT-Defense 2019

Created: 2019-02-12 Tue 09:20

Agenda

DNS - Wohin geht die Reise?
Grundlagen der (Un-)Sicherheit von DNS im Überblick
aktuelle DNS Sicherheitstechniken
- QNAME-Minimization
- Verschlüsselte Transportprotokolle
- DNSSEC
- DDoS-Angriffe erfolgreich abwehren
Zusammenfassung und Ausblick

Wer sprich hier?

Carsten Strotmann

dnsworkshop.de

DNS(SEC)/DANE/DHCP/IPv6 Trainer und Helfer

RIPE/IETF

DNS - Wohin geht die Reise

DNS (Domain Name System) wurde 1983 als generische Online-Datenbank für Netzwerk-Konfigurationsdaten entworfen …

DNS - Wohin geht die Reise

… und dann für 30 Jahre (fast) nur zur Auflösung von IP-Adressen benutzt
dies ändert sich seit einigen Jahren:
- DNS kommuniziert heute Sicherheits- und Konfigurations-Richtlinien (Policy-Service)
- DNS verteilt Arbeiten in Cloud-Installationen (Service-Discovery)

DNS als Richtlinien-Server

DNS kommuniziert heute wichtige Richtlinien der Domain an das Internet
- E-Mail Richtlinien (SPF, DMARC, DKIM)
- Sicherheitsgarantien für E-Mail Transportverschlüsselung (MTA-STS)
- TLS-Transport-Verschlüsselung (TLSA-Record)
- CA-Pinning der Domain-Zertifikate (CAA-Record)
- IPSec Konfigurationen (IPSECKEY-Record)
- PGP und S/MIME Schlüssel (OPENPGPKEY/SMIMEA-Records)

DNS als Richtlinien-Server

DNS zur Dienst-Authentisierung
- Adobe
- Facebook
- Google Webmaster Tools
- Yandex
- Atlassian
- Docusign
- Microsoft Office 365
- Let's Encrypt
- Digicert und andere CAs
- u.v.m.

DNS als Richtlinien-Server

Beispiel

# dig txt microsoft.com
[...]
;; ANSWER SECTION:
microsoft.com.          3600    IN      TXT     "docusign=52998482-393d-46f7-95d4-15ac6509bfdd"
microsoft.com.          3600    IN      TXT     "docusign=d5a3737c-c23c-4bd0-9095-d2ff621f2840"
microsoft.com.          3600    IN      TXT     "adobe-sign-verification=c1fea9b4cdd4df0d5778517f29e0934"
microsoft.com.          3600    IN      TXT     "facebook-domain-verification=bcas5uzlvu0s3mrw139a00os3o66wr"
microsoft.com.          3600    IN      TXT     "facebook-domain-verification=gx5s19fp3o8aczby6a22clfhzm03as"
microsoft.com.          3600    IN      TXT     "facebook-domain-verification=m54hfzczreqq2z1pf99y2p0kpwwpkv"
microsoft.com.          3600    IN      TXT     "google-site-verification=6P08Ow5E-8Q0m6vQ7FMAqAYIDprkVV8fUf_7hZ4Qvc8"
microsoft.com.          3600    IN      TXT     "FbUF6DbkE+Aw1/wi9x[...]GrQ/rVQKJi8CjQbBtWtE64ey4NJJwj5J65PIggVYNabdQ=="
microsoft.com.          3600    IN      TXT     "atlassian-domain-verification=jbey7I2+3Wy[...]c4za7ebQxar/qqujJH4kZLVQHZ"

DNS in Cloud-Infrastrukturen

am Beispiel Kubernetes (andere Systeme arbeiten ähnlich)

traditionelles DNS, unverschlüsselt, Daten nicht authentisiert

Diskussion

Grundlagen der (Un-)Sicherheit von DNS im Überblick

DNS Sicherheit - Grundlagen

DNS-Sicherheit - Angriffe

das ursprüngliche DNS Protokoll war nicht für sichere Kommunikation ausgelegt
es gibt eine Reihe Angriffe auf die DNS-Daten und -Infrastruktur

DNS Sicherheit - Angriffe

Alles nur Theorie?

das klassische DNS hat 30 Jahre gut funktioniert, warum jetzt ändern?

Alles nur Theorie?

die Sicherheit von Protokollen wie HTTPS und SMTP wurde in den letzten Jahren stark verbessert
Angreifer suchen nach dem "schwächsten Punkt" im Netzwerk
- dies ist nun immer öfters DNS

Angriffe 2018

Angriffe 2019

Diskussion

Privacy trotz DNS - wie geht das?

die IETF hat in den letzten Jahren das DNS-Protokoll um Sicherheitsfunktionen erweitert
- DNS-over-TLS (Transportverschlüsselung zwischen Client und DNS-Server)
- DNS-over-HTTPS (Transportverschlüsselung zwischen Client und DNS-Server)
- QNAME Minimization (Reduktion von Metadaten)
- EDNS-Padding (verstecken von DNS-Daten in verschlüsselten Verbindungen)

QNAME-Minimization

klassische Implementierungen sind sehr gesprächig
- es werden Daten gefragt/geliefert, welche (heute) vom DNS-Protokoll nicht unbedingt benötigt werden

QNAME-Minimization

RFC 7816 DNS Query Name Minimisation to Improve Privacy spezifiziert DNS-Namensauflösung mit minimalen Metadaten
- nur DNS-Resolver müssen angepasst werden.
- DNS-Clients, DNS-Authoritative-Server, Firewalls etc. brauchen keine Anpassung
- QNAME-Minimization ist keine Änderung des DNS-Protokolls, nur eine Implementierungs-Empfehlung!

Traditionelle DNS Namensauflösung (1/6)

Traditionelle DNS Namensauflösung (2/6)

Traditionelle DNS Namensauflösung (3/6)

Traditionelle DNS Namensauflösung (4/6)

Traditionelle DNS Namensauflösung (5/6)

Traditionelle DNS Namensauflösung (6/6)

DNS Namensauflösung mit QNAME Minimization

bei einem DNS-Resolver mit QNAME Minimization kennt der DNS-Server die Struktur des DNS im Internet (Root -> TLD -> SLD …)
der DNS-Resolver fragt für jede Ebene nach dem notwendigen Domain-Namen (Delegation/Ziel-Name)
in den meisten Fällen ist DNS-Auflösung mit QNAME-Minimization gleich schnell oder sogar schneller verglichen mit traditioneller DNS Auflösung

DNS Namensauflösung mit QNAME Minimization

QNAME-Minimization Implementierungen

Unbound
Knot-Resolver
BIND 9.13 (in Entwicklung)

QNAME Minimization Test

Einfacher Test per dig, ob der benutzte DNS-Resolver QNAME-Minimization anbietet

shell$ dig txt qnamemintest.internet.nl +short
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"

Diskussion

Sichere Transportprotokolle für DNS

Begriffe
- DoT = DNS-over-TLS - TLS als Transport
- DoH = DNS-over-HTTPS - HTTPS als Transport
- DoQ = DNS-over-QUIC - QUIC als Transport
- DoC = DNS-over-Cloud - DNS Auflösung über Dienst "in der Cloud" (Google, Q9, Cloudflare …)

DNS-over-TLS

RFC 7858 "Specification for DNS over Transport Layer Security (TLS)"
DNS wireformat over TLS over TCP
Port 853 (TCP)
Bietet Verschlüsselung und Authentisierung (CA-Modell oder per DANE)

DNS-over-TLS (1/3)

DNS-over-TLS (2/3)

DNS-over-TLS (3/3)

Geschwindigkeit von DNS-over-TLS

DNS-over-TLS Geschwindigkeit/Latenz bei der Benutzung von TLS 1.3 ist sehr gut
bei bestehenden TLS-Verbindungen vergleichbare Geschwindigkeit zu DNS-over-UDP
- Pipelining
- TCP fast open
- 0-RTT resume
derzeit sind die verfügbaren Implementationen noch nicht vollständig optimiert

DNS-over-TLS Betriebsmodi

DNS-over-TLS kann in zwei Modi betrieben werden
- opportunistic - versuche TLS, benutze den Server auch wenn die TLS-Authentisierung fehlschlägt
- strict - Verbindung wird nur benutzt, wenn es beim TLS-Verbindungsaufbau keine Fehler gab (Authentisierung etc.)

DNS-over-TLS Client Implementierungen

DoT Client Implementierungen
- Android "Pi" (9)
- Linux systemd
- OpenBSD "unwind"
- Knot-DNS / Unbound / PowerDNS dnsdist Load-Balancer
- DNS Privacy Daemon - Stubby
- jDNSProxy Simple fast and lightweight DNS proxy and cache, implementing DNS-over-TLS, DNS-over-HTTPS, and Serve-Stale
- veild und viele mehr

DNS-over-TLS Server Implementierungen

DoT Server Implementierungen
- CoreDNS
- TentaDNS
- sdns
- PowerDNS und andere DNS-Server via dnsdist
- jeder DNS-Server via stunnel, ha-proxy, nginx, relayd (OpenBSD)

DNS-over-TLS Anbieter

Anbieter

DoH - DNS over HTTP(S)

RFC 8484 DNS Queries over HTTPS (DoH) (P. Hoffman, ICANN and P. McManus, Mozilla) https://tools.ietf.org/html/rfc8484
DNS HTTP-Format over HTTPS over TCP, Port 443 (HTTP/2)
URL: https://server/dns-query{?dns}"
Verschlüsselung und Authentisierung

DoH - DNS-over-HTTPS

Vorteile

HTTPS wird wenig gefiltert (Firewall)
einfache Benutzbarkeit innerhalb von Web-Anwendungen und Web-Diensten
HTTPS-APIs in vielen Programmiersprachen verfügbar

Entwicklungen

IETF 100 - November 2017 - DNS over HTTP(S) (DoH) Arbeitsgruppe gegründet: https://datatracker.ietf.org/wg/doh/about/
IETF 101 - März 2018 - Arbeit an DNS Queries over HTTPS abgeschlossen, Start des working group last call (WGLC) im April 2018
Oktober 2018 - RFC 8484 veröffentlicht
viele Open-Source Implementierungen u.a. von Cloudflare, Google, Facebook

DNS-over-HTTPS und IDS/Netzwerk-Filter

Zitat aus RFC 8484:

Operational Considerations […] Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS.

DoH Client Implementierungen (1/2)

Firefox 61+ (manuell anschaltbar)
Firefox TRR Konfigurations Optionen

DoH Client Implementierungen (2/2)

Bromite Browser "Bromite is Chromium plus ad blocking and privacy enhancements"
cURL (Pull Request on Github)

DoH Resolver/Server

jDNSProxy Simple fast and lightweight DNS proxy and cache, implementing DNS-over-TLS, DNS-over-HTTPS, and Serve-Stale
m13253/DNS-over-HTTPS High performance DNS over HTTPS client & server
rust-doh A DNS-over-HTTP server proxy
doh-proxy A set of python 3 scripts that supports proxying DNS over HTTPS
dnss a daemon for using DNS over HTTPS (Client + Server)

DoH Anbieter (Auswahl)

DNS over QUIC

DNS over QUIC over UDP
Specification of DNS over Dedicated QUIC Connections https://tools.ietf.org/html/draft-huitema-quic-dnsoquic

was ist QUIC

moderner TCP-Ersatz von Google, wird derzeit in der IETF standardisiert
- benutzt UDP, implementiert TCP Funktionen
- ist Bestandteil von Anwendungen, nicht im Betriebssystem-Kern
- beinhaltet TLS 1.3
- 0-RTT
Geschwindigkeit vergleichbar mit klassischem DNS-over-UDP
QUIC Dokumente https://tools.ietf.org/wg/quic/

DNS over QUIC

DNS over QUIC im Vergleich

Figure 31: Source: https://datatracker.ietf.org/meeting/99/materials/slides-99-dprive-dns-over-quic

Diskussion

DNSSEC

Was ist DNSSEC

Absicherung von DNS Daten mittels kryptografischer Signaturen
Asymmetrische Verschlüsselung
der Empfänger von DNS Daten kann prüfen (validieren) das
- die Daten vom Besitzer des privaten Schlüssels der Zone kommen
- die Daten seit dem Einstellen in die Zone nicht geändert wurden

DNSSEC Geschichte

DNSSEC Validierung Grundlagen

DNSSEC Validierung

DNSSEC Validierung (vereinfacht)

DNSSEC-Validierung (vereinfacht)

DNSSEC und Client-Systeme

DDoS-Angriffe abwehren

in den vergangenden Jahren hat eine Variante von DDoS Angriffen auf DNS-Server zugenommen: Random-Subdomain Attack

per Botnetz werden authoritative DNS-Server mit unsinnigen DNS-Anfragen bombadiert
- die Anfragen sind für Domain-Namen, die nicht existieren
- jede Anfrage benutzt einen neuen, zufälligen Domain-Namen (verhindert Caching)
die angegriffenen DNS-Server können die Menge der DNS-Anfragen nicht beantworten und sind nicht mehr erreichbar
als Nebeneffekt wird die Namensauflösung in Caching-DNS-Servern gestört

Random-Subdomain Angriff (1/4)

Random-Subdomain Angriff (2/4)

Random-Subdomain Angriff (3/4)

Random-Subdomain Angriff (4/4)

Was ist NSEC/NSEC3

DNSSEC sichert (auch) negative Antworten ab
negative Antworten im DNS sind
- NXDOMAIN - diese Domain existiert nicht
- NXRRSET - dieser Resource Record Set (DNS-Daten-Typ) existiert für diesen Domain-Namen nicht
DNSSEC benutzt eine verkettete Liste der existierenden Namen (NSEC = Klartext, NSEC3 = SHA1 Hashes) und DNS-Record Typen

NSEC Chain

NSEC(3) aggressive use

RFC 8198 "Aggressive Use of DNSSEC-Validated Cache"
DNS-Resolver werten die NSEC/NSEC3 Antworten über die ursprüngliche Anfrage hinaus aus
weitere DNS-Anfragen nach nicht existierenden Domain-Namen (vom gleichen oder von anderen Client-Systemen) werden direkt vom DNS-Resolver negativ beantwortet (NXDOMAIN)
die authoritativen Server werden nicht mehr gefragt
NSEC(3) Records werden für die Zeit der TTL (Time-To-Live) benutzt

NSEC(3) aggressive use (1/4)

NSEC(3) aggressive use (2/4)

NSEC(3) aggressive use (3/4)

NSEC(3) aggressive use (4/4)

DNSSEC Risiken

Risiken beim Betrieb eines DNSSEC Resolvers
Risiken einer DNSSEC signierten Zone
Gegenmaßnahmen

Risiken: Betrieb eines DNSSEC Resolvers

bei einer defekten Vertrauenskette oder defekten Signatur lautet die DNS-Antwort "SERVFAIL"
"SERVFAIL" ist nicht DNSSEC spezifisch, sondern beschreibt beliebige DNS-Fehler im DNS-Prozess
der End-Benutzer kann nicht erkennen, das die DNS-Auflösung an der DNSSEC-Sicherheit scheitert und wird den Betreiber des DNS-Resolvers als Verursacher sehen

Risiken: Betrieb eines DNSSEC Resolvers

Betrieb eines DNSSEC Resolvers: Maßnahmen

offene Kommunikationspolitik gegenüber den End-Benutzern über DNSSEC-Fehlersituationen
Monitoring von DNSSEC-Validierungsfehlern auf den DNS-Resolvern
Einsatz von "Negative-Trust-Anchor" (NTA) vorbereiten

Risiken: DNS Server mit NSEC3-signierten Zonen

ein DNS-Server mit NSEC3 DNSSEC signierten Zone muss für jede negative Antwort (NXDOMAIN- und NODATA) ein SHA1-Hash errechnen -> Potential eines "Denial-of-Service" Angriffs auf die CPU-Resourcen des DNS-Servers

Gegenmaßnahmen: DNS Server mit NSEC3-signierten Zonen

NSEC statt NSEC3 einsetzen, wenn möglich (Zonewalking möglich, aber oft das "kleinere Übel")
genügend CPU-Resourcen für die gewünschte Anfrage-Kapazität vorhalten und testen
Response-Rate-Limiting auf dem DNS-Server aktivieren

Risiken: DNSSEC signierte Zone

Fehler bei der Signierung der Zone
Fehler beim Einbringen/Ersetzen des DS-Records in der Eltern-Zone
Fehler beim Aktualisieren der Record-Signaturen (RRSIG)
Fehler beim Austausch der DNSSEC-Schlüssel (Key-Rollover)
Fehler bei der Planung der Paketgrössen (Pakete > 1232 Byte über IPv6)
Ungünstiger DNS-Auflösungspfad
'Parent-Child-Delegation-Disagreement' (NS-Records der Delegation passen nicht zu den NS-Records der delegierten Zone)

Gegenmaßnahmen: DNSSEC signierte Zone

Fehler bei der Signierung der Zone
- Tests an 'unwichtigen' DNS-Zonen
- exteres Know-How für die Anfangszeit einkaufen
- Schulungen der DNS-Administratoren
- Time-To-Live Werte der Zone überprüfen und ggf. herabsetzen (unter 24 H)
- SOA-Parameter (Refresh/Retry/Expire/NegTTL) überprüfen und ggf. anpassen

Gegenmaßnahmen: DNSSEC signierte Zone

Fehler beim Einbringen/Ersetzen des DS-Records in der Eltern-Zone
- DS-Record vor Einbringen in die Elternzone lokal testen (z.B. mit 'unbound-host'
- Status des DS-Records und des KSK der Zone im Monitoring überwachen
- DS-Record Aktualisierung per API automatisieren

Gegenmaßnahmen: DNSSEC signierte Zone

Fehler beim Aktualisieren der Record-Signaturen (RRSIG)
- Aktualisieren der DNSSEC Signaturen automatisieren (BIND 9, PowerDNS, KnotDNS, Windows 2012/2016, OpenDNSSEC …)
- Signatur-Ablaufdatum im Monitoring überwachen

Gegenmaßnahmen: DNSSEC signierte Zone

Fehler beim Austausch der DNSSEC-Schlüssel (Key-Rollover)
- Tests an 'unwichtigen' DNS-Zonen
- exteres Know-How für die Anfangszeit einkaufen
- Schulungen der DNS-Administratoren
- DNSSEC-Key-Rollover automatisieren
- DNSSEC-Key-Rollover im Monitoring überwachen
- DNSSEC-'Logbuch' führen

Gegenmaßnahmen: DNSSEC signierte Zone

Fehler bei der Planung der Paketgrössen (Pakete > 1280 Byte über IPv6 = Fragmentierung)
- EDNS0-Buffergrösse auf den authoritativen DNS-Servern der Zone anpassen (1232 Byte DNS Payload)
- Domain-Namen sorgfältig wählen (Label-Compression)
- zu grosse Resource-Record-Sets vermeiden
- zu grosse RSA-Schlüssel vermeiden
- CNAME-Ketten vermeiden
- 'minimal-responses' einschalten
- 'minimal-any' einschalten

Gegenmaßnahmen: DNSSEC signierte Zone

Ungünstiger DNS-Auflösungspfad
- DNS-Auflösungspfad zwischen Redundanz und Auflösungs-Schritte ausbalancieren (auch ohne DNSSEC sinnvoll)
- CNAME-Verweise zwischen DNSSEC-signierten Zonen und Zonen ohne DNSSEC vermeiden

Gegenmaßnahmen: DNSSEC signierte Zone

'Parent-Child-Delegation-Disagreement' (NS-Records der Delegation passen nicht zu den NS-Records der delegierten Zone)
- NS-Records in der Delegation (der Eltern-Zone) und der delegierten Zone identisch halten (ist schon für klassisches DNS notwendig, hat aber dort nur selten negative Effekte)

Risiken: DNSSEC

Ist DNSSEC ein Risiko für das Netzwerk?
- Ja, aber ein Risiko welches mit Planung, Automatisierung und gewissenhaften Arbeiten minimiert werden kann
- die DNSSEC-Vorteile überwiegen die Risiken

Zusammenfassung und Ausblick (1/3)

das DNS Protokoll entwickelt sich derzeit schnell weiter
- zu schnell? (siehe “The DNS Camel”, or, the rise in DNS complexity und RFC 8324 DNS Privacy, …: Time for Another Look?)
Kommunikation zwischen DNS-Client und DNS-Resolver wird in Zukunft verschlüssel (DNS-over-TLS, DNS-over-HTTPS, DNS-over-QUIC)
DNS-over-HTTPS/QUIC kann zur Zentralisierung, oder aber auch zur De-Zentralisierung von DNS-Diensten führen
DNSSEC schützt (auch) gegen DDoS Angriffe

Zusammenfassung und Ausblick (2/3)

neue DNS-Protokollerweiterungen …
- … schützen die Privatsphähre von DNS-Nutzern
- … erhöhen die Sicherheit der DNS-Kommunikation
- … verringern die Nutzbarkeit von DNS-IDS/Passive-DNS
Sicherheitstechniken, basierend auf der Auswerung von DNS-Daten, sind in Zukunft weniger effektiv
Richten Sie Ihre Planung auf diese Änderungen aus!

Zusammenfassung und Ausblick (3/3)

was kann heute getan werden?
- DNSSEC Validierung auf DNS-Resolvern einschalten
- Absicherung der eigenen Zonen per DNSSEC-Signaturen prüfen
- bei Forwarding zum ISP-Resolver: DNS-over-TLS einsetzen (Provider motivieren)
- Authoritative und DNS-Resolver Funktionen im Unternehmensnetzwerk trennen
- QNAME-Minimization einschalten
- eigene DNS-Resolver überwachen

Vielen Dank!

Diskussion

Kontakt: cstrotm@dnsworkshop.de

Links

RFC 7816 "QNAME Minimization" https://tools.ietf.org/html/rfc7816
RFC 8198 "Aggressive Use of DNSSEC-Validated Cache" https://tools.ietf.org/html/rfc8198
Passive DNS Replication https://www.first.org/conference/2005/papers/florian-weimer-paper-1.pdf
RFC 7858 "Specification for DNS over Transport Layer Security (TLS) https://tools.ietf.org/html/rfc7858
DNS-over-TLS im Android
DNS-over-TLS Implementationen
- Unbound https://unbound.net
- Knot-DNS https://www.knot-dns.cz/
- PowerDNS 'dnsdist' https://blog.powerdns.com/2018/03/30/dnsdist-1-3-0-released/
- Stubby Privacy Stub-Resolver https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
- CoreDNS https://coredns.io
- TentaDNS https://tenta.com/blog/post/2017/12/dns-over-tls-vs-dnscrypt
DNS-over-TLS Anbieter (Auszug)
- Cloudflare/APNIC https://developers.cloudflare.com/1.1.1.1/dns-over-tls/
- Quad9 Resolver https://www.quad9.net/
- SurfNET https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
- Verisign https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
DNS over HTTPS
- DNS-over-HTTPS RFC 8484 https://tools.ietf.org/html/rfc8484
- Google DNS-over-HTTPS Dienst https://developers.google.com/speed/public-dns/docs/dns-over-https
- OpenResolve https://www.openresolve.com/
- DinGO https://github.com/pforemski/dingo
- CoreDNS https://coredns.io/2016/11/26/dns-over-https/
DNS-over-QUIC
- IETF Draft https://tools.ietf.org/html/draft-huitema-quic-dnsoquic
- QUIC Dokumente https://tools.ietf.org/wg/quic/
Ändert sich das DNS zu schnell?
- “The DNS Camel”, or, the rise in DNS complexity https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/
- RFC 8324 - DNS Privacy, … Time for Another Look? https://tools.ietf.org/html/rfc8324