Optimale Vorgehensweise bei DNS White Paper · Warenzeichen sind Eigentum der rechtmäßigen Besi...

InhaltIn diesem Text geht es um grundsätzliche DNS-Konzepte und Best Practice-Techniken für DNS, die am konkreten Beispiel erläutert werden.

Optimale Vorgehensweise bei DNSWhite Paper

2 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und

Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.

Nutzungsrechte dieses Dokuments

CopyrightDieses Dokument und die darin enthaltenen Informationen (in Form von Text, grafischen Benutzeroberflächen ("GUI"), Video und Audio, Bildern, Symbolen, Software, Entwürfen, Applikationen, Berechnungen, Modellen, Vorhersagen oder anderen Elementen, mittels dieses Dokuments zur Verfügung gestellt werden, sind Eigentum von BlueCat Networks oder Zulieferern, und sind durch kanadische und internationale Urheberrechte, Warenzeichen und Gesetze geschützt. Durch die Nutzung dieses Dokuments werden keinerlei Besitz- oder weitere Rechte oder Inhalte an Sie übertragen. BlueCat Networks behält sich alle Rechte vor, die nicht ausdrücklich gewährt wurden.

Dieses Dokument und die darin enthaltenen Informationen sind das ausschließliche geistige Eigentum von BlueCat Networks. Es ist untersagt, dieses Material in jeglicher Form zu reproduzieren, nachzubilden oder auf andere Weise zu verwenden, ohne die vorherige schriftliche Genehmigung von BlueCat Networks.

Copyright © October 23, 2006 5:31 PM BlueCat Networks (USA), Inc. Alle Rechte vorbehalten.

Information des HerausgebersVeröffentlicht in Kanada - Kein Teil dieses Dokumentes darf in irgendeiner Form reproduziert, übertragen, kopiert oder in einem Retrieval-System gespeichert, oder in irgendeiner Form oder mit irgendeiner Methode in eine andere menschliche Sprache oder eine Computersprache übersetzt werden, ohne die zuvorige ausdrückliche Genehmigung von:

Diese Publikation schließt Haftungsansprüche jeglicher Art aus, sowohl ausdrücklich als auch stillschweigend, einschließlich - aber nicht beschränkt auf - Gewährleistung, Tauglichkeit für einen bestimmten Zweck oder Rechtsverletzungen.

Alle in dieser Publikation aufgeführten Warenzeichen oder Handelsmarken sind als solche gekennzeichnet. BlueCat Networks übernimmt keinerlei Haftung für die Richtigkeit der hierin enthalten Informationen. Die Nutzung eines Warenzeichens in dieser Publikation deutet nicht darauf hin, dass die Gültigkeit dieses Warenzeichens oder Handelsnamens dadurch beeinträchtigt ist. Alle aufgeführten Warenzeichen, Handelsnamen und Logos (die "Warenzeichen") sind registrierte und nicht registrierte Warenzeichen der BlueCat Networks, Inc. und Anderer. Jegliche Nutzung dieser Warenzeichen ist untersagt, ohne die zuvorige schriftliche Genehmigung von BlueCat Networks oder des Dritten, der rechtmäßiger Eigentümer des Warenzeichens ist.

Keine fachmännische EmpfehlungDieses Dokument dient ausschließlich zu Nachschlage- und Informationszwecken. Dieses Dokument erhebt nicht den Anspruch, eine umfassende oder vollständige Exploration des angegebenen Themas zu sein, noch einen Ratschlag oder eine Empfehlung hinsichtlich wissenschaftlicher, technischer oder jeglicher anderer Natur darzustellen; noch ein Angebot für den Verkauf oder Kauf eines bestimmten Produktes oder einer Dienstleistung zu sein. BlueCat Networks übernimmt keine Haftung oder Veranwortung hinsichtlich der Nutzung, der Gültigkeit, Richtigkeit oder Zuverlässigkeit, oder die sich aus der Nutzung der Internetseite oder der Materialien dieses Dokuments oder für jegliche Internetseite, auf die verwiesen wird, ergibt. Dieses Dokument ist ausschließlich für die Nutzung durch den Empfänger bestimmt. Es stellt kein vollständiges Angebot dar und darf durch keine weitere Person reproduziert oder weitergegeben werden.

BlueCat Networks, Inc.4101 Yonge Street, Suite 502Toronto, OntarioKanada M2P 2C9

Zu Händen von: ProduktmanagerTelefon: 416-646-8400Fax: 416-225-4728E-mail: [email protected]: www.bluecatnetworks.com

mailto:[email protected]

http://www.bluecatnetworks.com/

mailto:[email protected]

http://www.bluecatnetworks.com/

Optimale Vorgehensweise bei DNS

Kurzfassung

Bei der Implementierung von DNS muss eine Vielzahl möglichst optimaler Verfahrensweisen in Betracht

gezogen werden. Dabei handelt es sich um in der Praxis erprobte und von Experten geprüfte Empfehlungen,

wie ein robuster und sicherer DNS-Service aufgebaut sein sollte.

Zunächst beschäftigen wir uns mit Best Practices für DNS selbst und für den jeweiligen Server, auf dem der

Dienst liegt. Die folgenden Informationen sind hilfreich für jede Art von Unternehmen, die den Aufbau eines

DNS planen, sei es ein kleinerer Betrieb, seien es mittelständische und große Unternehmen oder auch

Hosting-Dienstanbieter. Des Weiteren geht es im Detail um DNS auf Netzwerkebene, und abschließend

werden die möglichen Sicherheitsmaßnahmen thematisiert. Diese Informationen haben besonders für

Großunternehmen einen hohen Stellenwert, wenn diese mehrere DNS-Server einsetzen müssen. Im hier

vorliegenden White Paper beschränken wir uns allerdings auf Sicherheitsthemen, die Unternehmen mit nur

einem Server betreffen.

Inhaltsverzeichnis

Einführung ................................................................................................. 4DNS-Server ................................................................................................ 5Der DNS-Dienst ......................................................................................... 6

Erhöhte Redundanz ............................................................................................. 6Handhabung ...................................................................................................... 8IPAM ................................................................................................................. 9Sicherheit für den DNS-Service ............................................................................. 9

DNS-Netzwerkarchitektur ........................................................................ 10Iterative vs rekursive Abfragen ........................................................................... 10Autoritative Server ............................................................................................ 10Caching-Server ................................................................................................. 11Trennung von Funktionen .................................................................................. 12Bedingte Weiterleitung ...................................................................................... 13BIND Views ...................................................................................................... 14

Externe DNS und Sicherheit ..................................................................... 14Firewalls .......................................................................................................... 15Verborgener Master .......................................................................................... 15Zonentransfers und TSIG ................................................................................... 16Versionsmaskierung .......................................................................................... 17Interne DNS ..................................................................................................... 18Dynamische Updates ......................................................................................... 18

Ein vollständiges Netzwerk ...................................................................... 19Schlussfolgerung ..................................................................................... 20

3© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und



Einführung

Für Unternehmen ist ein DNS-Service unentbehrlich, er wird jedoch größtenteils vernachlässigt oder sogar

missverstanden. Die Verwaltung der DNS ist traditionell ein technisches Unterfangen. Die DNS-Dienste

selbst fallen allerdings ihrer eigenen Zuverlässigkeit und Leistungsfähigkeit zum Opfer, und werden schlicht

als gegeben hingenommen. Die Eigenschaften eines herkömmlichen Computernetzwerks verändern sich

jedoch, vor allem durch die Einführung neuer Anwendungsbereiche und Applikationen, wie beispielsweise

drahtlose Geräte und VoIP-Telefone. Zudem sind Netzwerke heute deutlich höher ausgelastet als noch in der

jüngeren Vergangenheit. Auf der anderen Seite spiegelt sich darin ein stark gewachsenes Vertrauen in die

datenpaketbasierten Netzwerke wider. Und diese sind es ja, die die neuen Kommunikationsformen erst

ermöglichen. Der DNS-Dienst ist für diese Art von Netzwerken unerlässlich. Ohne DNS würden die meisten

Ressourcen in einem Netzwerk sehr schnell nicht mehr erreichbar sein. Viele Netzwerke sind in punkto DNS-

Verwaltung und Dienste für ein solches Wachstum aber gar nicht ausgelegt. Dadurch entsteht eine Situation,

in der die Funktionalität eines Netzwerks durch einen menschlichen Fehler oder eine Anzahl einfach zu

implementierter Angriffe kompromittiert werden kann. Dazu gehören u. a. Denial of Service (DoS) Angriffe,

die den DNS-Dienst schlichtweg stilllegen und wesentlich raffiniertere Angriffe wie Cache-Poisoning, die

Benutzer auf betrügerische Internetseiten führen, die sich als legitim ausgeben.

Der Ansatz von BlueCat Networks für einen sicheren und gut verwalteten DNS umfasst die Überprüfung

sämtlicher beteiligter Komponenten, die an der Bereitstellung der DNS-Dienste beteiligt sind. Jede

Komponente muss so einfach wie möglich aufgebaut sein, um effizient, leicht zu administrieren und sicher zu

sein, aber auch komplex genug, um die erforderliche Funktionalität zu bieten. Zunächst legen wir unser

Augenmerk auf den Server, der den DNS-Dienst bereitstellt. BlueCat Networks empfiehlt hier ein Appliance-

Modell, zusätzlich erhalten Sie ergänzende Informationen für diese Vorstufe der Netzwerkplanung. Der DNS-

Dienst wird auf Schwachstellen hin überprüft, die sich direkt auf den DNS-Dienst selbst und die BIND

Implementierung des DNS zurückführen lassen. Im Folgenden wird die DNS-Netzwerkarchitektur erörtert, da

sie erhebliche Auswirkungen auf Sicherheit und Funktionalität haben kann. Im Anschluss geht es um die

Implementierung und Sicherheitsaspekte der externen DNS. Der letzte Abschnitt, "Ein vollständiges

Netzwerk", beschäftigt sich mit den unterschiedlichen Perspektiven zu DNS in einer typischen

Netzwerkimplementierung und wie sie zusammengeführt werden können.


Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen möglich.


DNS-Server

Zunächst sehen wir uns den Server genauer an, auf dem der DNS-Dienst ausgeführt wird. Ohne einen

zuverlässigen, sicheren und optimierten Server, kann der DNS-Dienst ausfallen oder erhebliche

Sicherheitslücken aufweisen. Sicherheitsexperten empfehlen Unternehmen einen dedizierten DNS-Server

zu betreiben, der nichts anderes tut als genau diese DNS-Aufgaben wahrzunehmen. Je einfacher ein Server

aufgebaut werden kann, desto einfacher ist es, ihn abzusichern und ausfallsicher zu machen.

Die Hardware, die für den DNS-Server zum Einsatz kommen soll, sollte eine handelsübliche, empfohlene

Hardware sein, die vollständig über das ausgewählte Betriebssystem verwaltet werden kann.

Schwachstellen in der Hardware können zu Ausfällen des gesamten Servers führen.

Das Betriebssystem des Servers sollte nicht nur in der Lage sein die Hardware sicher zu verwalten, sondern

auch selbst keine Sicherheitslücken haben. Dies bedeutet, dass das Betriebssystem selbst auf

Sicherheitslücken überprüft ist und alle Sicherheits-Patches installiert sein müssen. Tatsächlich werden

automatisierte Patch- und Updatemanagementsysteme aufgrund ihrer Reaktionszeit und Konsistenz immer

beliebter. Sicherheitslücken des Betriebssystems können ebenfalls geschlossen werden, indem alle

Komponenten entfernt werden, die nicht ursächlich für den Betrieb des DNS erforderlich sind. BIND kann in

einer "abgeschlossenen" CHroot Umgebung betrieben werden, was es Hackern unmöglich macht, den DNS-

Dienst anzugreifen und Zugang zum Server über eine Privilegien-Eskalation zu erhalten. Diese Kombination

aus Hardware- und Betriebssystemintegration ist normalerweise nur auf Applikationsservern zu finden.

Auf einem DNS-Server sollte kein weiterer Service laufen, insbesondere keiner mit Internetzugang. Oft wird

allerdings für den DHCP-Dienst (Dynamic Host Control Protocol), der auf dem gleichen Server ausgeführt

werden soll, eine Ausnahme gemacht. Man sollte stets die aktuellste BIND-Software verwenden, um den

Sicherheitslevel zu erhöhen und die aktuellsten Funktionen, wie beispielsweise BIND 9 Views, einsetzen

zu können.

Der für den DNS-Dienst verwendete Server sollte über eine Firewall verfügen, die auf dem neusten Stand

der Paket-Filterung ist und so wenig offene Ports wie möglich aufweist. Hacker verwenden meist offene

Ports, um Angriffe auf DNS-Server auszuführen. Je besser die Firewall und je weniger offene Ports

vorhanden sind, desto sicherer der Server.

Wie ein Server sich administrieren lässt, ist nicht zuletzt dafür verantwortlich, wie effizient und sicher er

arbeitet. Da DNS-Sicherheitsprobleme sehr häufig aufgrund von Konfigurationsfehlern auftreten, ist der

Wechsel von textbasierenden Eingabekonsolen zu menügeführten grafischen Bedienoberflächen sinnvoll

und nützlich. Unter anderem sollten Funktionen wie die Administration von Protokollen und Zertifikaten

intuitiv bedienbar sein und sich einfach konfigurieren lassen.




Figure 1: Server ohne Sicherheitslücken

Der DNS-Dienst

Erhöhte Redundanz

Der DNS-Dienst ist ein entscheidender Netzwerkservice. Die Kosten, die durch einen Ausfall entstehen, sei

es auch nur über einen Zeitraum von einer Stunde, übersteigen die Kosten für die Implementierung einer

korrekt konfigurierten, hoch verfügbaren DNS-Infrastruktur um ein Vielfaches. DNS ist vom zugrunde

liegenden Aufbau her ein skalierbarer und verteilter Dienst, der Fehler und stellenweise Ausfälle toleriert.

Setzt man eine DNS-Architektur ein, die einen primären (Master) Server und einen oder mehrere

sekundäre(n) (Slave) Server verwendet, kann ein Server ausfallen, ohne dass der DNS-Dienst als solcher

ausfällt. Dieser Aufbau hat jedoch auch gewisse Nachteile. Zum einen, wenn der Master Name-Server

ausfallen sollte und nicht innerhalb einer gewissen Zeit wieder in Betrieb genommen wird, können die

sekundären Name-Server letztendlich nicht mehr auf die verbindlichen Anfragen reagieren. Zum anderen ist

die Anmeldung für alle Arbeitsstationen in der Regel so konfiguriert, dass sie den Master-Name-Server zur

Namensauflösung nutzen. Daher kann die Anmeldung sehr viel Zeit in Anspruch nehmen, bis sie schließlich

an den sekundären Name-Server weiter geleitet wird.




Figure 2: Eine Master/Slave Architektur

Cluster und hoch verfügbare Services erlauben es, mit dem DNS-Server auch mehrere Server zu betreiben,

aber mit nur einem Kontaktpunkt. Die Server, die in einem aktiv/passiv Cluster betrieben werden,

überwachen ihre Funktionsfähigkeit gegenseitig mit einem so genannten "Herzschlag"-Mechanismus. Falls

ein aktiver Server ausfallen sollte, kann der passive Server innerhalb weniger Sekunden dessen Platz

übernehmen. Ausfälle auf Serverebene müssen somit nicht mehr mit Ausfällen des DNS-Service

einhergehen.




Figure 3: Eine hoch verfügbare Master/Slave Architektur

Es gibt etliche Firmen, die DNS-Software entwickeln und vertreiben. Der Industriestandard ist die Software

des Internet Software Consortiums (ISC) BIND (Berkeley Internet Name Domain). Übertragen durch das

IETF (Internet Engineering Task Force), ist diese Software standardisiert und weit reichend genug

implementiert, dass sie als Diskussionsgrundlage für bezüglich DNS-Services oder Dämon bildet.

Handhabung

Probleme mit dem DNS fallen in der Regel in den Bereich der Konfiguration oder der Sicherheit. Die am

häufigsten auftretenden Probleme mit dem DNS-Dienst selbst sind auf Konfigurationsfehler zurückzuführen.

DNS ist von Natur aus ein kompliziertes System. In der Regel überließ man die Konfiguration einem

fachkundigen Administrator, der das System aufsetzte und pflegte. Fehler treten oft aufgrund der Art und

Weise auf, wie DNS verwaltet wird und/oder aufgrund von unzulänglichen Werkzeugen, die üblicherweise für

die Verwaltung zur Verfügung stehen. Administratoren verwalten die DNS üblicherweise über eine Konsole

und verwenden dabei einen Texteditor (wie beispielsweise vi), um die DNS- Zonendateien einzurichten und

zu pflegen. Dies führt aufgrund von Syntaxfehlern, logischen Fehlern und Datensätzen, die auf nicht

vorhandene Ressourcen verweisen, zu Problemen in den Datensätzen selbst. Heute sind Werkzeuge

verfügbar, die sich aller drei dieser Datensatz-basierenden Probleme annehmen. Neuere Werkzeuge mit

grafischen Benutzeroberflächen bieten die Möglichkeit, Zonendateien ohne Texteditor bearbeiten zu können.

So ermöglichen moderne Managementwerkzeuge beispielsweise passend erzeugte Datensätze in




zurückliegenden Zonen vorzuhalten. Je mehr DNS-Datensätze mit einer leistungsfähigen

Benutzeroberfläche erstellt und gepflegt werden können, umso weniger benötigt man dazu einen DNS-

Experten. Ein gutes DNS-Managementwerkzeug schont personelle Ressourcen, gestattet es, sich auf

andere kritische Netzwerkbereiche zu konzentrieren und erlaubt es auch Neulingen unter den

Administratoren sich um die Wartung des Netzwerks zu kümmern.

Innerhalb der Konfiguration sollte auch berücksichtigt werden, dass Zonendateien, alle aktuellen

Kontaktinformationen der jeweils verantwortlichen Person enthalten. Bei DNS-Notfällen kommt im Regelfall

das gesamte Netzwerk zum Erliegen. Zu wissen, an wen man sich wenden muss, ist entscheidend.

IPAM

In größeren Netzwerken kann selbst ein gut geführter DNS-Service nicht ausreichend sein, um der

Komplexität und den steigenden Sicherheitsherausforderungen gerecht zu werden. In solchen Netzwerken

erlaubt ein IP-Adressen-Management (IPAM) -System eine wesentlich umfassendere Kontrolle über die

DNS-Services. Ordnungsgemäß konfigurierte IPAM-Systeme integrieren den DNS in ein größeres

Verwaltungssystem, das Entwicklungswerkzeuge für die Bereitstellung von IP-Bereichen und DHCP-

Managementwerkzeuge enthält. Dadurch sind die DNS-Konzepte immer auf dem aktuellen Stand und man

kann mit der zeitgemäßen Dynamic DNS (DDNS)-Funktionalität arbeiten. Netzwerkstrategien dieser Art,

inklusive der Network Access Control (NAC), können durch die enge Integration von DNS und DHCP bereits

wesentlich moderner ablaufen.

Sicherheit für den DNS-Service

Im Bereich Sicherheit für DNS-Services gilt es eine Reihe von Komponenten zu berücksichtigen. Der BIND-

Dienst sollte auf dem aktuellsten Build aktualisiert sein. Ebenso müssen immer die neuesten Patches

installiert sein, was Schutz vor Sicherheitslücken wie Buffer Overflows bietet. BIND kann auch in einer

"geschlossenen" CHroot Umgebung betrieben werden. Dies bedeutet, dass der Service ohne

Administratorrechte abläuft und in einem besonderen Verzeichnis liegt. So ist der Server keinem Risiko

ausgesetzt, selbst wenn es einem Hacker gelingen sollte auf den BIND-Service zuzugreifen.

Um DNS-Services sicherer und zuverlässiger zu machen, wechseln viele Unternehmen zu dedizierten

Appliances für diesen Bereich. Sie sind in der Lage die beschriebenen Best-Practice-Empfehlungen für

DNS-Server umzusetzen. Zusätzlich bieten sie Managementwerkzeuge und weitere Schnittstellen. Es ist

problemlos möglich, einen anwenderspezifischen DNS-Server zu erstellen, der all diese Faktoren

berücksichtigt. Rechnet man zusätzlich die Personalkosten mit ein, erschließt sich der Vorteil einer

dedizierten Appliance sofort. Diese Tendenz ist eine natürliche Entwicklung, die bereits bei vielen anderen

Geräten im Bereich des Netzwerkbetriebs Einzug gehalten hat, nicht zuletzt bei Routern und Firewalls.




DNS-Netzwerkarchitektur

Eine der wohl wichtigsten Vorgehensweisen im Bereich der DNS-Services ist es, den DNS-Dienst zwischen

Cache-Servern und autoritativen Servern aufzuteilen. Ein einzelner DNS-Server ist zwar in der Lage beide

Funktionen zu übernehmen, es gibt jedoch gute Gründe für eine Aufteilung.

Iterative vs rekursive Abfragen

Es gibt zwei Arten von DNS-Abfragen, die ausgegeben werden können: Iterative und rekursive. Wenn ein

DNS-Client, die IP-Adresse eines anderen Computers ermitteln muss, so erstellt er eine rekursive Abfrage

an den lokalen DNS-Server. Ein Beispiel für eine rekursive Abfrage wäre: "Ich möchte die IP-Adresse des

Web-Servers mit dem Namen www.example.com wissen". Die Namensumwandlung erstellt die Abfrage und

wartet auf eine Antwort. Aufgrund der eingeschränkten Funktionalität des Namensumwandlers ist dieser nur

in der Lage eine positive oder negative Antwort auf die rekursive Abfrage zu empfangen, mit anderen

Worten: nur ein Ja oder Nein. Während der Client auf die Antwort wartet, führt der lokale DNS-Server seine

Aufgabe fort, indem er eine weitere Abfrage ausführt, auch bekannt als iterative Abfrage an andere DNS-

Server (in der Regel an Server im Internet). Während einer normalen iterativen Abfrage, empfängt der lokale

DNS-Server eine Abfrage für den Web-Server einer Domain, für die er nicht maßgeblich ist, in diesem Fall

www.example.com. Dieser erstellt eine iterative Abfrage an einen der dreizehn Root-DNS-Server, um die IP-

Adresse von www.example.com abzufragen (optimal ist hier die erzwungene Weiterleitung dieser Abfrage

an einen Caching-DNS-Server, aus Gründen der Lesbarkeit verwenden wir hier nur den Begriff DNS-Server).

Aufgrund der hierarchischen und verteilten Struktur des DNS-Namensbereichs (Namespace), können die

DNS-Root-Server nur einen Bruchteil der Antwort liefern, welche in diesem Fall die IP-Adresse des .com

DNS-Servers ist. Der lokale DNS-Server übernimmt diese Information und erstellt eine zweite, iterative

Abfrage an den .com DNS-Server. Der .com Server antwortet mit der IP-Adresse des example.com DNS-

Servers. Der lokale Server erstellt nun eine dritte und letzte iterative Abfrage an die DNS-Server, die für die

www.example.com Domain maßgeblich sind. Der maßgebliche DNS-Server der www.example.com gibt nun

die IP-Adresse des www.example.com Computers zurück und der lokale DNS-Server kann nun auf die

ursprüngliche, rekursive Abfrage des Namenswandlers oder des Clients antworten.

Autoritative Server

Autoritative DNS-Server beantworten Abfragen im Hinblick auf die Zonen, für die sie maßgeblich

verantwortlich sind. In unserem Fall sind die autoritativen DNS-Server der example.com die einzigen Server,

die Abfragen über die example.com Domain verbindlich beantworten können. Indem man einen solchen

DNS-Server an der Beantwortung rekursiver Abfragen hindert, kann man gleichzeitig die Leistungsfähigkeit

steigern und den Sicherheitslevel erhöhen. Die Beantwortung rekursiver Abfragen ist ein

ressourcenintensiver Vorgang. Fällt die Notwendigkeit weg, rekursive Abfragen beantworten zu müssen,

ermöglichen wir dem autoritativen Server, seine Ressourcen auf die Beantwortung der Abfragen seiner




Domain zu konzentrieren. Die Deaktivierung der Rekursion bedeutet sicherheitstechnisch, dass dieser DNS-

Server nicht mehr mit dem Root- oder einem anderen DNS-Nameservers im Internet kommuniziert. Je

weniger ein autoritativer Nameserver nach außen exponiert ist, desto geringer ist die Wahrscheinlichkeit,

dass er einem bekannten Angriff zum Opfer fällt.

Figure 4: Autoritative DNS

Caching-Server

Caching-Server sind demgegenüber so konfiguriert, dass sie rekursive Abfragen von Namensumwandlern

annehmen oder, im Falle der Weiterleitung, von anderen Nameservern annehmen. Auf Caching-Servern

sollten keine Zonen abgelegt sein. Ihre Funktion besteht nur darin, die rekursiven Abfragen im Interesse der

Clients zu beantworten und die iterativen Abfragen, wie oben beschrieben, auszustellen. Dies ist die einzige

Aufgabe, die sie zu erfüllen haben. Wenn Sie mit Caching-Servern arbeiten, ist es unerlässlich ACL (Access

Control List) zu verwenden; so ist gewährleistet, dass die Cache-Server nur auf Abfragen reagieren, die von

internen Clients gesendet wurden. Ansonsten ist es durchaus möglich, dass der DNS-Caching-Server durch

einen DDoS (Distributed Denial-of-Service) Angriff außer Betrieb gesetzt wird. Ein DDoS-Angriff wird durch

das Senden einer Vielzahl von Anfragen an den Server ausgelöst. Durch die Einschränkung des DNS-

Caching-Servers, nur rekursive Abfragen von internen Clients zu beantworten, wird das Risiko eines solchen

Angriffs nahezu beseitigt. Server, die rekursiven Abfragen gegenüber offen sind, können auch für DNS-

Cache-Poisoning anfällig sein. Cache-Poisoning Angriffe platzieren falsche Datensätze in einen DNS-

Server. In der Regel geschieht dies durch Manipulation des rekursiven Abfragemechanismus. Alle DNS-

Server sollten mit der aktuell verfügbaren Version von BIND aktualisiert werden, um das Risiko eines DNS-

Cache-Poisoning zu minimieren, da die neueren Versionen in der Lage sind, sicherere Transaktionen

durchzuführen.

DNS-Services, wie sie heute noch implementiert werden, wurden bereits zu einem Zeitpunkt verwendet, als

Sicherheitsbelange noch längst nicht eine so entscheidende Rolle spielten. Aufgrund der umfassenden

Sicherheitsproblematik des DNS-Caching wurde allgemein festgelegt, dass DNS-Caching-Server nur die

Abfragen interner Clients bearbeiten sollen. Autoritative Server dagegen sollten vollständig von Caching-

Servern getrennt sein, damit diese nicht den gleichen Sicherheitslücken unterliegen.




Figure 5: Ein Caching-Server der eine Abfrage bearbeitet

Trennung von Funktionen

Um die Trennung der DNS-Server-Funktionen zu erreichen, ist es ratsam, das so genannte DNS-Forwarder

(DNS-Weiterleitung) -Konzept anzuwenden. Häufig sind DNS-Clients so konfiguriert, dass sie ihre Anfragen

an einen verbindlichen DNS-Server des Unternehmens senden. Erinnern wir uns daran, dass wir hinsichtlich

der Rekursion unserer verbindlichen Server sehr vorsichtig sein wollen. Gibt ein Client eine Abfrage über

einen internen Datensatz aus, für welche der DNS-Server verbindlich zuständig ist, so kann und soll dieser

Server die Abfrage aus seiner Zoneninformation heraus beantworten. Ist die Abfrage jedoch an eine Zone

gerichtet, für die der Server nicht zuständig ist, konfigurieren wir den lokalen DNS-Server so, dass er die

rekursive Abfrage an den DNS-Caching-Server weiterleitet, anstatt die Rekursion zu deaktivieren. Der

Caching-Server "durchläuft" dann den DNS-Namensbereich, indem er iterative Abfragen ausgibt, die bei den

Root-Servern beginnen, und die Antwort dann an den abfragenden DNS-Server weitergeben. Dieser

antwortet dann auf die ursprüngliche Abfrage des Clients. Durch die Verwendung von Forwardern

(Weiterleitung), können DNS-Administratoren den DNS-Server auf entsprechende Funktionen beschränken.

Figure 6: Weiterleitung an einen Caching-Server




Bedingte Weiterleitung

Man kann den Einsatz der Forwarder noch ausweiten, indem man Forwarding-Zones verwendet (auch als

‚bedingte Weiterleitung' bekannt). Anstatt alle Abfragen, für die der DNS-Server nicht zuständig ist, an einen

Forwarder weiterzuleiten, kann ein DNS-Server so konfiguriert werden, dass er bestimmte Abfragen direkt

an spezifische DNS-Server versendet, die für diese Zonen zuständig sind. In der Regel sind diese

Forwarding-Zonen auf anderen, unternehmensinternen DNS-Servern abgelegt. Nehmen wir zu

Anschauungszwecken an, dass ein Unternehmen mehr als eine DNS-Zone verwaltet. Die Domain

example.com wird von einer Gruppe von einem DNS-Server aus verwaltet, während die Domain

example2.com von DNS-Servern aus einer anderen Abteilung verwaltet wird. Erhält nun der DNS-Server der

example.com eine Anfrage über die example2.com Domain, so kann diese Anfrage direkt an den DNS-

Server der example2.com Domain weitergegeben werden, ohne zuerst die Anfrage an den Caching-Server

weiterzuleiten, der dann die Anfrage an die Root-Server weitergibt usw. Diese Funktion gewährleistet, dass

Anfragen nach Ressourcen, die in den Zuständigkeitsbereich des jeweiligen DNS-Servers fallen, das

Netzwerk nicht verlassen. Rekursive, internetweite Anfragen würden in diesem Szenario nur für nicht-lokale

Ressourcen verwendet werden. Dadurch wird der Caching-Server weniger belastet. Ein Hacker, der den

Datenverkehr zwischen dem Unternehmen und dem Internet abhören will, wird niemals auf Abfragen nach

internen Ressourcen zugreifen können. Auch diese Funktion macht DNS erheblich sicherer.

Figure 7: Bedingte Weiterleitung

13© 2006 BlueCat Networks (USA), Inc. Alle Recht vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und



BIND Views

Es gibt weitere Funktionen, die DNS-Administratoren anwenden können, um die DNS-Infrastruktur sicherer

und zugleich ausfallsicherer zu machen. Durch die BIND Views- Funktion kann ein DNS-Server die Clients,

die ihn nutzen, "erkennen" und ist somit in der Lage entsprechend zu reagieren. Falls ein DNS-Server nur für

eine bestimmte Benutzergruppe zuständig ist, können die Anfragen an den Server mit einer ACL (Access

Control List) verglichen werden. Verwendet man BIND Views, werden die Abfragen erst dann ausgeführt,

wenn die IP-Adresse in der ACL-Liste aufgeführt ist, von der die ursprüngliche Abfrage stammt. Ein View

kann die Anfrage eines Clients erst dann beantworten, wenn dieser in einer der jeweiligen ACL-Listen

aufgeführt ist. Mit der View-Funktion kann ein Server vielseitiger gestaltet werden. Er kann beispielsweise

unterschiedliche Daten für unterschiedliche Benutzergruppen anzeigen oder die Anfragen einer

Benutzergruppe bearbeiten und dabei alle anderen ignorieren. Das minimiert jedoch keineswegs das

Sicherheitsrisiko, wenn der Caching-Server und der DNS-Server nicht getrennt sind.

Figure 8: BIND-Ansichten

Externe DNS und Sicherheit

Auch hinsichtlich des externen DNS gibt es optimale Vorgehensweisen. Auf externen DNS-Servern werden

Ressourcen-Datensätze abgelegt, auf die über das Internet (Web, E-Mail, ftp usw.) zugegriffen werden kann.

Diese Server beantworten Abfragen über Ressourcen von externen Clients, für die sie zuständig sind. Diese

Ressourcen sind für Benutzer zugänglich, die sich außerhalb des Unternehmens befinden und über

Protokolle, wie beispielsweise Web-Server, Mail-Server usw. darauf zugreifen.




Firewalls

Das Erste, an das wir uns bei externen DNS erinnern sollten ist, dass Firewalls ein unverzichtbarer

Bestandteil sind. Sie gewährleisten bei der Einrichtung einer DMZ zwischen internem Netzwerk und dem

Internet, dass der Netzwerkverkehr nur dann sichtbar wird, wenn beispielsweise Daten über das Internet

übertragen werden. Der Einsatz einer Firewall auf der öffentlichen Seite des DMZ gewährleistet, dass die

Server vor ungewollten Zugriffen aus dem Internet geschützt sind. Die Firewall im internen Bereich der DMZ

gewährleistet, dass die Ressourcen im internen Netzwerk durch Beschränkungen und Richtlinien zusätzlich

abgesichert werden. Durch Firewalls entsteht im Netzwerk eine Zone, in der nur eine bestimmte Form des

Datenverkehrs regulär und zulässig ist.

Figure 9: Eine DNS-Topologie mit einer Firewall

Verborgener Master

Eine der Möglichkeiten, einen externen Master-Nameserver abzusichern ist eine Konfiguration, die als

"Verborgener Master" bekannt ist. Mit dem Konzept des "verborgenen Masters" können Sie einen Master-

Nameserver hinter einer Firewall auf der internen Seite eines Netzwerks verbergen. Es sind keine weiteren

Sicherheitsmaßnahmen erforderlich. Der "verborgene Master" wird nie in einem NS-Datensatz einer DNS-

Zone aufgeführt, daher ist er für alle öffentlichen Ansichten (Views) dieser Zone unsichtbar. Dieser

"verborgene Master" Server wird für Modifikationen an Zonendateien und zur Übertragung der Zonendateien

an die "Slave" Server in der DMZ verwendet. Damit ist die wichtigste DNS-Information nie öffentlich

zugänglich.




Figure 10: Die Topologie eines verborgenen Masters

Zonentransfers und TSIG

Beim Entwurf einer externen DNS-Infrastruktur ist es äußerst wichtig, auch die Sicherheit der Zonentransfers

zu berücksichtigen. Beachten Sie stets, wer oder "was" Zonen von Ihrem primären Server übertragen kann

und darf. Ein offener Server, der jedem Host Zonentransfers ermöglich, ist in zweierlei Hinsicht ein Problem.

Der Server ist für Denial-of-Service Angriffe (DoS) offen. Ein Angreifer kann ein einfaches Skript erstellen,

welches ständig Zonentransfers im Ziel-Server auslöst. Das schränkt die Ressourcen und die Bandbreite

eines Servers erheblich ein. Zudem geben Zonentransfers jedem Angreifer einen "Lageplan" des

Zielnetzwerks an die Hand. Das ist besonders dann kritisch, wenn das interne System in externen Zonen

angezeigt ist (was allerdings nie der Fall sein sollte). Zonentransfers sollten ausschließlich auf berechtigte

Hosts eingeschränkt werden, wie über ACL (Access Control Lists) möglich. Zonentransfers können

zusätzlich über digitale Unterschriften authentifiziert werden, um sie noch weiter abzusichern. Neuere BIND-

Versionen verwenden TSIG (Transaction Signatures (Transaktionssignaturen)), um Nameserver zu

authentifizieren, die Zonentransfers durchführen. Dies geschieht durch einen Kryptografieservice, der auf

zuvor ausgegebenen Schlüsseln basiert. Damit dieses System funktionieren kann, benötigt der berechtigte

Sekundär-Server einen TSIG-Schlüssel. Für einen Eindringling ist es dann wesentlich schwieriger einen

Zonentransfer von einem geschützten Master-Server anzufordern. TSIGs können dazu verwendet werden,

Daten so zu zergliedern, dass nur die ausgegebenen Daten gültig sind und nicht modifiziert wurden.




Figure 11: Geschützte TSIG Zonentransfers

Versionsmaskierung

Best Practice ist ebenfalls das Verbergen der BIND-Version auf dem Server, auf dem sie gerade ausgeführt

wird. BIND (und andere Nameserver) beantworten per Voreinstellung alle Versionsabfragen. Dies ist eine

durchaus nützliche Funktion für Administratoren, öffnet aber zugleich eine Hintertür für potenzielle Angreifer

(indem sie bekannte Exploits für die jeweilige Version des BIND-Dienstes verwenden). Das Verbergen der

BIND-Version ist keine Wunderwaffe, bietet aber einen zusätzlichen Sicherheitslevel. Dieses Szenario

beinhaltet ein hoch verfügbares Cluster für den Master-Server. Auch bei einem Hardwarefehler würde der

DNS-Service weiterhin in Bereitschaft und verfügbar sein. In diesem Szenario kommt mehr als nur ein

Slave-Server zum Einsatz, was eine maximale Verfügbarkeit der externen DNS gewährleistet. Dabei wird

selbstverständlich ein autoritativer Server zur Namensauflösung externer DNS rekursive Anfragen

annehmen.

Figure 12: Beispiel eines externen DNS


Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen


Figure 10: Die Topologie eines verborgenen Masters

Zonentransfers und TSIG

Beim Entwurf einer externen DNS-Infrastruktur ist es äußerst wichtig, auch die Sicherheit der Zonentransfers

zu berücksichtigen. Beachten Sie stets, wer oder "was" Zonen von Ihrem primären Server übertragen kann

und darf. Ein offener Server, der jedem Host Zonentransfers ermöglich, ist in zweierlei Hinsicht ein Problem.

Der Server ist für Denial-of-Service Angriffe (DoS) offen. Ein Angreifer kann ein einfaches Skript erstellen,

welches ständig Zonentransfers im Ziel-Server auslöst. Das schränkt die Ressourcen und die Bandbreite

eines Servers erheblich ein. Zudem geben Zonentransfers jedem Angreifer einen "Lageplan" des

Zielnetzwerks an die Hand. Das ist besonders dann kritisch, wenn das interne System in externen Zonen

angezeigt ist (was allerdings nie der Fall sein sollte). Zonentransfers sollten ausschließlich auf berechtigte

Hosts eingeschränkt werden, wie über ACL (Access Control Lists) möglich. Zonentransfers können

zusätzlich über digitale Unterschriften authentifiziert werden, um sie noch weiter abzusichern. Neuere BIND-

Versionen verwenden TSIG (Transaction Signatures (Transaktionssignaturen)), um Nameserver zu

authentifizieren, die Zonentransfers durchführen. Dies geschieht durch einen Kryptografieservice, der auf

zuvor ausgegebenen Schlüsseln basiert. Damit dieses System funktionieren kann, benötigt der berechtigte

Sekundär-Server einen TSIG-Schlüssel. Für einen Eindringling ist es dann wesentlich schwieriger einen

Zonentransfer von einem geschützten Master-Server anzufordern. TSIGs können dazu verwendet werden,

Daten so zu zergliedern, dass nur die ausgegebenen Daten gültig sind und nicht modifiziert wurden.




Figure 13: DHCP und DDNS mit TSIG

Ein vollständiges Netzwerk

Viele, wenn nicht die meisten Unternehmen betreiben eine Kombination aus internen und externen DNS. Für

die Clients des internen Netzwerks ist in der Regel ein Zugriff auf interne und externe Ressourcen

erforderlich, während für Clients außerhalb des Unternehmens der Zugriff im Normalfall auf die extern

verfügbaren Ressourcen eingeschränkt wird, wie beispielsweise auf Web-Server, Mail-Server usw.

Die internen DNS-Clients sind so konfiguriert, dass sie einen internen DNS-Server zur Namensauflösung

verwenden. Ist eine angefragte Ressource intern, so gibt der DNS-Server die Adresse der Ressource

zurück. Betrifft die angefragte Information eine externe Ressource, so ist der interne DNS-Server so

konfiguriert, dass er die Anfrage an den Caching-Server weiterleitet. Ein Caching-Server kann in einem

internen Netzwerk oder in der DMZ platziert werden, je nach dem, ob andere Geräte in der DMZ darauf

zugreifen müssen. Nachdem der Caching-Server die Abfrage aufgelöst hat, gibt er die Antwort an den

internen DNS-Server weiter. Dieser antwortet dann auf die ursprüngliche Abfrage des Clients. So bleibt der

autoritative Server von dem oder den Caching-Server/n getrennt. Die Abbildung illustriert die Integration der

hier angesprochenen Best Practice Empfehlungen auf Netzwerkebene.




Figure 14: Ein vollständiges Netzwerk

Die externen und internen DNS-Daten werden auf physikalisch getrennten Servern abgelegt. Durch die

Platzierung des Master-Servers im internen Netzwerk, wird dieser vor äußeren Angriffen geschützt und als

“verborgener” Master konfiguriert und die DNS noch zusätzlich abgesichert. Falls gewünscht, kann eine

hoch verfügbare Konfiguration eingesetzt werden, um sich gegen Hardwarefehler auf dem Master-Server

abzusichern. Die externen DNS-Slave-Server werden in der DMZ des Unternehmens platziert und durch

Zonentransfers durch den externen View auf den DNS-Master-Server aktualisiert. Es ist äußerst wichtig,

dass sich auf den externen DNS-Servern keine Datensätze der internen DNS befinden, da diese von

externen Clients abgefragt werden können.

Schlussfolgerung

Die geschilderten DNS-Verfahrensweisen, werden sich mit der Zeit immer mehr zum Standard entwickeln.

Grundsätzlich wird dem DNS-Service oft zu wenig Beachtung geschenkt, was zu schlecht konfigurierten

Services führen kann. Sie sind dann entweder nicht vollständig verfügbar, funktionieren nicht richtig oder

können sehr leicht kompromittiert werden. Durch die zunehmende Anzahl der implementierten

Applikationen, mit einer Vielzahl an zusätzlichen Werkzeugen, wird dieses Problem etwas minimiert. Um

sicherzustellen, dass das Internet auch bei weiterer Expansion ein verlässliches Medium für

Informationsvermittlung und geschäftliche Transaktionen bleibt, ist die Implementierung von sicheren und




effizienten DNS zwingend erforderlich. Zudem wird DNS immer besser organisiert und verstanden. Eine

zusätzliche Integration des DNS-Dienstes in IPAM Systeme ist eine natürliche Reaktion auf die neu

entstehenden Komplexitätsebenen, wenn sich Netzwerke weiterentwickeln. Best Practice für DNS auf einen

Nenner gebracht: Komplexe Netzwerke sicher verwalten!




22 © 2006 BlueCat Networks (USA), Inc. Alle Recht vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und

Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind zu erwarten.

Optimale Vorgehensweise bei DNS White Paper · Warenzeichen sind Eigentum der rechtmäßigen Besi...

Documents

Transcript of Optimale Vorgehensweise bei DNS White Paper · Warenzeichen sind Eigentum der rechtmäßigen Besi...