ZTDNS - Zero Trust DNS Client

Dieses Buzzword ist im Mail 2024 durch eine Ankündigung von Microsoft auf dem Radar erschienen. Schon Früher gibt es ZTNA - Zero Trust Network Access als Keyword und im Grund haben beide Ansätze das gleiche Ziel: Ein Client soll nur auf vertrauenswürdige Dienste zugreifen können. Dafür gibt es aber unterschiedlich Wege:

Keine Wege zur dunklen Seite

Angreifer versuchen das Endgerät oder den Server von Firmen aus unterschiedlichsten Gründen zu übernehmen. Einige "Unwanted Programs" blenden Werbung ein, wollen zum Produktkauf überreden, rechnen Cryptocoins auf Koten des Anwenders oder missbrauchen das System als Spamschleuder. Das ist unschön aber gefährlicher ist Code, der Systeme verschlüsselt, Daten verändert oder löscht. Da stellt sich die Frage, wie solcher Code auf das Gerät kommt und mir fallen da drei Wege ein:

  • Per E-Mail
    E-Mail ist immer noch ein Einfallstor für Spam aber auch böse Links, die vom Anwender angeklickt werden oder direkt Anlagen, die weder vom Spamfilter blockiert wurden oder vom Mailclient ausgeführt werden. Hier kann ich nur darauf plädieren, dass Sie jegliche ausführbaren Anlagen konsequent unterbinden, sei es EXE, COM, BAT, VBS, etc. aber auch Makros in Dokumenten (DOCM, XLSM etc.) oder anderen Dateien. Dann bleiben überwiegend nur noch die Links die ein User anklicken muss.
  • System vom Internet erreichbar
    Der zweite Weg ist natürlich ein aus dem Internet erreichbares System, welches unsicher konfiguriert ist oder eine Lücke hat. Exchange Administratoren erinnern sich sicher noch an den Hafnium Exploit. Da gibt es auch keinen 100% Schutz aber wer seine System aktuell und auch sonst die Angriffsflächen klein hält, minimiert das Risiko.
  • System lädt etwas vom Internet
    Die größte Problematik ist aus meiner Sicht der Download von Code aus dem Internet durch Anwender oder Malware und deren Kommunikation mit einem "Command and Control-Server" im Internet. Dazu muss der Client sich natürlich per DNS die Adresse zu einem Namen holen und dann eine TCP-Verbindung aufbauen.

Für all diese Wege gibt es schon Lösungen, die sehr gut aber nicht in allen Fällen ausreichend sind. Natürlich kann und muss ein SMTP-Filter solche ausführbaren Anlagen blockieren und möglichst auch Links unschädlich machen. Auch eine Firewall kann zu einer Verbindung sowohl die vorherige DNS-Anfragen mit der IP-Adresse und dann die TLS-Verbindung zu dieser IP-Adresse zusammenführen und den SNI-Namen auslesen und gegen Listen abprüfen. Auch ein HTTP-Proxy kann mit SSL-Inspection die Download scannen, wenn IIS Extended Protection dies nicht verhindert.

Mittlerweile hat fast jedes Betriebssystem eine "integrierte" Firewall und auch die Windows Firewall wird immer wieder unterschätzt. Sicher kann sie keine TLS-Inspection oder Contentscans durchführen, aber sie ist eine passable Paketfilter-Firewall, die auf Basis von Netzwerk-Protokoll (IP, ICMP, UDP, TCP), Quell/Ziel-IP-Adresse und Port und Prozessnamen die Verbindungen erlauben oder blockieren kann.

Funktionsweise

Microsoft leitet seinen Blog-Artikel mit folgendem Worten ein.

To support Zero Trust deployments trying to lock down devices to only access approved network destinations, we are announcing the development of Zero Trust DNS (ZTDNS) in a future version of Windows. 
Quelle: https://techcommunity.microsoft.com/t5/networking-blog/announcing-zero-trust-dns-private-preview/ba-p/4110366

Eine Schutzfunktion kann daher darin bestehen, generell ausgehende Verbindungen erst zuzulassen, wenn die Gegenseite irgendwie verifiziert wurde. Da wir bisher selten wissen, welche Programme auf einem PC denn eine ausgehende Verbindung starten und Windows in der Standardeinstellung jedem Programm eine ausgehende Verbindung ohne Grenzen erlaubt, ist dies schon ein grundsätzlicher Wechsel. Eingehende Verbindung von extern auf einem PC blockt die Firewall in der Regel schon ab, wie ein Blick auf ihre Firewall-Konfiguration zeigt.

Diese Verhalten können wir hier mit einem Mausklick schon anpassen und auch ausgehende Verbindungen erst einmal blocken und anhand der definierten Prozesse, Ziel-Adressen und Ziel-Ports und Protokollen erlauben. Das wäre möglich aber selbst für ein rein internes LAN mit festen internen IP-Adressen schon mit sehr viel Vorbereitung verbunden. Sie müssten dazu zu allererst einmal ermitteln, welche Zielsysteme ihre Clients denn ansprechen dürfen. Da ist es dann vermutlich einfacher, auf den Zielsystemen zu steuern, von welchen Clients die angesprochen werden dürfen.

Sobald es aber in Richtung Internet geht, kommen Sie mit einem statischen Ansatz nicht mehr weiter. Hier setzt dann ZTDNS auf, indem jede DNS-Anfragen über einen "vertrauenswürdigen DNS-Server" geleitet wird, der zu dem Namen eine "Bewertung" kennt. Wenn der Name "vertrauenswürdig" ist, dann bekommt der Client die IP-Adresse. Und da das alles auf Basis des DNS-Resolvers auf dem Client als "System" erfolgt, kann das System auch gleich der Firewall diese "Freigabe" mitteilen. Erst dann kann Anwendung die Verbindung auch aufbauen.

Die Verbindung zum "vertrauenswürdige DNS-Server" ist natürlich keine "Klartext-DNS-Abfrage" über Port 53/UDP/TCP, sondern nutzt z.B. DoH (DNS over HTTP) oder DoT (DNS Over TLS) um entsprechend "Vertrauenswürdige DNS-Server" zu erreichen.

Das ist natürlich nur eine Kurzfassung.

An alles gedacht?

Das Konzept sieht auf den ersten Blick überraschend überzeugend aus. Das waren aber viele Ideen  zum Spamschutz in der Vergangenheit auch und haben in der echten Welt dann auch nicht bestehen können. DNS ist aber eine grundlegende Funktion in einem IP-Netzwerk, und ohne DNS wird es schwer einen Service zu finden. Es gibt nur wenige Dienste, die ohne DNS arbeiten und IP-Adressen direkt ansprechen. Bei der Nutzung von DNS ist es aber alles andere als einfach. Normalerweise fragt ein Client seinen per DHCP oder statische zugewiesenen DNS-Server an. In einem Firmennetzwerk ist das oft zugleich der Domaincontroller und im Heimatnetzwerk der DSL-Router.

Der DNS-Server liefert dann die Antwort entweder aus seiner lokalen Datenbank, einem Cache aus früheren Auflösungen oder fragt seinerseits Upstream-Forwarder oder lässt sich von den Root-Servern vermitteln. Diese bewährte Verfahren sorgt auch dafür, dass z.B. Cloud Anbieter anhand der Source-IP des Anfrage auf den Provider des Kunden schließen können und bei Verwendung von Geo-DNS einen netzwerktechnisch naheliegenden Zugangspunkt ausliefern können. Sobald die Namensauflösung den regulären Weg verlässt, müssen Sie aufpassen, dass Sie nicht nur eine gültige, sondern auch die optimierte Antwort bekommen. Dies gilt für Cloud-Dienste ebenso wie für lokale Active Directory-Umgebungen bei der Suche nach dem lokalen Domain Controller. Hier ein paar Beispiele:

  • HTTP-Proxy
    Die meisten Firmen setzen heute schon einen HTTP-Proxy oder sogar einen HTTP-Cloud-Proxy ein. Ein Client wird dann zumindest für das Protokoll HTTP nicht mehr den lokalen DNS-Stack verwenden, sondern die Anfrage an den Proxy-Server geben, der seinerseits dann die Namen auflöst und hoffentlich vergleichbare Schutzfunktionen umsetzt. Nur wenn Ziele als Ausnahme (z.B. WPAD/Proxy.pac) vom Proxy definiert sind, muss der Client selbst tätig werden.
  • Lokale Dienste und Namen
    Dann sollte ein Client im Firmen-LAN besser keinen "vertrauenswürdigen Microsoft-DNS" Server im Internet befragen, um lokale Dienste aufzulösen. Die könnte ja auf "<firmenname>.local" o.ä. enden und dürften kaum vom externen DNS-Server auflösbar sein und das Internet weiß bei einem privaten Netzwerk mit den privaten IP-Adressen nichts anzufangen. Sie müssen also die lokalen Domainnamen ausschließen, wenn ihr Client in ihrem Netzwerk ist. Also muss auch hier eine Art Network Location Service NLS genutzt werden, wie wir das bei Direct Access schon kennen.
  • Sonderfall Homeoffice/VPN
    Denken Sie an die Benutzer zuhause und unterwegs. Diese stehen in der Regel nicht innerhalb einer durch Firewalls gesicherten Netzwerke sondern können im Prinzip mit jeder Gegenstelle im Internet sprechen, wenn sie nicht grade ein "Tunnel-VPN" haben. Ohne VPN kann es schon interessant sein, wen der Client gar nicht die regulären DNS-Server fragt. Die Zugangsprovider filtern eigentlich nie, es sei denn der Gesetzgeber schreibt eine Blockade von Domains vor.
  • ETC/Hosts
    Ich habe noch keine Information, ob die DNS-Anpassung auch lokale Hosts-Dateien berücksichtigt. Der lokale DNS-Resolver sollte dies schon respektieren aber könnte die Sicherheit untergraben, sofern ein Angreifer diese Datei verändern kann. Aber es gibt auch Firmen, die aktiv mit der HOSTS-Datei arbeiten und diese per Softwareverteilung aktualisieren, z.B. damit Systeme auch ohne DNS funktionieren.
  • Dienste ohne DNS
    Es gibt durchaus Dienste, die DNS nur dazu nutzen, einen "Austauschpunkt" zu ermitteln, über den dann die Clients ihre IP-Adressen austauschen. Das machen eigentlich alle VoIP-Dienste so, d.h. Microsoft Teams, WebEx, Zoom aber auch VoIP-TK-Anlagen, die auf ICE, Kandidaten, STUN und TURN setzen. Auch Browser und Teams Townhall/LiveEvents (Siehe Teams CDN/eCDN), Windows Update und natürlich die klassischen Dateiplattformen (Emule etc.) nutzen P2P-Traffic
  • IP-Sharing
    IPv4-Adressen sind knapp und nicht nur große Content Delivery Services wie Cloudflare, Akamai etc. nutzen Server Name Indication (SNI), um unterschiedliche URLs unter einer IP-Adresse zu betreiben.
  • Plattformmissbrauch
    CDN-Dienste wie Cloudflare oder auch Plattformen wie GitHub werden von vielen Menschen genutzt, auch wenn diese ganz unterschiedliche Daten vorhalten. Wie wahrscheinlich ist es, dass ein Angreifer wirklich eine eigene Domain nutzt, wenn er einige Dinge einfach auf anderen Plattformen bereitstellen kann. Es wäre nicht das erste mal, dass auch Angreifer die Dienste eines CDN nutzt, wie ich auf QR-Code Phishing mit Microsoft 365 schon analysiert habe oder Befehle und Konfiguration als "frei verfügbaren Sourcecode" auf GitHub ablegt.
  • "Free WiFi"-Portalseiten
    Ich kenne nur ganz wenig "Free Wifi"-Angebote, bei denen das WLAN ohne Kennwort oder nur mit einem bekannten Kennwort erreichbar ist. Meist sind Vorschaltseiten mit Werbung oder Portale zur Anmeldung dazwischen geschaltet. Wenn der Client aber einen "Redirect" auf das Portal bekommt aber die DNS-Anfrage nach dem Namen (noch) nicht funktioniert, dann steckt er in einer Sackgasse. Ob alle Free-WiFi-Betreiber ihre Zugänge entsprechend "kompatibel" umrüsten?

