Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03343.jsonl.gz/1541

TIBER-EU Framework
Dominik Altermatt
Das Domain Name System (DNS) stellt heute eine der wichtigsten Dienste dar, um das Internet, wie wir es heute kennen und nutzen, zu ermöglichen. Im Prinzip ist DNS einfach erklärt: meist wird eine Analogie zu einem Telefonbuch (des Internets) gemacht. Möchte man eine bekannte Person anrufen, kennt aber deren Telefonnummer nicht, weil Zahlen schwieriger zu merken sind als der Name, konsultiert man ein Telefonbuch. Man sucht solange bis man den Namen gefunden hat und dahinter steht die entsprechende Telefonnummer. Nach dieser Analogie stellt der Name einer Person den Domainnamen dar, die IP Adresse die Telefonnummer und das Telefonbuch sodann das Domain Name System. Möchte man also www.scip.ch aufrufen, muss man die IP Adresse des zugrundeliegenden Netzwerkteilnehmers (der Webserver von www.scip.ch) in Erfahrungen bringen. Dazu erfragt sich das Betriebssystem die nötige IP Adresse über DNS. Eine grundsätzliche Einführung wie DNS funktioniert wird unter learndns.com rasch und gut erklärt.
Auf der technischen Ebene ist DNS komplex und eine Wissenschaft für sich. Man muss sich vorstellen, dass das DNS-System global in der Lage sein muss die aber Millionen Webseiten (2014 wurde die Milliardengrenze überschritten) zu indexieren und mit einer IP Adresse zu koppeln. So dass jeder Internetteilnehmer mit der korrekten IP Adresse versorgt werden kann, die er gerade benötigt. Diese Aufgabe bewältigt DNS mittels einer dezentralisierten und hierarchischen Struktur. Eine DNS-Anfrage geschieht über den Resolver oder auch Rekursive DNS-Server genannt. Dieser hat einige Domainnamen in seinem Cache, welcher er dem Requestor sogleich beantworten kann. Jene Domainnamen, die nicht im Cache eines Resolvers zwischengespeichert sind, werden anhand der hierarchischen Struktur von DNS aufgelöst. Der Resolver befragt einer der 13 Root-Name-Server. Dieser verweist an einen Name-Server, der die TLD (Top-Level-Domains) verwaltet, wie z.B.
.ch oder
.net. Die Bereiche eines Domainnamens zwischen den Punkten werden auch Zonen genannt, bei der Auflösung von www.scip.ch wird also der Root-Name-Server den Request an den Name-Server der Zone
ch. weiterleiten. Dieser wiederum kennt den Name-server der Zone
scip., welcher schlussendlich die IP-Adresse von www.scip.ch kennt, und diese dem Requestor als Antwort übermittelt.
Aus Sicht einer Unternehmung haben sich die Domainnamen zu einem wertvollen Gut entwickelt. Sei es der Internetauftritt zu Marketingzwecken oder konkrete Anwendungen wie Online-Shops. Von einer anderen Seite betrachtet kann man sich als Unternehmung die Fragen stellen: Wie können Kunden unser Produkt oder Marke finden oder unsere Dienstleistung nutzen, wenn sie dies nicht über das Internet und einer entsprechenden Domain Name Adresse tun? Mit der Beantwortung dieser Frage, sollte für viele Unternehmungen klarwerden, wie wichtig der Internetauftritt und insbesondre dessen Erreichbarkeit und somit auch DNS ist.
Eine weitere interessante Sichtweise stellt die Tatsache, dass eine Vertrauensbeziehung zwischen Kunden/Benutzer zu Domainnamen bestehen. Dabei können die Themen Online-Banking, E-Government oder E-Health genannt werden. Der Benutzer vertraut darauf, dass auch effektiv mit den Servern seiner Krankenkasse kommuniziert, wenn er sich z.B. auf www.MeineKrankenkasse.example einloggt, um vertrauliche Daten (z.B. Rückforderungsbelege, Diagnosen, etc.) hoch zu laden. Dabei helfen dem Benutzer nur die Eingabe des korrekten Domain Name und allenfalls das “Look and Feel” der Webseite, um zu verifizieren, dass er sich tatsächlich auf der echten Webseite seiner Krankenkasse befindet
Unter der obigen Betrachtung von DNS, respektive die Möglichkeiten seine Dienstleistungen über eine Domain Name im Internet einer breiten Öffentlichkeit zugänglich zu machen, muss der eigene Domainname als schützenswertes und wichtiges Gut einer Unternehmung erkannt werden. So kann dem Thema DNS auch eine ordentliche Berechtigung in den Risiko- und IT-Sicherheitsüberlegungen einen angemessenen Platz einnehmen. Man erkennt nun das Potential, welches rund um DNS für Angriffe und Betrüger liegt.
Im Folgenden werden eigne der gängigen Attacken und möglichen Mitigierungsmassnahmen rund um DNS vorgestellt.
Die Distributed Reflection DoS Attacke nutzt die Tatsache, dass sogenannte offene Resolver jedem eine Antwort geben, der ihm einen DNS-Anfrage sendet. So kann ein Angreifer viele DNS-Anfragen mit gespoofter IP-Adresse (mit jener des Angriffsziels) senden. Die Antworten des Resolvers gehen somit nicht an den ursprünglichen Requestor zurück, sondern an jene IP-Adresse, welche der Angreifer in dem gefälschten DNS-Anfrage vorgesehen hat. Hinzukommt, dass die Grösse der Request-Datenpakete an den Resolver wesentlich kleiner als die Antwort an das Angriffsziel sind, damit wird das Angriffsvolumen einer DoS-Attacke über den Zwischenschritt des Resolvers vervielfältigt. So spricht man bei diesem Angriff von einer reflected und amplified Angriffstechnik, da der Angriff über den Resolver reflektiert und verstärkt wird. Damit die Attacke effektiv wird, werden dazu die gespooften DNS-Anfragen nicht nur an einen sondern an viele offene Resolver gesendet, um die grösste mögliche Menge von DNS-Responses zu erzeugen, daher das distributed im Namen diese Attacke.
Das Ausmass einer DDoS Attacke via DNS kann Anhand des Vorfalls von 2013 bei Spamhouse nachvollzogen werden. Angreifer konnten unteranderem mittels DNS-Amplifikation mit 75Gbps die Server von Spamhouse fluten. Hierbei sei angemerkt, dass heute durch die IoT-Botnetze die Amplifikation etwas weniger Verwendung findet, da nun Millionen von IoT-Gräten als Botnetz zusammengeschlossen wurde und daher eine Amplifikation nicht mehr direkt von Nöten ist. In diesem Zusammenhang ist das IoT-Bonet Mirai zu nennen, welches Ende 2016 eine Wucht von über 620Gbps auf die Server ihrer Ziele richten konnte.
Als Unternehmen kann man solche DDoS-Attacken nicht direkt verhindern, jedoch können redundante Systeme und UTM-Firewalls das Risiko von DDoS-Attacken auf die eigenen am Internet exponierten Komponenten massgeblich minimieren. Dabei sollte ein solides Logging, Monitoring und sinnvolles Alerting der Aktivitäten am eigenen Perimeter vorhanden sein. Damit können IT-Administratoren angemessen und zeitnah auf solche Attacken reagieren, geeignet Massnahmen einleiten und wenn nötig Kunden, Partner und die Belegschaft informieren.
Die Natur dieser Attacke verlangt daher Massnahmen auf Seiten der DNS- und “Internet”- (ISPs) Betreiber. Diese können durch verschiedene Konfigurationsmassnahmen die Möglichkeit von DDoS-Attacken minimieren. Als erstes sollten natürlich die unnötigen Open Resolvers sicher konfiguriert werden. Wer einen DNS-Dienst für seine Unternehmen betreibt, muss diesen nicht Antworten lassen, wenn DNS-Anfragen von beliebigen Internetteilnehmern gestellt werden. Weiter können DNS-Betreiber auch RRL (Response Rate Limiting) einsetzen, welches in einigen der bekannten DNS-Software verfügbar ist. Mit dieser Konfiguration wird der DNS-Server angewiesen nur eine bestimmte Menge von identischen DNS-Antworten an einen IP-Adressbereich zu zulassen. Sobald das Limit überschritten wurde, verwirft der DNS-Server die weiteren identischen DNS-Antworten. Auch für die Wurzel dieser Attacke, die Möglichkeit DNS-Anfragen mit gespoofter IP Adresse abzusetzen, gib es bereits seit einiger Zeit Lösungsansätze. Eine Möglichkeit stellt dabei BCP38 dar, welche in RFC2827 beschrieben wird. Mit BCP38 soll verhindert werden, dass IP-Pakete mit gefälschter IP Adresse überhaupt das Internet “betreten” dürfen (Ingress Filtering).
Unter DNS-Hijacking versteht man, wenn ein Angreifer Domainnamen auf eine IP-Adresse seiner Wahl zeigen lassen kann. Damit ist es möglich Webseiten grundsätzlich unerreichbar zu machen oder Internetbenutzer auf spezifische gefälschte Webseiten zu leiten, um damit z.B. Informationen wie Zugangsdaten für Onlinebanking und dergleichen zu stehlen. Um einem Domainnamen eine falsche IP-Adresse zu zuweisen, gibt es unteranderem folgende Möglichkeiten:
Gelingt es einem Angreifer den Default DNS-Server-Eintrag auf einem Computer oder auf ein DNS-Server zu ändern, erlangt er damit die Kontrolle über alle DNS-Anfragen, die der Benutzer von diesem System stellt. Damit kann der Angreifer für jeden beliebigen Domainnamen festlegen auf welche IP Adresse dieser zeigen soll. Eine solche Manipulation erfolgt oft durch eine Infizierung einer Schadsoftware, die auf vielfältigen Wegen auf einem Computersystem installiert werden kann.
Um diesem Problem zu entgegnen, kann sichergestellt werden, dass Antivieren Programme mit den aktuellen Updates ausgestatte sind, adäquates Hardening auf den Systemen betrieben wird und Benutzer auf Cyber-Risiken sensibilisiert sind.
Beim DNS Cache Poisoning nutzt ein Angreifer den Zwischenspeicher der DNS-Server aus. Diese halten DNS-Einträge für eine definierte Zeit (Time-To-Live, TTL) in ihrem Cache. Dies geschieht aus Perfomancegründen, damit nicht jede einzelne DNS-Anfrage über die komplette DNS-Hierarchie aufgelöst werden muss. Nachdem die TTL abgelaufen ist, entsteht ein sehr kurzer Moment, in dem der besagte DNS-Server nicht mehr weiss, wie die IP-Adresszuweisung für eine bestimmte Domain lautet. Daher erfragt sich dieser DNS die entsprechende IP bei einem anderen DNS-Server. Ist der Angreifer nun in der Lage in der Zeit zwischen der DNS-Anfrage und der DNS-Antwort des besagten Servers eine gefälschte DNS-Antwort mit einer falscher IP-Adresszuweisung zu übermitteln, wird dieser Eintrag wieder im Cache des DNS-Servers abgelegt, so lange bis wiederum dessen TTL abgelaufen ist. Somit ist der Cache dieses DNS Server durch den gefälschten DNS-Eintrag vergiftet. Benutzer, die nun diesen DNS-Server nach der IP dieser Domain befragen, erhalten eine falsche IP-Adresse und landen so nicht auf Ihrem Ziel, sondern auf einem Server, der durch den Angreifer kontrolliert wird. Diese Technik funktioniert nur unter der Bedingung, dass die DNS-Requestor unter den involvierten DNS-Servern keine authentisierten DNS-Antworten benutzen.
Wurde der Cache eines DNS-Server vergiftet kann, auch eine Trickel-Down Effekt entstehen, da andere DNS-Server den gefälschten DNS-Eintrag übernehmen. Der gefälschte DNS-Eintrag kann so bis auf den Lokalen DNS-Cache von Computer und Netzwerkgeräten “sickern”.
Um das Risiko von Cache-Poisoning zu reduzieren, existieren unterschiedliche und sich ergänzende Massnahmen. Grundsätzlich sollte darauf geachtet werden, dass die eingesetzte DNS-Software auf den neusten Patchständen betrieben wird. Weiter können die DNS-Server so konfiguriert werden, dass diese strenge Vertrauensbeziehungen untereinander pflegen, um damit das Einschleusen von gefälschten DNS-Einträgen durch Angreifer zu erschweren. Dazu können die TTL-Werte niedrig gehalten und die Caches der lokalen Computer und Netzwerkkomponenten in regelmässigen Abständen gelöscht werden. Auch DNSSEC trägt dazu bei, das Risiko von Cache Poisoning zu minimieren. DNSSEC signiert die DNS-Informationen, damit verifiziert werden kann, dass dem Ursprung der DNS-Information vertraut werden kann. Schlussendlich kann damit verifiziert werden, dass eine IP-Adresse effektiv zum angefragten Domainnamen gehört und nicht durch einen Angreifer manipuliert wurde. Dies funktioniert jedoch nur dann, wenn die ganze Kette der Namesauflösung (von Root bis zur vollendeten Namensauflösung der Domain) mittels DNSSEC signiert wurde.
DNS-Tunneling ist keine Attacke auf DNS im klassischen Sinne. Da DNS für all jenen zu Verfügung stehen muss, welche Domainnamen auflösen wollen, ist DNS-Traffic (Port 53) auf vielen Firewalls zugelassen. Diese Tatsache können Angreifer nutzen, um in einem bereits infiltrierten Netzwerk Daten unbemerkt zu exfiltrieren oder Command & Control Callbacks abzusetzen. Eine weitere Anwendung von DNS-Tunneling ist das Umgehen von Captive Portal Angeboten (Internet Access gegen Bezahlung), z.B. in Hotels oder heutzutage auch bei WLAN-Angebot auf Flugreisen. Dabei kann die gewünschte Kommunikationsart, z.B. über TCP Pakte im DNS-Verkehr versteckt werden. Dazu lässt sich z.B. das Tool iodine verwenden.
Um Datenabfluss via DNS-Tunneling zu verhindern, ohne aber den DNS-Verkehr grundsätzlich zu blockieren, bieten sich verschiedenen Techniken an. Einerseits das Monitoring auf der Firewall auf ungewöhnliche DNS-Kommunikationen hin, z.B. eine hohe Menge an DNS-Paketen an denselben Empfänger oder die Analyse der DNS-Pakte auf Ihren Inhalt. Dies kann z.B. mit Deep Packet Inspection (DPI) bewerkstelligt werden, ist aber ressourcenintensiv. Weiter ist Blacklisting von unbekannten Empfängern, respektive Whitelisting von bekannten Empfänger eine Option. Wichtig dabei erscheint, dass bei ungewöhnlichem Verhalten umgehend die IT-Administratoren informiert werden bzw. die Firewalls bzw. IT-Security-Appliances mit entsprechenden Block-Regeln ausgestattet sind. Auch ist das Blockieren von DNS-Verkehr von internen Hosts zum Internet denkbar, dies bedingt aber den internen Betrieb eines lokalen DNS.
Die hier Beschrieben Risiken, Angriffstechniken und Massnahmen sind nur ein kleiner Auszug aus der Welt von DNS. Sicher ist, dass Unternehmen, welche ihr Geschäftsmodell vom Internet abhängig gemacht haben, sich mit der Thematik DNS-Sicherheit beschäftigen müssen. In den letzten Jahren scheint die Relevanz von DNS-Sicherheit zugenommen zuhaben. Grosse Enterprise Unternehmungen wissen schon länger um die Risiken rund um das DNS.
Aber auch die KMUs sollten die Risiken nicht unterschätzen und sich mit Ihren IT-Partner/Abteilungen über die Risiken, die durch DNS entstehen unterhalten. Dabei soll geklärt werden, ob und welche Abhängigkeiten ihr Geschäftsmodell zu DNS hat. Sind Abhängigkeiten vorhanden, z.B. wenn das Produkt ausschliesslich über das Internet vertrieben wird, mach es Sinn sich über den Zustand der Sicherheit des genutzten DNS zu informieren. Generell kann der Hoster angefragt werden, welche Techniken zum Schutz der Domain im Einsatz sind, aber auch den ISP welche Techniken zum Schutz von DNS-Cache-Poisoning und DDoS eingesetzt werden.
Werden eigene DNS-Server betrieben, sollte eine adäquates Hardening, regelmässige Softwareupdate des DNS-Server und eine sichere Konfiguration (Stichwort Open Resolver) zum Pflichtenheft gehören.
Unsere Spezialisten kontaktieren Sie gern!
Dominik Altermatt
Dominik Altermatt
Dominik Altermatt
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv