Domain Name Service

Übersicht

Anmerkung: In der Literatur finden Sie die Bezeichnungen Domain Name System und Domain Name Service. Im Grunde meinen beide einunddasselbe. Domain Name System bezeichnet genau genommen die Methode der Umsetzung von IP-Adressen in symbolische Namen. Die technische Umsetzung hingegegen, also alle Routinen zusammen genommen, die das System implementierten, formen einen Dienst - den Domain Name Service. Der Praktiker spricht also vom Service und der Theoretiker vom System.

Vorläufer des DNS

Zu Beginn der sechziger Jahre, als die USA und die damalige UdSSR sich mitten im Kalten Krieg befanden und das Internet (bzw. ARPAnet) als solches noch gar nicht existierte, gab das amerikanische Verteidigungsministerium (Department of Defense, DoD) den Auftrag, ein dezentrales, ausfallsicheres und technisch fortschrittliches Netzwerk zu entwickeln und zu implementieren, um die vermeintliche Bedrohung durch die UdSSR möglichst gering zu halten.

Einige der renommiertesten Universit舩en, Organisationen und Unternehmen arbeiteten an der Umsetzung und 1969 war es schließlich soweit. Vier Universitäts-Rechner in Kalifornien (University of California, Los Angeles, University of California Santa Barbara, Stanford Research Institute) und Utah (University of Utah) bildeten die Grundlage des neuen ARPAnets und konnten miteinander kommunizieren. In diesem Stadium der Entwicklung wurden die Informationen der verschiedenen Systeme noch in einer einzigen Datei, der »HOSTS.TXT«, verwaltet, von der alle angeschlossenen Systeme über identische Kopien verfügten. Diese Datei ist quasi ein Vorläufer der heutigen /etc/hosts-Datei.

Von der Idee und des dahinter steckenden Aufwandes war dies eine außerordentlich clevere und einfach zu handhabende Administrationsangelegenheit. Doch mit der Umstellung des Netzwerkprotokolle auf TCP/IP Mitte der siebziger Jahre stieg die Anzahl der zu verwaltenden Systeme immens an, womit die Aktualität der Datei »HOSTS.TXT« kaum mehr gewährleistet werden konnte und deren Umfang unpraktikable Ausmaße annahm. Der ursprüngliche Ansatz, eine dezentrale Verwaltung zu erschaffen, wurde aufgrund des benötigten Überblicks bei der Vergabe neuer Rechnernamen und -adressen »ad absurdum« geführt.

So war es unumgänglich, dass in den achtziger Jahren - die Anzahl der verbundenen Rechner betrug mittlerweile über 1000 - ein neues System, das Domain Name System (DNS), entwickelt und eingeführt wurde.

Ziele und Funktionen des DNS

Wie bereits erwähnt, übernimmt DNS die Aufgabe der Umwandlung von Internetnamen in numerische Internetadressen und umgekehrt. Diese Auflösung basiert auf der Verwendung des TCP/IP-Protokoll-Stacks. Hierbei wird jedem öffentlich zugänglichen System (Host, Router, Gateway, ...) eine eindeutige 32-Bit große binäre Zahl zugeordnet (IP-Adresse), über die es angesprochen werden kann. Zur Vereinfachung des Umgangs mit IP-Adressen werden diese in vier Oktetts unterteilt und in Form von durch Punkte getrennten Dezimalzahlen dargestellt (»11111111 11111111 11111111 11111111« »255.255.255.255«). Ein Oktett besitzt somit einen Werteumfang von 0..255 (2⁸ = 256). Seltener anzutreffen ist die hexadezimale Notation (»FF.FF.FF.FF«), wobei diese vorrangig beim Nachfolger des jetzigen IP-Adressformats angewandt wird (IPv6).

Da das menschliche Gehirn bekanntlich besser mit Namen als mit Zahlen umgehen kann, wird jeder dieser Adressen ein eindeutiger Namen zugeordnet. So lässt sich grundsätzlich mit der IP-Adresse »216.239.39.101« als auch mit dem Namen »www.google.de« die gleiche Web-Seite auf dem gleichen System erreichen. Da die Vermittlung im Internet aber einzig auf IP-Adressen basiert, ist bei Verwendung von symbolischen Rechnernamen vorab eine Adressauflösung durchzuführen.

Abbildung 1: DNS-Namensraum

