[DNS & DNS SECURITY] 1. DNS & DNS Security

Transkript

1 [DNS & DNS SECURITY] 1 DNS & DNS Security Thomas Vogel & Johannes Ernst Funktionsweise von DNS und deren Security Eigenschaften. Was es für Angriffe gibt, welche Gegenmaßnahmen dafür erforderlich sind und den Ausblick in die Zukunft. DNS & DNS Security

2 2 [DNS & DNS SECURITY] Inhaltsverzeichnis Was ist DNS?... 3 Wie Funktioniert DNS?... 3 Protokoll... 4 Schwachstellen... 4 Spam- Abwehr... 4 Angriffe auf das DNS Protokoll... 5 DDoS auf DNS... 5 DNS- Amplification- Angriff... 5 DNS- Cache Poisoning... 5 DNS- Spoofing... 6 DNSSEC als Gegenmaßname... 6

3 [DNS & DNS SECURITY] 3 Was ist DNS? Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Netzwerk/ Internet, dessen Hauptaufgabe die Durchführung von Anfragen zur Namensauflösung ist. Da sich IP- Adressen schlecht einprägen lassen, diese aber für eine korrekte Adressierung und Routing unerlässlich sind, werden einfacherer Namensadressen, sogenannte Hostnames vergeben. Die Aufgaben von DNS ist nun, diese Hostnames, z.b. der Hochschule Furtwangen (hs- furtwangen.de) in die IP- Adresse aufzulösen. Obwohl DNS eigentlich für das Internet entwickelt wurde, lässt es sich auch im lokalen IP- Netz einsetzen. Mit der Einführung von IPv6 und der damit längeren und schwerer zu merkenden IP- Adressen, wird DNS immer wichtiger. Wie Funktioniert DNS? Wird eine Anfrage auf eine Homepage, z.b. hs- furtwangen.de gestartet, wird zunächst überprüft ob hierzu schon einen Eintrag im lokalen DNS- Cache des Clients vorhanden ist. Falls nicht muss zunächst dieser die Adresse eines Name- Servers wissen, an den er seine initiale Anfrage richten kann. Diese könnte ein Root- Server sein, oder besser ein Server, der sich netztopologisch in der Nähe des Clients befindet, zum Beispiel ein vom Internet Service Provider eines Benutzers unterhaltener Name- Server oder ein Name- Server aus dem lokalen Intranet einer Firma. Es gibt zwei Möglichkeiten eine Anfrage zu starten, die Iterative und die Rekursive Vorgehensweise. Iterative Anfragen Hierbei fragt das System, das einen Namen auflösen möchte selber jeweils jeden im vorherigen Schritt ermittelten Server und gelangt über die Antworten schließlich zum zuständigen Name- Server, der bei einer letzten Anfrage die Adresse übermittelt. Hierbei kann es passieren, dass der Client viele Anfragen stellen muss. Rekursive Anfragen Bei einer rekursiven Anfrage erlaubt der Client einem Name- Server, an den er eine Anfrage richtet, dass dieser, falls er die Anfrage nicht direkt beantworten kann, selber den nächstzuständigen Server kontaktiert und diesem gegebenenfalls wieder ein rekursives Bearbeiten der Anfrage erlaubt. Der Lokale Nameserver gehört nicht zur Hierarchie der DNS- Server. Er kümmert sich um die Anfrage so lange, bis eine endgültige Antwort vorliegt, diese wird dann an den Client zurückgeschickt. Ist hier auch kein Eintrag im Cache vorhanden wird eine Anfrage an einen sogenannten Root- Server gestellt. Weltweit gibt es 13 Root- Server. Diese beantworten ausschließlich iterative Anfragen, da sie sonst mit der Anzahl der Anfragen schlicht überlastet wären. Der Rootserver leitet die Anfragen an den zuständigen Top- Level- Domain Server weiter. Ein Top- Level- Domain- Server ist verantwortlich für com, org, edu etc. sowie für alle Länder- Domains, z.b. de, uk, fr usw.. Dieser leitet die Anfrage auf den Zuständigen Autorativen DNS- Server weiter, welcher autorisierte Abbildungen der Namen dieser Organisation auf IP- Adressen anbietet. Die Antwort wird an den lokalen Nameserver weitergeleitet, dieser Cachet ihn und leitet ihn an den Client weiter.

4 4 [DNS & DNS SECURITY] Protokoll DNS ist auf der Anwendungsschicht des OSI- Schichtenmodells angeordnet. Deshalb nutzt es zur Übertragung TCP und UDP auf dem Port 53. In der Regel verwendet der Resolver das UDP- Protokoll. Wenn die Antwort größer als 512 Byte ist, werden nur 512 Byte übertragen. Anschließend muss der Resolver seine Anfrage noch mal über TCP wiederholen, damit die Antwort in mehrere Segmente aufgeteilt werden kann. Der Datenaustausch zwischen dem Primary und Secondary DNS- Server wird ausschließlich mit TCP geregelt. Schwachstellen Untersuchungen haben eine Entwurfsschwachstelle im DNS- Protokoll offenbart, die das Implantieren beliebiger Daten in den Cache von DNS- Resolvern sehr viel leichter ermöglicht, als bislang gedacht. Damit werden solche Angriffe wieder attraktiv, da sie wirtschaftlicher sind. Es gibt unterschiedlichste Angriffsszenarien deren Ziel es ist falsche Einträge in DNS- Resolvern zu platzieren. Auf die gängigsten Methoden wird später genauer eingegangen. Da DNS aus Gründen der Effizienz auf dem unzuverlässigen UDP basiert, sorgen Client und Server dafür, dass unbeantwortet Anfragen wiederholt werden. Unerwartete Antworten, dazu gehören auch Antworten auf Anfragen die schon empfangen wurden, werden einfach ignoriert. Wer einen autoritativen DNS- Server für seine eigenen Domains betreibt, muss natürlich für Anfragen von beliebigen IP- Adressen offen sein. Um zu verhindern, dass Internetteilnehmer diesen Server als allgemeinen Nameserver verwenden (z. B. für Angriffe auf Root- Server), erlaubt BIND es, die Antworten auf die eigenen Domains einzuschränken. Ein offener DNS- Server kann auch eine Falle sein, wenn er gefälschte IP- Adressen zurückgibt. Spam- Abwehr Zur Filterung von Spam- Mails überprüfen viele Mailserver routinemäßig mit Hilfe des DNS die Absenderadressen eingehender Mails. Als erster Schritt wird dabei der MX Record ermittelt. Aus der so erhaltenen IP- Adresse wird per reverse Lookup ein Name erfragt. Dieser muss mit dem ursprünglichen Absendernamen identisch sein, sonst wird die Mail verworfen. Ein Spammer ist dann nicht mehr in der Lage, beliebige Absenderadressen zu erfinden, sondern muss auf registrierte Domainnamen zurückgreifen.

5 [DNS & DNS SECURITY] 5 Angriffe auf das DNS Protokoll In der Regel zielt man bei Angriffen auf das DNS Protokoll darauf, dass entweder Seiten nicht mehr erreichbar sind oder um User auf gefälschte Seiten zu leiten, damit dort an kritische Daten zu gelangen oder den User zu infizieren. DDoS auf DNS Bei einer DDoS (Distributed- Denial- of- Service) Attacke werden unzählige Anrufe des Dienstes durch Clients erzeugt, bis dessen Kapazität erreicht ist und keine weiteren Anfragen mehr akzeptiert werden können. Der Dienst ist dann quasi nicht erreichbar. Das macht man sich bei einer DDoS Attacke auf einen DNS Server zu nutze. Es werden dabei jede Menge Anfragen an den Server gestellt bis dieser keine legitime Anfragen von Clients mehr beantworten kann. Sollte es für die auf dem DNS Server gehosteten Zonen keine weiteren Nameserver, für die Auflösung der Domain, zur Verfügung stehen oder aber auch diese per DDoS ausgelastet sein, ist die Webseite bzw. Domain nicht mehr erreichbar. Die Domain kann nicht mehr zu einer IP- Adresse umgesetzt werden kann. Für diesen Angriff gibt es keine konkrete Gegenmaßnahme, man kann die Dienste wie DNS nur per Cluster oder ähnliches ausbauen, dass auch DDoS Anfragen bearbeiten werden können. Darüber hinaus kann man die Anfragen pro Zeiteinheit ermitteln, diese auf IP- Adressen aufschlüsseln und diese schon am Transit oder Peering Port Null- Routen (Pakete nicht an den Server leiten sondern verwerfen) damit der Datenstrom an Anfragen nicht mehr auf die Server auftreffen. Sollte die Flut jedoch so groß sein, dass die Anbindungen überlastet sind hilft auch dieses nicht mehr. DNS- Amplification- Angriff Der DNS- Amplification- Angriff ist ein DoS Angriff der nicht auf den User selbst abzielen sondern um eine Internet Verbindung des Opfers zu blockieren. Dabei macht man sich zu nutzen, dass DNS Server bei kurzen Anfragen mit sehr langen und somit großen Rückantworten antworten. Dabei kann aus einer 60 Byte Anfrage eine 3000 Byte Antwort generierten werden und somit sein Angriff um den Faktor 50 vergrößert werden. Man lenkt nun den Datenstrom durch gefälschte Absender Adresse auf die IP des Opfers um, somit spart man sich den hohen Datenstrom und kann so auch seine IP- Adresse verschleiern. Ingress- Filter können als Gegenmaßnahme eingesetzt werden, dabei werden Pakete gefiltert die eine gefälschte IP- Adresse besitzen. DNS- Cache Poisoning Beim Cache Poisoning Angriff wird versucht bei einem Nameserver gefälschte Einträge in dessen Cache zu bringen. Damit dieser bei Anfragen mit diesen gefälschten Daten antwortet. Dabei stellt man eine Anfrage an den Nameserver für eine Zone die er selbst nicht verwaltet, dieser fragt nun die dazugehörigen Nameserver, der Angreifer sendet jedoch auf diese Anfrage direkt eine gefälschte Antwort mit der gefälschten Zone. Der

6 6 [DNS & DNS SECURITY] Nameserver speichert nun die Daten in seinem Cache. Dabei muss der Angreifer die 16 bittige Transaktionsnummer erraten, damit die Antwort angenommen wird, weshalb der Angriff mit viel Arbeit verbunden ist. Eine Erweiterung des Angriffs ist es auf korrekte Antworten von Anfragen des Nameservers noch weitere Zonen und dessen Daten mitzusenden. Der Nameserver erhält dann die korrekte Antwort, jedoch werden noch Zonen auf gefälschte IPs mitgeliefert die der Nameserver dann auch in seinem Cache speichert. Bei einer Anfrage eines Users werden diese nun auf die Webseite des Angreifers weitergeleitet. Seit 2008 gibt es ein Verfahren (Kollisionsangriff) um die Transaktionsnummer schneller zu erraten und wurde deshalb wieder sehr interessant. Als Gegenmaßnahme kann hier DNSSEC zur Einsatz kommen, der die DNS Zonen signiert und somit nicht mehr fälschen lassen. DNS- Spoofing Das DNS- Spoofing ist ähnlich wie DNS Poisoning, jedoch wird hier nicht der Cache angegriffen sondern die Antworten an den Client auf Anfragen gefälscht. Entweder nutzt man hier eine Man- in- the- Middle Attacke bei der der Angreifer direkt gefälschte Antwort auf eine DNS Querry gesendet wird oder man nutzt einen Trojaner der die Host File im Betriebssystem verändert um dort direkt die IP- Adressen auf Hostnamen zu hinterlegen. Auch gäbe es die Möglichkeit einen DNS Server über eine andere Lücke direkt zu übernehmen und dort die Zonenfiles anzupassen. DNSSEC als Gegenmaßname Um DNS Attacken zu verhindern wurde DNSSEC (RFC 2535) eingeführt. Dabei werden die Zonen auf dem Nameserver per asymmetrischem Hashing per Private Key signiert, der Client der die Antwort verifizieren möchte, kann per Öffentlichen Schlüssel die Antwort prüfen und sicherstellen das diese korrekt ist. Um das Schlüsselmanagement so klein wie möglich zu halten, kann der öffentliche Schlüssel an eine höhere angesiedelte Zonen per Vertrauenskette delegiert werden. Nachteil dieser Lösung ist es, dass DDoS Angriffe nicht verhindert werden können und durch eine Kompromittierung der Vertrauenskette auch wieder gefälschte Daten eingebracht werden können. Beispiel signierte Zone: