Erst kürzlich konnte sich das Domain Name System, kurz DNS, über das 25-jährige Bestehen freuen. Das mit den RFCs 882 und 883 von Jon Postel, Paul Mockapetris und Craig Partridge ersonnene Protokoll hat in der Praxis bis heute nahezu unverändert überdauert. War es im Vorläufer des heutigen Internets, dem ARPAnet, noch üblich, die IP-Adressen über eine lokale Datei auf Namen abzubilden (die dann in diversen Ausprägungen ausgetauscht wurden), zeigte sich spätestens 1983 –  nicht zuletzt durch das enorme Anwachsen bzw. die Zusammenschlüsse verschiedenster wissenschaftlicher und kommerzieller Netze –, dass ein globales Namenssystem unabdingbar war. Den Weg dafür hat im Grunde erst der Umstieg auf die wesentlich besser für weltumspannende, verteile Netzwerke skalierende Protokollsuite TCP/IP bereitet, die zu diesem Zeitpunkt eingeführt wurde.

Um zentralistische Konstruktionen zu vermeiden, hat das DNS einen hierarchischen, verteilten Charakter. Weiters sollten Namensabfragen das Internet insgesamt und die beteiligten Rechner möglichst schonen. Daher war das Protokoll auf das verbindungslose datagramm-basierende User Datagram Protocol (UDP) zugeschnitten. Etwaige Verschlüsselungsansätze zur Sicherung des Inhalts oder der Sicherstellung der Authentizität beteiligter Partner sucht man im ursprünglichen Ansatz vergeblich. Trotz aller Protokolleffizienz sind Caching-Verfahren auf den bei Abfragen beteiligten Nameservern unvermeidlich, machen aber das System umso effektiver. Die eigentlichen Teilnehmer eines Netzwerks wie das Internet, seien es Arbeitsplatzrechner oder Server für Applikationen, Mailservice etc. sind hier als so genannte Clients die Nutznießer des Systems. Lediglich eine IP-Adresse eines Nameservers (der Redundanz geschuldet sind es oft mehrere) reicht aus, um am weltumspannenden Namenssystem teilnehmen zu können.

Diente das Namensservice bis Ende der 90er Jahre vornehmlich dazu, Rechnernamen (Hostnamen) und E-MailAdressen aufzulösen (sowie auch umgekehrt, um von einer IP-Adresse auf einen Hostnamen zu kommen), ersann man auch die Verwendung des Systems für gänzlich andere Zwecke, die ihren Ursprung im Themenkomplex E-Mail und Spam haben. Dabei wird nicht nach der zu einem Namen gehörenden IP-Adresse gefragt, sondern die Existenz des entsprechenden Eintrags gibt hier die entsprechende Auskunft. Dieser Weg bietet sich an, da DNS-Abfragen verhältnismäßig wenig „kosten“. Dazu „kodiert“ man den Abfragewert in einen Pseudo-Domainnamen, dessen Auflösung via DNS dann das gewünschte Ergebnis liefert.

Eine Abfrage, ob die IP-Adresse 100.99.1.1 z. B. auf der RBL+ Blacklist eingetragen ist,  wird auf den abzufragenden Domainnamen 1.1.99.100.rbl-plus.mail-abuse.org abgebildet. Die Abfrage ist positiv, wenn der Eintrag (die retournierte IP-Adresse – meist eine 127.x.x.x Variante – klassifiziert gegebenenfalls das Ergebnis weiter) existiert. Auf diese Art lassen sich nicht nur IPv4-Adressen sondern auch IPv6-Adressen oder auch die Domain- oder Hostnamen aus Webadressen, wie sie in Spam-Mails verstreut werden, einkodieren, abfragen und bewerten.

Eine weitere Entwicklung ist die Internationalisierung von Domainnamen, die auf Unicode aufgebaut sind, wodurch z. B. Umlaute in Domainnamen möglich sind. Die hierzu verwendete spezielle Kodierung (Punycode) nutzt die bisherige DNS-Infrastruktur ohne irgendeine Anpassung. Lediglich die an der Kommunikation beteiligten Partner (z. B. Browser und Webserver) müssen dieser Kodierung gewahr sein und die Domainnamen entsprechend „umgestalten“.

Eine neuere Adaptierung des DNS der moderneren Art ist die Telefonnummernauflösung (ENUM), um die im Internet erreichbaren Gerätschaften für typischerweise Voice over IP -Dienste adressieren zu können.

