DNS RPZ - Blockieren und Ändern von Namen

DNS RPZ

Blockieren und Ändern von Namen

Jeroen Massar
von Jeroen Massar
am 18. Januar 2018
Lesezeit: 13 Minuten

Keypoints

  • DNS RPZ erlaubt das Blockieren und Ändern von Hostnamen
  • Es kann in einer lokalen Zone oder mit einer Anbindung an mehrere RPZ-Feeds betrieben werden
  • Ein klassisches DNS Master/Slave Setup leitet die Updates via AXFR/IXFR weiter
  • Whitelists und Blacklists verhindern das versehentliche Blockieren von legitimen Ressourcen
  • Das Umgehen der Vorgaben kann durch eine klare Trennung auf L3 durchgesetzt werden

Das Domain Name System (DNS) gilt als das Telefonbuch des Internets, denn es verknüpft Hostnamen mit IP-Adressen. Nicht nur wird es durch Unternehmen und Privatpersonen für nicht-kriminelle Aktivitäten genutzt – Es spielt auch eine wichtige Rolle für Botnetz-Betreiber, Phisher, Werbe- und Spam-Netzwerke sowie andere böswillige Akteure im Internet. Viele Leute setzen einen browserbasierten Adblocker ein, wie zum Beispiel uBlock Origin. Diese setzen im Hintergrund auf Hostnamen- und IP-basierte Filtern. Ein solcher Adblocker grenzt jedoch lediglich die Zugriffe im Browser ein.

Mit DNS Response Policy Zones können Zugriffe nicht nur blockiert werden, sondern es wird auch das Abändern der DNS-Anfragen möglich. Jede Komponente, die eine DNS-Abfrage durchführen möchte, kann buchstäblich belogen werden, indem der Zugriff über einen RPZ-Feed gesteuert wird. Gegenwärtig unterstützen sowohl BIND als auch PowerDNS diesen Ansatz von Haus aus. Sie müssen nur dementsprechend konfiguriert und aktiviert werden.

DNS RPZ – Firewall für DNS

RPZ gewährt eine Vielzahl an Möglichkeiten, um Antworten zu manipulieren. Der einfachste Ansatz liegt in der Ausgabe einer NXDOMAIN Fehlermeldung, dass die angefragte Ressource nicht existiert. Eine andere beliebte Möglichkeit ist das Umleiten auf eine andere Ressource. Typischerweise geschieht dies innerhalb eines Walled Garden über einen Webschnittstelle.

Der IETF Draft, der die Details des RPZ-Protokolls spezifiziert, zeigt im Anhang ein paar gute Beispiele, wie das System genutzt werden kann. Eine andere gute Quelle ist das Buch DNS for Rocket Scientists, welches sowohl ein allgemeines Kapitel über RPZ als auch ein spezifisches zur Konfiguration von RPZ beinhaltet.

ISC, die Maintainer des bekannten DNS-Server BIND bieten einen Bereich in ihrer Knowledge Base zum Thema RPZ. Darin finden sich eine Vielzahl an Informationen zu Konfigurationseinstellungen sowie konkreten Vorschlägen.

Ein einfaches Beispiel, um mittels RPZ eine ganze Domain komplett verschwinden zu lassen:

$ORIGIN rpz.example.net.
bad.example	CNAME	.
*.bad.example	CNAME	.

Dieser Ansatz kann herangezogen werden, um einen Virus oder gar ein ganzes Botnetz zu blockieren. Oder man betreibt Zensur damit.

Um einen Hostnamen auf einen anderen umzuleiten, wird auf Anfragen einfach ein anderer Name zurückgegeben:

$ORIGIN rpz.example.net.
evil.example	CNAME	good.example.

Hier gilt es darauf hinzuweisen, dass der Host-Header innerhalb von HTTP ignoriert wird oder im Zusammenhang mit HTTPS mit einem validen Zertifikat mitgeliefert werden muss. Letztgenanntes ist möglich, indem eine CA auf allen Clients installiert und on-the-fly ein Zertifikat mit einer Lösung wie mitmproxy erzeugt wird. Die meisten anderen Protokolle stützen sich nur auf der IP-Adresse ab und nicht auf einem Hostnamen ab.

RPZ Feeds

Damit RPZ eingesetzt werden kann, muss entweder eine Local Zone oder ein RPZ-Feed genutzt werden. Die meisten RPZ-Feeds stellen abonnementsbasierte Dienste dar, auf die nach der Einwilligung des Server-Betreibers über AXFR zugegriffen werden kann. Es können mehrere Feeds konfiguriert werden, wobei der erste Treffer für ein DNS-Label diktiert, wie mit dem Resultat für die Anfrage umgegangen werden muss.

Verteilen von RPZ-Zonen

Da DNS RPZ Zonen schlussendlich normale DNS-Zonen sind, können sie mit klassischen DNS-Techniken verteilt werden. Ein typisches DNS Master/Slave Setup wird, falls entsprechend konfiguriert, automatisch die Updates der DNS RPZ Zone mit der Hilfe von DNS AXFR/IXFR verteilen und entsprechend die inkrementellen Änderungen effizient propagieren.

RPZ und DNSSEC

Da RPZ grundsätzlich ein Ansatz ist, um ein System zu belügen, kann DNSSEC nicht wie üblich validieren. Man müsste einen privaten Schlüssel generieren und diesen auf allen Recursors, die eine Prüfung mittels DNSSEC machen sollen, verteilen. Nur so kann das gesamtheitliche System belogen werden.

Dies ist grundsätzlich gut, denn DNSSEC kann nicht beigezogen werden, um eine Man-in-the-Middle-Attacke (MITM) unter Zuhilfenahme von DNS RPZ durchzuführen. Da keine anständige Signierung des Eintrags gegeben ist, wird die Validierung fehlschlagen. Dies führt dazu, dass das DNS-Label korrekterweise als verändert identifiziert wird. Die meisten Implementierungen von DNSSEC dabei einen SERFVAIL-Fehler generiert.

Bekannte RPZ-Fallgruben

Wenn automatisch generierte oder externe RPZ-Feeds genutzt werden, sollten diese vorgängig auf ihre Qualität hin geprüft werden. Andernfalls kann ein ungewolltes Blockieren stattfinden.

Ein wichtiger Schritt hierbei ist das Einrichten einer lokalen RPZ, die eine Whitelist mit Domains und IP-Adressen beinhaltet, die nicht beeinträchtigt werden dürfen. Ein versehentlicher Fehler im RPZ-Feed würde weitreichende Folgen in Bezug auf die Erreichbarkeit der lokalen Domains bzw. der wichtigsten Domains haben.

Wie die Best Practice für DNS-Server diktiert, sollten authoritative und rekursive DNS-Server getrennt werden. Das Applizieren von RPZ-Policies auf den authoritativen Servern könnte unerwartete Resultate provozieren, vor allem wenn nicht geprüfte RPZ-Feeds herangezogen werden.

Walled Garden mit RPZ

Ausserhalb des Walled Garden

Ein typisches Einsatzgebiet für RPZ ist das Einrichten eines sogenannten Walled Garden. Ein Walled Garden ist in diesem Zusammenhang eine Technik, um einen Host im Netzwerk vom Internet zu entkoppeln. Dies wird normalerweise getan, um diesen Host daran zu hindern, auf Internet-Ressourcen zuzugreifen. Wenn zum Beispiel erkannt wurde, dass er Aktionen ausführt, die sich negativ auf das Netzwerk auswirken können.

Beispielsweise können Verbindungen zu einer IP erkannt werden, die normalerweise für die Kommunikation mit einem Botnetz verwendet wird. Oder der Host versucht, nach Hosts zu suchen, die Teil einer Command and Control-Infrastruktur (C&C) sind. Ein Walled Garden kann auch verwendet werden, um eine Authentifizierung von einem Host zu verlangen, bevor er die übrige Infrastruktur nutzen darf.

Die Grafiken Ausserhalb des Walled Garden und Innerhalb des Walled Garden illustrieren dieses Konzept. Die Abbildung Ausserhalb zeigt Client A und C, die normalerweise mit dem grünen/normalen Netzwerk verbunden sind. Da sie mit dem Router verbunden sind, können sie auch Pakete an das Internet senden. Wenn C den RPZ-fähigen DNS-Server nach der Adresse von B fragt, wird die Adresse des Walled Garden zurückgegeben und das VLAN wird vom normalen VLAN in das des Walled Garden geändert. Client C ist dadurch in das Netz des Walled Garden umgezogen. Die IP-Adressen der Router, DNS- und DHCP-Server bleiben dabei gleich; die einzige Kommunikation kann aber nur noch mit dem Walled Garden Server stattfinden.

Der Walled Garden ist damit sein eigenes Netzwerk. Es verfügt über einen eigenen DHCP-Server und stellt somit sicher, dass Clients eine IP-Adresse erhalten. Es verfügt ausserdem über einen DNS-Server, der nur Antworten zurückgibt, die auf die IP-Adresse des Walled Garden Servers verweisen. Durch die Verwendung eines eindeutigen VLANs stellen wir sicher, dass kein Verkehr andere Teile des Netzwerks erreichen kann. Es gibt auch kein gemeinsam genutztes DNS/DHCP, um sicherzustellen, dass ein versehentliches Datenleck vorliegt (z.B. könnte man durch DNS tunneln). Technisch mit einem VLAN und eigenem Router, DHCP und DNS ist für den Client auf den Walled Garden beschränkt.

Um den Fall eines bekannten Botnets zu adressieren, geben wir die Hostnamen, Domainnamen und/oder IP-Adressen in einer RPZ-Zone ein und als CNAME die Zieladresse unseres Walled Garden Server:

