DNS-Sicherheit im Rahmen eines IT-Grundschutz-Bausteins

Transkript

1 DNS-Sicherheit im Rahmen eines IT-Grundschutz-Bausteins Thomas Ledermüller B A C H E L O R A R B E I T Nr. xxx-xxx-xxx-x eingereicht am Fachhochschul-Bachelorstudiengang Computer- und Mediensicherheit in Hagenberg im Jänner 2009

2 Diese Arbeit entstand im Rahmen des Gegenstands Sicherheitsmanagement 4 im Wintersemester 2008/09 Betreuer: Dieter Vymazal, MSc ii

3 Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe. Hagenberg, am 7. März 2009 Thomas Ledermüller iii

4 Inhaltsverzeichnis Erklärung Kurzfassung Abstract iii vi vii 1 Einleitung 1 2 Technische Grundlagen zu DNS Eingliederung im Protokollstack Domainstruktur Nameserver Resolver Funktionsweise Kommunikation Anwendung - DNS Nameserver Synchronisation Nameserver und Resolver gleichzeitig Standardimplementierung eines Resolvers Resource Records DNS Messages HEADER DNS Query DNS Reply Reverse Mapping Gefährdungen Organisatorische/Technische Gefährdungen Fehlende/unzureichende Planung des DNS-Einsatzes Fehler bei der Domainbeantragung und -verwaltung Fehler bei der Erstellung der Domain-Informationen Unsichere Konfiguration von Nameservern Vorsätzliche Handlungen Denial-of-Service - DNS Flooding Bogus Nameserver iv

5 Inhaltsverzeichnis v DNS Spoofing - ID Prediction DNS Hijacking DNS-Amplification-Angriff DNS Information Leakage Ausnutzen dynamischer Updates Angriffe auf verwendete Nameserver-Version Sicherheitsmaßnahmen Organisatorische Maßnahmen Auswahl der Nameserver-Software Planung der DNS-Infrastruktur Schulungsmaßnahmen Leistungskapazität Technische Maßnahmen Verbergen der Nameserver-Version Nameserver mit eingeschränkten Rechten Absichern von Queries Ausschließen von Bogus-Nameserver Blackhole TSIG Absichern von Zonentransfers Absichern von dynamischen Updates DNSSEC IT-Grundschutz-Baustein BSI Aufbau Aufgaben IT-Grundschutz Entwicklung Ansatz BSI-Standards zur IT-Sicherheit IT-Grundschutz-Kataloge Zertifizierung DNS Baustein Gefährdungen Maßnahmen Zuordnung Conclusio 64 Literaturverzeichnis 66

6 Kurzfassung Um mit einem Rechner in einem Computernetz anhand seines Namens zu kommunizieren, muss im Hintergrund zuerst die entsprechende IP-Adresse gefunden werden, damit dieser adressiert werden kann. Das Mapping funktioniert auch in die umgekehrte Richtung. Realisiert wird diese Funktionalität durch den Domain Name Service (DNS). Für Namensauflösungen in lokalen Netzen, vor allem aber im Internet, wird dieser Dienst genutzt und stellt somit eine zentrale Rolle dar. Bei einem Ausfall von DNS ist die Kommunikation in Netzen nur noch eingeschränkt durchführbar. Es besteht auch die Möglichkeit, durch gezieltes Angreifen von Nameservern, deren Verfügbarkeit einzuschränken bzw. die Domain-Informationen zu manipulieren. Einige dieser Attacken sind: DNS Spoofing, Cache Poisoning, unerlaubte Zonentransfers und (Distributed)- Denial-of-Service-Attacken. Neben durchdachter Planung und sorgfältiger Konfiguration kann ein Nameserver zusätzlich durch DNS-Erweiterungen wie TSIG, zur sicheren Durchführung von Zonentransfers, und DNSSEC, zur Sicherstellung der Datenintegrität, abgesichert werden. Aufgrund der Wichtigkeit von DNS werden die aus der Bachelorarbeit gewonnenen Informationen in einem IT-Grundschutz-Baustein aufbereitet. Die IT-Grundschutzkataloge des Bundesamts für Sicherheit in der Informationstechnik Deutschland (BSI) sind modular in Form von Bausteinen aufgebaut und beschäftigen sich mit Themen der IT-Sicherheit. Der Baustein bietet eine Einleitung in das Thema, bespricht die Gefährdungen und anschließend die Absicherungsmaßnahmen. Die Maßnahmen werden in die Schutzbedarfskategorien eingeteilt und den Gefährdungen gegenübergestellt. Anhand der Maßnahmenkataloge der Bausteine können Firmen ihr IT-Sicherheitsniveau laut IT-Grundschutz zertifizieren lassen. vi

