Quelle: Eigene Darstellung
Im ersten Teil dieser Blogreihe über das Domain Name System (DNS) haben wir verschiedene technische Details erklärt. Schon allein dadurch, dass für Umwandlung von Rechnernamen in IP-Adressen DNS-Server befragt werden, kommt dem System eine sehr zentrale Rolle für das Funktionieren des Internets zu.
DNS im Fokus von Angreifer*innen
Durch die zentrale und vitale Rolle des DNS richtete sich auch bald der Fokus von Angreifer*innen auf dieses System. Neben Angriffen auf die eigentliche Implementierung des Dienstes (klassisches Denial of Service, Exploit von Schwachstellen) bzw. dessen Funktionalität (z.B. Cache Poisoning oder Hijacking) werden vermehrt auch die gespeicherten Inhalte, also DNS-Einträge, für Angriffe missbraucht.
Hierbei macht man sich zu Nutze, dass das DNS sehr dezentral organisiert ist. Das bedeutet, dass nicht nur die Server mit den Datenbeständen weltweit verteilt sind, sondern dass auch keine zentrale Instanz existiert, die darüber bestimmen könnte, welche Domainnamen im DNS eingetragen werden dürfen und welche nicht. Möchte ein*e Angreifer*in bspw. eine seriöse Webseite vortäuschen, so werden sich irgendwo auf der Welt DNS-Anbieter finden, die wenig Sorgfalt walten lassen und die Eintragung ganz ähnlich lautender Domainnamen erlauben.
DNS als Kommunikationskanal für Schadsoftware
Ein anderer unseriöser Gebrauch des DNS besteht darin, dass man über DNS-Einträge bestimmter Schadsoftware erlauben kann, die Kommunikation mit der Außenwelt aufzubauen und z.B. Kommandos zu empfangen (Command and Control Server). Sogar die Schadsoftware an sich könnte man in DNS-Records unterbringen. Ein weiterer Gesichtspunkt ist, dass man durch die Verwendung des DNS nicht nur Informationen abrufen kann, sondern mittels Anfragen auch Informationen an die Außenwelt übertragen kann. Angreifer*innen benutzen deshalb DNS auch für die Exfiltration interner Informationen oder allgemeiner für den Transport schädlicher Informationen. DNS wird auch deshalb für solche unerwünschten Zwecke genutzt, da er ein fundamentaler Dienst ist, den man z.B. nicht abschalten kann und möchte.
Die DNS-Firewall an der RWTH
Um Schadsoftware, die häufig solche Mechanismen verwendet, abzuwehren, hat das Security Operation Center (SOC) der RWTH als neue Schutzmaßnahme eine DNS-Firewall eingeführt, welche auf dem Konzept der Response Policy Zones (RPZ) basiert. Diese Technik ist bereits in dem Softwareprodukt integriert, das die RWTH auf ihren DNS-Servern verwendet. Hierdurch wird es möglich, die Antworten auf dubiose DNS-Anfragen gezielt zu blockieren oder umzuleiten – noch bevor der eigentliche Kontakt zu einem potenziell gefährlichen Zielsystem entsteht. Hat man Listen von solchen unseriösen Domainnamen, so kann man auf ihrer Grundlage entweder die Anfrage gar nicht beantworten oder modifizierte Antworten zurückliefern.
In Teil 1 haben wir bereits erwähnt, dass anfragende Clients mit lokal konfigurierten Caching DNS-Servern kommunizieren, um Informationen aus dem DNS zu beziehen. Entsprechend ist unsere DNS-Firewall dort implementiert. Versucht ein Client, der mit Schadsoftware infiziert ist, aus dem DNS Informationen über einen schädlichen Server zu erhalten, um diesen zu kontaktierten, greift an dieser Stelle die DNS-Firewall und prüft zunächst, ob der angefragte Name auf einer der erwähnten Listen steht. Falls ja, antwortet er so, als gäbe es die Domain gar nicht.
Steuerung durch Response Policy Zones (RPZ)
Bei dem von uns verwendeten DNS-Serverprodukt werden Listen von besonders zu behandelnden DNS-Einträgen über einen Mechanismus namens Response Policy Zones (RPZ) implementiert, bei dem diese Einträge in sogenannten Zonen-Dateien abgelegt werden. Die Einträge darin basieren auf DNS-Namen, auch mit der Möglichkeit von Wildcard-Schreibweisen. Ein solche Orientierung an Namen anstelle von IP-Adressen bietet den Vorteil deutlich besserer Granularität und Flexibilität. So kann bspw. bei Webhostern, bei denen eine große Zahl von Domainnamen auf dieselbe IP-Adresse verweist, gezielt das schädliche Web-Angebot blockiert werden, ohne alle anderen Webseiten an dieser Adresse unzugänglich zu machen. Auch gegen die erwähnten Command and Control Server ist dieser Mechanismus deswegen sehr wirksam.
Um den rasch wechselnden Bedrohungen zu begegnen, erfolgt die Aktualisierung des Datenbestandes der DNS-Firewall automatisch. Wir beziehen entsprechend gepflegter Listen negativ aufgefallener Domainnamen unter anderem vom deutschen DFN-Verein, vom schweizerischen Forschungs- und Bildungs-Netz SWITCH sowie vom Anbieter abuse.ch („ThreatFox“). Zusätzlich wird auch eine RWTH-eigene Liste gepflegt, die Vorrang vor den von Dritten bezogenen Daten hat. Diese dient einerseits dazu, die Reaktionszeit zwischen eigener Erkennung und dem Neutralisieren problematischer Anfragen möglichst kurz zu halten. Andererseits können wir sie verwenden, um das Verhalten der DNS-Firewall an lokale Anforderungen anzupassen.
Unterstützung bei Problemen mit blockierten Domains
Anfragen aus der Hochschule an die DNS-Server der RWTH werden also vor der Weiterleitung geprüft, und wenn die Domain aus Sicht der DNS-Firewall unbedenklich ist, gelangt die Antwort wie gewohnt zum anfragenden Gerät. Die normale Netznutzung soll auf diese Weise also nicht negativ beeinflusst werden, während zugleich Sicherheitsbedrohungen, die das DNS ausnutzen, begegnet wird.
Sollten einzelne DNS-Anfragen wider Erwarten nicht wie gewohnt funktionieren, könnt ihr euch über das IT-ServiceDesk an uns wenden. Der Änderungswunsch wird dann an die Fachabteilung weitergegeben.
Damit endet der zweite Teil unserer Blogreihe über das DNS. Freut euch auf weitere technische Beiträge aus dem Bereich der Datennetze.
Verantwortlich für den Inhalt dieses Artikels sind Bernd Kohler und Christoph Viethen.
Schreibe einen Kommentar