Die einfache und effiziente Gestaltung des DNS-Protokolls geht aber auch mit etlichen Schwachstellen einher, die auch im Laufe der letzten Jahre bei den am DNS beteiligten Software-Produkten aber auch am Protokoll selbst heftige Diskussionen hervorgerufen haben. Sicherheitsrelevante Vorkommnisse haben jedoch nie das System insgesamt wesentlich in Bedrängnis gebracht. In Anbetracht der möglichen Folgen für einen großflächigen oder totalen Ausfall der Namensauflösung im Internet (aus lokaler Sicht haben viele sicher die ein oder andere unangenehme Situation erfahren) hat sich das System erstaunlich robust gezeigt.

Die bislang bedeutsamsten Probleme fallen in die beiden Klassen

• Cache-Poisoning
• Spoofing

Beide Klassen zielen darauf ab, einem Nameserver bösartig modifizierte Antworten unterzuschieben oder zusätzliche (bösartige) Informationen mit legitimen Antworten „mitzuliefern“. Im betroffenen Nameserver landen diese „Veränderungen“ schlussendlich im Cache, welcher dann derart „vergiftet“ ist, dass die infolge stattfindenden Abfragen von Clients (die aus dem Cache bedient werden) auf völlig andere Ziele umgelenkt werden. Dies ist eine typische Variante,  wie sie kaum idealer als Grundlage für „Phishing“-Angriffe Verwendung finden kann, der ein Benutzer praktisch hilflos und völlig in Unwissenheit bleibend ausgeliefert ist.

Verbesserungen verspricht langfristig nur das kryptographisch gesicherte DNSSec-Verfahren als Erweiterung zum bestehenden DNS-Protokoll. Das funktioniert aber nur flächendeckend und ist leider in der Umsetzung und Akzeptanz weit hinter den Erwartungen zurück. Zwischenzeitlich behilft man sich mit immer neuen Detailverbesserungen, die Angriffe zwar erschweren, aber nicht völlig abwenden können.

Typisch ist das neueste Angriffsszenario, das in Sicherheitskreisen seit 9. Juli 2008 für Furore gesorgt hat (wird in weiterer Folge auch im Detail behandelt). Dank immer größerer verfügbarer Bandbreiten sind „brute-force“ Angriffe (sowohl von außerhalb, speziell aber auch von „intern“) machbar und zielen darauf ab, einer legitimen Antwort zu einer Anfrage zuvor zu kommen, indem mit einer großen Anzahl von möglichen Antwortvariationen versucht wird, eine passende Anwort zu erraten. Erreicht die eigentliche Antwort den unter „Beschuss“ stehenden Nameserver zu spät (auch da gibt es Tricks, die Antwort etwas aufzuhalten), kann die untergeschobene Antwort beliebige Nameservice-Daten manipulieren, die dann vorübergehend im Cache liegend an alle anfragenden Clients ausgeliefert werden.

Wesentliche Punkte sind die Redundanz, Stabilität und Skalierbarkeit. Für die TU-interne Sicht stehen bekanntlich zwei Nameserver (tunamea/b) zur Verfügung. Hinter diesen verbergen sich jeweils mehrere Rechner, die einen redundanten Verbund bilden. Bei dieser Konstruktion „verstecken“ sich (derzeit) zwei Server hinter einer der beiden bekannten IP-Adressen für die Nameserver. So können im Desasterfall bis zu zwei Server ausfallen, ohne dass Clients hiervon etwas davon bemerken (schlimmstenfalls in der Antwortzeit, sollte sich die Last auf den verbliebenen Servern allzu sehr konzentrieren). Die Leistung der Nameserver kann problemlos und für Benutzer transparent durch Hinzufügen von weiteren Servern zu jedem Verbund einfach erhöht werden.

Erst kürzlich machten sich im TUNET Unregelmäßigkeiten im DNS-Service bemerkbar. Auslöser war die am 9. Juli 2008 veröffentlichte Schwachstelle in den verschiedensten Serverimplementierungen, unter anderem auch in der an der TU Wien eingesetzten ISC Bind Software. Hier zeigte sich, dass die infolge veröffentlichten Korrekturen und Anpassungen in einer Software trotz bester Absicht ins Negative umschlagen können. Das Zusammenwirken von mehreren Faktoren hat in Kombination dann zu beträchtlichen und vor allem merkbaren Einbußen bzw. Störungen im Nameservice geführt. Die Auswirkungen waren dabei vielfältig und offenbarten sich nicht immer gleich als typisches DNS-Problem: An die TU Wien gerichtete E-Mails verzögerten sich, wurden leider sogar fallweise abgewiesen, weil plötzlich Namen von Mailzielen über andere Wege (welche nicht verwendet werden sollten) aufgelöst wurden und sich daraus keine brauchbaren Weiterleitungen ergaben. Web-Surfen innerhalb des TUNET wurde zur Geduldprobe, obgleich kein Bandbreitenengpass im Netzwerk vorlag.

Alles nahm seinen Ausgangspunkt in der Änderung des Modus, wie eine Namensauflösung erfolgt (mit dem eigentlichen Zweck, es einem Angreifer möglichst schwer zu machen, korrekte Antwortpakete zu erraten und einzuschleusen). Abfragen werden dann intensiver und in jedem Teilschritt der rekursiven Namensauflösung abgewandelt, dass ein Erraten statistisch möglichst unwahrscheinlich wird. Der Nebeneffekt davon war, dass Limits an den diversen Firewalls der TU Wien, die die Nameserver und die Rechner am TUNET vor allerlei Ungemach aus dem Internet schützen, auch diesen aufs Vielfache angewachsenen DNS-Verkehr einschränkten – mit fatalen Folgen für den Auflösungsprozess: Anfragepakete wurden von den Firewalls verworfen, die DNS-Server erhielten keine Antworten und versuchten, alternative Nameserver zu kontaktieren, was noch mehr neue Abfragen produzierte und die Firewall noch weiter an die künstlich gesetzten Grenzwerte drängte. Verschärft wurde diese Abfragesituation dann noch durch betriebssystemspezifische Limits, die die plötzlich viel höheren gleichzeitig aktiven Abfragen nicht mehr im vollen Umfang akzeptierten. Die Nameserver erstickten förmlich in ihren eigens produzierten Abfragen und konnten sich – einmal in diese Situation gekommen – wie ein festgefahrenes Auto im Schlammloch nicht mehr alleine aus der Situation befreien. Manchmal war die Situation auch so grenzwertig, dass zu einem mehr oder weniger unvorhergesehenen Zeitpunkt die Situation vom Normalbetrieb in eine kritische Phase „kippte“.

Ein Beispiel: Aus der Sicht der zentralen Mailserver (diese sind wegen der Vielzahl von Blacklist/Whitelist-Überprüfungen, SPF-Checks, MX-Auflösung, IP-Hostnamenauflösung im Zuge der Anti-Spam-Maßnahmen quasi die Hauptquelle des DNS-Datenverkehrs) erzeugte die schlichte Abfrage des Domainnamens, beispielsweise qmail.de (im Überlastfall, bei leerem Cache), eine Flut von 850 Paketen, wovon knapp 800 verloren gingen und nur rund 50 Pakete davon fanden als Antwort (großteils verspätet) den Weg zurück. Im Normalfall produziert eine solche Abfrage (bei leerem Cache) rund 200 Pakete (wobei 100 abgehende und 100 eingehende Pakete auftreten, sofern kein Paket verloren geht). Ähnliche Abfragen (in der gleichen Hierarchie) benötigen dann in Folge nur noch wenige Pakete (da die Zwischeninformationen bereits im Cache lagern). Bedenkt man, dass mit jeder eingehenden und akzeptieren E-Mail rund 20 bis 30 Namen aufgelöst werden, verwundert der Umfang des DNS-Verkehrs nicht mehr weiter.

Nicht nur die Analyse und das Erfassen der Problematik waren für uns zeitraubend, auch war eine Reihe von Experimenten notwendig, um für eine ausgewogene Kon- stellation bei den Parametern für Firewalls und Nameserversoftware zu sorgen und trotzdem ein gewisses Maß an Sicherheit zu gewährleisten bzw. das Missbrauchspotenzial (von außerhalb des TUNET, aber auch von innerhalb) sinnvoll einzuschränken. Diese neue Qualität des Anspruchs erforderte zudem die Umstellung des gesamten tunamea/b Nameserver-Verbundes auf eine neue, leis-tungsfähigere Hardware.

ISC (Internet Systems Consortium) musste selbst feststellen, dass es Performance-Probleme in ihrer Software gab und hat dann im Laufe der Wochen nach und nach in der Bind-Software (Nameserver-Software) nachgebessert. Von unsere Seite waren immer wieder aufwändige Tests notwendig, die aktuelle Software zu kompilieren, zu prüfen (auf Solaris und Linux), wo die Betriebssystemlimits waren, ob auf der jeweils aktuellen Hardware die Lastverhältnisse akzeptabel blieben. Dabei war die Nameserver-installation auf 12 bis 14 Servern anzupassen/zu ersetzen.