7 Abstract To communicate with a computer within a computer network by using its name, the corresponding IP address has to be found in order to address the PC. This mapping also works the other way around. The functionality is realized through the Domain Name Service (DNS). For name resolutions in a local network as well as on the Internet, this service is used. Therefore DNS constitutes a central functionality in a computer network. In the case of a DNS failure, the communication within a computer network only works rudimentarily. But there is also the possibility to attack a name server in order to minimize its availability or to manipulate the data. Some of these attacks are: DNS spoofing, cache poisoning, illegal zone transfers and (distributed) denial-of-service attacks. Hardening a name server can be done by planning the name server infrastructure properly and by implementing secure configurations. In addition, DNS extensions like TSIG and DNSSEC ensure zone transfers and guarantee data integrity. Due to the importance of DNS, the gathered information will be prepared as a "Baustein" for the "IT-Grundschutz" of the "Bundesamt für Sicherheit in der Informationstechnik Deutschland (BSI)". The "IT-Grundschutzkataloge" of the BSI are designed modularly and have IT security themes as topics. The "Baustein" gives an introduction to the topic and provides information about the threats and the corresponding security measures. The measures are separated into security requirement categories and are contrasted with the threats. Meeting the requirements of the measures from the "Bausteine" is necessary for a company wanting to obtain the "IT- Grundschutz" certificate. vii

8 Kapitel 1 Einleitung Der Schutz der eigenen IT-Infrastruktur ist für Unternehmen von grundlegender Bedeutung. Als Basis für ein IT-Sicherheitskonzept können die IT- Grundschutzkataloge des Bundesministeriums für Sicherheit in der Informationstechnik Deutschland (BSI) verwendet werden. Der Aufbau der IT- Grundschutzkataloge ist streng modular in Form von Bausteinen, welche ein spezifisches Thema aus dem Bereich der IT-Sicherheit behandeln. Für den Domain Name Service (DNS), einer der grundlegenden Dienste heutiger IT- Infrastrukturen, ist noch kein Baustein vorhanden. Um einen Computer in einem Netz über seinen Namen adressieren zu können, muss es einen Dienst geben, der die entsprechende IP-Adresse [22] findet, da in IP-Netzen nur über diese adressiert wird. Diese Funktionalität stellt DNS zur Verfügung. Es können Domainnamen in IP-Adressen und umgekehrt aufgelöst werden. Im Weiteren wird DNS dazu benötigt, um Mailserver und Nameserver im Domain-Namensraum automatisiert zu finden. Bei einem Ausfall von DNS ist die Netzkommunikation nur mehr eingeschränkt möglich. Des Weiteren besteht die Möglichkeit, durch Manipulieren von DNS-Einträgen, die Namensauflösung gezielt zu beeinflussen, um somit ein Netz und indirekt dessen Systeme anzugreifen. Ziel dieses Dokuments ist es, die technischen Grundlagen zu DNS, relevante Angriffsmethoden und deren Abwehr zu erarbeiten. Anschließend werden die gesammelten Informationen in Form eines Bausteins für das BSI aufbereitet. Der Baustein beschreibt die relevanten Gefährdungen und erläutert geeignete Maßnahmen zur Absicherung von DNS. Dieser kann danach im Rahmen des IT-Grundschutzes von Unternehmen genutzt werden, um die eigene Sicherheit zu bewerten und bei Lücken entsprechende Maßnahmen zu treffen. Durch die Anzahl der umgesetzten Maßnahmen laut Baustein wird das IT-Sicherheitsniveau eines Unternehmens messbar und zertifizierbar. Im heutigen Geschäftsleben sind dies höchst relevante Punkte. Vor allem die Zertifizierung ist von großem Interesse, da damit gegenüber Kunden, Lieferanten und Konkurrenten ein festgelegtes Sicherheitsniveau nachgewiesen 1

9 1. Einleitung 2 wird. Als Einstieg in die Thematik werden in Kapitel zwei die notwendigen Grundlagen zu DNS beschrieben. Neben den grundlegenden Bestandteilen von DNS (dem Domain-Namensraum, den Nameservern und den Resolvern) wird die Funktionsweise und der Kommunikationsablauf im Detail dargestellt. In Kapitel drei werden die elementaren und für den IT-Grundschutz relevanten Angriffe behandelt. Dabei wird zwischen organisatorischen, technischen Gefährdungen und vorsätzlichen Handlungen unterschieden. Darauf folgend werden in Kapitel vier die entsprechenden Gegenmaßnahmen besprochen. Dieses Kapitel stellt zusammen mit Kapitel fünf das Kernelement der Arbeit dar. Für den IT-Grundschutz sind die Gefährdungen und Schwachstellen von Interesse, das Hauptaugenmerk liegt aber auf deren Behebung. Im fünften Kapitel wird zunächst der IT-Grundschutz und dessen Methodik näher vorgestellt. Der Baustein wird aufgrund der Kapitel zwei-vier erstellt und als eigene Dokumentensammlung verfasst. Im Anschluss werden die wesentlichen Punkte in diesem Kapitel dargestellt. Im abschließenden sechsten Kapitel wird ein kurzes Resumé über die Ergebnisse der Arbeit und die Effektivität der Schutzmaßnahmen gezogen.

10 Kapitel 2 Technische Grundlagen zu DNS Wie bereits im ersten Kapitel besprochen ist DNS für die Auflösung von Domainnamen und IP-Adressen verantwortlich. Es wird dabei zwischen der Vorwärtsauflösung (forward mapping) und der Rückwärtsauflösung (reverse mapping) unterschieden. Bei der Vorwärtsauflösung wird zu einem bestimmten Hostnamen die entsprechende IP-Adresse gesucht (z.b. hat folgende IP-Adresse: ), bei der Rückwärtsauflösung wird zu einer IP-Adresse der entsprechende Hostname gesucht. DNS kann mit einem Telefonbuch verglichen werden und stellt eine wichtige Grundlage für Internet- und Netzdienste dar. Einer der Hauptgründe für die Notwendigkeit von DNS ist, dass sich Menschen Namen besser merken als Nummern in Form von IP-Adressen 2.1 Eingliederung im Protokollstack DNS ist ein Anwendungsprotokoll und befindet sich im TCP/IP [23] Protokollstack auf Layer 4 (nähere Details siehe [33]). Für Namensauflösungen wird üblicherweise UDP [31] verwendet (Port 53), für Zonentransfers (siehe Kapitel 2.5.2) wird TCP verwendet (Port 53). 2.2 Domainstruktur Der Domain-Namensraum, siehe Abbildung 2.1, hat eine baumförmige Struktur. Der Baum besteht aus Knoten und Blättern, die als Label bezeichnet werden. Jedes Label hat eine Maximallänge von 63 Zeichen [29]. Die Verkettung aller Labels, getrennt durch Punkte, ergibt einen Domainnamen. Das Root-Label wird als Punkt dargestellt. Wird ein Domainname durch einen Punkt abschlossen, dann handelt es sich um einen Fully-Qualified-Domain- Name (FQDN). Die maximale Länge eines Domainnamen beträgt 255 Zeichen. Wird eine Domainname nicht durch einen Punkt abgeschlossen, dann handelt es sich um einen relativen Domainnamen. Relative Domainnamen 3

11 2. Technische Grundlagen zu DNS 4 können mit relativen Pfaden in Dateisystemen verglichen werden, dargestellt in Abbildung 2.2. Abbildung 2.1: Domain-Namensraum Abbildung 2.2: Dateisystem vs. Domain-Namensraum, angelehnt an [18] Jeder Pfad in einem Dateisystem muss eindeutig sein und identifiziert ein bestimmtes Verzeichnis/eine Datei, wobei ein Verzeichnis selbst wiederum in Unterverzeichnisse aufgeteilt sein kann. Im Domain-Namensraum verhält es sich ebenso, jeder Domainname muss ebenfalls eindeutig sein und identifiziert eine bestimmte Domain/einen Host, wobei eine Domain selbst wieder in Subdomains 1 aufgeteilt sein kann. Der Unterschied zwischen Domain- 1 Eine Subdomain würde im Dateisystem einem Unterordner entsprechen.

