Ein „Technical Deep Dive“. Liebe Kaufleute, für heute sind Sie raus.
An dieser Stelle veröffentlichen wir üblicherweise eher Themen für Entscheider. Nicht heute. In Zukunft werden wir unseren Blog thematisch separieren, um auch den Technikern unter unseren Lesern Inhalte mit praktischem Nutzwert präsentieren zu können.
Als WatchGuard Gold Partner nimmt die KLESYS regelmäßig am Beta-Programm des IT-Sicherheits-Herstellers teil, um die neuesten Funktionen noch vor dem offiziellen Erscheinen evaluieren und ihren Einsatz in verschiedensten Kundenszenarien planen zu können. In diesem Zusammenhang sind wir auf eine Störung gestoßen, die durch ein Leistungsmerkmal verursacht wird, das in der neuesten Fireware 12.1.1 hinzugekommen ist. „DNSWatch“ führt dazu, dass Vodafone WiFi Calling nicht mehr funktioniert.
WiFi Calling, das von allen drei deutschen Netzbetreibern angeboten und in diesem FAZ-Artikel anschaulich erklärt wird, ermöglicht es, auch an Orten mit schlechtem Handyempfang mobil zu telefonieren. Man nutzt einfach ein vorhandenes WLAN als Übertragungsmedium. Das ist hilfreich gerade in so gottverlassenen Gegenden wie dem Niederrhein und innerhalb von Gebäuden mit Stahlbeton-Mauerwerk oder metallbedampften Fensterscheiben. Aber auch Zugreisende kommen mit WiFi Calling dank des neuen, im Vergleich zu früher revolutionär gut arbeitenden ICE-WLANs in den Genuss unterbrechungsfreier Telefongespräche. Hier die Produktbeschreibung von Vodafone, hier WLAN Call von O2 und hier das WLAN Call der Telekom.
WiFi Calling ist bei der Telekom und O2 auch im Ausland nutzbar. Hier zählt immer der deutsche Tarif, d.h. man kann auch im Ausland ohne Roamingzuschlag angerufen werden und bei Gesprächen nach Deutschland seine nationale Flatrate nutzen. Nicht so bei Vodafone: Hier will man verhindern, dass die Kunden die teuren Roaming-Gebühren auf Geschäftsreisen oder Urlauben im Ausland umgehen, indem sie WiFi-Calling einschalten und ihre heimische Flat zum Telefonieren nutzen.
Technisch realisiert Vodafone die Unterscheidung zwischen In- und Ausland über ein Geofencing auf Basis des DNS-Dienstes: Alle deutschen DNS-Server können bestimmte, von Vodafone genutzte DNS-Namen zu IP-Adressen auflösen, wohingegen ausländische DNS-Server keine gültige Antwort liefern. Ohne IP-Adresse kann sich das Mobiltelefon nicht mit dem WiFi-Calling-Server verbinden – dem Nutzer bleibt lediglich die Telefonie über das normale Mobilfunknetz.
Damit Vodafone WiFi Calling funktioniert, muss somit ein deutscher DNS-Server in den Einstellungen der Internetverbindung bzw. als DNS Forwarder der eigenen DNS Server eingetragen sein, also beispielsweise die vom Internet-Provider vorgegebenen. Die beliebten Google DNS Server (IPv4 8.8.8.8 und 8.8.4.4) sind nicht geeignet. Üblicherweise werden schon aus Latenzgründen der oder die DNS-Server des jeweiligen Internet-Providers in die Firewall eingetragen. Bei (V)DSL-Anschlüssen der Telekom und anderer Anbieter werden die DNS-IP-Adressen beim Verbindungsaufbau automatisch mitgeteilt, man muss in diesen Fällen also gar nichts konfigurieren.
Hier kommt nun DNSWatch ins Spiel. DNSWatch von WatchGuard ist ein cloudbasierter Sicherheitsdienst, der Blocklisten auf Basis von DNS-Abfragen bereitstellt. Das Neue an DNSWatch ist, dass potenziell gefährlicher Traffic unabhängig vom Verbindungstyp, Protokoll oder Port unterbunden wird. Versuche, den bösartigen Datenverkehr zu tunneln oder zu verschlüsseln, bleiben erfolglos, weil die Kommunikation mit der vom Schadprogramm aufgerufenen DNS-Adresse gar nicht erst zustande kommt. Gleichzeitig erhält der Anwender, auch das ist neu, eine – aktuell leider nur englischsprachige – Meldung über den Vorfall, was zur Sensibilisierung der Nutzer in IT-Sicherheitsfragen beiträgt.
Technisch setzt WatchGuard die Filterfunktion um, indem – vereinfacht ausgedrückt – die DNS-Server auf der Firewall durch DNSWatch-Server ausgetauscht werden. Deren IP-Adressen sind nicht in Deutschland registriert und lassen somit die DNS-Namensabfragen von Vodafone WiFi-Calling ins Leere laufen. Weitere Dienste, die mit Geoblocking arbeiten, könnten ebenfalls durch DNSWatch gestört werden.
Uns stand keine ausreichende Zeit zur Verfügung, um Netflix, Amazon Prime Video und Co. zu testen, es ist aber davon auszugehen, dass DNSWatch auch hier Beeinträchtigungen verursacht. Für diese Dienste gilt prinzipiell derselbe Workaround wie der nachfolgend beschriebene.
Zunächst aktiviert man, falls noch nicht geschehen, das DNS-Forwarding in den Netzwerkeinstellungen der Firebox:
Die beiden DNS Server IPs sind die amerikanischen; wie weiter unten erwähnt, werden intern die europäischen IPs weitergegeben und von der Firebox verwendet.
Nachdem wir das Forwarding aktiviert haben, können wir die Schnittstellen auswählen, für die es gelten soll. Wir haben in unserer Test-Firebox nur bestimmte Schnittstellen ausgewählt. Nicht, weil wir WiFi Calling nur auf bestimmten Schnittstellen aktivieren wollen, sondern weil wir weitere Forwardings eingerichtet haben, die nur auf bestimmte Schnittstellen Anwendung finden sollen.
Nun richten wir diejenigen DNS-Forwarder ein, die wir für WiFi Calling benötigen. Es handelt sich dabei um pub.3gppnetwork.org, vodafone-ip.de und vodafone-dns.net. Letzterer ist nach offiziellen Informationen nicht erforderlich. Wir haben Zugriffe darauf jedoch in den Firewall-Logs bemerkt und finden, dass es nicht schaden kann, diesen Eintrag hinzuzufügen, bewirkt das Forwarding doch lediglich, dass DNSWatch bei dieser Domain bzw. Subdomain nicht greift.
Als Forwarding-Ziel tragen wir einfach die zuvor, also vor der Aktivierung von DNSWatch, in den „normalen“ Netzwerkeinstellungen konfigurierten DNS-Server ein. Das funktioniert natürlich nur bei statischen Einträgen. Die bereits erwähnten dynamischen IPs mancher DSL-Anbieter, welche die DNS-Server während des PPPoE-Verbindungsaufbaus übermitteln, können wir hier nicht verwenden. Als Workaround bedienen wir uns einer Fritz!Box, die anstelle der WatchGuard den PPPoE-Verbindungsaufbau vornimmt und hinter der die WatchGuard als „Exposed Host“ eingerichtet ist. Die Fritz!Box leitet per Default Namensabfragen an die DNS-Server des Internetanbieters weiter:
Hier die erwähnte „Exposed-Host“-Freigabe für die Firebox:
Die Fritz!Box-Lösung werden wir wohl nur an kleinen Außenstandorten präferieren, insbesondere, wenn der Kunde zusätzlich eine dezentrale VoIP-Lösung nutzen will, beispielsweise einen normalen VoIP-Anschluss der Telekom. Das Geschäftsführer-Homeoffice ist ein klassisches Anwendungsbeispiel. Nachteil dieser Vorgehensweise: Das Out-of-Band-Management der Fritz!Box ist nicht möglich, weil der dafür benötigte Port, sei es nun HTTPS oder IKE/L2TP, an die WatchGuard als „Exposed Host“ weitergereicht wird und keine zweite externe Schnittstelle zur Verfügung steht.
Professionelle PPPoE-fähige Router anstelle von Fritz!Boxen versetzen uns über das Out-of-Band-Management hinaus in die Lage, mehrere Geräten gleichzeitig und automatisiert zu verwalten. Daher könnten sie in zwei Szenarien zum Einsatz kommen: in größeren Umgebungen mit vielen Außenstellen sowie bei räumlich weit entfernten oder schwer zugänglichen Außenstandorten, wo eine VPN-Störung und der damit verbundene Zusammenbruch des In-Band-Managements einen Vor-Ort-Einsatz mit hohen Reisekosten auslösen würde.
In aller Regel leitet man den externen Netzwerkverkehr von kleinen Außenstellen ohnehin über die Zentrale, was die Einrichtung von lokalen DNS-Servern und die Absicherung derselben über DNSWatch überflüssig macht. In manchen Fällen jedoch ist ein lokaler Breakout bestimmten Traffics erforderlich – siehe das Beispiel „Geschäftsführer-Homeoffice“. Solche Umgebungen lassen sich mit oben skizzierter Architektur zukünftig auch mittels DNSWatch schützen.
Vodafone WiFi Calling benötigt über die deutschen Nameserver hinaus Zugriff über IPsec auf das Vodafone-Subnetz 139.7.117.160/28, wie aus diesem Beitrag hervorgeht. Falls IPsec-Verkehr bisher nicht gestattet ist, so muss man ihn zumindest für das genannte Subnetz zulassen. Die entsprechende Regel könnte so aussehen:
So! Nun haben wir jede Menge Änderungen an unserer Infrastruktur vorgenommen. Um die Anpassungsarbeiten einer Qualitätskontrolle zu unterziehen, sollten wir nun noch die Funktion von DNSWatch testen. Dazu rufen wir die Test-Homepage http://strongarm.test/ (nicht HTTPS!) auf. Wenn wir als Antwort eine Seite mit „DNSWatch Website Blocked“ erhalten, ist DNSWatch weiterhin aktiv.
Scheitert der Seitenaufruf, liegt an irgendeiner Stelle eine Fehlkonfiguration vor.
Übrigens: Ursprünglich verfügte WatchGuard über lediglich zwei Nameserver an der US-Ostküste. Für asiatische und europäische Kunden bedeutete dies eine zu hohe Latenz und somit eine unnötige Verlangsamung beim Surfen. WatchGuard hat nachgebessert und sowohl in Asien, als auch in Europa zusätzliche Serverkapazität eingekauft. Die europäischen Server werden im AWS-Rechenzentrum in Dublin gehostet und sind somit qua Standort EU-DSGVO-konform. Die IP-Adressen der DNSWatch-Nameserver passen sich dynamisch an den Standort der WatchGuard-Firewall an, wie man im Front Panel des Firebox System Managers sehen kann:
Diesen Blogbeitrag haben wir auf Basis der Fireware-Beta-Release B555638 erstellt. Auf dem Bild ist als dritter externer DNS-Server noch der amerikanische zu sehen. Ob die Entwicklungsabteilung das bis zum Inkrafttreten der EU-DSGVO am 25. Mai noch ändert, wissen wir nicht. Sicherlich wird sich ein WatchGuard-Partner oder Kunde finden, der einen entsprechenden Feature-Request stellen wird.
Der Dienststatus von DNSWatch lässt sich unter einer der folgenden URLs abrufen:
Wir freuen uns über Ihr Feedback zu diesem Beitrag! Nutzen Sie die Kommentarfunktion, um mit uns über das Thema DNSWatch in Dialog zu treten.