$ORIGIN rpz.example.net.
virus.example		CNAME	walled.garden.example.net.
*.virus.example		CNAME	walled.garden.example.net.
42.2.18.198.rpz-ip	CNAME	walled.garden.example.net.
42.zz.db8.2001.rpz-ip	CNAME	walled.garden.example.net.

 

Innerhalb des Walled Garden

Mit diesen RPZ-Regeln wird alles, was versucht virus.example aufzulösen oder DNS-Zugriffe auf 198.18.2.42 bzw. 2001:db8::42 auf die Adresse von walled.garden.example.net umzuschreiben.

Wenn der Client-Host nun versucht eine Verbindung zu diesen Servern herzustellen, wird die Adresse des Walled Garden Servers zurückgegeben und stattdessen zu diesem eine Verbindung hergestellt. An dieser Stelle könnte man sich dafür entscheiden, dass HTTP eine Webseite mit Details zum Problem zurückgibt (“Sie sind mit einem Virus infiziert”). Man könnte zusätzlich die Kommunikation zum Internet unterbrechen oder noch besser den Host automatisch in ein separates VLAN migrieren, das nicht nur die Kommunikation mit dem Internet sondern auch mit dem lokalen Netzwerk verhindert. Also ein VLAN, das als Walled Garden fungiert und nur Kommunikationen zum Walled Garden Server zulässt.

NTP lokal belassen mit RPZ

Die meisten Computersysteme werden mit NTP-Clients betrieben, die standardmässig entweder für Windows-Hosts auf time.windows.com oder für Linux-basierte Systeme auf distro.pool.ntp.org konfiguriert sind.

Das bedeutet, dass all diese Systeme irgendeinen Host irgendwo im Internet fragen, wie spät es ist. Gerade bei pool.ntp.org weiss man nicht, wie vertrauenswürdig die Zeitangabe ist, wo sich diese Hosts befinden und welche Netzanbindung sie haben. NTP verlangt auch, dass Firewalls ziemlich weit geöffnet sind, obwohl bekannt ist, dass es verschiedene DoS-Angriffe dank falsch konfigurierter DNS-Server gibt.

Wenn Sie einen lokalen (GPS-synchronisierten) NTP-Server einsetzen, wäre es natürlich besser, wenn Sie stattdessen diese lokale Zeitquelle verwenden würden. Anstatt sämtliche Systeme manuell zu konfigurieren oder darauf zu hoffen, dass DHCP Option 42 beigezogen werden kann, kann der bekannte NTP-Server mit RPZ eingebunden werden:

$ORIGIN rpz.example.net.
time.windows.com	CNAME	ntp.example.net.
pool.ntp.org		CNAME	ntp.example.net.
*.pool.ntp.org		CNAME	ntp.example.net.

Damit verwenden automatisch alle Clients, die diesen RPZ-fähigen DNS-Server ansteuern, die lokal definierte NTP-Quelle.

Verhindern des Umgehens von RPZ

Die RPZ-Konfiguration ist nur auf dem rekursiven DNS-Server aktiviert. Wenn ein Client zum Beispiel 8.8.8.8 oder 2001:4860:4860::8888 der öffentlichen DNS-Server von Google verwendet, werden keine DNS-Anfragen an den RPZ-fähigen DNS-Recursor mehr gestellt. Dieser kann also keinen Einfluss mehr nehmen. Ebenso könnte ein Client ein VPN verwenden und damit alle lokalen Einschränkungen umgehen.

Dies ist auch der Grund, warum im Beispiel des Walled Garden eine komplette Trennung auf L3 gegeben ist, damit Pakete aus dem Internet weder gesendet noch empfangen werden können. Andernfalls könnte dieses Sende-/Empfangsverhalten missbraucht werden, um die gewünschte Verbindung mittels Tunneling überbrücken zu können.

Das Filtern verhindert in der Regel nicht, dass gewillte Personen ihr Ziel nicht doch erreichen können. Daher ist die vollständige Trennung die einzige echte Lösung für einen Walled Garden.

Um sicherzustellen, dass alle Clients den lokalen RPZ-fähigen DNS-Recursor verwenden, könnte jeder UDP- und TCP-Verkehr über Port 53 dazu gezwungen werden, zum lokalen RPZ-fähigen DNS-Recursor zu gehen. Selbstverständlich würde auch da jeder Client, der auf ein VPN, Tunnel oder Tor setzt, nicht den lokalen DNS-Server einbeziehen und damit die Vorgaben von RPZ umgehen. Genauso, wie wenn sie die Regeln einer lokalen Firewall umgehen würden.

Über den Autor

Jeroen Massar

Jeroen Massar arbeitet seit Mitte der 1990er Jahre im Netzwerkbereich. Zu den Themen, die ihm am Herzen liegen gehören Netzwerkprotokolle, Performance, Monitoring, Anonymität und das Umgehen von Internet-Zensur.

Links

Werden auch Ihre Daten im Darknet gehandelt?

Wir führen gerne für Sie ein Monitoring des Digitalen Untergrunds durch!

×
TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Cyber Threat Intelligence

Cyber Threat Intelligence

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv