Was ist DNS

Ans Internet angeschlossene Computer adressieren sich gegenseitig mittels für Menschen mehr oder minder bedeutungslos scheinender Adressen wie z. B. 2a00:1328:e102:ccc0::122 oder 213.73.89.123. Um einfach merkbare Namen wie www.ccc.de in diese Maschinenadressen umzusetzen, wurde das Domain Name System geschaffen. Es handelt sich bei DNS um eine hierarchisch verteilte Datenbank. So ist z. B. für alle Namen die auf .de enden, die deutsche Genossenschaft DeNIC e.G. zuständig. Diese delegiert die Zuständigkeit für z. B. ccc.de an den Chaos Computer Club. Auf technischer Ebene erfolgt dies durch einen Datenbankeintrag bei der DeNIC, der für alle Internetteilnehmer einsehbar ist.

Wenn man einen der DNS-Server der DeNIC nach ccc.de fragt, antwortet dieser: "Liegt auf ns.ccc.de, und der hat die IP-Adresse 212.12.48.1". Der Server ns.ccc.de, also der mit der Adresse 212.12.48.1, betreibt eine ebensolche Datenbank, nur ist diese kleiner und enthält nur Einträge für Namen, die in .ccc.de enden. Wird dieser Server nun nach www.ccc.de gefragt, antwortet dieser mit: "Das liegt hier: 2a00:1328:e102:ccc0::122 oder hier: 213.73.89.123". Diese Antwort hilft nun z. B. dem Browser eines Besuchers von www.ccc.de, der eine Verbindung zum Server "2a00:1328:e102:ccc0::122" herstellen kann. Damit nun nicht jedesmal immer erst die DeNIC und dann der CCC-DNS-Server gefragt werden muss, gibt es – meist bei Providern, doch zu deren Zuverlässigkeit später mehr – DNS-Resolver. Ein DNS-Resolver macht nichts anderes, als Anfragen von Nutzern entgegen zu nehmen und im Hintergrund die oben genannten Schritte zu vollziehen. Er erspart zum einen den langen Weg, und speichert zum anderen die Ergebnisse für einen bestimmten Zeitraum zwischen, um sie später bei einer identischen Anfrage eines weiteren Nutzers schneller ausliefern zu können und keine Anfrage an die ranghöheren Server stellen zu müssen. DNS-Server spielen also eine zentrale Rolle in der täglichen Nutzung des Internets. Dies macht sie zu begehrten Zielen; sowohl für zensurfreudige Regierungen als auch für andere Bösewichte, die sie gerne zu Angriffen benutzen würden.

Geschichte der Netzsperren in Deutschland

Bereits 1996 forderte die Bundesanwaltschaft das Deutsche Forschungsnetz (DFN-Verein [1]) auf, eine Internetseite zu sperren. Durch die IP-Sperrung des niederländischen Providers XS4ALL wurden sämtliche dortigen Webseiten dem Zugriff aus deutschen Forschungseinrichtungen entzogen. Ab Anfang 2002 erzwang die Bezirksregierung Düsseldorf unter ihrem Regierungspräsidenten Büssow mittels einer Sperrverfügung die DNS-Sperrung von Webseiten bei dutzenden Zugangsanbietern. Der Chaos Computer Club verwies bereits damals auf die Gefahr für das Netz, die durch solche technischen Zensurmaßnahmen erwächst. Sobald eine technische Möglichkeit entwickelt wurde, wird sie nicht mehr nur dort und für den ursprünglichen Zweck benutzt, wie sich durch bei Wikileaks veröffentlichte Zensurlisten aus verschiedenen, auch nichtdemokratischen Staaten zeigte. Aus Sicht des Clubs sollen technische Infrastrukturen nicht durch gezielte Manipulation geschwächt werden. Neben politischen Forderungen hat der CCC daher durch Bereitstellung einer Vielzahl von technischen Mitteln an der Gewährleistung der Integrität und Vertraulichkeit informationstechnischer Systeme mitgewirkt. Beispiele hierfür sind der Betrieb von Knotenpunkten im Anonymisierungsnetzwerk Tor sowie eben jenes offenen DNS-Resolvers.

Was ist cache poisoning

