c't 21/2021
S. 116
Wissen
Anonymes DNS analysieren

Heuhaufen

Was Netzbetreiber in Mitschnitten lesen können

Neue Protokolle zur anonymen DNS-Kommunikation sollen eine große Lücke im Privatsphärenschutz schließen. Aber wie gut gelingt das angesichts der Tatsache, dass Angreifer im Firmennetz oder auch Provider allen Internet-Verkehr eines Anschlusses mitschneiden können?

Von Dušan Živadinović

Jedes internetfähige Gerät sendet Anfragen an das weltweite Domain Name System, damit dieses Domainnamen zu IP-Adressen auflöst. Dann kann der Webbrowser den Zielserver anhand dessen IP-Adresse ansteuern und Webseiten abrufen.

DNS-Anfragen sind unverschlüsselt, sodass jeder, der sie liest, genau im Bilde ist, was ein User so den ganzen Tag treibt. Protokolle zur anonymen DNS-Anfrage sollen das unterbinden. Auf den Seiten 106 und 110 beschreiben wir, wie sie funktionieren, und wie man sie ausprobieren kann.

Andererseits stehen aber in jedem verschickten und empfangenen IP-Paket die Quell- und Ziel-IP-Adressen, also individuelle Daten des Senders und Empfängers. Schneidet man den Verkehr mit, sollten sich die Aktivitäten doch ebenso lückenlos überwachen lassen. Mitschneiden können Angreifer, die physischen Zugang zu einem Firmen- oder Heimnetz haben und natürlich Provider.

Mitschnitte können Provider aus den Enterprise- und Backbone-Router ausleiten. Allerdings werden nur Metadaten wie Quell- und Ziel-IP-Adressen, Protokollart und dergleichen notiert.

Wir haben Zulieferer von Backbone-Routern gefragt, wie verbreitet solche Funktionen in ihren Geräten sind. Juniper wollte dazu nichts sagen.

Ein Sprecher von Cisco antwortete: „Aufgrund der Vielzahl von Router-Plattformen und Softwareversionen gibt es keine pauschale Antwort. Die Funktionen zur Aufzeichnung können in der Basisausstattung enthalten oder kostenpflichtig sein. Prinzipiell ist die Verschlüsselung von DNS-Anfragen als zusätzlicher Schutzmechanismus sehr zu begrüßen, weil damit das Risiko der Ausspähung des Verkehrs deutlich reduziert wird.“

Wie sieht die Mitschnittfunktion von Enterprise- oder Backbone-Routern konkret aus? Generell dröseln sie den Verkehr in einzelne Flows auf. Es gibt zwar unterschiedliche Implementierungen (wie NetFlow, sFlow), aber alle tun mehr oder weniger das Gleiche: Pro Flow (also etwa eine TCP-Verbindung oder eine UDP-Konversation) erfasst der Router verschiedene Parameter und gibt sie an ein zentrales Netzelement weiter. Das kann heutzutage jeder ernstzunehmende Router-Hersteller.

Enterprise- und Backbone-Router und auch große Firewalls können Metadaten des Verkehrs, den sie durchleiten, erfassen und an eine zentrale Stelle weiterreichen. In diesem Beispiel ist die Konfiguration der Ziel-IP-Adresse einer Palo-Alto-Firewall zu sehen.

Damit generiert man aber erst mal nur viel Datenmüll. Um Nutzen daraus zu ziehen, braucht man Einsammler, Datenbanken und Auswerte-Tools. Provider nutzen das fürs Grobe, um zu erfassen, mit welchen anderen Providern sie wie viele Daten austauschen, um dann das Peering zu erweitern oder auch einzustellen. Andere Varianten merken sich die Zuordnung von Clients hinter der (CG)NAT zu den öffentlichen IP-Adressen des Routers und können erfassen, wer zum Zeitpunkt X welche IP-Adresse für den Zugriff auf die Website Y genutzt haben könnte.

Drölfhundert Websites

Das klingt zwar nach einem sehr konkreten Werkzeug zur Massenüberwachung, aber: Sehr viele Client-Zugriffe laufen bei CDN-Betreibern wie Akamai, Google, Amazon AWS oder Cloudflare auf. Der Inhalt ist verschlüsselt und hinter der IP-Adresse X können drölfhundert verschiedene Websites antworten, je nachdem, welchen Server ein User ansteuert.

Viele Computer führen dieses wichtige Detail im ersten Paket des TLS-Handshake auf (Servername Indication, SNI), sodass man daran alternativ zu DNS-Anfragen ebenfalls sehen kann, wer was tut.

Doch das QUIC-Protokoll, das Google vor einigen Jahren für Chrome eingeführt hat, verschlüsselt den SNI. Auch TLS 1.3 soll das bald können (encrypted Client Hello). In beiden Fällen sieht das Monitoring-Tool nicht, mit welchen Servern ein Client kommuniziert, wenn zu einer IP-Adresse mehr als eine Domain konfiguriert ist.

Kurz: Wenn ein Client unverschlüsselt nach der IP-Adresse einer Domain fragt, kann man einfach aus seinem DNS-Anfrage-Paket auslesen, was den bösen Revoluzzer interessiert. Mit DNS-Verschlüsselung, anonymisiertem DNS, QUIC und TLS 1.3 geht das an Enterprise- und Backbone-Routern nicht mehr. Übrig bleiben die CDNs: Die Betreiber können klar zuordnen, welche Client-Adresse welche Webseite abruft. Aber die Daten von allen möglichen CDNs der Welt dürften nicht mal mehr Staatsschützer vollständig in die Hände bekommen. (dz@ct.de)

Kommentieren