Um diese Auflösung zu verstehen, sollten Sie den Aufbau des DNS-Namensraumes kennen (Abbildung 1). Ausgehend von einer Wurzel (root), die die Bezeichnung ».« trägt, sind die Domains in einer baumartigen Struktur organisiert. Die der Wurzel folgende Ebene umfasst die so genannten Top Level Domains (TLD's). Eine Ebene tiefer folgen die Subdomains, denen entweder unmittelbar die Rechnernamen folgen oder aber eine weitere Ebene lokaler Domains, unterhalb derer dann die Rechnernamen liegen.

Top-Level-Domains

Die Top-Level-Domains (TLD) gliedern sich in zwei Kategorien ein. Zur Kategorie der so genannten generischen TLD's zählen »org« (Non-Profit Organisationen), »mil« (militärische Einrichtungen), »com« (Kommerzielle Unternehmen), »edu« (Bildungseinrichtungen), »net« (Netzorganisationen) und »gov« (Regierungsbehden). Im Jahre 2000 erfuhren die generischen TLD's eine Erweiterung um »biz«, »info«, »coop«, »aero«, »name«, »pro« und »museum«. Die zweite Kategorie beinhaltet die länderspezifischen TLD's, wie bspw. »de« (Deutschland), »uk« (Grossbritannien), »aw« (Aruba), »cc« (Cocos Islands), »jp« (Japan) oder »ch« (Schweiz). Eine vollständige Liste aller TLD's wird von der Internet Assigned Numbers Authority (IANA), der Dachorganisation des Internets, verwaltet.

Die Abarbeitung eines Internetnamens, bspw. »www.linuxfibel.de«, erfolgt hierarchisch von rechts nach links, d.h. (vergleiche Abbildung 1) beginnend in der Wurzel führt der Zweig »de« (TLD) zum Zweig »linuxfibel« (registrierte Domain), der wiederum im Punkt »www« (Name eines Rechners der Domain »linuxfibel.de«) endet. Die Suche nach einem entsprechenden System erfolgt also stets baumabwärts beginnend im Root-Verzeichnis.

Korrekterweise müsste eine Domain immer mit einem abschliessenden Punkt, der das Root-Verzeichnis repräsentiert, geschrieben werden. Allerdings kann dies vernachlässigt werden, da inzwischen alle DNS-Werkzeuge hinreichend intelligent und tolerant sind, um trotzdem ein positives Ergebnis zurück zu melden. Bei einer Bind-Konfiguration wäre jedoch ein fehlender Punkt am Ende fatal, wie Sie später noch erfahren werden.

Forward- und Reverse-Lookup

Bei einer Namensauflösung wird i.d.R. das Äquivalent zu einem Internetnamen in Form einer Internetadresse, also eine Umsetzung von Namen nach Adresse, gesucht.

Abbildung 2: Auflösung der IP-Adresse eines Rechnernamens

Bedarf eine Anwendung der IP-Adresse zu einem Rechnernamen (»www.linuxfibel.de« vergleichen Sie das Beispiel in Abbildung 2), so übernimmt der so genannte Resolver, eine Sammlung von Funktionen aus der C-Bibliothek, die weitere Recherche. In typischen Konfigurationen wird der Resolver eines Clients (»sonne.galaxis.de«) zunächst die lokale Datei /etc/hosts nach entsprechenden Einträgen durchforsten. Wird er dort nicht fündig, reicht er die Anfrage an den zuständigen Nameserver weiter (in Abbildung 2 als »server.galaxis.de« bezeichnet). Jeder Nameserver verfügt über einen Cache, indem er die Daten der zuletzt recherchierten Anfragen eine Zeit lang zwischenspeichert. Erst wenn der lokale Nameserver die Adresse nicht in seinem Cache hat, beginnt der mit der Auflösung des Namens von $raquo;hinter her«. D.h. er fordert einen der Rootserver an (eine Liste solcher hält der Nameserver in einer Konfigurationsdatei), ihm die Adresse des für die Domain »de« zuständigen Nameservers mitzuteilen. An die gelieferte Adresse sendet er die folgende Anfrage nach der Adresses des für »linuxfibel.de« zuständigen Nameservers. Bei letzterem Server erhält er schließlich die gewünschte Informationen, die er sowohl in seinen Cache einträgt, als auch zum anfragenden Clientrechner weiterleitet.

Zur Auflösung in die Gegenrichtung (Adresse in Namen), das sogenannte Reverse Lookup, wurde eine neue Domain »in-addr.arpa« (Address and Routing Parameter Area domain) eingeführt. Unterhalb dieser speziellen Domain existieren 256 Subdomains (0..255). Insgesamt wiederholt sich diese Unterteilung viermal, bis die 32-Bit-Adresse vollständig dargestellt ist (Abbildung 3).

Abbildung 3: Reverse-Lookup mit Hilfe der Pseudodomain »in-addr.arpa«

Für das kommende IP-Adressformat IPv6 wurde die Domain »ip6.arpa« eingeführt, die nach einem ähnlichen Prinzip funktioniert, wie »in-addr.arpa« für IPv4 (offizielle Bezeichnung des IP für 32 Bit Adressen).

Anmerkung: Eine weitere Pseudodomain »e164.arpa« dient der Recherche von whois-Anfragen.

Unterschiede zwischen Domains und Zonen

Eine sehr wichtige Unterteilung in diesem Schema ist, um Verwirrungen auszuschlieﾟen, der Unterschied zwischen Domain und Zone. Leider ist dieser Unterschied nicht allzu groﾟ und daher auch nicht allzu offensichtlich, aber immerhin vorhanden. Eine Domain beinhaltet alle unter ihm liegenden Domains, Zonen und Systeme (Hosts), d.h. alle baumabw舐ts liegenden Verwaltungseinheiten gehen zu dieser Domain. Da dies aber keinerlei Sinn macht alles auf dieser Ebene zu verwalten, wurden sogenannte Zonen eingerichtet. Diese Zonen konnten nun an die verschiedenen Einrichtungen und Unternehmen abgegeben werden, die die Verwaltung bernehmen und neue Knoten zeitnaher und schneller einbinden konnten. Jede Zone ist in sich abgeschlossen und beinhaltet nur die Knoten, die direkt zu ihr gehen. Sollten weitere Unterteilungen benigt werden, so werden neue Zonen errichtet, die jedoch vlig unabh舅gig voneinander sind.

Abbildung 4: Zone und Domain

An dieser Stelle werden Namensserver (Nameserver) eingesetzt um die Verwaltung der Zonen zu bernehmen. Hierbei kann jedem Nameserver eine oder auch mehrere Zonen delegiert werden, fr die er zust舅dig ist. Man spricht auch von "Autorit舩" einer Zone.

Generell besitzt jede Zone einen prim舐en Nameserver ("primary Master", "Primary") und evtl. mehrere sekund舐e Nameserver ("secondary Master", "Secondary"), die die Zonendaten untereinander austauschen, um auf dem neuesten Stand zu bleiben.

Eine Domain ist also ein logischer Oberbegriff, der zwar im t臠lichen Sprachgebrauch sehr h舫fig verwendet wird, im DNS wird jedoch lediglich mit Zonen gearbeitet. Oftmals findet auch keinerlei Unterscheidung statt, so dass die beiden Begriffe 舍uivalent behandelt werden.

Die Bind-Software

Die Entstehungsgeschichte der Bind-Software

Die Entwicklung des Berkeley Internet Name Domain Pakets, kurz Bind, startete Anfang der achtziger Jahre an der University of Berkeley als Diplomarbeitsprojekt einiger Studenten und stand unter Aufsicht namhafter Organisationen wie Defense Advanced Research Projects Administration (DARPA) und der Computer Systems Research Group (CSRG). Letztere Organisation zeichnete für die Versionen bis einschließlich 4.8.3 verantwortlich.

Zwischen 1985 und 1987 widmeten sich vorrangig Angestellte von Digital Equipment Corporation (DEC) der weiteren Entwicklung von Bind. Unter Federführung von DEC erschienen die Versionen 4.9 und 4.9.1. Die Version 4.9.2 sponserte Vixie Enterprices; Paul Vixie wurde zum Chefarchitekten von Bind.

Ab 4.9.3 ging die Verantwortung an das 1993 gegründete Internet Software Consortium (ISC) über, das von nun an für die Entwicklung und den Vertrieb bis einschließlich Version 8.2 zuständig war. Diese Organisation bezog ihre Mittel hauptsächlich von Sponsoren, die allerdings über die Jahre hinweg immer weniger freigiebig wurden, so dass mit Version 9 die Verantwortung an das Unternehmen Nominum Inc. abgegeben wurde, das seither die Weiterentwicklung vorantreibt.

Mit dem Start seiner Entwicklung wurde Bind zum Quasi-Standard und ist nahezu mit DNS selbst gleichzusetzen. Dieser Marktführerschaft trägt sogar Microsoft Rechnung, indem sie eine NT-Version von Bind herausbrachten, die allerdings in der internationalen IT-Infrastruktur keine bedeutende Rolle spielt.

Überblick über die einzelnen Versionen und ihre Merkmale

Die Wechsel der Verantwortlichkeiten für die Entwicklung von Bind deckt sich stets mit entscheidenden Versionssprüngen. Jede dieser drei Hauptversionen beinhaltete grundlegende Änderungen und Erweiterungen.

Die 4er Versionen brachten den Durchbruch von Bind und setzten so den Startpunkt als de-facto-Standard. Fortan fehlte Bind in kaum einem der Unix-Systeme. Das Kernstück in Bind-4 bildete eine Datei namens »/etc/named.boot«, in der sich die Informationen über die Lage aller weiteren Konfigurationsdateien, die zum Betrieb notwendig waren, befanden. Dem Konzept der zentralen Datei ist Bind bis heute treu geblieben.

Funktionen wie Caching, d.h. das Vorhalten von Adressinformationen bereits aufgelöster Namen bzw. Adressen, Forwarding, dem Weiterleiten an bspw. dedizierte Nameserver, oder Query Logging, die Analyse getätigter Auflösevorgänge, wurden implementiert. Bind-4 brachte allerdings ebenso ein erhöhtes Sicherheitsrisiko mit sich, da etliche entscheidende Programmteile mit teils extremen Fehlern (Bugs) behaftet waren. Trotzt zahlreicher Nachbesserungen am Quellcode konnte Bind-4 nie seinen Ruf als potentielle Sicherheitslücke abwerfen und verschwand mit Erscheinen der Version 8 binnen kurzer Zeit von der Servern.

In der Version Bind-8 wurden weite Teile des Quellcodes neu- bzw. komplett umgeschrieben. Weiterhin kamen neue Funktionen hinzu, die heute nicht mehr wegzudenken sind, wie dynamische Updates, Benachrichtigungen der Slaveserver bei Änderungen, ACLs zur Zugriffskontrolle auf den Server, verbesserte Zonentransfers und Updates sowie eine verbesserte Performance. Das Sicherheitsrisiko sank durch die Neuprogrammierung enorm.

Die aktuellste Version ist Bind-9. Auch hier wurden Sicherheit und Stabilität zum obersten Gebot. Signaturen ermöglichen nun gesicherte Zonenzugriffe (DNS Security, DNSSEC); Transaction Signatures (TSIG) ermöglichen signierte DNS-Anfragen. Das IPv6-Protokoll wird in Bind-9 vollständig unterstätzt, indem es neue Ressource-Einträge implementiert (»A6«, »AAAA«, »DNAME«) und beide Schreibformate der 128-Bit-Adressen akzeptiert (»Nibble« [veraltet] und »Bitstring«). Zur effizienteren Arbeit können Zonen mit konkreten Views angelegt werden, womit Definitionen getrennter Zonen für Anfragen aus dem internen und dem externen Netz mlich sind. Derartige Zonen sind komplett voneinander abgeschottet und parallel auf einunddemselben System lauffähig. Als wesentliche Neuerung unterstützt Bind-9 nun Multiprozessorsysteme. Wie auch seine Vorgänger ist Bind-9 für alle verbreiteteten Plattformen verfügbar.

Die wichtigsten DNS/Bind-Programme (Bind-Utils) kurz beschrieben

Zu diesem Zeitpunkt sollen die verschiedenen Programme und Daemons nur kurz benannt und ihr Zweck erläutert werden. Weitere Informationen zu den administrativen Vertretern der Programme erhalten Sie im weiteren Text. Die Hilfsprogramme zum Zugriff auf Informationen des DNS werden im Zusammenhang mit dem DNS-Client diskutiert.

Dig

Dig (Domain Information Groper) ermöglicht die interaktive Befragung von DNS-Servern. Es vollzieht DNS-Recherchen und veranschaulicht die Antworten aller befragten Server. Dig ist somit vorallem zur Diagnose der DNS-Funktionalität nützlich.

Dnssec-keygen, dnssec-makekeyset, dnssec-signkey, dnssec-signzone

Host

Host ist ein weiteres DNS-Abfragewerkzeug. In der Voreinstellung begnügt es sich mit der Ausgabe eines Adresse zu einem gegebenen Rechnernamen bzw. umgekehrt. Verschiedene Optionen ermöglichen ähnlich komplexe Recherchen wie »dig«.

Lwresd

Named

Named-checkconf

Named-checkzone

Nslookup

Nslookup liegt Bind-9 nur noch aus Kompatibilitätsgründen bei. Es ist quasi die »alte« Version von »dig« mit ähnlichem Funktionsumfang aber auch anderem Bedienkonzept (es beinhaltet einen interaktiven Modus). Nslookup beherrscht nicht den Umgang mit Adressen nach IPv6.

Rndc

Sicherheit von Bind

Der Domain Name Service ist eine der Schlüsselkomponenten des Internets und folglich ein vorrangiges Ziel potentieller Angreifer. Bei der Komplexität der Software sind Fehler kaum auszuschließen und in jeder bisherigen BIND-Version wurden mehr oder weniger gravierende Schwachstellen aufgedeckt. Gerade als Administrator eines öffentlichen DNS-Servers sollten Sie deshalb gewissenhaft die in Mailinglisten diskutierten Sicherheitsthemen verfolgen und ggf. ihre Serversoftware auf den aktuellsten Stand halten.

Inwiefern die aktuelle Bind-Auflage Fehler beinhaltet, vermag niemand zu erraten. Aber die problematischsten Schwachstellen früherer Versionen sollen im nachfolgenden Text Erwähnung finden.

Erlangen von Root-Rechten

Das hhste der erreichbaren Ziele fr jeden Angreifer ist es, die UID 0 zu erhalten, d.h. Herr ber den root-Account zu werden. Wurde der root-Account erst einmal bernommen, kann das System zu allem missbraucht werden, ohne die Gegenmaﾟnahmen frchten zu mssen. Dieses Erlangen wird oftmals durch Fehler in der Software (Bugs) untersttzt, dass durch sogenannte Exploits ausgenutzt wird. Allerdings sind bei Bind9 bis dato noch keine Exploits bekannt, die fehlerhafte Codeteile ausnutzen knen, was auch sehr fr den Einsatz in unserer DMZ spricht. Bind4 und Bind8 dagegen waren, vor allem in der Frhphase ihrer Entwicklung, stark von Bugs betroffen und hatten immense Sicherheitsprobleme. Einer dieser Bugs soll hier einmal kurz exemplarisch dargestellt werden.

NXT-Bug: (Einstufung: critical)

Der NXT-Eintrag in den Konfigurationsfiles dient dazu, dass negative Antworten ber signierte Zonen die nicht vorhanden sind, trotzdem abgeschickt werden. Er gibt an, welches der n臘hst erreichbare Zonen-Name ist.

Ein Angreifer, der diesen Bug ausnutzt, muss die DNS-Datenbank ver舅dern und seinen Nameserver als Zonen-Autorit舩 einsetzen. Danach wird eine Anfrage auf die Zone des Angreifers gestartet, der nun die Auflung von sich selbst erh舁t. Wenn nun Bind versucht, die Abfrage abzuschlieﾟen, indem er eine Verbindung zu dieser Zone zu etablieren, ger舩 es in einen kritisch instabilen Zustand. Nun tritt der Exploit in Kraft und fhrt die folgenden Kommandos aus cd /; uname -a; pwd; id womit ein Buffer Overflow erreicht wurde, Bind abstrzt und der Angreifer eine Shell erh舁t, inklusive s舂tlicher Privilegien, mit denen Bind gestartet wurde (meist root).

Eine weiterer Bereich, in dem Schwachstellen auftreten knen, ist der administrative Bereich. Hier werden oftmals Konfigurationsfehler, wie zu geringe Zugangsbeschr舅kungen (Authentifizierung) oder falsche Zoneninformationen, in den Konfigurationsdateien gemacht meist lediglich zum debuggen, oftmals aber auch aus Unkenntnis oder Faulheit. Diese Schw臘hen knen leicht zum Verlust der Kontrolle oder der Daten des Systems fhren, werden jedoch durch die neuen Features wie ACL oder DNSSEC, die sp舩er noch ausfhrlich beschrieben werden, entsch舐ft.

Stillegen eines Nameservers

Ein weitere verbreitete Methode einen Nameserver zu attackieren, ist die Mlichkeit ihn durch sogenannte Denial-of-Service-Attacken (DoS) einfach stillzulegen damit er seine Zoneninformation, die er vorh舁t, nicht mehr weiterverbreiten kann. Als Folge davon kann es zu einem sehr groﾟen Chaos und Durcheinander kommen, da doch viele Anwendungen lediglich mit einer Namensauflung funktionieren bzw. diese zwingend benigen.

Insgesamt wird dem DNS-DoS weit weniger Aufmerksamkeit geschenkt, als dem bekannteren IP-Spoofing, mit dem Web-Server attackiert werden, was zur Folge hat, dass die Administratoren dieses Thema nur unzureichend ernst nehmen.

Umleiten einer Domain

Ein noch effektiveres Ergebnis wird durch die Umleitung von Domains erzielt. Hierbei legt der Angreifer in erster Linie kein destruktives Verhalten an den Tag, sondern will die F臧igkeit des bestehenden Nameservers und der Domain fr sich ausnutzen. Die Verluste, die dabei entstehen lassen sich teilweise nur sehr schlecht einsch舩zen, da meist ein Vertrauensbruch zwischen Kunde und Anbieter entsteht. Denn wer wird seine Daten oder Geld weiterhin an einen Anbieter weitergeben, der sich nicht mal selbst schtzen kann. Entgangene Gewinne in der Zeit der Umleitung und danach sind ebenfalls als ein groﾟer Verlust zu betrachten, der vor allem Anbieter betrifft, die ihr Geld mit Informationen oder Angeboten aus dem Internet verdienen, wie amazon.de, ebay oder auch booxtra.

Mit Cache Poisoning versucht der Angreifer den bestehenden Puffer-Cache infolge von Zusatzinformationen dahingehend umzuleiten, dass ein Besucher nicht mehr die richtige IP-Adresse zurckgeliefert bekommt, sondern die neue (falsche) Adresse. Diese neuen Informationen erhalten auﾟerdem einen sehr langen Lebenszeit-Eintrag (Time To Live, TTL), da Bind jeden Eintrag erst nach Ablauf der TTL aus seinem Cache verbannt und somit Falschinformationen lang in Umlauf sind.

Beim Response Spoofing (Query-ID-Prediction) erfolgt die Manipulation auf der Paketebene. ﾄhnlich eines TCP/IP-Handshackes wird in den Paketen eine 16-Bit-ID mitgesendet, die oftmals sequentiell erht wird. Hierbei wird versucht bei einer Kommunikation diese ID vorherzusagen und vor der eigentlichen Antwort eine gef舁schte Nachricht zu senden. Die eigentliche Antwort wird bei Eintreffen sofort ignoriert und verworfen, da die ID nicht mehr korrekt, bzw. nicht mehr zuordenbar ist.

Bei der Man-in-the-Middle-Attacke setzt der Angreifer ebenfalls eine Falschinformation bei einem Nameserver ein und bekommt nun alle Anfragen zu dieser bestimmten Adresse weitergeleitet. Da dies generell jedem Anwender auffallen wrde, wenn er an einem anderen Punkt herauskommt als erwartet, leitet der Angreifer die Anfrage an das ursprngliche Ziel weiter und arbeitet nun als Vermittler. Warum aber der Aufwand? Gesetzt der Fall, dass das Ziel eine Bank oder ein Anbieter ist, das heikle Daten erwartet, bspw. PINs, TANs oder Kreditkartennummern, wrde der Angreifer alle diese Daten zu Gesicht bekommen, abspeichern und weiterleiten. Der Anwender bekommt von dieser Zwischenspeicherung berhaupt nichts mit, denn er bekommt nur sein erwartetes Login oder seine gltige Verifikation zu sehen. Alles was dazwischen geschehen ist, bleibt ihm weitestgehend verborgen.

Abbildung 5: Man-in-the-Middle-Attacke

Eine strikte Trennung zwischen den einzelnen Angriffszielen ist nicht mlich, da es oft ein Mix aus allen mlichen Varianten ist. Generell l舖st sich sagen, dass zwar Bind9 viele Sicherheitsrisiken durch seine Features ausger舫mt hat, aber bei rein destruktiven Angriffen auf Hardware (siehe DoS) dennoch keine Chancen hat.

Standard-Konfigurationen von Bind

Die vorliegenden Beispiele basieren auf der derzeit (September 2002) aktuellesten Bind-Version 9.2.1. Des Weiteren erfordert die Unterstützung für DNSSEC die Installation von OpenSSL > 0.9.5. Alle Pfadangaben beziehen sich somit auf eine Standardinstallation, d.h. die Datei »named.conf« liegt in »/etc« und die Programme rund um Bind in den Verzeichnissen »/usr/local/bin« bzw. »/usr/local/sbin«.

Die Datei »/etc/named.conf«

Zentraler Anaufpunkt einer jeden Bind-Konfiguration ist die Datei »/etc/named.conf«. Sie enthält die frei wählbaren Namen der Dateien mit den eigentlichen Datenbankeinträgen. Des Weiteren umfasst sie u.a. Steuerdaten, wie Protokollierung, Zugangsbeschränkungen, Schlüssel- und Zonendefinitionen oder Startoptionen für den Bind-Daemon »named«.

Vorerst begnügen wir uns mit einer relativ einfach aufgebauten Datei »named.conf«, anhand derer die Schritte zu einem funktionierenden Nameserver demonstriert werden. Im Verlauf des Abschnitts werden Sie mit etlichen weitergehenden Möglichkeiten der Konfiguration in dieser Datei konfrontiert werden.

In dieser kleinen Beispielkonfiguration sieht man, dass der Nameserver, der diese Datei verarbeitet, fr die Zone zoneA.de als Master fungiert, d.h. er der prim舐e Ansprechpartner anderen zur Verfgung steht und das alle ﾄnderungen von ihm ausgehen. Der Parameter file beschreibt den Pfad, in dem die Zoneninformationen in verschiedene listenartigen ASCII-Dateien abgelegt werden. Dies ist nicht notwendigerweise zwingend, jedoch bei zunehmender Anzahl zu verwaltender Zonen, wrden sonst alle Listen im definierten Root-Verzeichnis eingestellt. Es dient lediglich zur bersichtlichen Haltung der Daten. Bspw. kann der Administrator bei einem manuellen Zonentransfer der Einfachheit halber alle Listen im Verzeichnis rev/slave und slave lchen, ohne vorher berprfen zu mssen, welche Zonen sich dahinter verbergen.

Zus舩zlich zu diesen Daten fehlt noch der Eintrag fr den Localhost (127.0.0.1) und die Root-Dateien. Der Localhost ist normalerweise immer sein eigener Master-Nameserver kann aber auch als Slave von anderen fungieren, da diese Informationen stets die gleichen sein mssten. Sicherer ist es, wenn eine Master-Zonendatei lokal vorgehalten wird, da bei einem Ausfall der Localhost nicht mehr angesprochen werden kann.

Die Root-Datei beinhaltet die Adressen aller Root-Server. Dies ist notwendig, wenn der Nameserver sie Anfrage nicht auflen kann und, wie in Abbildung 2 zu sehen ist, ganz oben in der Hierarchie beginnen muss, nach dem Ergebnis zu suchen. Diese Datei ist allerdings bei einem Forwarding nicht erforderlich, da alle unbekannten Abfragen immer an den Forwarder weitergeleitet werden. Eine aktuelle Version dieser Datei kann beim Internic bezogen werden.

Die Root-Zone

Der zentrale Punkt des DNS-Namensraums ist die Wurzel. Vermag ein Nameserver eine Anfrage nicht selbst aufzulösen, beginnt er mit der Suche nach dem Ergebnis ganz oben in der Hierarchie, also bei einem Nameserver, der die Root-Zone verwaltet (Vergleichen Sie auch Abbildung 2). Dessen Adresse muss jeder Nameserver zwingend kennen. Deshalb liegt jedem Bind-Paket eine Datei bei, die die Liste der Root-Server enthält. Die Adressen der Root-Server werden i.d.R. niemals geändert, sodass Sie von der Aktualität der Liste ausgehen können.

Die lokale Zone

Zonendefinitionen der zu verwaltenden Zonen

In den Zonendefinitionen selbst werden die einzelnen Systeme auf Adressen abgebildet.

Neu seit Bind8.2 ist der Eintrag TTL. In frheren Versionen wurde diese Option an anderer Stelle aufgefhrt, aber seit der Verfentlichung von RFC 2308 musste die TTL-Anweisung an einem anderen Ort angegeben werden und hierfr wurde die erste Zeile gew臧lt. Dieser Wert gibt an, wie lange ein abfragender Nameserver die Daten in seinem Cache halten darf, bevor er die Daten aus dem Cache wieder entfernt.

Der zweite wichtige Eintrag ist der SOA ( Start of Authority )-Eintrag. In dieser Zeile stehen die Zone, die Klasse, der Ressource Record selbst, die Autorit舩 der Zone und den Ansprechpartner (Mailadresse auf der Autorit舩) bei Problemen.

Zus舩zlich zu diesen Angaben beinhaltet dieser SOA-Eintrag noch einige Steuerdaten, wie Seriennummer, Aktualisierung oder Zeitpunkt der Ungltigkeit, wobei der wichtigste die Seriennummer darstellt, wie im n臘hsten Kapitel noch beschrieben wird.

Nachfolgend wird die Abbildung der Namen und Adressen vorgenommen. Die NS-Records geben den Namen aller Nameserver an, die mit der Zone etwas zu tun haben, die A-Records sind eine einfache Abbildung von Namen auf IP-Adressen, Mailserver-Eintr臠e (MX) und CNAME-Records ( canonical names ) sind Aliase auf bereits beschriebene Namen, womit es mlich ist, ein System mit mehreren Namen anzusprechen.

Die andere wichtige Datei fr eine Zone ist die in-addr.arpa -Datei, mit der das Reverse-Lookup ermlicht wird. Hier auch ein kurzer Auszug mit den wichtigsten Informationen und Eintr臠en.

Die ersten beiden Zeilen haben dieselbe Bedeutung wie in der db.zoneA -Datei und drfen auch hier nicht fehlen. Da diese Datei fr das Reverse-Lookup zust舅dig ist werden hier mit Pointer-Records (PTR) von Adressen auf Namen verwiesen. Dabei wird die IP-Adresse in umgekehrter Form inklusive der Domain in-addr und Arpa angeben (Vgl. Abbildung 4 und 5), da die Auflung, gleich der Auflung von Namen, von rechts nach links erfolgt.

Wichtig bei beiden Dateien ist der Punkt hinter den Adress- und Namensangaben . Dieser Punkt symbolisiert die Wurzel (Root), von der alles ausgeht. Wird dieser Punkt nicht angegeben, so hat dies fatale Folgen, denn Bind interpretiert alle Angaben ohne Punkt als relativ und h舅gt den Zonennamen an. Als Beispiel hier ein Systemeintrag:

Dieser Name wird durch den fehlenden Punkt am Ende als server1.zoneA.de.zoneA.de. gesetzt und der Nameserver reagiert auch nur auf diesen Namen, d.h. er kennt das System server1 berhaupt nicht. Alternativ dazu gibt es die Mlichkeit den Punkt wegzulassen.

In diesem Fall wird richtigerweise an den Namen server1, die Zone .zoneA.de. angeh舅gt. Sind diese beiden Zonen-Dateien auf dem Server vorhanden, so kann das System bereits alle Anfragen zu der verwalteten Zone beantworten.

Um nicht in jede Konfigurations-Datei immer dieselben gleichbleibenden Daten, wie MX-Eintr臠e, SOA-Eintr臠e oder Steuerdaten, eintragen zu mssen, werden diese oft in Dateien auﾟerhalb abgelegt und per INCLUDE-Anweisung in diese Konfigurationsdateien eingefgt. Der Vorteil dieser Vorgehensweise ist vor allem bei ﾄnderungen an diesen Daten zu spren. Sollte sich der SOA-Eintrag 舅dern oder ein zus舩zlicher MX-Record dazukommen muss der Neueintrag lediglich in einer, anstelle von 300 Dateien vorgenommen werden.

Master- und Secondaryzonen

Im vorhergehenden Kapitel ging es rein um die Master-Dateien auf einem Server. Ein System, das als Master fr eine Zone fungiert muss die beiden gerade genannten Dateien vorhalten und den Slave-Servern (falls vorhanden) zur Verfgung stellen. Der Slave-Server erkennt durch die Eintr臠e in der /etc/named.conf fr welche Zonen er Daten und von welchem Server er diese abrufen muss, d.h. auf ihm werden diese beiden Dateien keinesfalls erstellt. Schon allein aus Redundanz- und Fehlergrnden werden die Dateien einmal erstellt (Master) und bei Bedarf transferiert (Slave), so minimiert sich die Pflege erheblich. Dies bedeutet auch, dass beide Zoneninformationsdateien, sowohl auf dem Master- als auch auf dem Slave-Nameserver, vollkommen identisch sind und beide dieselben Records beinhalten [Vgl. G].

Der Slave-Nameserver wird auch nicht bei jeden Aufruf einen Transfer initiieren, sondern lediglich, wenn die TTL ausl舫ft, die Zonendaten aus dem Cache entfernt oder sich die Seriennummer erht. Nun wird auch der Sinn der Seriennummer deutlich. Der Administrator muss bei jeder ﾄnderung die Seriennummer erhen. ﾜberprft nun der Slave-Nameserver die Zonendateien und stellt fest, dass sich die Seriennummer erht hat, initiiert er sofort einen Transfer und bringt seinen Informationsbestand auf den neuesten Stand. Schneller geht es durch die Option notify. Hierbei versendet der Master-DNS eine Benachrichtigung an alle Slave-Nameserver, damit ein Update durchgefhrt werden kann.

Nameserver-Start

Startoptionen von named...

Erweiterte Konfigurationen

Caching und Forwarding

Jedem Nameserver stet ein Cache zur Verfgung, in dem er alle bereits get舩igten Abfragen hinterlegt. Dies dient in erster Linie zum schnelleren Bearbeitung von Anfragen, denn wenn das Ergebnis bereits im Cache vorhanden ist, wird sofort geantwortet und andere Nameserver werden auﾟen vor gelassen. Dies geschieht so lange, bis der Cache entweder gelcht oder veraltet ist (TTL). Erst dann wird wieder der Weg ber andere (evtl. Root-Server) gew臧lt. Eine besondere Form dieses Caches ist ein Cache-Only-DNS. Dieser Cache-Only-DNS stellt seinerseits keine Anfragen, sondern leitet erhaltene Anfragen lediglich weiter und speichert die erhaltenen Ergebnisse. In dieser Konfiguration beschr舅kt sich die /etc/named.conf nur auf das nigste an Optionen. Die wichtigste Option stellt das Forwarding dar.

Beim Forwarding werden die Anfragen exakt an die in den Optionen angegebenen Nameserver weitergegeben. Diese Forwarder sind meist gut dimensionierte Nameserver grerer Firmen bzw. Provider, die ber eine hohe Bandbreite auf die Root-Server zugreifen knen. Mit dem Forwarding wird auch die eigene Vorhaltung der Root-Server-Datei hinf舁lig, da alles ber diese Forwarder l舫ft. Eine weitere versch舐fte Form eines Forward-DNS ist die Option forward only. Bei dieser Betriebsart leitet der Nameserver ebenfalls alle Anfragen weiter, jedoch verl舖st er sich 100%-ig auf die Forward-DNS. Sollte der Forward-DNS kein Ergebnis oder eine Timeout zurckliefern, kontaktiert unser Nameserver keinen weiteren externen Nameserver, sondern vertraut dem Ergebnis des Forward-DNS. Allerdings bleiben die internen Zonen von diesem Forwarding unbetroffen, d.h. wenn Auflungsanfragen ber eine Zone deren Autorit舩 (Master oder Slave) er ist, ankommen, beantwortet er diese natrlich.

Weiterfhrende Sicherheitsfunktionen und Schutzmechanismen

Diese grundlegenden Konfigurationen ermlichen zwar einen Betrieb des Nameservers, jedoch gibt es unter Bind9 noch einige weitere fortgeschrittene Funktionen, die ein sichereres und differenzierteres Arbeiten und Administrieren ermlichen. Die Entwicklung dieser Funktionen zielt in erster Linie in Richtung Sicherheit mit kryptografischen Elementen oder Zugangsbeschr舅kungen ab und genau diese Features und Funktionen werden in unserem Konzept benigt um etwas hardening [Vgl. Anhang A Hardening] durchzufhren.

chroot Die abgesicherte Umgebung

Beim chroot ( change root ) handelt es sich um eine geschtzte Arbeitsumgebung fr Bind. Es wird, 臧nlich wie bei FTP- oder HTTP-Servern, eine passende Dateistruktur in einem geschtzten Bereich aufgebaut, eine Art Gef舅gnis , bei dem /chroot als Root-Verzeichnis fungiert. Als weitere Sicherheitsmassnahme wird in diesem Zusammenhang auch noch der Besitzer des Daemons, meist root, auf einen ungef臧rlicheren User gesetzt. Dies geschieht aus dem Grunde, falls ein Angreifer jemals die Kontrolle ber den Nameserver, bspw. wie beschrieben durch Buffer Overflows, erlangt, so besitzt er sofort die Rechte, des Users, der den Daemon gestartet hat. Wenn dieser Fall eintritt, findet sich der Angreifer als unterprivilegierter User in einem eingeschr舅kten Bereich wieder, was doch sehr schnell das Interesse sinken l舖st.

Oftmals wird dieser geschtzte Bereich auch noch auf ein zus舩zliches Filesystem ausgelagert, um bei einer eventuellen DoS-Attacke das eigentliche System nicht der Gefahr auszusetzen, einen Reboot machen zu mssen. Hier kann beim Erkennen, sofort das Filesystem abgeh舅gt werden und das Betriebssystem bleibt weitestgehend unbeeindruckt davon. Da /chroot nun als Wurzelverzeichnis dient, sind andere Verzeichnisse nicht sichtbar und deshalb auch nicht erreichbar.

Aus diesem Grund mssen einige Dateien manuell in dieses Gef舅gnis kopiert werden, damit ein Betrieb mlich ist. Bei Bind9 sind es nur noch wenige Dateien, wie die Konfigurationsdatei /etc/named.conf und natrlich alle bereits angelegten Zoneninformationsdateien. Eine genauere Dokumentation ist im Anhang D zu finden.

ACL - Zugriffslisten

Ein weitverbreitetes Feature von Bind sind die ACLs ( access control list ). Bei diesen ACLs wird unter einem Arbeits- oder symbolischen Name, Systeme mit gleichen Berechtigungen oder Eigenschaften zusammengefasst, die sp舩er unter diesem Namen angesprochen werden. Diese Zusammenfassung wird Address-Match List genannt.

Neben der eigenen Vergabe noch ACLs gibt es noch einige vorgegebene Schlsselwerte wie all (alle Systeme), none (kein System), localhost (alle internen Interfaces) und localnets (alle Netze, zu denen der Server ein direktes Interface besitzt).

Mit Hilfe dieser ACLs knen nun die Berechtigungen sehr feinknig definiert werden.

In diesem Beispiel sind alle vier mlichen Berechtigungen kurz aufgefhrt, die fr die Zone zoneA.de gelten. Sollen diese Berechtigungen global gelten, so mssen sie unter die option -Option gestellt werden, da alle dort gemachten Einstellungen fr s舂tliche folgenden Zonen Gltigkeit besitzen.

Views - DNS Split

Der n臘hste Schritt, nachdem die ACLs definiert sind, ist eine Aufteilung in Sichten (Views). Dies bedeutet, verschiedene Systeme bekommen bestimmte zugeteilte Zoneninformationen zu sehen, andere jedoch nicht. Besonders in einer DMZ ist dies sehr hilfreich, da einerseits externe Nameserver und Clients aus dem Internet, als auch interne Systeme auf einige Zonen zugreifen drfen, die nicht unbedingt die gleichen sein mssen.. Bei dieser Konstellation ist es nicht fderlich, wenn die interne Struktur von auﾟen einsehbar ist. Gerade aus diesem Grund drfen externen Anfragern lediglich die fentlichen Zoneninformationen zur Verfgung stehen. Vor Bind9 wurde dieses Problem durch eine Aufteilung auf 2 Nameserver gelt, wobei der eine fr interne Zonen und der andere fr externe Abfragen zust舅dig war. Nun, da dies mit internen Funktionen mlich ist, knen gezielt Szenarien aufgebaut werden, die einen weiteren Schutzmechanismus bilden.

Die Option match-clients gibt an, fr welche Systeme berhaupt die nachfolgenden Zonen zug舅glich, bzw. sichtbar sind. Zur besseren Verwaltbarkeit sind diese meist als ACL angegeben. Der nun folgenden Rest ist 舍uivalent zu den bereits in vorigen Kapiteln beschriebenen Zonendefinitionen. Vorsichtig sollte der Administrator bei der Rangfolge sein, denn eine ANY-Zusage zu Beginn der Definition kann sp舩er nicht mehr zurckgenommen werden. Aus diesem Grunde werden zuerst beschr舅kten Zugriffe definiert, damit auf diese Zonen auch wirklich nur ausgew臧lte Systeme zugreifen knen und erst danach wird der Nameserver fr alle anderen gefnet.

Ligthweight-Resolver

Laufzeitkonfiguration und Diagnose

Laufzeitkonfiguration mit Rndc

Rndc (Remote Name Daemon Control) ist ein Administrationstool, das dem Administrator eine Eingriffsmlichkeit bietet mit der Befehlszeile den Daemon zu steuern. Es ist die Weiterentwicklung des Tools ndc, dass mit Bind8 zur Verfgung stand, um auch ber ein bestehendes TCP-Netz die Kontrolle zu behalten. Mit ihm knen Befehle wie Neuladen von Konfigurationsdateien oder Zonen (reload), Laden von neuen oder ver舅derten Zoneninformationen (reconfig), Statistiken (stats), Erstellen von Cache-Dumps (dumpdb), Stoppen nach gesicherten Ver舅derungen (stop), sofortiger Stop ohne Sicherung (halt), Erhen des Debug-Levels (trace), Leeren des Caches (flush) oder Anzeigen des Status des Nameservers (status).

Die Sicherheit der Netzadministration wird durch einen signierten Schlssel gew臧rleistet, der mit einigen anderen Angaben in einer Steuerungsdatei namens /etc/rndc.conf steht.

Diagnose

named-checkconf

named-checkzone