DNS Over HTTPS (DoH): Auswirkungen auf die Filterung in öffentlichen WiFi-Netzwerken

Willkommen beim Purple Technical Briefing. Ich bin Ihr Moderator für die heutige Sitzung, und wir werden uns in den nächsten zehn Minuten mit einem Thema befassen, das derzeit still und leise die Richtlinien zur Inhaltsfilterung in Tausenden von öffentlichen WiFi-Bereitstellungen untergräbt – DNS over HTTPS, kurz DoH. Wenn Sie Gast-WiFi in einem Hotel, einer Einzelhandelsimmobilie, einem Stadion oder einer Einrichtung des öffentlichen Sektors betreiben und DoH in Ihrer Netzwerkarchitektur nicht gezielt berücksichtigt haben, besteht eine hohe Wahrscheinlichkeit, dass Ihre Filterrichtlinie eine erhebliche Lücke aufweist. Lassen Sie uns genau analysieren, worin diese Lücke besteht, warum sie wichtig ist und was Sie dagegen tun können. Abschnitt eins – Kontext und Problemstellung. Beginnen wir mit einer kurzen Zusammenfassung der Funktionsweise der herkömmlichen DNS-Filterung, denn um den Umgehungsmechanismus zu verstehen, muss man verstehen, was umgangen wird. Wenn sich ein Gastgerät mit Ihrem WiFi verbindet und versucht, eine Website zu besuchen, sendet es als Erstes eine DNS-Abfrage – im Grunde die Frage nach der IP-Adresse für diese Domain. Diese Abfrage läuft über UDP oder TCP auf Port 53. Ihre Netzwerkinfrastruktur fängt diese Abfrage ab, leitet sie an den von Ihnen gewählten DNS-Resolver weiter, und dieser Resolver gleicht die Domain mit Ihrer Filterrichtlinie ab. Wenn sich die Domain auf einer Sperrliste befindet – Malware, jugendgefährdende Inhalte, Glücksspiel, was auch immer Ihre Richtlinie für die zulässige Nutzung vorsieht –, weigert sich der Resolver, die IP-Adresse zurückzugeben, und die Verbindung kommt nie zustande. Dies ist die Grundlage jeder DNS-basierten Inhaltsfilterung. Sie ist kostengünstig, beeinträchtigt den Durchsatz nicht und ist seit fast einem Jahrzehnt der Standardansatz für Standortbetreiber. DNS over HTTPS bricht dieses Modell auf. Und das funktioniert so. DoH verpackt DNS-Abfragen in standardmäßigen HTTPS-Traffic auf Port 443. Aus Sicht Ihres Netzwerks sieht dies absolut identisch mit jedem anderen verschlüsselten Web-Traffic aus. Es gibt keine Möglichkeit, eine DoH-Abfrage von einem Benutzer zu unterscheiden, der eine Webseite lädt, ein Video streamt oder auf eine Banking-App zugreift. Die Abfrage goes direkt an einen externen DoH-Resolver – Googles 8.8.8.8, Cloudflares 1.1.1.1, oder zahlreiche andere – über einen verschlüsselten Kanal, den Ihr DNS-Filter nicht überprüfen kann. Das Ergebnis? Ihre sorgfältig konfigurierte DNS-Filterrichtlinie wird vollständig umgangen. Das Gerät löst die Domain direkt auf, ohne dass Ihr Resolver die Abfrage jemals sieht. Das ist kein bewusster Angriff Ihrer Gäste. In den meisten Fällen geschieht dies völlig passiv. In Firefox ist DoH seit 2020 standardmäßig aktiviert. Chrome stuft DNS-Abfragen automatisch auf DoH hoch, wenn der konfigurierte Resolver dies unterstützt. Android 9 und höher unterstützt standardmäßig Private DNS mit DNS over TLS. iOS unterstützt DoH-Konfigurationsprofile seit iOS 14. Dies sind gängige Endgeräte, die genau das tun, was ihre Hersteller beabsichtigt haben. Ihre Gäste versuchen nicht, Ihre Filterung zu umgehen. Ihre Geräte tun es einfach automatisch. Abschnitt zwei – der technische Deep-Dive. Kommen wir zur Funktionsweise. Es gibt zwei primäre DoH-Implementierungsmuster, auf die Sie in der Praxis stoßen werden. Das erste ist DoH auf Anwendungsebene, bei dem die Anwendung – typischerweise ein Browser – ihre eigene DoH-Konfiguration unabhängig von den DNS-Einstellungen des Betriebssystems verwaltet. Firefox ist das klassische Beispiel. Wenn Firefox installiert und DoH aktiviert ist, ignoriert er den System-DNS-Resolver vollständig und sendet alle seine DNS-Abfragen an seinen konfigurierten DoH-Anbieter, standardmäßig Cloudflare. Ihr per DHCP zugewiesener DNS-Server ist irrelevant. Ihre Abfangregeln für Port 53 sind irrelevant. Firefox führt eine völlig separate DNS-Kommunikation über Port 443, die Sie nicht sehen können. Das zweite Muster ist DoH auf Betriebssystemebene, bei dem das Betriebssystem selbst das Upgrade übernimmt. Chrome sowie Windows 10 und 11 verfolgen diesen Ansatz. Sie prüfen, ob der konfigurierte DNS-Resolver des Systems – der von Ihrem DHCP-Server zugewiesene – einen entsprechenden DoH-Endpunkt besitzt. Wenn dies der Fall ist, führen sie automatisch ein Upgrade auf DoH durch. Dies wird als opportunistisches DoH bezeichnet. Wenn Sie 8.8.8.8 as DNS-Server für Ihre Gäste zuweisen, verwendet Chrome automatisch den DoH-Endpunkt von Google. Wenn Sie 1.1.1.1 zuweisen, wird der DoH-Endpunkt von Cloudflare verwendet. Dieser Unterschied ist wichtig für Ihre Eindämmungsstrategie, auf die wir gleich noch eingehen werden. Es gibt noch einen dritten Vektor, der erwähnenswert ist: DNS over TLS, oder DoT. Dieses läuft auf Port 853 und verschlüsselt DNS-Abfragen mittels TLS, anstatt sie in HTTPS zu verpacken. Es ist einfacher zu blockieren als DoH, da es einen dedizierten Port verwendet, ist jedoch auf Android-Geräten mit aktiviertem Private DNS immer häufiger anzutreffen. Ihre Eindämmungsstrategie muss beide abdecken. Sprechen wir nun darüber, warum dies ein Compliance- und Betriebsrisiko darstellt und nicht nur eine technische Kuriosität ist. Wenn Ihre Richtlinie zur zulässigen Nutzung unter der GDPR besagt, dass Sie bestimmte Inhaltskategorien filtern, Ihre technischen Kontrollen diese Richtlinie jedoch nicht tatsächlich durchsetzen, haben Sie eine Lücke zwischen Ihren erklärten Verpflichtungen zum Datenschutz und zur Inhaltskontrolle und Ihrer tatsächlichen technischen Implementierung. Das ist ein Problem für die rechtliche Absicherung, falls Sie jemals mit einer behördlichen Untersuchung oder einem Vorfall konfrontiert werden. Nach dem Online Safety Act des Vereinigten Königreichs haben Standortbetreiber, die einen öffentlichen Internetzugang bereitstellen, Verpflichtungen zum Schutz der Nutzer – insbesondere von Minderjährigen – vor schädlichen Inhalten. Wenn DoH Ihre Inhaltsfilterung stillschweigend umgeht, erfüllen Sie diese Verpflichtungen möglicherweise nicht. Für Standorte, die in den Geltungsbereich von PCI DSS fallen – insbesondere solche, bei denen Zahlungskartendaten über Netzwerke fließen, die an das Gast-WiFi angrenzen –, verlangt PCI DSS Version 4.0, dass Sie den DNS-Traffic als Teil Ihrer Netzwerksicherheitskontrollen überwachen und steuern. Unüberwachter DoH-Traffic stellt eine Lücke in diesem Kontrollrahmen dar. Und aus reiner Sicherheitssicht wurde DoH bereits aktiv von Malware ausgenutzt. Bedrohungsakteure haben DoH als Command-and-Control-Kanal genutzt, da es mit normalem HTTPS-Traffic verschmilzt. Die GodLua-Backdoor nutzte DoH für die Command-and-Control-Kommunikation. Die PsiXBot-Malware nutzte den DoH-Dienst von Google. Wenn Ihre Sicherheitsüberwachung auf DNS-Transparenz angewiesen ist, um böswillige Aktivitäten zu erkennen, sind DoH-Blindspots eine echte Bedrohung. Abschnitt drei – Empfehlungen zur Implementierung. Gut, werden wir praktisch. Es gibt drei primäre Eindämmungsstrategien, und bei den meisten Standort-Bereitstellungen sollten Sie alle drei in Kombination implementieren. Strategie eins: Bekannte DoH-Resolver-Endpunkte an der Firewall blockieren. Dies ist Ihre erste Verteidigungslinie und die am schnellsten umsetzbare Option. Führen Sie eine Sperrliste bekannter DoH-Resolver-IP-Adressen und -Domains – Google, Cloudflare, Quad9, NextDNS, AdGuard und andere – und blockieren Sie ausgehenden HTTPS-Traffic zu diesen Endpunkten aus Ihrem Gast-VLAN. Die IETF und verschiedene Sicherheitsanbieter veröffentlichen und pflegen diese Listen. Das curl-Projekt auf GitHub führt eine umfassende Liste bekannter DoH-Resolver, die ein guter Ausgangspunkt ist. Dieser Ansatz deckt den Großteil des DoH-Traffics ab, da, wie Untersuchungen des Software Engineering Institute der Carnegie Mellon University gezeigt haben, der meiste DoH-Traffic an eine kleine Anzahl bekannter Resolver geht. Benutzer, die sich gut genug mit DNS auskennen, um einen benutzerdefinierten DoH-Resolver zu konfigurieren, sind eine verschwindend geringe Minderheit. Die Einschränkung dieses Ansatzes besteht darin, dass es sich um eine Sperrliste handelt, und Sperrlisten müssen gepflegt werden. Neue DoH-Resolver tauchen regelmäßig auf. Aber in Kombination mit den anderen Strategien bietet dies eine solide Abdeckung. Strategie zwe: TLS-Inspektion auf Ihrer Next-Generation Firewall. Next-Generation Firewalls von Anbietern wie Palo Alto Networks, Fortinet, Check Point und Cisco Firepower unterstützen die TLS-Inspektion – auch SSL-Inspektion oder Deep Packet Inspection genannt. Wenn diese aktiviert ist, fungiert die Firewall als Man-in-the-middle für den HTTPS-Traffic, entschlüsselt ihn, prüft die Nutzdaten und verschlüsselt ihn vor der Weiterleitung erneut. Dadurch kann die Firewall DoH-Traffic selbst dann identifizieren, wenn er an einen unbekannten Resolver gerichtet ist. Die App-ID von Palo Alto kann DoH-Traffic gezielt identifizieren und Richtlinien darauf anwenden. FortiGates von Fortinet verfügen über ähnliche Funktionen. Der entscheidende Konfigurationsschritt besteht darin, sicherzustellen, dass der Traffic Ihres Gast-VLANs über die Inspektionsrichtlinie geleitet wird. Der betriebliche Aspekt hierbei ist das Zertifikatsvertrauen. Damit die TLS-Inspektion auf Gastgeräten funktioniert, müssen diese Geräte Ihrem Inspektionszertifikat vertrauen. Auf verwalteten Unternehmensgeräten ist dies unkompliziert – Sie verteilen das Zertifikat über ein MDM. Auf unverwalteten Gastgeräten ist es komplexer. Der praktische Ansatz für Gast-WiFi besteht darin, den Akzeptanzprozess des Captive Portal zu nutzen, um Benutzer darüber zu informieren, dass der Traffic zum Zwecke der Inhaltsfilterung inspiziert werden kann, und sich auf die Kombination aus DoH-Resolver-Blockierung und DNS-Abfangung als primäre Kontrollen zu verlassen, mit TLS-Inspektion als sekundärer Ebene für Umgebungen mit höherem Risiko. Strategie drei: DNS-Abfangung und -Umleitung erzwingen. Konfigurieren Sie Ihre Firewall oder Ihren Wireless-Controller so, dass der gesamte ausgehende DNS-Traffic auf UDP- und TCP-Port 53 abgefangen und an Ihren konformen DNS-Resolver umgeleitet wird. Dies verhindert DoH zwar nicht, stellt jedoch sicher, dass jeglicher DNS-Traffic, der auf Port 53 zurückfällt – weil DoH fehlgeschlagen ist oder nicht verfügbar war –, erfasst und gefiltert wird. Kombinieren Sie dies mit dem Blockieren des ausgehenden Ports 853 aus dem Gast-VLAN, um zu verhindern, dass DNS over TLS Ihre Kontrollen umgeht. Für verwalteten Endpunkte – Unternehmensgeräte, Mitarbeitergeräte – haben Sie eine zusätzliche Option: Gruppenrichtlinien- oder MDM-Konfigurationen, um DoH auf Browser- und Betriebssystemebene zu deaktivieren. In Firefox deaktiviert die Einstellung „network.trr.mode“ auf 5 DoH vollständig. In Chrome bewirkt das Flag „disable-features=DnsOverHttps“ dasselbe. Windows 10 und 11 verfügen über Gruppenrichtlinieneinstellungen zur Steuerung des DoH-Verhaltens. Dies ist die zuverlässigste Kontrolle für verwaltete Geräte, lässt sich jedoch nicht auf unverwaltete Gastgeräte anwenden. Abschnitt vier – Fallstricke bei der Implementierung. Einige Dinge, die in der Praxis häufig schiefgehen. Die häufigste Fehlerursache ist eine unvollständige Port-53-Abfangung. Teams konfigurieren ihren DNS-Filterdienst korrekt, vergessen aber, die Firewall-Regel hinzuzufügen, die den gesamten ausgehenden Port-53-Traffic umleitet. Geräte mit fest codierten DNS-Einstellungen – 8.8.8.8, 1.1.1.1 – umgehen den Filter vollständig. Überprüfen Sie immer, ob diese Regel aktiv ist, und testen Sie sie, indem Sie ein Testgerät mit einem fest codierten DNS-Server konfigurieren und bestätigen, dass gefilterte Domains weiterhin blockiert werden. Der zweite häufige Fehler besteht darin, IPv6 nicht zu berücksichtigen. DNS-Abfragen über IPv6 werden immer häufiger, und viele Firewall-Regeln sind nur für IPv4 geschrieben. Stellen Sie sicher, dass Ihre Port-53-Abfangung und Ihre DoH-Resolver-Sperrlisten sowohl IPv4- als auch IPv6-Adressen abdecken. Drittens: Veraltete DoH-Resolver-Sperrlisten. Wenn Sie eine statische Sperrliste von DoH-Resolver-IPs pflegen, wird diese veralten. Automatisieren Sie den Aktualisierungsprozess oder nutzen Sie einen DNS-Filterdienst, der diese Liste für Sie pflegt. Cloudflare Gateway, Cisco Umbrella, und ähnliche DNS-Dienste für Unternehmen enthalten die Erkennung von DoH-Umgehungen als verwaltete Funktion. Viertens: Zu großes Vertrauen in eine einzige Eindämmungsebene. Die DoH-Eindämmung ist eine Defense-in-Depth-Herausforderung. Keine einzelne Kontrolle ist ausreichend. Das Blockieren bekannter Resolver deckt die meisten Fälle ab. Die TLS-Inspektion deckt Grenzfälle ab. Das Abfangen von DNS bietet ein Sicherheitsnetz. Kombinieren Sie alle drei Ebenen. Abschnitt fünf – Fragen im Schnelldurchlauf. Beeinträchtigt die DoH-Eindämmung legitime Datenschutz-Tools? Potenziell ja. Wenn ein Benutzer eine legitime, auf Datenschutz ausgerichtete Browserkonfiguration verwendet, zwingt Ihre DoH-Blockierung ihn dazu, Ihren DNS-Resolver zu verwenden. Ihre Richtlinie zur zulässigen Nutzung sollte klarstellen, dass der DNS-Resolver des Standorts für Zwecke der Inhaltsfilterung verwendet wird. Dies ist gängige Praxis und rechtlich vertretbar. Kann DoH verwendet werden, um Daten aus meinem Netzwerk auszuschleusen? Ja, und das ist ein realer Bedrohungsvektor. DNS-Tunneling über DoH wurde in der Praxis bereits nachgewiesen. Die DoH-Erkennungsfunktion Ihrer Next-Generation Firewall sollte eine Anomalieerkennung für ungewöhnlich hohe Abfragevolumina oder Abfragemuster umfassen, die auf Tunneling hindeuten. Was ist mit mobilen Apps, die DoH nutzen? Dies ist der schwierigste Fall. Mobile Apps, die ihren eigenen DoH-Stack implementieren – anstatt die DNS-Einstellungen des Betriebssystems zu verwenden –, sind ohne TLS-Inspektion schwer zu kontrollieren. Ihre beste Eindämmung ist die Kombination aus der Blockierung bekannter Resolver und der TLS-Inspektion. Ist WPA3 hier relevant? WPA3 verbessert die Verschlüsselung über die Luft und bietet Perfect Forward Secrecy, was hervorragend für die Privatsphäre der Gäste ist. Aber WPA3 befasst sich nicht mit DoH – das ist ein Problem des Anwendungsprotokolls auf Layer 7, kein Problem der drahtlosen Sicherheit auf Layer 2. Es handelt sich um komplementäre Kontrollen, die unterschiedliche Bedrohungsvektoren abdecken. Abschnitt sechs – ROI und geschäftliche Auswirkungen. Lassen Sie mich mit dem Business Case für eine ordnungsgemäße Umsetzung schließen. Die Kosten für die Nichtberücksichtigung von DoH sind asymmetrisch. Ein einziger Vorfall – ein Gast, der über Ihr Netzwerk auf illegale Inhalte zugreift, ein Malware-Callback, der unbemerkt bleibt, weil Ihre DNS-Überwachung einen blinden Fleck hatte, oder eine behördliche Untersuchung bezüglich Ihrer Compliance bei der Inhaltsfilterung – kann erheblich mehr kosten als die Investition in eine ordnungsgemäße Eindämmung. Für eine Hotelgruppe mit 20 Standorten umfasst die Bereitstellung der DoH-Eindämmung in der Regel einen einmaligen Konfigurationsaufwand von zwei bis vier Stunden pro Standort für die Firewall-Regeln und die Konfiguration des DNS-Abfangs, plus einen laufenden betrieblichen Aufwand für die Pflege von Resolver-Sperrlisten – was weitgehend automatisiert ist, wenn Sie einen verwalteten DNS-Filterdienst nutzen. Die Gesamtinvestition ist im Verhältnis zur Risikominderung bescheiden. Für Einzelhandelsketten, die unter PCI DSS fallen, ist der Compliance-Vorteil direkt quantifizierbar. Der Nachweis, dass Ihre Netzwerksicherheitskontrollen eine DoH-Eindämmung umfassen, verringert das Risiko von Feststellungen bei einem PCI DSS-Audit und die damit verbundenen Behebungskosten. Für Standorte des öffentlichen Sektors und solche, die unter den Online Safety Act fallen, ist eine dokumentierte DoH-Eindämmung Teil Ihrer Nachweiskette, dass Sie angemessene technische Schritte unternommen haben, um Ihre Richtlinie zur Inhaltsfilterung durchzusetzen. Fazit: DoH ist kein Problem der Zukunft. Es ist ein Problem der Gegenwart. Firefox, Chrome, Android und iOS liefern bereits jetzt DoH-fähige Konfigurationen an die Geräte Ihrer Gäste aus. Wenn Sie Ihre DNS-Filterarchitektur in den letzten 12 Monaten nicht auf DoH-Umgehungsvektoren überprüft haben, sollte diese Überprüfung auf Ihrer kurzfristigen Roadmap stehen. Zusammenfassend die wichtigsten Erkenntnisse aus dem heutigen Briefing. Erstens: DoH verschlüsselt DNS-Abfragen in HTTPS auf Port 443, wodurch sie für die herkömmliche DNS-Filterung auf Port 53 unsichtbar werden. Dies geschieht standardmäßig bei gängigen Browsern und Betriebssystemen. Zweitens: Die dreistufige Eindämmungsstrategie – Blockieren bekannter DoH-Resolver-IPs, Implementieren einer TLS-Inspektion auf Ihrer Next-Generation Firewall und Erzwingen des Abfangens von Port 53 – bietet eine Defense-in-Depth-Abdeckung sowohl für verwaltete als auch für unverwaltete Gastgeräte. Drittens: Dies ist ein Compliance-Thema, nicht nur ein technisches. GDPR, der Online Safety Act und PCI DSS haben alle Auswirkungen auf Standorte, an denen DoH die Richtlinien zur Inhaltsfilterung stillschweigend umgeht. Viertens: Der häufigste Implementierungsfehler ist ein unvollständiges Abfangen von Port 53. Testen Sie es. Überprüfen Sie es. Gehen Sie nicht davon aus, dass es funktioniert. Fünftens: Verwaltete DNS-Filterdienste – Cloudflare Gateway, Cisco Umbrella und ähnliche – enthalten zunehmend die Erkennung von DoH-Umgehungen als verwaltete Funktion, was den betrieblichen Aufwand für die Pflege statischer Sperrlisten verringert. Das war's für das heutige Purple Technical Briefing. Wenn Sie Ihre aktuelle DNS-Filterarchitektur überprüfen oder eine DoH-Eindämmung an Ihren Standorten implementieren möchten, bietet die Purple-Plattform die Netzwerkinformationen und die Gast-WiFi-Verwaltungsebene, um diese Bereitstellung zu unterstützen. Vielen Dank fürs Zuhören, und wir sehen uns in der nächsten Sitzung.