Sie sind hier: Home » Uni-Firewall » Hinweise für einzelne Protokolle und Anwendungen » DNS-Server und DNS-Resolver

DNS-Server und DNS-Resolver

Aufgrund der prinzipiellen Schwachstellen des Domain Name System (DNS) ist der Betrieb von autoritativen Name Servern und DNS-Resolvern mit besonderen Risiken verbunden, die entsprechende Vorkehrungen erfordern. Damit DNS-Server möglichst hohen Schutz durch die Firewall der Universität Stuttgart genießen können, sind u.U. Änderungen der Server-Konfiguration erforderlich.

Inhalt

Hintergrund

Das Domain Name System ist ein weltweit verteiltes System, das die Übersetzung (Auflösung) von menschlich lesbaren Hostnamen in durch Rechnersysteme im Netzwerk verarbeitbare IP-Adressen vornimmt.

So wird beispielsweise der Hostname cert.uni-stuttgart.de durch den autoritativen Name Server des RUS-CERT in die IP-Adresse 141.58.89.3 aufgelöst. Gibt ein Benutzer den URL https://cert.uni-stuttgart.de in die Adressleiste seines Browsers ein, so muss dieser zunächst herausfinden, welche IP-Adresse der Webserver des RUS-CERT hat, denn nur über diese kann er eine Netzwerkverbindung mit dem Server herstellen.

Zu diesem Zweck fragt er seinen lokalen Resolver. Dieser schaut zunächst in seinem Cache nach, ob dort das entsprechende Ergebnis noch vorhanden ist und liefert es gegebenenfalls. Im anderen Fall fragt er den autoritativen Name Server für die Domain cert.uni-stuttgart.de, der ihm das Ergebnis liefert, kopiert es in seinen Cache (um zeitlich nahe weitere Abfragen rascher bedienen zu können) und reicht es dem anfragenden Client weiter.

Beide Spielarten, autoritativer Name Server und rekursiver Resolver, firmieren unter dem Oberbegriff DNS-Server und kommen häufig kombiniert zum Einsatz, erfüllen also gleichzeitg beide Funktionen. Zwar sind für die Freischaltung beider Arten für die Firewall der Universität Stuttgart spezielle Freischaltungstypen vorgesehen, diese werden aber aus Sicherheitsgründen nur noch in begründeten Ausnahmefällen eingerichtet.

Autoritativer Name Server (DNS-Server)

Für den Betrieb eines autoritativen Name Servers, der von außerhalb der Universität Stuttgart erreichbar sein soll, ist eine DNS-Server-Freischaltung erforderlich.
Hierdurch werden die Ports 53/UDP und 53/TCP geöffnet. Aus technischen Gründen wird dadurch ein Resolver, der auf den statischen Port 53/udp konfiguriert und damit stark gefährdet ist, unter derselben IP-Adresse erreichbar. Bitte sorgen Sie dafür, dass dieser Fall nicht eintritt und konfigurieren Sie Ihren Server so, dass er keine DNS-Antworten auf diesem Port erwartet.

Im allgemeinen ist es möglich, dass das Rechenzentrum diesen Dienst in für den Besitzer der Domain komfortabler Weise übernimmt und somit eine entsprechende Freischaltung entfallen kann.

Wenden Sie sich dazu bitte an die Kollegen den DNS-Dienstes:

dns-support@rus.uni-stuttgart.de

Hidden primaries brauchen im übrigen nur dann eine Freischaltung, falls der nach außen hin sichtbare autoritative Name Server außerhalb des Universitätsnetzes liegt.

DNS-Resolver

Rekursive Resolvers, die Anfragen von Clients in der Universität an externe DNS-Server weiterleiten, sind innerhalb der Universität Stuttgart aus Sicherheitsgründen nicht mehr zugelassen und entsprechende Freischaltungen für DNS-Resolvers können grundsätzlich nicht mehr eingerichtet werden!

An der Universität Stuttgart können Resolvers weiterhin betrieben werden, müssen Ihre Anfragen jedoch an die zentralen DNS Forwarders der Universität Stuttgart weiterleiten und in jedem Fall die sog. source port randomization implementieren. Beides ist bei den gängigen Resolver-Implementierungen leicht zu konfigurieren.

Angriffe auf DNS

Im Juli 2008 ist ein trickreiches, jedoch simples Angrifsszenario bekannt geworden, das sehr einfache und schnelle cache poisoning von DNS-Resolvers zulässt, die ihre Kommunikation fest über den Port 53/udp abwickeln (Details).

Zur Abmilderung des Problems wurde zur Steigerung der Kompexität des Angriffs die sog. source port randomization flächendeckend eingeführt. Viele Systeme (insbesondere BIND und Microsoft-basierte Resolver, s.u.) der damaligen Zeit konnten diese neue Eigenschaft nur durch die Installation eines Patches erwerben, der extra installiert werden musste. Aktuelle Versionen besitzen diese Funktion bereits.