12 2. Technische Grundlagen zu DNS 5 Namensraum und Dateisystem besteht darin, dass die Pfade aus gegengesetzter Richtung gelesen werden, dargestellt in Abbildung 2.3. Der Domain-Namensraum wird aufgrund der Struktur in Form einer verteilten Datenbank abgespeichert. Diese Struktur erlaubt es, Domains lokal zu verwalten. So kann beispielsweise die Verwaltung der Domain companyx.com. an die Firma CompanyX übergeben werden. Gleichzeitig ist durch die hierarchische Struktur garantiert, dass eindeutige Domainnamen entstehen. CompanyX kann innerhalb seiner Domain beliebige Domainnamen verwenden, da diese durch Verwendung des Pfades eindeutig werden. Abbildung 2.3: Lesen der Pfadangaben, angelehnt an [18] 2.3 Nameserver Neben dem Domain-Namensraum und den Resolvern in Abschnitt 2.4, sind die Nameserver eine der drei zentralen Komponenten. Nameserver sind Anwendungen, die Informationen über einen bestimmten Bereich des Domain-Namensraums verwalten. Die Informationen sind in Zonen (Zonendateien) gespeichert. Verwaltet ein Nameserver mehrere Domains, z.b. example.com.und die Subdomains a.example.com., b.example. com. und c.example.com. so sind die Informationen jeweils in eigenen Zonen gespeichert. Der Unterschied zwischen einer Zone und einer Domain wird in Abbildung 2.4 illustriert. Für jede Zone sind mindestens zwei Nameserver authorativ, dies bedeutet, dass diese Nameserver die Domain-Informationen dieser Zone verwalten. Zusätzlich kennt jeder Nameserver die authorativen Nameserver für seine

13 2. Technische Grundlagen zu DNS 6 Abbildung 2.4: Unterschied Zone und Domain Subdomains. 2. Das bedeutet, dass beispielsweise die Nameserver für com die Nameserver für example kennen und somit bei einer Namensauflösung an diese verweisen können. Die Informationen einer Zone liest ein Nameserver aus dem konfigurierten Master File ein und liefert bei entsprechenden Queries (=Anfrage an einen Nameserver, siehe Abschnitt 2.7.2) von Resolvern eine Reply (=Antwort eines Nameservers, siehe Abschnitt 2.7.3), dargestellt in Abbildung 2.5. Kann der Nameserver eine Query anhand der eigenen Zoneninformationen beantworten, werden diese Antwortdaten als authorativ bezeichnet. Erhält ein Nameserver eine Query, welche nicht seine eigene(n) Zone(n) betrifft/betreffen und im Weiteren keine Daten im Cache vorhanden sind, gibt es folgende Möglichkeiten, wie ein Nameserver reagieren kann: Delegierung Auflösung über Root-Nameserver [7] (Rekursiv, Iterativ) Weiterleitung Delegierung Delegierung bedeutet, dass ein Teil der Informationen über den Domain-Namensraum in eine Subdomain ausgelagert und dafür eine entsprechende Zone gebildet wird. Erhält nun der Nameserver für example.com. dar. 2 Die Domain example in Abbildung 2.4 stellt beispielsweise eine Subdomain von com

14 2. Technische Grundlagen zu DNS 7 Abbildung 2.5: Nameserver und Master Files, angelehnt an [30] eine Query über hostx.c.example.com. und befinden sich keine Informationen im Cache, wird er an den zuständigen Nameserver für c.example. com. verweisen. Wie bereits erwähnt funktioniert dies, da ein Nameserver die authorativen Nameserver seiner Subdomains kennt. Root-Nameserver Befinden sich die gewünschten Daten außerhalb der verwalteten Domain(s) und sind auch keine Informationen im Cache des Nameservers vorhanden, dann müssen die Root-Nameserver befragt werden (A-M.ROOT-SERVERS.NET.). Insgesamt gibt es 13 Root-Nameserver, die über die Welt verteilt sind. Sie haben gespeichert, welche Nameserver für die Top-Level-Domains authorativ sind. Root-Nameserver beantworten nur iterative Queries. Iterative Queries bedeuten, dass der befrage Nameserver, sofern er die benötigten Daten nicht gespeichert hat, an den nächsten zuständigen Nameserver verweist. Der Resolver des Clients muss somit selbst die gesamte Namensauflösung durchführen. Eine Namensauflösung bezüglich der IP-Adresse zu über die Root-Nameserver würde wie folgt aussehen. Im ersten Schritt wird bei den Root-Nameservern nach dem Nameserver, der für com. zuständig ist, angefragt. Im zweiten Schritt wird von dem für com. zuständigen Nameserver der Nameserver ermittelt, der für extern.com. zuständig ist. Schließlich kann der Nameserver für extern.com. die IP-Adresse zu liefern. Bei rekursiven Queries funktioniert die Auflösung nach dem gleichen Schema, jedoch übernimmt der befragte Nameserver die gesamte Auflösung. Der Client muss nur eine Query stellen, um die Reply zu erhalten. Ob ein Nameserver rekursive Queries akzeptiert, lässt sich in dessen Einstellungen konfigurieren. Root-Nameserver beantworten nur iterative Queries, da rekursive Queries eine zu hohe Last bedeuten würden.

15 2. Technische Grundlagen zu DNS 8 Weiterleitung Kann ein Nameserver die gewünschten Informationen nicht liefern, leitet er die Query an einen vorher konfigurierten Nameserver weiter. 2.4 Resolver Der Resolver ist üblicherweise Teil des Clientbetriebssystems und wird benötigt, um an DNS teilzunehmen. Clientanwendungen, die eine Namensauflösung benötigen, stellen eine Query an den Resolver. Dieser verpackt die Query in ein DNS konformes Paket und leitet dieses an die konfigurierten Nameserver weiter. Resolver können, wie bereits erwähnt, iterative und rekursive Queries stellen. Ein Resolver hat drei grundlegende Aufgaben zu erfüllen [18]: Queries an Nameserver stellen Replies interpretieren (Daten oder Fehlermeldungen) Replies an die aufrufende Anwendung retournieren 2.5 Funktionsweise Kommunikation Anwendung - DNS Anwendungen kommunizieren über die Schnittstelle Resolver mit Nameservern, dargestellt in Abbildung 2.6. Um die Last auf die Nameserver und das Netz zu verringern, betreiben sowohl Resolver als auch Nameserver einen eigenen Cache. Alle Daten, die ein Nameserver bzw. ein Resolver erhält, kommen für die Zeitdauer der Time To Live (TTL) in den Cache. Befinden sich die gewünschten Daten im Cache des Resolvers, muss dieser keinen Nameserver befragen, sondern kann direkt die Daten aus dem Cache benutzen. Gecachte Domain-Informationen sind nie authorativ. Nach Ablauf der TTL werden die entsprechenden Daten aus dem Cache gelöscht. Erhält ein Nameserver eine negative Antwort (eine Fehlermeldung) wird über eine eigene TTL definiert, ob negative Antworten zwischengespeichert/gecacht werden dürfen [8] Nameserver Synchronisation Da DNS Basis für eine Großzahl der Netzanwendungen, vor allem im Internet, ist, muss jede Zone von mindestens zwei authorativen Nameservern verwaltet werden [29]. Da es zu aufwändig ist, für jeden Nameserver eigene Master Files, die konsistent sein müssen, zu verwalten, wird die Synchronisation über Zonentransfers durchgeführt. Es gibt Primary Nameserver - kurz Primary - und Secondary Nameserver - kurz Secondary. Primary Nameserver lesen ihre Daten aus Master Files und Secondary Nameserver beziehen die

16 2. Technische Grundlagen zu DNS 9 Abbildung 2.6: Kommunikation Anwendung und DNS [30] Daten von ihrem Primary bzw. von einem anderen Secondary über Zonentransfers. Ein Primary kann eine NOTIFY Message (Abbildung 2.7) an seine Secondaries senden, um diese zu informieren, dass Domain-Informationen geändert wurden. Abbildung 2.7: Primary und Secondary Nameserver [30]

