DNS im Umbruch : Standards für verschlüsselte DNS-Abfragen

Von Kirill Kasavchenko, Frankfurt/Main

Das Akronym „DoH“ für „DNS over HTTPS“ ist durchaus ironisch zu verstehen und zeugt vom Humor der Standard-Autoren. Seit diese Variante zur verschlüsselten Abfrage von Domain-Name-Service-(DNS)-Daten jedoch von großen Softwareanbietern implementiert wird, ist sie zu einem zentralen Thema in vielen Diskussionsforen geworden, in denen der Ausruf „DOH!“ als Ausdruck von Besorgnis, Enttäuschung und Missverständnissen über die möglichen Auswirkungen von DoH zu hören ist.

Unter Privacy-Advokaten scheint es einen Konsens zu geben, dass die Verschlüsselung von DNS erforderlich ist, um zu verhindern, dass „Interessierte“ Einblicke in die Websites und Dienste erhalten, die Verbraucher suchen und schließlich auch besuchen. Je nachdem, wen man fragt, gibt es mehrere Bedrohungsmodelle: Einige nennen Netzbetreiber, die DNS-Daten sammeln und später weiterverkaufen oder in gezielten Marketingkampagnen verwenden könnten – andere zeigen sich besorgt über Datensammlungen von Cloud-DNS-Anbietern oder mögliche Massenüberwachungsprogramme, die von Regierungen durchgeführt werden.

Auf der anderen Seite stehen IT- und CyberSicherheitsabteilungen, deren Aufgabe es ist, das Unternehmen, für das sie arbeiten, zu schützen. Und diese sind zunehmend besorgt darüber, dass die Sichtbarkeit des DNS verschwindet und sie die Kontrolle darüber verlieren, was sich wiederum auf ihren täglichen Betrieb auswirkt.

Alternative DNS-Protokolle

Zur Verschlüsselung der DNS-Kommunikation wurden zwei Protokolle erstellt: DNS over TLS (DoT, [1]) und DNS over HTTPS (DoH [2]). Beide gewährleisten die Verschlüsselung von DNS-Daten unter Verwendung des Transport-Layer-Security-(TLS)-Protokolls, sodass sich damit derselbe Grad an Vertraulichkeit und Integrität erreichen lässt. TLS ist jedoch die einzige Gemeinsamkeit zwischen zwei Protokollen – es gibt hingegen einige sehr wichtige Unterschiede:

• Protokoll-Schichtung: DoT ist im Wesentlichen einfach „DNS over TLS“ und DoH ist in der Tat „DNS over HTTP over TLS“. Obwohl DoH in Bezug auf die Schichtung komplexer erscheint und diese Komplexität theoretisch seine Leistung beeinträchtigen und die Fehlersuche erschweren könnte, liegt darin nicht das Hauptanliegen seiner Kritiker.
• Unterschiedliche Portnummern: DoT-Verkehr verwendet den dedizierten Port 853 und bleibt daher in der Netzwerkschicht unterscheidbar – DoH verwendet aufgrund der Protokollschichtung den HTTPS-Port 443. Folglich ist es relativ einfach, DoT-Kommunikation mithilfe von Netzwerkrichtlinien zu reglementieren (Beschränkung von TCP- und UDP-Verkehr zu Port 853), aber nicht trivial, DoH zu blockieren. Denn TCP- oder UDP-Verkehr zu Port 443 zu blockieren, wirkt sich sofort auf sonstigen verschlüsselten HTTPS-Datenverkehr sowie Anwendungen aus, die Quick-UDP-Internet-Connections (QUIC) nutzen.
• Unterschiedliche Fähigkeiten: DoT ist weitgehend das gute alte DNS, wie wir es kennen [3,4], während DoH in gewissem Umfang Funktionen von DNS und HTTP kombiniert. Die bemerkenswertesten erweiterten DoH-Funktionen sind die Optionen, DNS-Daten vom Server nach dem „Push“- statt „Pull“-Prinzip zu bewegen und die Möglichkeit für Web-Browser zu definieren, welcher DNS-Resolver anstelle des im Betriebssystem konfigurierten (und somit vom Systemadministrator oder Netzzugangsanbieter vorgegebenen) Resolvers verwendet wird.