Ich bin sicher, dass es noch viele andere "Sonderfälle" gibt. Ich denke da an IoT-Konfigurationen mit mDNS, Multicasts, UPNP-Discover. Wenn ein IP-Stack eine Verbindung nur noch zulässt, wenn die "trusted DNS-Server" zu einem Namen eine IP-Adresse geliefert haben, dann kann auch eine DNS-Störung (Offline, DDoSAttacke, Wartung etc.) ein eigentlich funktionierendes Netzwerk kräftig stören.

Dennoch ist der Ansatz schon interessant, dass man für "Zero Trust" die erfolgreiche DNS-Auflösung als Freischaltung einer Kommunikation zu einer IP-Adresse erst einmal erlaubt. Sie könnte ja lokale Domains und interne IP-Adressen generell auf einer Allow-List setzen.

Das schwächt aber wieder ihren Schutz, denn wer sagt ihrem Client, dass er in "ihrem" privaten Netzwerk ist und nicht das Hotel zufällig die gleichen Subnetze verwendet?

Einschätzung

Dass wir kontinuierlich an der Sicherheit von Clients und Servern arbeiten müssen, ist uns allen klar. Ob hier ein DNS-Server mit Filter-Funktion und einem Client, der anhand der DNS-Antworten erst Verbindungen zulässt, der passende Weg ist, muss ich zeigen. Es gibt schon heute Firewalls, die anhand von DNS-Antworten Verbindungen erlauben, HTTP-Proxy-Server mit leistungsfähigeren Möglichkeiten auf Basis eines SNI-Handshake statt einer IP-Adresse und lokale Firewalls samt Management-Produkten, die schon heute entsprechende "Allow"-Listen abhängig vom Standort umsetzen können.

Für Firmen ist dieser Ansatz vermutlich weniger interessant aber er könnte für alle "Personal Devices" eine Verbesserung darstellen, wenn Windows als Bordmittel schon eine Firewall-Konfiguration per DNS zulässt. Wir werden aber abwarten müssen, wie die Konfiguration (Manuell, Gruppenrichtlinien, DHCP-Options, Intune o.ä.) umgesetzt wird und wie einfach eigene "vertrauenswürdige Server" konfiguriert werden können.

Ambitionierte Anwender nutzen ja heute schon Programme wie "Pi-hole" oder Cloud-Dienste wie NextDNS.IO, oder andere DNS-basierte Malwarefilter. (Siehe auch DNS-Malwarefilter und Office 365) Im Grund sind das auch schon für die Nutzer "vertrauenswürdige DNS-Server", die jede Anfrage prüfen und "schlechte" URLs nicht zulassen, d.h. umleiten oder als "nicht auflösbar" abblocken.

Interessant wird der Ansatz, wenn Firmen all ihre Client generell auf eine von ihnen selbst verwaltete Instanz von DNS-Servern lenken, und damit sowohl interne als auch externe Namen korrekt auflösen und die Client sich dazu am DNS-Server z.B. per DoT/DoH mit einem Client Zertifikat authentifizieren und das auch aus dem Homeoffice geht.

Denken Sie dann aber wieder daran, dass die bekannten Cloud-Dienste ausgenommen sein sollten, damit die Home-Office Clients den optimalen Zugangspunkt finden. Sie dazu auch DNS-Malwarefilter und Office 365, speziell wenn die Cloud-Anbieter kein Anycast-Routing nutzen.

Weitere Links