Da insbesondere DNS-Resolvers per UDP kommunizieren, können sie leicht für sog. Verstärkerangriffe missbraucht werden. Dabei werden vergleichsweise kurze Anfragen mit gefälschter Absenderadresse an einen entsprechenden Resolver gesendet, der eine – je nach Anfragetyp – um ein Vielfaches längere Antwort an die Absenderadresse zurücksendet. Bei entsprechend vielen Anfragen an viele entsprechend missbrauchbare Resolvers können die Ressourcen des Systems, das die Antworten erhält (jenes, das die gefälschte Absenderadresse tatsächlich besitzt), leicht zum großen Teil oder vollständig verbraucht werden und es damit in einen unbenutzbaren Zustand versetzen (sog. Denial-of-Service-Angriff). Die IP-Adressen der missbrauchten Resolvers erscheinen dabei als Angreifer.

Aufgrund des hohen Risikopotentials, das Resolvers mit festem Port 53/udp darstellen, dürfen Resolvers an der Universität Stuttgart nur mit eingeschalteter source port randomization sowie konfigurierten Forwarders betrieben werden. Sie dürfen nicht aus dem Internet erreichbar sein weshalb spezielle Freischaltungen für diese Systeme grundsätzlich nicht eingerichtet werden.

BIND Versionen vor 9

BIND Versionen vor 9 werden an der Universität Stuttgart nicht mehr unterstützt!

Falls eine solch alte Version eingesetzt wird, sollte umgehend auf BIND 9 aufgerüstet werden, da der Betrieb des Resolvers aufgrund der Kommunikation auf dem festen Port 53/udp mit erheblichen Risiken verbunden ist. Die für den Betrieb des Resolvers erforderliche kleine DNS-Resolver-Freischaltung wird nicht mehr vergeben. Bestehende Freischaltungen wurden im Rahmen der Vulnerability Response zur Abwehr von Gefährdungen durch die im Juli 2008 bekannt gewordene Angriffsmethode aufgehoben.

BIND 9

Source Port randomization

BIND 9 Installationen ab BIND 9.3.5-P1, BIND 9.4.2-P1 oder BIND 9.5.0-P1 implementieren die sog. source port randomization und verwenden in der Voreinstellung (abhänging von verschiedenen Faktoren mehr oder weniger) zufällig gewählte UDP-Ports im Bereich 1024 bis 65535 (sog. high ports). Dies mildert damit die Gefahr von “cache poisoning” Angriffen (s.o.).

Ältere Versionen verwenden in der Voreinstellung den festen Port 53/udp und sind damit gegen solche Angriffe verwundbar. Sie sollten umgehend entsprechend aufgerüstet bzw. ersetzt werden.

Für den Betrieb eines Resolvers werden aus Sicherheitsgründen grundsätzlich keine Freischaltungen eingerichtet.

Resolver müssen grundsätzlich die sog. source port randomization implementieren und daher entsprechend konfiguriert sein. Dies bedeutet, dass in der Konfigurationsdatei /etc/named.conf die Zeilen

options { /* ... */ query-source port 53; }

bzw.

options { /* ... */ query-source address * port 53; }

durch die folgenden Zeilen ersetzt werden müssen:

options { /* ... */ query-source address * port *; }

andernfalls ist die source port randomization nicht eingeschaltet und das System ist gegen cache poisoning Angriffe um Größenordnungen verwundbarer als mit eingeschalteter source port randomization.

Benutzen der Resolvers des TIK

Um ohne Freischaltung ordnungsgemäß funktionieren zu können, müssen Resolver in den Netzen der Universität Stuttgart die zentralen Resolver der Universität als sogenannte Forwarders verwenden. Alle Anfragen werden dann an diese gestellt, welche sie dann weiterleiten, die Ergebnisse empfangen und an die Anfragenden Resolver zurückgeben.

Zur Konfiguration der Forwarders müssen die folgenden Zeilen eingefügt werden:

options { /* ... */ forwarders { 129.69.252.252; 129.69.252.212; 129.69.252.202; }; forward only; }

Betrieb von DNS-Server und DNS-Resolver in einem

Damit ein BIND DNS-Server für interne Netze als Resolver auftreten kann, muss aus Sicherheitsgründen sichergestellt werden, dass er nicht für externe Systeme als Resolver erreichbar ist (“Offener Resolver”).
Mit der Option “allow-query” kann man einschränken, welche Systeme berechtigt sind, Fragen zu einer Zone zu stellen.

Als erstes wird also in den globalen Optionen allow-query und allow-query-cache auf die lokalen Netze beschränkt, zum Beispiel:

options { /* ... */ allow-query { 129.69.0.0/16; 141.58.0.0/16; 127.0.0.0/8; 10.0.0.0/8; 192.168.0.0/16; }; allow-query-cache { 129.69.0.0/16; 141.58.0.0/16; 127.0.0.0/8; 10.0.0.0/8; 192.168.0.0/16; }; }

Dann kann für einzelne Zonen der Zugang von außen wieder erlaubt werden (wenn Zonen extern nicht sichtbar sein sollen, können Sie diese hier überspringen):

zone "cert.uni-stuttgart.de." { type master; file "/etc/bind/zones/cert.uni-stuttgart.de"; allow-query { any; }; }

Allgemeines

Zur Aktivierung der Konfigurationsänderungen muss dem named noch ein HUP-Signal gesendet werden.
Unter Linux:

# killall -HUP named

Unter anderen Unix-Varianten kann das killall-Kommando eine andere Funktion haben. In diesem Fall muss ein kill-Befehl abgesetzt werden, der als Parameter die ProzessID des named-Prozesses erfordert.

# kill -HUP `ps -ef | grep named | awk -F \ '{print $2}'`

Nur in begründeten Ausnahmefällen kann eine DNS-Resolver-Freischaltung eingerichtet werden, so dass das System in der Lage ist, Anfragen zur Namensauflösung an Name Server und Rekursive Resolver außerhalb der Netze der Universität Stuttgart zu senden.
Achten Sie in diesem Fall darauf, das Sie unbedingt alle RPC-Dienste und weitere UDP-Dienste abschalten!

Kleine DNS-Resolver-Freischaltungen auf dem festen Port 53/udp können aufgrund der Gefährdung für das freigeschaltete System nicht mehr eingerichtet werden!

Microsoft DNS Service

Falls dieser Server als Resolver eingesetzt wird, muss sichergestellt sein, dass die mit dem Microsoft Security Bulletin MS08-037 bereitgestellten Updates installiert und die zentralen Resolver der Universität Stuttgart (129.69.252.252, 129.69.252.212 und 129.69.252.202) als Forwarders konfiguriert sind.

Ein Microsoft DNS Server kann nicht gleichzeitig als DNS-Server (von außen erreichbar) und als DNS-Resolver betrieben werden, da sich die Resolver Funktion nicht auf lokale Netze einschränken lässt.
In diesem Fall gibt es verschiedene Lösungsansätze:

  • Trennen von Server und Resolver
  • Betrieb des Servers als Hidden-Primary mit den Nameservern des Rechenzentrums als öffentlich sichtbare Nameserver; damit entfällt die Freischaltung als externer DNS-Server

Bind9 als Secondary NS

Um Bind9 (oder andere DNS Server) als Secondary Nameserver zu betreiben, muss auf jedem Domain Controller der Zone Transfer und Notify zu diesem Server aktiviert werden. Außerdem sollte er natürlich auch als NS eingetragen werden.

Beispiel für eine Bind9 Konfiguration (als masters werden die Domain Controller eingetragen):

zone "ad-domain.example.net." { type slave; masters { 192.168.0.1; 192.168.0.2; }; allow-query { any; }; }

Active Directory Server als Hidden-Primary

Im Normalbetrieb tragen sich alle Active Domain Controllers einer Domain als Nameserver in die Zone ein.
Um dies zu verhindern, muss auf einem der zugriffsberechtigten Domain Controller für jede Zone folgendes eingegeben werden:

dnscmd /config ad-domain.example.net /AllowNSRecordsAutoCreation 0.0.0.0

Hinweis: Diese (und andere) Änderungen können einige Minuten brauchen bis sie auf den anderen Domain Controllern sichtbar werden; und es kann nochmal länger dauern, bis die Änderungen auch über DNS zu sehen sind.

Danach kann nur noch ein Domain Controller mit der angegeben IP sich als Nameserver eintragen – und 0.0.0.0 sollte dabei nicht vorkommen.
Dann können in den Zonen die Domain Controller als Nameserver manuell gelöscht werden, ohne dass sie nach kurzer Zeit wieder automatisch eingefügt werden.

Die aktuelle Konfiguration kann mit folgendem Befehl angezeigt werden:

dnscmd /ZoneInfo ad-domain.example.net /AllowNSRecordsAutoCreation

Die _msdcs. Subdomains sind nicht für die Öffentlichkeit bestimmt – die Domain Controller beantworten Anfragen für diese Zone nur angemeldeten System. Für diese Zonen sind also keine extern erreichbaren Secondaries zu betreiben, und es wird auch keine Konfiguration als Hidden-Primary benötigt (die Domain Controller sind an dieser Stelle auch sehr empfindlich).

Andere

Für den Einsatz anderer DNS-Resolver-Implementierungen lesen Sie bitte die RUS-CERT-Meldung Nr.1476 [Generic/DNS] Schwachstelle im DNS-Protokoll vereinfacht cache poisoning