17 2. Technische Grundlagen zu DNS Nameserver und Resolver gleichzeitig Ein Server, auf dem ein Nameserver betrieben wird, hat durch das Betriebssystem einen eigenen Resolver. Somit befinden sich Resolver und Nameserver gemeinsam auf einem Host, dargestellt in Abbildung Dabei wendet sich der Resolver, je nach den gewünschten Domain-Informationen, direkt an den eigenen bzw. an einen externen Nameserver. Werden Domain-Informationen benötigt, greift der Resolver zuerst auf die gemeinsame Datenbasis zu. Diese besteht aus authorativen und zwischengespeicherten (Cache) Domain- Informationen. Werden die gewünschten Domain-Informationen nicht gefunden, dann wendet sich der Resolver an einen externen Nameserver. Abbildung 2.8: Informationskanäle in einem Nameserver, angelehnt an [29] 3 Abbildung 2.8 kombiniert die Abbildungen 2.6 und 2.7

18 2. Technische Grundlagen zu DNS Standardimplementierung eines Resolvers Die Resolver aus den vorher gezeigten Abbildungen müssen die volle Funktionalität, so wie in [29,30] spezifiziert, implementieren. Resolver mit verringerter Funktionalität werden als Stub-Resolver bezeichnet, dargestellt in Abbildung 2.9. Diese unterstützen nur rekursive Queries und verwalten keinen Cache. Die Namensauflösung wird meist von einem Caching-Only-Nameserver durchgeführt. Ein Caching-Only-Nameserver ist selbst für keine Zone, abgesehen von localhost, verantwortlich und leitet alle Queries weiter. Stub- Resolver entlasten den Clientrechner, da dieser nur eine iterative Namensauflösung durchführen muss. Zusätzlich wird, anstatt lokaler Caches, ein gemeinsamer Cache geführt, wodurch die Anzahl Queries sinkt. Abbildung 2.9: Stub-Resolver 2.6 Resource Records Jeder Domainname bezeichnet einen Knoten/ein Blatt. Die Domain-Informationen zu diesem werden in Form von Resource Records (RR) vom zuständigen Nameserver über die Master Files eingelesen, verwaltet und weitergegeben. Ein Resource Record [29] baut sich, wie in Abbildung 2.10 dargestellt, auf. NAME ist der zu den Daten gehörige Domainname. TYPE legt den Typ der der RDATA fest. Folgende Werte sind dabei zulässig: A: Host IP-Adresse

19 2. Technische Grundlagen zu DNS 12 Abbildung 2.10: Aufbau eines RR [30] CNAME: Canonical Name (Domainname) eines Alias HINFO: beinhaltet Informationen zu CPU und OS des Hosts MX: identifiziert einen Mailserver NS: identifiziert einen authorativen Nameserver PTR: identifiziert einen Zeiger zu einem anderen Pfad im Domain- Namensraum (siehe Abschnitt 2.8) SOA: identifiziert die Domain und ihre Grunddaten CLASS (Klasse) identifiziert die Protokollfamilie. IN: Internet System CH: Chaos System TTL definiert wie lange eine Resource Record gültig im Cache aufbewahrt werden darf. RDLENGTH legt die Länge des folgenden RDATA Feldes fest. RDATA beinhaltet die Information laut TYPE. A: für die Klasse IN eine IP-Adresse CNAME: ein Domain-Name MX: ein Integer-Wert der die Priorität des Nameservers angibt, gefolgt von einem Domainnamen

20 2. Technische Grundlagen zu DNS 13 NS: ein Hostname PTR: ein Domainname SOA: mehrere Felder, siehe Beispiel Ein Beispiel für einen A Record in einem Master File kann wie folgt aussehen: example.com IN A Dabei weicht die Struktur eines RR in einem Master File vom in Abbildung dargestellten Aufbau ab. Das liegt daran, dass die TTL für die gesamte Zone im SOA Record gespeichert ist. Des Weiteren wird in Master Files keine RDLENGTH angegeben. Ein Beispiel für einen SOA Record kann wie folgt aussehen: example.com. IN SOA ns.example.com. admin.example.com. ( 1 ; Seriennummer 3h ; Refresh nach drei Stunden 1h ; Retry nach einer Stunde 1w ; Expire, verwerfen nach einer Woche 1h ) ; Cachen von negativen Replies - eine Stunde Die verwaltete Domain ist example.com., gefolgt von der CLASS, in diesem Fall das Internet System. Der Wert ns.example.com. spezifiziert den Primary Nameserver für die Zone. Der Wert admin.example.com. ist die E- Mail-Adresse des Ansprechpartners für die Zone. wird durch einen Punkt ersetzt, da dies ein nicht erlaubtes Zeichen ist. Danach folgen die Seriennummer und verschiedene Zeitintervalle. Die Seriennummer spielt bei Zonentransfers eine Rolle. Ein Zonentransfer wird nur durchgeführt, wenn die Seriennummer am Primary Nameserver höher ist als jene auf dem/den Secondary Nameserver(n). Refresh gibt an, in welchen Zeitabständen die Secondary Nameserver die Aktualität ihrer Daten gegenüber dem Primary kontrollieren sollen. Retry spezifiziert, nach welcher Zeit eine erfolglose Prüfung wiederholt werden soll. Expire gibt schließlich an, nach welcher Zeit ohne erfolgreiche Prüfung die Daten verworfen werden sollen. Der letzte Wert definiert die TTL der Daten aus negativen Replies. 2.7 DNS Messages Die gesamte Kommunikation zwischen Resolvern und Nameservern läuft über Messages in Form von Queries und Responses. Jede Message gliedert sich in 5 Abschnitte, wie in Abbildung 2.11 dargestellt: 4 Abbildung 2.10 stellt dar wie ein RR bei der Übertragung aufgebaut ist.

21 2. Technische Grundlagen zu DNS 14 Abbildung 2.11: Aufbau einer Message [30] HEADER siehe Abschnitt QUESTION beinhaltet die Query über die gewünschten Daten. ANSWER beinhaltet die entsprechenden Antwortdaten. AUTHORITY beinhaltet Information über authorative Nameserver. ADDITIONAL Dieses Feld beinhaltet zusätzliche Informationen. Wird beispielsweise der Mailserver für eine bestimmte Domain abgefragt, steht der entsprechende RR im ANSWER-Feld. Da mit großer Wahrscheinlichkeit auch die IP-Adresse benötigt wird, beinhaltet dieses Feld dessen A RR. Dadruch wird eine zusätzliche Query vermieden HEADER Der Header teilt sich selbst wieder in mehrere Felder auf, dargestellt in Abbildung Die Längenangabe der einzelnen Felder ist in Bits dargestellt. ID ist ein 16-Bit-Integerwert, der eine Query identifiziert. Die Response auf eine Query muss dieselbe ID enthalten. QR bestimmt, ob es sich bei der Message um eine Query oder eine Response handelt. OPCODE bestimmt die Art der Query. AA wenn das AA Bit gesetzt ist, dann handelt es sich um eine authorative Reply.

22 2. Technische Grundlagen zu DNS 15 Abbildung 2.12: Aufbau des Headers [30] TC TrunCation bedeutet, dass die Message zu lange für ein UDP-Datagramm ist und daher auf mehrere aufgeteilt wurde. RD Recursion Desired - ist dieses Bit gesetzt, handelt es sich um eine rekursive Query. RA Recursion Available - ist dieses Bit gesetzt, unterstützt der Nameserver Rekursion. Z ist für zukünftigen Gebrauch vorgesehen und muss in allen Messages der Wert null sein. RCODE Dieses Feld beinhaltet die entsprechende Statusmeldung. (no error condition, server failure, name error, not implemented, refused; nachzuschlagen in [30]) QDCOUNT gibt die Anzahl der Einträge im Bereich QUERY an. ANCOUNT gibt die Anzahl der RRs im Bereich ANSWER an. NSCOUNT gibt die Anzahl der Nameserver RRs im Bereich AUTHORI- TY an. ARCOUNT gibt die Anzahl der RRs im Bereich ADDITIONAL an.

23 2. Technische Grundlagen zu DNS DNS Query Queries werden dazu benutzt, um Domain-Informationen abzufragen. Der Bereich QUERY in einer Message ist, wie in Abbildung 2.13 dargestellt, aufgebaut. Abbildung 2.13: Aufbau einer Query [30] QNAME beinhaltet den Namen der Domain, über die Informationen abgefragt werden sollen. QTYPE Dieses Feld gibt den Typ des gewünschten RRs an. Es kann daher jeden Typ annehmen, der für RRs spezifiziert ist (siehe Abschnitt 2.6). Zusätzlich zu den RR-Typen kann dieses Feld folgende Werte enthalten: "*": liefert alle RR Typen MAILB: liefert alle MX Records AXFR: beantragt einen Zonentransfer QCLASS beinhaltet die gewünschte Klasse, z.b. IN für das Internet System. Für weitere Klassen siehe [18, 29] DNS Reply Replies stellen die Antworten auf Queries dar. Sie können die angefragten Informationen bzw. im Fehlerfall eine entsprechende Fehlermeldungen enthalten. Die Daten für Replies können von authorativen Nameservern aber auch aus Caches von Resolvern und nicht authorativen Nameservern stammen. Bei Replies werden die benötigten RRs in die entsprechenden Felder (ANSWER, AUTHORITY, ADDITIONAL) geschrieben und zurückgesendet. Wie bereits erwähnt, muss die ID einer Query und der zugehörigen Reply gleich sein.

