DNS Over HTTPS (DoH): Auswirkungen auf die Inhaltsfilterung im öffentlichen WiFi

Willkommen beim Purple Technical Briefing. Ich bin Ihr Gastgeber 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 Content-Filterrichtlinien in Tausenden von öffentlichen WiFi-Bereitstellungen untergräbt - DNS over HTTPS, oder DoH. Wenn Sie Gast-WiFi in einem Hotel, einem Einzelhandelsgeschäft, einem Stadion oder einer Einrichtung des öffentlichen Sektors betreiben und DoH in Ihrer Netzwerkarchitektur nicht explizit berücksichtigt haben, besteht eine recht große Wahrscheinlichkeit, dass Ihre Filterrichtlinie eine erhebliche Lücke aufweist. Lassen Sie uns genau analysieren, was diese Lücke ist, 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 Bypass-Mechanismus zu verstehen, muss man wissen, 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 - es fragt im Wesentlichen 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 prüft die Domain anhand Ihrer Filterrichtlinie. Wenn sich die Domain auf einer Sperrliste befindet - Malware, jugendgefährdende Inhalte, Glücksspiel oder was auch immer Ihre Richtlinie zur akzeptablen Nutzung vorschreibt -, verweigert der Resolver die Rückgabe der IP-Adresse, und die Verbindung kommt erst gar nicht zustande. Dies ist die Grundlage jeder DNS-basierten Content-Filterung. Sie ist kostengünstig, beeinträchtigt den Durchsatz nicht und ist seit fast einem Jahrzehnt der Standardansatz für Betreiber von Veranstaltungsorten. DNS over HTTPS bricht dieses Modell auf. Und das funktioniert so. DoH verpackt DNS-Abfragen in Standard-HTTPS-Traffic auf Port 443. Aus der Perspektive Ihres Netzwerks sieht dies 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 Online-Banking-App zugreift. Die Abfrage geht direkt an einen externen DoH-Resolver - Google's 8.8.8.8, Cloudflare's 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. Dies ist jedoch kein absichtlicher Angriff Ihrer Gäste. In den meisten Fällen geschieht dies völlig passiv. In Firefox ist DoH seit 2020 standardmäßig aktiviert. Chrome aktualisiert DNS-Abfragen automatisch auf DoH, 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 für Verbraucher, die genau das tun, was ihre Hersteller beabsichtigt haben. Ihre Gäste versuchen nicht, Ihre Filterung zu umgehen. Ihre Geräte tun dies einfach ganz 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. Der erste Typ 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 hierfür das klassische Beispiel. Wenn Firefox installiert und DoH aktiviert ist, ignoriert der Browser den DNS-Resolver des Systems vollständig und sendet alle DNS-Anfragen an seinen konfigurierten DoH-Anbieter, was standardmäßig Cloudflare ist. Ihr per DHCP zugewiesener DNS-Server ist dabei 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 - also der von Ihrem DHCP-Server zugewiesene - über einen entsprechenden DoH-Endpunkt verfügt. 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 als DNS-Server für Ihre Gäste zuweisen, nutzt 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 Risikominderungsstrategie, auf die wir gleich noch zu sprechen kommen. Es gibt noch einen dritten Vektor, der erwähnenswert ist: DNS over TLS oder DoT. Dies läuft über Port 853 und verschlüsselt DNS-Anfragen mittels TLS, anstatt sie in HTTPS zu verpacken. Es ist einfacher zu blockieren als DoH, da es einen dedizierten Port nutzt, ist jedoch auf Android-Geräten mit aktiviertem privaten DNS immer häufiger anzutreffen. Ihre Risikominderungsstrategie muss beide Protokolle berücksichtigen. Sprechen wir nun darüber, warum dies ein Compliance- und Betriebsrisiko darstellt und nicht nur eine technische Kuriosität. Unter der GDPR gilt: Wenn Ihre Richtlinie zur akzeptablen Nutzung besagt, dass Sie bestimmte Kategorien von Inhalten filtern, Ihre technischen Kontrollen diese Richtlinie jedoch nicht tatsächlich durchsetzen, klafft eine Lücke zwischen Ihren erklärten Verpflichtungen zum Datenschutz und zur Content-Governance und Ihrer tatsächlichen technischen Implementierung. Das ist ein Problem für die Verteidigungsfähigkeit, sollten Sie jemals mit einer behördlichen Untersuchung oder einem Vorfall konfrontiert werden. Unter dem Online Safety Act im Vereinigten Königreich haben Betreiber von Veranstaltungsorten, die einen öffentlichen Internetzugang bereitstellen, die Pflicht, Nutzer - insbesondere Minderjährige - vor schädlichen Inhalten zu schützen. Wenn DoH Ihre Inhaltsfilterung stillschweigend umgeht, erfüllen Sie diese Verpflichtungen möglicherweise nicht. Für Standorte, die in den Anwendungsbereich von PCI-DSS fallen - insbesondere solche, bei denen Zahlungskartendaten über Netzwerke fließen, die an das WiFi für Gäste angrenzen - verlangt die PCI-DSS-Version 4.0, dass Sie den DNS-Verkehr als Teil Ihrer Netzwerksicherheitskontrollen überwachen und steuern. Unüberwachter DoH-Verkehr stellt eine Lücke in diesem Kontrollrahmen dar. Und aus rein sicherheitstechnischer Sicht wurde DoH bereits aktiv von Malware ausgenutzt. Bedrohungsakteure haben DoH als Command-and-Control-Kanal genutzt, da es im normalen HTTPS-Verkehr untergeht. Die GodLua-Backdoor nutzte DoH für die Command-and-Control-Kommunikation. Die PsiXBot-Malware nutzte den DoH-Dienst von Google. Wenn sich Ihre Sicherheitsüberwachung auf die Sichtbarkeit von DNS-Einträgen verlässt, um schädliche Aktivitäten zu erkennen, sind DoH-Blindspots eine reale Bedrohung. Abschnitt drei - Implementierungsempfehlungen. Kommen wir nun zur Praxis. Es gibt drei primäre Schadensbegrenzungsstrategien, und bei den meisten Bereitstellungen an Veranstaltungsorten werden Sie alle drei in Kombination implementieren wollen. Strategie eins: Blockieren bekannter DoH-Resolver-Endpunkte an der Firewall. Dies ist Ihre erste Verteidigungslinie und die am schnellsten einsatzbereite Option. Führen Sie eine Blockierliste bekannter DoH-Resolver-IP-Adressen und -Domänen - Google, Cloudflare, Quad9, NextDNS, AdGuard und andere - und verweigern Sie ausgehenden HTTPS-Traffic an diese Endpunkte von Ihrem Gäste-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 von Carnegie Mellon gezeigt haben, der meiste DoH-Traffic an eine kleine Anzahl bekannter Resolver geht. Nutzer, die genug über DNS wissen, um einen benutzerdefinierten DoH-Resolver zu konfigurieren, sind eine sehr kleine Minderheit. Die Einschränkung dieses Ansatzes besteht darin, dass es sich um eine Blockierliste handelt und Blockierlisten gepflegt werden müssen. Regelmäßig tauchen neue DoH-Resolver auf. Aber in Kombination mit den anderen Strategien bietet dies eine solide Abdeckung. Strategie zwei: TLS-Inspektion auf Ihrer Next-Generation-Firewall. Next-Generation-Firewalls von Anbietern wie Palo Alto Networks, Fortinet, Check Point und Cisco Firepower unterstützen 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, inspiziert die Nutzdaten und verschlüsselt ihn vor der Weiterleitung neu. Dadurch kann die Firewall DoH-Traffic selbst dann identifizieren, wenn er an einen unbekannten Resolver geht. Die App-ID von Palo Alto kann DoH-Traffic gezielt identifizieren und Richtlinien darauf anwenden. Die FortiGate von Fortinet verfügt über ähnliche Funktionen. Der entscheidende Konfigurationsschritt besteht darin, sicherzustellen, dass der Traffic Ihres Gäste-VLANs über die Inspektionsrichtlinie geleitet wird. Der betriebliche Aspekt ist hierbei das Vertrauen in Zertifikate. 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 MDM. Auf unverwalteten Gastgeräten ist es komplexer. Der praktische Ansatz für Gäste-WiFi besteht darin, den Akzeptanzprozess im Captive Portal zu nutzen, um die Nutzer 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-Interzeption als primäre Kontrollen zu verlassen, mit TLS-Inspektion als sekundärer Ebene für Umgebungen mit höherem Risiko. Strategie drei: DNS-Interzeption 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 von Port 853 ausgehend aus dem Gäste-VLAN, um zu verhindern, dass DNS over TLS Ihre Sicherheitskontrollen umgeht. Für verwaltete Endpunkte - Firmengerä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 gesetzt 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, kann jedoch nicht auf unverwaltete Gäste-Geräte angewendet werden. Abschnitt vier - Fallstricke bei der Implementierung. Einige Dinge, die in der Praxis häufig schiefgehen. Der häufigste Fehlermodus ist die 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 hinterlegten DNS-Einstellungen - 8.8.8.8, 1.1.1.1 - umgehen den Filter dann vollständig. Stellen Sie immer sicher, dass diese Regel aktiv ist, und testen Sie sie, indem Sie ein Testgerät mit einem fest hinterlegten DNS-Server konfigurieren und bestätigen, dass gefilterte Domains weiterhin blockiert werden. Der zweite häufige Fehler ist die Nichtberücksichtigung von IPv6. 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 die 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 eine DoH-Umgehungserkennung als verwaltete Funktion. Viertens: Übermäßige Abhängigkeit von einer einzigen Schutzebene. Die DoH-Eindämmung ist ein Defense-in-Depth-Problem. Keine einzelne Kontrolle ist ausreichend. Das Blockieren bekannter Resolver deckt die meisten Fälle ab. Die TLS-Inspektion deckt Grenzfälle ab. Die DNS-Abfangung bietet ein Sicherheitsnetz. Kombinieren Sie alle drei Ebenen. Abschnitt fünf - Schnelle Fragen und Antworten. Beeinträchtigt die DoH-Eindämmung legitime Privatsphäre-Tools? Potenziell ja. Wenn ein Benutzer eine legitime, auf Privatsphäre ausgerichtete Browser-Konfiguration verwendet, zwingt Ihr Blockieren von DoH diesen dazu, Ihren DNS-Resolver zu nutzen. Ihre Richtlinien zur akzeptablen Nutzung sollten 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 Abfragevolumen oder Abfragemuster beinhalten, die auf Tunneling hindeuten. Wie sieht es mit mobilen Apps aus, 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-Inspection nur schwer zu kontrollieren. Ihre beste Abhilfemaßnahme ist die Kombination aus dem Blockieren bekannter Resolver und TLS-Inspection. Ist WPA3 hier relevant? WPA3 verbessert die Verschlüsselung über die Luft und bietet 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 angemessene Behandlung dieses Themas schließen. Die Kosten für die Nichtbeachtung von DoH sind asymmetrisch. Ein einziger Vorfall - ein Gast, der über Ihr Netzwerk auf illegale Inhalte zugreift, ein Malware-Callback, der unentdeckt bleibt, weil Ihre DNS-Überwachung einen blinden Fleck hatte, eine behördliche Anfrage zur Einhaltung Ihrer Inhaltsfilterung - kann erheblich mehr kosten als die Investition in eine angemessene Risikominderung. Für eine Hotelgruppe mit 20 Standorten erfordert die Implementierung von DoH-Schutzmaßnahmen in der Regel einen einmaligen Konfigurationsaufwand von zwei bis vier Stunden pro Standort für die Firewall-Regeln und die DNS-Interception-Konfiguration, plus einen laufenden Betriebsaufwand für die Pflege von Resolver-Blocklisten - 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 DoH-Schutzmaßnahmen umfassen, verringert das Risiko von Feststellungen bei einem PCI-DSS-Audit und die damit verbundenen Behebungskosten. Für Betreiber von öffentlichen Veranstaltungsorten und solche, die unter den Online Safety Act fallen, ist eine dokumentierte DoH-Schutzmaßnahme Teil Ihrer Nachweisbasis, dass Sie angemessene technische Schritte unternommen haben, um Ihre Richtlinie zur Inhaltsfilterung durchzusetzen. Unterm Strich: 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-Bypass-Vektoren überprüft haben, sollte diese Prüfung auf Ihrer kurzfristigen Roadmap stehen. Zusammenfassend die wichtigsten Erkenntnisse des heutigen Briefings. Erstens: DoH verschlüsselt DNS-Abfragen innerhalb von HTTPS auf Port 443, was sie für die herkömmliche DNS-Filterung auf Port 53 unsichtbar macht. Dies geschieht standardmäßig bei gängigen Browsern und Betriebssystemen. Zweitens: Die dreistufige Minderungsstrategie - Blockieren bekannter DoH-Resolver-IPs, Implementierung von TLS-Inspection auf Ihrer Next-Generation-Firewall und Erzwingung der Interzeption von Port 53 - bietet eine umfassende Defense-in-Depth-Abdeckung sowohl für verwaltete als auch für nicht verwaltete Gastgeräte. Drittens: Dies ist ein Compliance-Thema, nicht nur ein technisches. Die GDPR, der Online Safety Act und PCI-DSS haben alle Auswirkungen auf Standorte, an denen DoH Richtlinien zur Inhaltsfilterung stillschweigend umgeht. Viertens: Der häufigste Fehler bei der Implementierung ist eine unvollständige Interzeption von Port 53. Testen Sie es. Verifizieren Sie es. Gehen Sie nicht davon aus, dass es funktioniert. Fünftens: Managed DNS-Filterdienste - Cloudflare Gateway, Cisco Umbrella und ähnliche - enthalten zunehmend eine DoH-Bypass-Erkennung als verwaltete Funktion, was den betrieblichen Aufwand für die Pflege statischer Blocklisten verringert. Das war's für das heutige Purple Technical Briefing. Wenn Sie Ihre aktuelle DNS-Filterarchitektur prüfen oder eine DoH-Mitigation in Ihrem gesamten Standort-Portfolio implementieren möchten, bietet die Purple Plattform die Network Intelligence und die Guest WiFi Management-Ebene, um dieses Deployment zu unterstützen. Vielen Dank fürs Zuhören und bis zum nächsten Mal.