Die Tatsache, dass es zwei Möglichkeiten gibt, ein ähnliches Ziel zu erreichen, hat zu einer gewissen Divergenz innerhalb der Internet-Gemeinschaft geführt, da einige Organisationen mit der Einführung und Förderung von DoT begannen und andere DoH aufgriffen. Die erste Gruppe besteht weitgehend aus Dienstleistungsanbietern und Unternehmen: Für sie ist DoT eine natürliche Entwicklung, da es die Art und Weise, wie Netzwerke konzipiert, betrieben und gesichert werden, nicht grundlegend ändert. Web-Firmen und Browser-Entwickler setzten jedoch auf DoH und boten Benutzern die Möglichkeit, DNS-Dienste zu umgehen, die von ihren Dienstleistern bereitgestellt oder von Systemadministratoren konfiguriert werden. Sie bieten ihre eigenen Cloud-DNS-Dienste an, wobei sie als Unterscheidungsmerkmal eine Kombination aus besserem Datenschutz und höherer Leistung versprechen – zwei Dinge, die für Endbenutzer attraktiv klingen, jedoch für den IT- und Sicherheitsbetrieb in Unternehmen viele Bedenken aufwerfen.

Problematik von DoH

Die erste Sorge ist die Verlagerung von Verantwortlichkeiten, die von Endanwendern möglicherweise nicht ausreichend verstanden wird: Man stelle sich vor, ein normaler Büroangestellter installiert oder aktualisiert einen Browser mit eingeschalteter DoH-Unterstützung, der für die Nutzung eines Cloud-DNS-Diensts vorkonfiguriert ist. Wie bereits erwähnt, würden die DNS-Einstellungen des Browsers die von der IT-Abteilung bereitgestellten DNS-Systemeinstellungen umgehen. Nehmen wir an, dieser DNS-Dienst fällt aus irgendeinem Grund aus – beispielsweise aufgrund eines internen Ausfalls oder wegen eines Distributed-Denial-of-Service-Angriffs (DDoS). Einem nicht-technischen Nutzer würde dieser Vorfall wahrscheinlich in Form einer banalen Meldung wie „keine Internetverbindung“ angezeigt werden. In der Folge dürfte es im Unternehmen vermutlich zu einem Support-Anruf beim internen IT-Helpdesk kommen, der aber mit dem problematischen DoH-Dienst nichts zu tun hat und sich dessen Existenz vielleicht nicht einmal bewusst ist.

Die zweite Sorge ist die Unfähigkeit, eine DNS-Richtlinie zu erstellen und durchzusetzen -– zum Beispiel dahingehend, welche Domains aufgelöst werden dürfen und welche nicht. In Unternehmen dienen DNS-Richtlinien häufig zur Kontrolle: Es gibt dann eine Liste verdächtiger Domänen, die von den DNS-Servern schlicht nicht aufgelöst werden, wodurch die Kommunikation mit ihnen auf der DNS-Ebene effektiv blockiert ist (die IP-Adressen könnten zwar immer noch erreichbar sein, werden aber zumindest durch „normale“ Zugriffe via Domain-Names nicht erreicht). Durch den Wechsel zu alternativen DNS-Resolvern in der Cloud umgehen Endanwender diese Sicherheitskontrolle und erschweren es der Sicherheitsabteilung, Bedrohungen zu stoppen.