24 2. Technische Grundlagen zu DNS Reverse Mapping Für das Reverse Mapping also die Rückwärtsauflösung, wird eine eigene, spezielle Domain betreut - die IN-ADDR.ARPA Domain. Die IN-ADDR.ARPA Domain ist für die Auflösung von IP-Adressen in Domainnamen zuständig. Dazu werden die PTR RRs verwendet. Über einen solchen RR wird einer IP-Adresse ein Domainname zugewiesen. Ein PTR RR könnte wie folgt aussehen: IN-ADDR.ARPA. PTR a.corp.example.com. In der IN-ADDR.ARPA Domain wird die Reihenfolge der Oktetts einer IP- Adressen umgedreht. Der Grund wird in Abbildung 2.14 dargestellt und in Abbildung 2.15 weiter verdeutlicht. Abbildung 2.14: Hierarchische Struktur der IN-ADDR.ARPA Domain, angelehnt an [18] Das erste Oktett mit dem Wert 193 ist am wenigsten spezifisch, der Wert 1 hingegen ist am spezifischsten. Genauso verhält es sich mit com und a. Durch die Umordnung entsteht nun eine Domain, in der sich alle IP- Adressen befinden, die mit 193 beginnen. Darunter befindet sich wiederum eine Domain mit 168 etc.. Würde diese Umordnung nicht stattfinden, würde das bedeuten, dass alle IP-Adressen zusammengefasst werden, die beispielsweise auf 15 enden. Diese Art der Ordnung ergibt semantisch keinen Sinn.

25 2. Technische Grundlagen zu DNS 18 Abbildung 2.15: Auflösung in der IN-ADDR.ARPA Domain, angelehnt an [18]

26 Kapitel 3 Gefährdungen DNS ist aufgrund seiner weiten Verbreitung ein potenzielles Angriffsziel und wurde in der Vergangenheit bereits häufig attackiert. Angriffe auf DNS zielen meist nicht auf die Vertraulichkeit ab, da Domain-Informationen großteils als öffentlich anzusehen sind. Eine weitaus bedeutendere Rolle spielen Integrität und Verfügbarkeit. Es sind dabei menschliche/organisatorische Gefährdungen und rein vorsätzliche Angriffshandlungen zu beachten. Dieses Kapitel stellt die Grundlage für die Gefährdungslagen des IT- Grundschutz-Bausteins dar. Für Informationen zum IT-Grundschutz laut BSI siehe Kapitel fünf. Gefährdungen, wie beispielsweise durch Viren, die in den IT-Grundschutz-Gefährdungskatalogen bereits abgedeckt sind, werden in diesem Dokument nicht behandelt. 3.1 Organisatorische/Technische Gefährdungen Fehlende/unzureichende Planung des DNS-Einsatzes Bevor mit der Installation von Nameservern begonnen werden kann, muss der Einsatz erst sorgfältig geplant werden. Wird die Planung des DNS-Einsatzes vernachlässigt, kann dies zu Problemen und Sicherheitslücken im laufenden Betrieb führen. Ungeeignete Nameserver-Software Bevor mit der Planung der Nameserver-Infrastruktur begonnen wird, muss grundsätzlich entschieden werden, welche Software zum Einsatz kommt. Veraltete bzw. wenig getestete Software beinhaltet oft Softwareschwachstellen und ermöglicht somit Angriffe. Ist für die ausgewählte Software nicht genügend geschultes Personal vorhanden, wird dies meist zu unsicheren Konfigurationen führen. Eine weitere Gefährdung kann es sein, für alle Nameserver dieselbe Software in derselben Version zu verwenden. Wird ein Nameserver in einer Softwaremonokultur erfolgreich aufgrund einer Softwareschwachstelle angegrif- 19