Dass diese oder ähnliche Vorkommnisse nicht weltumspannend zu Problemen führten, ist vermutlich der im Grunde saloppen und auch normalerweise risikoreichen uneingeschränkten Behandlung von UDP-Verkehr zu verdanken (nicht aber an der TU Wien, aus anderer leidvoller Erfahrung durch Attacken). Hinzu kommt, dass hier nur solche Nameserver betroffen waren, die normalerweise isoliert agierend ein rekursives Namensservice für Clients anbieten. Jene Nameserver, die entlang der hierarchischen Auflösung eines Domainnamens aktiv sind, sind hier passiv (nicht rekursiv) und von der ganzen Problematik praktisch nicht betroffen. Bildlich dargelegt: Das Geäst des DNS-Baumes war so gesehen immun und lediglich in manchen Blättern raschelte es mehr oder weniger.

Im Kreis der Benutzer-Authentifizierung spielt DNS oftmals eine wesentliche Rolle. Nicht selten wird eine IP-Adresse auf den zugehörigen Namen abgebildet, um dann erneut zu überprüfen, ob tatsächlich der Name auch wieder die ursprüngliche IP-Adresse liefert. Solche Maßnahmen setzt man oft und gerne bei Webmasken ein, die der Authentifizierung dienen. Zum einen kann man so gleich von vornherein einige unliebsame Quellen (eventuell Robots, die Webangebote „abgrasen“) fernhalten. Andererseits hat man eine gewisse Sicherheit hinsichtlich des verbindenden Hostnamens, wenn dieser in das Authentifizierungsschema einfließt und deswegen eine gewisse Zuverlässigkeit aufweisen sollte. Als typischer Vertreter sei hier das ZID Authentifizierungsservice/-portal genannt (siehe auch Seite ). Hier offenbart sich aber auch gleich ein neuer Problemkreis, der seinen Ursprung in diversen Inkonsistenzerscheinungen im Nameservice fremder Provider haben kann. Typische Fälle sind, dass die Nameserver eines Providers nicht synchron sind, wie z. B.

• eine IP Adresse löst einmal auf, ein anderes mal nicht
• eine IP Adresse löst auf unterschiedliche Namen auf

Vom Fehlerbild schlägt dies leider bis zu den internen Nameservern der TU Wien durch, die diesen wackeligen Datenstand weitergereicht bekommen. Nicht selten entsteht dabei der Eindruck, es wären die TU Nameserver, die inkonsistente Daten aufweisen. Dies liegt aber schlicht daran, dass die TU Nameserver (bei Daten, für die sie nicht zuständig sind, üblicherweise tuwien.ac.at-fremde Domainnamen) jeweils einen separaten Cache besitzen, dessen Einträge zu unterschiedlichen Zeitpunkten eingetragen, von unterschiedlichen Nameservern geliefert werden und wieder zeitlich versetzt aus dem Cache herausfallen. D. h. also, dass zwei Abfragen an tunamea oder tunameb auch zwei verschiedene Antworten liefern können, ohne dafür verantwortlich zu sein.

Es bleibt im Grunde nur, sich dieser technischen Feinheiten bewusst zu sein und gegebenenfalls den verantwortlichen Nameservice-Provider auf die Inkonsistenzen in dessen Nameservice hinzuweisen (und auf eine Korrektur zu hoffen). Als technische Maßnahme hinsichtlich Webprogrammierung bleibt einem nur die IP-Adresse als zuverlässige Information.

Die Umstellung auf die neuen IP-Adressen der TU-internen Nameserver tunamea/b ist ja schon seit längerem im Gange. Die Abschaltung des Nameservices auf den alten Nameserver-IP-Adressen zeichnet sich bereits ab und dessen Verwendung wird aktiv verfolgt, um die betroffenen Organisationseinheiten in der termingerechten Umstellung zu begleiten.

RFC 882, RFC 883. http://www.ietf.org/

Where wizards stay up late: the origins of the internet, Katie Hafner, Matthew Lyon, 1996

Verbesserungen im Nameservice, Johann Haider, ZIDline 17, Dezember 2007, http://www.zid.tuwien.ac.at/zidline/zl17/nameservice/

ZID Authentifizierungsservice:  http://www.zid.tuwien.ac.at/sts/dateninfrastruktur/authentifizierungsservice/