Ein wahres Schreckensszenario ist der Missbrauch von DoH als „Deckmäntelchen“ durch Cyberangreifer: Die Mehrheit moderner Malware greift Informationen ab und „ruft zurück“, um die infizierten Computerdetails an eine vom Angreifer kontrollierte Infrastruktur zu senden, die gewöhnlich als Command&Control-Hosts (C2) bezeichnet wird. Um diese Kommunikation vor Sicherheitssystemen zu verbergen, verwenden Angreifer eine Vielzahl von Verfahren wie Domain-Generation-Algorithmen (DGA, siehe etwa https://attack.mitre.org/techniques/T1483/) oder Verschlüsselung und Verschleierung des Datenverkehrs zu C2-Hosts, sodass sich dieser nicht vom üblichen Datenverkehr der Endanwender unterscheiden lässt. DoH scheint dabei eine ideale Wahl als Transportprotokoll für die C2-Kommunikation zu sein, da es nicht mit per Netzwerkrichtlinie blockiert werden kann und daher wie legitimer Traffic aussieht, solange man es nicht entschlüsselt und den Inhalt inspiziert – was eine nicht-triviale Aufgabe ist. Mehrere Sicherheitsforscher haben bereits demonstriert, wie Cyberangreifer Cloud-DoH-Dienste nutzen können, um Daten mit einem infizierten Computer auszutauschen, zum Beispiel durch die Verwendung von DNS-TXT-Resource-Records. Da dieser Austausch effektiv eine HTTPS-Sitzung zwischen dem Benutzer und dem Cloud-DoH-Dienst ist, sieht er einem normalen DoH-Austausch sehr ähnlich.

Gegenmaßnahmen

Die meisten Sorgen um DoH und DoT verursachen Unternehmen letztlich gar nicht die Protokolle selbst, sondern die Nutzung externer DNS-Dienste. Daher sollte man kontrollieren, welche DNS-Dienste tatsächlich in einer Unternehmensumgebung zum Einsatz kommen. Nachfolgend sind einige Empfehlungen zur Steigerung der Sicherheit näher ausgeführt.

Security-Awareness

Wie üblich beginnt alles mit dem Bewusstsein: Da sich einige Nutzer für verbesserte Privatsphäre und Leistungssteigerungen via DoH und DoT begeistern und diese am Arbeitsplatz ausprobieren könnten, wird empfohlen, alle Vor- und Nachteile dieser Verfahren während der regelmäßigen Schulungen zum Sicherheitsbewusstsein zu erklären. Die Unterstützung und das Verständnis der Nutzer würden der IT- und Sicherheitsabteilung enorm helfen, eine Richtlinie für den akzeptablen Einsatz von DoT und DoH im Unternehmen einzuführen.

Wissen um Web-Browser-Unterstützung

IT- und Sicherheitsteams sollten die Ankündigungen aller Browser-Hersteller zu Einsatz und Unterstützung von DoH verfolgen und verstehen. Zum Beispiel gibt es einen signifikanten Unterschied zwischen dem standardmäßigen DoH-Verhalten in Google Chrome und Mozilla Firefox: Während Chrome standardmäßig DNS-Resolver verwendet, die im Betriebssystem konfiguriert sind, verlässt sich Firefox auf den DoH-Dienst von Cloudflare. Dieses Vorgehen kann sich aber jederzeit ändern, wenn Browser-Hersteller Aktualisierungen bereitstellen. Ähnliches gilt für mögliche Konfigurationsoptionen zu den neuen Protokollen. So wurde angekündigt, dass Chrome während der Einführungs- und Testphase des Protokolls im Browser DoH zunächst deaktivieren soll, sofern dieser erkennt, dass das betroffene Gerät im gemanagten Betrieb läuft, Teil eines Active-Directories (AD) ist oder eine Enterprise-Policy angewendet wird [5]. Firefox nutzt hingegen eine sogenannte „CanaryDomain“: Der Browser prüft, ob ein lokales Netzwerk DoH unterstützt haben möchte, indem er eine DNS-Abfrage für die Domäne use-application-dns.net an einen lokalen DNS-Resolver sendet. Die Aktivierung dieser Domäne auf dem lokalen Resolver signalisiert dem Browser, dass DoH nicht erwünscht ist – folglich sollte Firefox DoH dann deaktivieren, es sei denn, der Benutzer setzt dies explizit außer Kraft.

Einige Browser könnten zudem versuchen, DoT und DoH auf den im System konfigurierten DNS-Resolvern zu verwenden, bevor sie auf Cloud-DNS-Anbieter zurückgreifen. Man sollte daher durchaus erwägen, beide Protokolle auf internen DNS-Resolvern zu aktivieren: Damit wird signalisiert, dass ein lokaler DNS-Resolver verwendet werden sollte, und die Wahrscheinlichkeit verringert, einen externen DNS-Resolver heranzuziehen.

Netzwerküberwachung

Überwachen Sie den Verkehr von Ihrem Netzwerk zu bekannten DoH- und DoT-Hosts: Während es für DoT dank der dedizierten Portnummer relativ einfach sein kann, müssten bei DoH öffentlich verfügbare Informationen oder Feeds verwendet werden, um eine Liste aktiver DoH-Server zu pflegen. Aus Netzwerksicht auftretende Anomalien im DoT und DoH, ein plötzliches Ansteigen des Datenverkehrs zu bestimmten DoT/DoH-Servern oder langlebige Sitzungen zu diesen Servern können aufschlussreiche Ergebnisse liefern.

Eine weitere Anomalie, die es zu beachten gilt, ist ein DNS-Austausch, dem kein weiterer Verkehr folgt. Der normale, legitime Paketfluss sollte wie folgt aussehen: Host A initiiert eine HTTPS- oder DoT-Sitzung zum Cloud-DNS-Dienst, um einen Hostnamen in eine IP-Adresse (Host B) aufzulösen. Wenn die DNS-Auflösung erfolgreich ist, beginnt Host A direkt mit Host B zu sprechen. Sollte der erste Schritt ohne den nachfolgenden zweiten erfolgen, kann dies ein Hinweis auf erfolglose DNS-Anfragen (Host A hat eine SERVFAIL- oder NXDOMAIN-Antwort vom DNS-Server statt der IP-Adresse von Host B erhalten) sein – oder eben auf eine nicht standardmäßige Verwendung von DoH/DoT, einschließlich möglicher Missbrauchsfälle.

Fazit

Es wird deutlich, dass die DNS-Verschlüsselung ein weiteres Problem für IT- und Sicherheitsexperten in Unternehmen darstellt. Aber was bedeutet die DNS-Verschlüsselung für die globale Internet-Architektur und die gesamte Branche? Wie zu Beginn erwähnt, gibt es derzeit noch eine Debatte über die Richtung, welche die Branche einschlagen sollte. Es genügt wohl zu sagen, dass sich sogar die Behörden der Nationalstaaten an dieser Debatte beteiligen, was für das Niveau und die Bedeutung der Diskussion spricht.

Für Security-Analysten und Netzbürger sind dies interessante Zeiten, da wir sehen können, wie sich die Internet-Architektur an eine grundlegende Veränderung des DNS, eines Schlüsselelements der Steuerungsebene, anpasst. Wenn sich DoH durchsetzt und Web-Firmen sich zu den wichtigsten DNS-Anbietern entwickeln, werden wir wohl eine weitere Runde der Zentralisierung erleben – „eine weitere“, weil die Zentralisierung der Inhalte und die Dominanz der Content-Delivery-Networks (CDNs) bereits im letzten Jahrzehnt stattgefunden hat. In dieser neuen Welt würde HTTPS de facto zu einem universellen Transportprotokoll werden, was Ideen wie das OSI-Schichtenmodell weniger relevant machen würde.

Da sowohl DoT als auch DoH mehr und mehr an Boden gewinnen, machen sich zeitgleich Netzwerkund Sicherheitsexperten immer mehr Sorgen über die Auswirkungen, die eine mangelnde DNS-Sichtbarkeit auf ihre täglichen Aktivitäten haben wird. Hier gilt es auf dem Laufenden zu bleiben und gegebenenfalls sorgsam gegenzusteuern.

Kirill Kasavchenko ist Principal Security Technologist im CTOOffice von Netscout.

Literatur

[1] Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, P. Hoffman, Specification for DNS over Transport Layer Security (TLS), RFC 7858, Mai 2016, https://tools.ietf.org/html/rfc7858
[2] P. Hoffman, P. McManus, DNS Queries over HTTPS (DoH), RFC 8484, Oktober 2018, https://tools.ietf.org/html/rfc8484
[3] P. Mockapetris, Domain Names – Concepts and Facilities, RFC 1034, November 1987, https://tools.ietf.org/html/rfc1034
[4] P. Mockapetris, Domain Names – Implementation and Specification, RFC 1035, November 1987, https://tools.ietf.org/html/rfc1035
[5] Kenji Baheux, DNS over HTTPS same-provider autoupgrade in Chrome: heads-up about our post-experiment plan, Forum-Post, Dezember 2019, https://groups.google.com/a/chromium.org/d/msg/net-dev/lIm9esAFjQ0/vJ93oMbAAgAJ