Im konkreten Fall von dnscache.berlin.ccc.de wurde die Software dnscache [2] des US-amerikanischen Hochschullehrers Dan J. Bernstein [3] eingesetzt. Es handelt sich hierbei um eine sehr schlanke und sicherere Implementierung eines DNS-Resolvers. Bisher sind keine Schwachstellen bekannt geworden, die eine Kompromitierung des Servers erlauben, auf der sie läuft. Allerdings sind die in der DNS-Implementierung vorgesehenen Mechanismen, die vor einem sogenannten cache-poisoning-Angriff schützen sollen, nicht mehr zeitgemäß. Um erfolgreich einen gefälschten Eintrag zu platzieren, muss der Angreifer die zufällig vom Server ausgewählte Portnummer sowie die Transaktions-ID erraten. Bei einer einzelnen Anfrage ist dies sehr unwahrscheinlich, da es sich um eine Chance von 1 zu 2×10⁹ handelt. Diese wird bei dnscache jedoch erheblich reduziert, da mehrere parallele identische Anfragen möglich sind. Ein erfolgreicher Angriff ist unter realistischen Bedingungen in unter zwanzig Minuten mit einer Bandbreite von nur 10MBit/s realisierbar. [4] Gegenmaßnahmen, die einen solchen Angriff vereiteln, wurden leider nie in die von Dan J. Bernstein veröffentlichte Software eingearbeitet, sondern sind lediglich von anderen Autoren veröffentlicht worden [5].

Jedem dnscache-Betreiber sei die Verwendung dieser patches an dieser Stelle wärmstens ans Herz gelegt. Der CCC Berlin hat die Gelegenheit dazu genutzt, auf eine Neuentwicklung umzusteigen und setzt nunmehr die Software unbound[6] ein, die mit Unterstützung führender DNS-Infrastrukturbetreiber als Ersatz für die ursprüngliche DNS-Software BIND[7] geschaffen wurde und fortwährend weiterentwickelt wird. Sie bietet zeitgemäße und flexible Konfigurationsoptionen, insbesondere gegen verschiedene Angriffsmuster wie cache-poisoning und DNS-Verstärkte "Denial of Service"-Angriffe[8].

Solange DNS-Antworten nicht signiert[9] sind, ist es für den betroffenen Nameserver nicht ohne Weiteres möglich, echte von gefälschten Antworten zu unterscheiden. Jeder recursive resolving nameserver ist daher mehr oder weniger anfällig gegen diese Art des Angriffs. Es gibt durchaus Gegenmaßnahmen, die Angriffe auf das Protokoll – wie cache poisoning – erheblich erschweren, jedoch besteht auch hier mangels der Verifizierbarkeit der Antworten keine absolute Sicherheit. Ein Angreifer wird sich in jedem Fall vorher die Reichweite, also das Erfolgspotenzial seines Angriffs ansehen. Daher sind rege genutzte Resolver grundsätzlich attraktivere Ziele. Dem kann man letztenendes nur durch dezentralisierte Infrastruktur vorbeugen. Je dezentraler die Infrastruktur ist, desto schwieriger werden derlei Angriffe, da die Anzahl der Opfer eher begrenzt ist. Aufgrund der geltenden Rechtslage sind Anbieter von DNS-Diensten einerseits dazu verpflichtet, das Telekommunikationsgeheimnis zu wahren und dürfen keine Kenntnis der Begleitumstände nehmen, andererseits sind sie aufgrund des Providerprivilegs im Gegenzug auch nicht für die übermittelten Inhalte haftbar. In der Folge können lediglich statistische Anomalien zur Fehlererkennung benutzt werden.

Grundsätzlich zeigt sich hier die Stärke offener Protokolle und freier, quelloffener Software. Während in proprietären Umgebungen die Entdeckung von Sicherheitslücken schwierig ist, und die Hersteller oftmals Monate brauchen, um eine Produktrevision zu veröffentlichen, kann bei quelloffener Software eine Veränderung leichter und schneller eingebaut werden. Durch offen standardisierte und patentfreie Protokolle gibt es darüberhinaus Wettbewerb der Produkte und die Möglichkeit zur laufenden Modernisierung der Infrastrukturkomponenten.

Links und weiterführende Informationen

• [0] http://de.wikipedia.org/wiki/Sperrungen_von_Internetinhalten_in_Deutschland
• [1] http://www.dfn.de
• [2] http://cr.yp.to/djbdns/dnscache.html
• [3] https://en.wikipedia.org/wiki/Daniel_J._Bernstein
• [4] http://www.your.org/dnscache/djbdns.pdf
• [5] http://www.your.org/dnscache/
• [6] http://unbound.net/
• [7] http://en.wikipedia.org/wiki/BIND
• [8] http://en.wikipedia.org/wiki/Denial-of-service_attack#Reflected_.2F_Spoofed_attack
• [9] http://dnscurve.org/forgery.html