Null Vertrauen bei Microsoft: Windows erhält Zero-Trust-DNS-Client

Inhaltsverzeichnis

Gerade durch die Nutzung von Hyperscalern und deren Public-Cloud-Services sind IP-basierende Regelwerke nur noch bedingt sinnvoll. Gleichzeitig befinden sich DNS-Resolver im System und in Applikationen verteilt und kommunizieren vielfach auch noch unverschlüsselt. Microsoft möchte mit Zero Trust DNS (ZTDNS) nun mit wenigen Ausnahmen jegliche Kommunikation ohne DNS unterbinden und gemäß Antwort dynamische Freigaben erstellen. Dies soll ein Aufbrechen der Verschlüsselung und SNI Inspection unnötig machen.

Hintergrund

Microsoft kombiniert mit ZTDNS den Windows System-DNS-Client mit der Windows Filtering Platform (WFP), um DNS-basierende Regelwerke implementieren zu können. Dazu erhält der Client eine Liste von speziellen DNS-over-HTTPS oder DNS-over-TLS geschützten DNS-Servern, die ausschließlich zulässige Domänennamen auflösen sollen, sowie Listen mit Serverzertifikaten, um diese validieren zu können. Zusätzlich können Administratoren dem Client gemäß Angaben von Microsoft in der Provisionierung eine IP-Whitelist für Ziele ohne Namensauflösung mitgeben. Optional kann er noch ein Clientauthentifizierungszertifikat zur Authentifizierung gegenüber dem DNS-Server erhalten.

Im nächsten Schritt blockiert Windows den gesamten ausgehenden IPv4- und IPv6-Verkehr, mit Ausnahme von DHCPv4, DHCPv6, NDP-Verkehr für Netzwerkinformationen und den geschützten DNS-Verkehr. Jedoch verwendet der Client nur die geschützten DNS-Server und ignoriert entsprechende alternative DHCP-Optionen zur Namensauflösung.

Möchte ein Client nun auf eine Serverressource zugreifen, befragt er zunächst den geschützten DNS-Server. Falls die dort hinterlegte Richtlinie den Zielserver erlaubt, erhält der Client eine positive DNS-Antwort. Durch die Kopplung mit der Windows Filtering Platform wird auf dem Client infolge der Antwort die Kommunikation zum Zielserver erlaubt.

Erhält der Client eine negative DNS-Antwort oder versucht Kommunikationsbeziehungen zu Serverdiensten ohne DNS-Auflösung oder DNS-Servern aus Applikationen und nicht in der IP-Whitelist enthaltenen Adressen aufzubauen, werden diese Anfragen entsprechend bereits lokal ausgehend geblockt. Administratoren können DNS-basierte Filter definieren. Zur Identifikation des anfragenden Clients dienen entsprechend Clientauthentifizierungszertifikate.

Komplexität gesteigert

Infolge der standardmäßigen Blockade können einige Dienste systemimmanent nicht korrekt funktionieren. Drucker müssten entweder über IP-Whitelisting erlaubt oder über Microsofts Universal Print mit Namensauflösung angesprochen werden. Windows Updates können nicht mehr lokal Peer-to-Peer verteilt werden, da diese Kommunikation nicht per DNS freigegeben wurde. Hier gilt es, die Updates nur noch über WSUS oder den neuen Microsoft Connected Cache for Enterprise and Education zu verteilen.

Kollaborationsplattformen, wie MS Teams, Webex und Zoom, stellen ebenfalls Herausforderungen dar: Diese ermitteln über das STUN- und TURN-Protokoll die Zieladressen der Audio- und Videostreams und nicht über DNS. Gleiches gilt für klassische IP-Telefonie, bei der die Adressinformationen im Session Description Protocol (SDP) innerhalb der Signalisierung ausgetauscht werden. Bei beiden Beispielen braucht es IP-Whitelistings.

Problematisch sind drahtlose Streamings an Bildschirme, die nach Angaben von Microsoft mit dieser Technik schlicht nicht funktionieren werden. Eine WLAN-Infrastruktur mit Captive Portals, wie im Hotel oder der Bahn, stellen ein weiteres Problemfeld dar, da diese meist den DNS-Datenverkehr abfangen und Ziele umleiten. Dies bezeichnet Microsoft als "Unsupported Scenario". Auch DNS-Hinterlegungen im Browser oder in anderen Applikationen müssten deaktiviert werden.

VPN-Clients, die per gesicherter DNS-Auflösung ihren Tunnelendpunkt finden oder in der IP-Whitelist enthalten sind, können innerhalb des Tunnels nach Angaben von Microsoft ungehindert kommunizieren. Gleiches gilt für Hyper-V-VMs und das WSL.

Fazit

Der Ansatz erscheint zunächst spannend und gruselig zugleich. Gerade für WLAN-Umgebungen mit einem Captive Portal wird Microsoft noch eine Lösung erarbeiten müssen, um die Akzeptanz von ZTDNS sicherzustellen. Ansonsten könnte es in einem Placebo-Effekt münden, indem alle oder ein Großteil der IP-Adressen in der Whitelist landen. Gleichzeitig macht es die TLS-Inspection nicht unnötig, da nur durch DNS-basierende Filter noch keine Nutzdaten überprüft werden können. Lediglich der SNI-basierende Filter fällt weg. Somit stellt sich die Frage, ob ZTDNS eher ein Over-Engineering darstellt und die Kunden weg von DNS-Produkten von Drittanbietern treiben soll, um Microsoft die "spannenden DNS-Informationen" nicht vorenthalten zu können. Zudem können Admins laut Microsoft auch nur komplette Server als Ziel blockieren oder erlauben. Die jeweiligen Dienste dahinter lassen sich auf diese Weise nicht reglementieren.

Alle Details zu ZTDNS finden sich im Blogbeitrag der Tech Community.

(fo)