Technic Blog

Technik BlogDNS Security Extensions - Teil I

02. März 2017 Maximilian Fruth, Dr. Wolfgang Gehrke

Domain Name System absichern mit DNSSEC

DNSSEC (Domain Name System Security Extensions) ergänzen das DNS (Domain Name System) durch Sicherheitsfunktionen zur Garantie von Echtheit und Unversehrtheit der gelieferten Informationen. Diese Überprüfung findet aber meist nicht auf den Endgeräten selbst statt, sondern muss am jeweils benutzten Resolver konfiguriert werden. Dieser liefert dann auch im Falle des Scheiterns des Verifikationstests einen Fehler an den anfragenden Client weiter.

Der DNS Resolving Prozess

DNS Client und rekursiver DNS Resolver
DNS Client und rekursiver DNS Resolver
DNS Resolver und Root/TLD DNS Server
DNS Resolver und Root/TLD DNS Server
DNS Resolver und Authoritative DNS Server
DNS Resolver und Authoritative DNS Server

1. Der DNS Client sendet eine DNS Abfrage an den DNS Resolver, der üblicherweise vom Internet Provider administriert wird. Der Client zeigt durch Setzen eines speziellen Flags (DO=1) an, dass er falls möglich, eine DNSSEC validierte Auflösung wünscht.

2. Der DNS Resolver sendet eine DNS Anfrage zum Root und TLD DNS Server. Dabei signialisert er seine DNSSEC Awareness ebenfalls durch Setzen des entsprechende Flags (DO=1).

3. Der Root und TLD Server liefert dem DNS Resolver die IP Adresse des "Authoritive DNS Servers" für die Zone. Die DNS Server für die Parent Zone zeigen an, dass die Child Zone signiert ist und liefern den sog. Secure Delegation Record (DS Record) in der Antwort auf die Anfrage.

4. Der DNS Resolver sendet eine DNS Anfrage an den "Authoritive DNS Server" für die Zone. Durch Setzen des DNSSEC Awareness Flags wird dem DNS Server angezeigt, dass der Resolver signierte Resource Records validieren will (CD=1) und die notwendigen Informationen in der Antwort erwartet.

5. Falls vorhanden, sendet der "Authoritive DNS Server" die DNSSEC Signaturen in sog. RRSIG Records in der Antwort mit. Damit kann der Resolver die Antworten validieren.

6. Der Resolver sendet dem Client in seiner Antwort den Resource Record (z.B. eine IP Adresse), falls die Validierung erfolgreich war bzw. einen Fehler falls der Record nicht existiert oder die Validierung fehlgeschlagen ist. Die erfolgte DNSSEC Validierung wird mit Hilfe des Flags (AD=1) in der Rückantwort an den Client signalisiert.

Threats beim DNS Resolving

DNS Redirection durch Trojaner

(1) Trojaner/Virus

Falls das Client System mit Schadsoftware infiziert ist, kann der Resolving Prozess auf unterschiedliche Art manipuliert werden, Ein Beispiel ist das Fälschen von Betriebssystem Konfigurationen, um DNS Anfragen an einen arglistigen Resolver umzulenken. Generell gilt, daß Trojaner viefältige Möglichkeiten zur Fälschung von Daten und Protokolle auf dem Client System haben, um Security Controls zu umgehen.

DNSSEC verhindert Manipulationen durch Trojaner nicht!

(2) DNS Injection

Beim DNS Injection findet ein Angriff auf Netzwerkebene statt. Klassische Angriffspunkte sind hierfür öffentliche WLAN-Netze wie in Hotels oder Flughäfen.

Beim sog. Man-In-the-Middle Angriff fängt ein Angreifer DNS Anfragen ab und schleust gespoofte Antworten in die Kommunikation ein. Da beim DNS die Datagramme nicht verschlüsselt übertragen werden, kann die sog. Query-ID der Anfrage leicht mitgelesen und zusammen mit der IP Adresse des Resolvers passend in die Antwort eingebaut werden. Für den Client ist diese Art der Manipulation nicht zu erkennen.

DNSSEC bietet keinen Schutz vor DNS Injection!

DNS Cache Poisoning mit DNS Injection

(3) + (4) DNS Cache Poisoning mit DNS Injection

Beim DNS Cache Poisoning versucht ein Angreifer gefälschte Informationen während des rekursiven Namensauflösung in den Resolver Cache einzuschleusen. Dies kann zum Beispiel mittels DDoS Angriff auf den Authoritive DNS Server erfolgen. Während des Angriffs kann dieser wegen der hohen Last DNS Anfragen nur verzögert oder gar nicht beantworten. Diese Zeit nutzt ein Angreifer für die DNS Injection aus. Kommt DNSSEC zum Einsatz, identifiziert der Validierungsprozess bei der Rückverfolgung der "Chain of Trust" falsche Informationen, wenn diese keine richtigen Signaturen liefern.

DNSSEC schützt vor Cache Poisoning mit DNS Injection!

(5) DNS Cache Poisoning mit Attacker's Domain

Dabei versucht der Angreifer eine mögliche Schwachstelle der Resolver Software zu nutzen. Hierzu sendet der Angreifer eine DNS Anfrage für eine Domain, deren Authoritive DNS Server unter seiner Kontrolle ist. Die Antwort des DNS Servers enhält Zusatzdaten, die unter Ausnutzung der Schwachstelle in den Resolver Cache eingeschleust werden. Auch diese Art von DNS Cache Poisoning wird durch DNSSEC fast unmöglich.

DNSSEC erschwert Cache Poisoning mit Attacker's Domain!

Es muss erwähnt werden, daß weitere Verfahren und Schwachstellen bekannt sind, die eine Bedrohung für DNS Anfragen darstellen. Diese betreffen aber primär die DNS Server selbst und vor allem, wenn bei der Administration dieser Systeme wichtige Sicherheitsaspekte nicht beachtet werden.

DNSSEC fähige DNS Resolver

Ohne DNSSEC fähige Resolver, bleiben signierte DNS Zonen ein vertrauensbildende Maßnahme ohne tatsächlichen Nutzen für den Internet User. Viele Provider scheuen den Support Aufwand für Ihre Kunden der dadurch entsteht, wenn Fehler in der DNSSEC Validierung zu unverständlichen Fehlermeldungen z.B. beim Aufruf einer Website im Browser des Kunden führen.

Leider können diese Fehlermeldungen nicht zwingend mit einem Sicherheitsvorfall in Zusammenhang gebracht werden. Auch Konfigurationsfehler beim Administrator der DNS Zone können hierfür die Ursache sein. In diesen Fällen bleibt dem Provider des DNS Resolvers nur die Möglichkeit eine Behebung des Problems anzufragen, ohne die Sicherheit zu haben, daß die Korrektur auch umgesetzt wird.

In diesem Zusammenhang stellt sich die Frage, wieviele DNSSEC signierte Domains von den Resolvern tatsächlich validiert werden. APNIC stellt hierzu ein interessantes Monitoring zur Verfügung.

Externer Link DNSSEC Validation Rate by Country

Gemäß den Statistiken von APNIC werden ca. 14% aller signierten Domains auch vollständig validiert, in Deutschland sind es immerhin mehr als 31%. Wenn man davon die 15% der Validierungen über den Public DNS Service (PDNS) von Google abzieht (Anm.: eine erschreckend hohe Zahl!), bleibt noch ein Validierungsgrad von 16%. Dies bedeutet:

Für mehr als 80% aller Internet Nutzer, die nicht abhängig von Google PDNS sein wollen, sind DNSSEC signierte Domains beim Surfen nutzlos, weil keine Validierung durch die DNS Resolver erfolgt!

Eine weitere interessante Information ist, daß laut Auskunft der Denic nur 0.5% der über 16 Mio .de Domains einen DNSKEY hinterlegt haben (April 2017). Die Zahl der "DNSSEC Domains" ohne DNSKEY Record in der .de TLD soll deutlich höher sein. Letztere Aussage soll an dieser Stelle nicht näher bewertet werden, es gilt:

Nur 0.5% der .de Domains sind signiert und können validiert werden!

DNSSEC Resolver beim Hosting

Bisher wurde ausschliesslich die Bedrohung der Clientsysteme durch DNS Angriffen betrachtet. Mindestens genauso gefährlich sind DNS Angriffe auf Serversysteme, wenn spezielle Sicherungsmaßnahmen nicht getroffen wurden.

DNS Angriffszenario auf Serversysteme

Dieses Angriffszenario betrifft Serversysteme, die Software über ein Respository installieren bzw. aktualisieren.

Ein Umleiten des Software Mirrors durch Cache Poisoning führt zur Installation infizierten Codes auf dem Serversystem, wenn keine zusätzliche Validierung von Signaturen auf Packet Ebene vorgenommen wird.

Wer beispielsweise Wordpress Auto-Update auf seinem Server System aktiviert hat bzw. Updates via PECL, PEAR oder CPAN durchführt, ist potentiell verwundbar.

Im Fall Wordpress fehlt nicht nur ein Verfahren zur Verifikation der Signaturen, eine Validierung von api.wordpress.org ist mangels DNSSEC Signierung ebenfalls unmöglich.

Desweiteren überrascht, dass die Domains aller grossen Software Unternehmen in der Regel signiert, aber die für den Software Update wichtigen CDN CNAMES häufig unsigniert sind.

Domains von Software Mirrors sind mit DNSSEC zu schützen!

Das beschriebene Szenario ist bewusst einfach dargestellt. Ein Hosting Provider stellt üblicherweise ein Software Repository als Mirror verschiedener Software Distributoren zur Verfügung. Für diesen Mirror gilt aber das Gleiche hinsichtlich der Gefahr einer Malware Injection. Software Packete sind zu validieren und DNSSEC fähige Resolver sind auf dem Mirror Server zu konfiguren.

Generell sollte man bei der DNS Konfiguration auf Server Systemen einen pragmatischen Ansatz wählen. Wenn ausgehende Verbindungen ausschließlich für dedizierte Ziel IPs zulässig sind, kann auf DNSSEC fähige Resolver verzichtet werden. Für alle anderen Fälle empfiehlt sich die Konfiguration von DNSSEC Resolver, falls eine leistungsfähige DNS Resolver Infrastruktur vorhanden ist.

Hinweise zur Konfiguration des DNSSEC Resolving

Der Client muss die Erweiterungen des DNS aktivieren:

# example /etc/resolv.conf
options edns0
...

Da der Client im Betriebssystem meist nur einen stub resolver besitzt, muss dieser auf einen validating resolver verweisen:

# example /etc/resolv.conf
nameserver <IP of validating resolver>
...

Sind mehrere Resolver konfiguriert, dann sollten sie alle den Validierungsprozess durchführen, denn sonst kann ein nicht validierender Resolver antworten:

# example /etc/resolv.conf with insecure setting
nameserver <IP of validating resolver>
nameserver <IP of non-validating resolver>
...

Außer der Nutzung eines lokalen Resolvers kann auch die Nutzung eines remote Resolvers über einen VPN Tunnel in Betracht kommen. Manche Anbieter stellen inzwischen sogar eine DNS Namensauflösung über https zur Verfügung. Beide Optionen sichern die Kommunikation zwischen Client und Resolver.

Warum DNSSEC?

Vorteile

Es bietet mehr Sicherheit bei der Benutzung einer eigenen Domäne und für die Nutzer, welche auf diese Domäne zugreifen.

Alle Arten von Resource Records wie z.B. MX für den Mailtransport, NAPTR für die Internettelefonie, TXT mit Angaben zum Sender Policy Framework können gesichert werden.

Öffentlichem Schlüsselmaterial kann auf diese Weise sicher publiziert werden.

DNS Records, welche davon profitieren können

CAA Einschränkung der CAs für eine Domain als Information an die ausstellenden CAs

CERT Zertifikate u.a. für PGP zur Verschlüsselung von Email

IPSECKEY für öffentliches Schlüsselmaterial zum Aufbau eines VPN mit IPsec

SSHFP für die initiale Kommunikation mit einem SSH Server zur Kommunikation des Fingerprint

TLSA Information über Hashes von TLS-Zertifikaten, welche sogar pro Port angegeben werden können

Der Betreiber einer Zone bekommt somit eine Alternative zur Publikation von eigenem Schlüsselmaterial. Auf diese Weise können auch zulässige Certificate Authorities festgelegt bzw. self-signed Zertifiate publiziert werden. Am meisten nachgefragt wird DNSSEC im Kontext von sicherem eMail-Transport unter dem Einsatz von DANE, DNS-based Authentication of Named Entities.

Was wäre wünschenswert?

Am besten wäre es, wenn eine Anwendung, die sichere DNS Daten benötigt, sich auch selbst um die Validierung der gelieferten Informationen kümmert. Im Falle eines Web-Browser bedeutet dies, dass er selbst diese Validierung der "chain of trust" übernimmt. Leider nutzen die meisten Anwendungen diese Möglichkeit noch nicht.

Im Linux Kontext wäre es auch möglich, einen validating resolver auf dem gleichen Host zu betreiben. Dafür steht nicht nur BIND als Software zur Verfügung. Auch das Paket "unbound" kann zu diesem Zweck verwendet werden.

# example /etc/resolv.conf with local DNS server
nameserver 127.0.0.1
...

Erfolgt die Validierung gleich auf dem Endgerät, dann ist es nicht möglich, falsche Informationen auf dem Weg zwischen Client und Resolver einzuschleusen. Das setzt natürlich ein normal funktionierendes Gerät voraus, welches nicht mit Schadsoftware infiziert ist. Bei Verwendung von den oben erwähnten Records ist dieses Herangehen ein echter Sicherheitsgewinn.