Allgemein
In Verbindung mit dem Programm BIND (Berkeley Internet Name Daemon) vom Internet Systems Consortium (ISC) kam es in der Vergangenheit immer wieder zur Veröffentlichung von Sicherheitslücken (BIND Security Advisories), für deren Ausnutzung zum Teil auch der fertige "Exploit-Code" aus dem Internet geladen werden kann. Ein sicherer Betrieb des BIND ist - sofern eine aktuelle und unterstützte Version zum Einsatz kommt - durchaus möglich. Jeder für BIND zuständige Administrator sollte sich aber in die Mailling-Liste für Ankündigungen eintragen, um bei einem eventuell neu auftretenden Problem zeitnah gewarnt zu sein, damit er dann schnellstmöglich reagieren zu kann.
Es gibt verschiedene Versionen der BIND-Software, die sich zum Teil in Ihren Features wesentlich unterscheiden:
BIND 9
9.9.0, 9.8.2 und 9.7.5 sind die aktuellen und vom ISC empfohlenen Versionen. Sie erhalten Patches gegen Fehler und Sicherheitslücken.
9.6-ESV-R6 wird bis Mai 2013 unterstützt und erhält Patches gegen Fehler und Sicherheitslücken, ebenso version 9.4-ESV-R5-P1.
Ältere Versionen von BIND 9 werden nicht mehr gepflegt.BIND 10
BIND 4 und BIND 8 werden schon seit längerer Zeit nicht mehr gepflegt und sind im Zustand "Deprecated". Daher sollten diese Versionen nicht mehr produktiv eingesetzt werden.
10-devel-20110705 ist eine Betaversion, die noch nicht produktiv eingesetzt werden sollte.BIND8/BIND4 als Forwarder ungeeignet!
BIND 8 und BIND 4 sollten ebenfalls nicht mehr als "Forwarder" eingesetzt werden. Sie sind anfällig gegenüber Angriffen auf die Integrität von DNS Caches (Cache Poisoning). Führen Sie bitte bei allen Nameservern, die als Forwarder verwendet werden, ein Upgrade zu BIND 9 durch.Die jeweils älteren Versionen sollten nicht zum Einsatz kommen, da diese "remote exploitable" sind, d.h. der Daemon kann z.T. über Netzwerk mit manipulierten Paketen durch einen Pufferüberlauf zum Absturz gebracht werden. Die Folge ist, dass eine Shell mit dem konfigurierten Benutzer (meist "named", tw. aber auch "root") zur Verfügung gestellt wird. Fertige "ready-to-use" Exploits stehen im Internet der Allgemeinheit zur Verfügung!
Eine auf dem System eingesetzte Version kann durch folgendes Kommando abgefragt werden:
# named -v
BIND 9.7.1
Konfigurationstipps
Info: Diese Tipps beziehen sich auf BIND 8 und höher.Korrekte Einträge im SOA-Record
| DeNIC-Roboter | DTAG-Roboter | |
|---|---|---|
| serial | Mindestens 6 Zahlen YYMMDDxx oder YYYYMMDDxx wobei xx eine lokale Seriennummer sein kann |
|
| refresh | 3600...86400 (= min. 1 h) | |
| retry | 900...28800 (= min. 0.25 h) | |
| expire | 604800...3600000 (= min. 7 d) | |
| ttl | 180...86400 (= min. 3 m) | 40000...345600 (min. 11 h) |
Manipulation der Server-Versionsnummer für Abfragen aus dem Internet
BIND hat standardmäßig die Ausgabe der Versionsnummer nicht deaktiviert. Eine Abfrage kann durchgeführt werden mit$ dig CHAOS TXT version.bind @ns.nicht-bestens-konfiguriert.firma.de
;; ANSWER SECTION:
VERSION.BIND. 0S CHAOS TXT "8.2.3-REL"
Angreifer können diese Information unter Zuhilfename von
automatischen Scannern gut benützen, um eine Vorsortierung
durchzuführen.
Diese Versionsnummernausgabe läßt sich allerdings auch
einfach abändern, dazu ist nur in dem Abschnitt "options" in
"named.conf" folgender Eintrag nötig und resultiert in
version "surely you must be joking";$ dig CHAOS TXT version.bind @ns.besser-konfiguriert.firma.de
;; ANSWER SECTION:
VERSION.BIND. 0S CHAOS TXT "surely you must be joking"
Binden des Server-Ports an dedizierte IP-Adressen
Falls der Nameserver auf einem Gateway nur für interne Netze DNS-Auflösungen durchführen soll, besteht keine Notwendigkeit, daß der Server-Port auch an die externe IP-Adresse gebunden ist. Ein Test mit "netstat" zeigt, ob dies der Fall ist.Ein "named", gebunden an alle IP-Adressen ("any")# netstat -na | grep ":53\W" | grep "^udp"Ein "named", gebunden nur an die "localhost" und eine interne IP-Adresse
udp 0 0 0.0.0.0:53 0.0.0.0:*
Dies hindert externe automatisch, Kontakt mit diesem DNS-Server aufzunehmen.# netstat -na | grep ":53\W" | grep "^udp"
udp 0 0 192.168.0.1:53 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
Einsatz des DNS-Servers in einer chroot-Umgebung
Der Einsatz des DNS-Servers in einer chroot-Umgebung ist durchaus zu empfehlen, wiewohl selbst diese nicht 100% sicher sind sind. Am besten man kombiniert mehrere Sicherheitsmethoden gleichzeitig, z.B. unter Linux- Chroot für BIND: siehe Chroot-BIND-HOWTO und evtl. verfügbare RPM-Pakete rpmfind/bind-chroot
- Stärker abgesicherte Linux-Kernel: AERAsec/Security/Systems/Linux
Einsatz von Access-Control-Lists (ACLs)
Durch den Einsatz von ACLs kann der Zugriff auf die Informationen im DNS beschränkt werden. Dies sollte z.B. unbedingt für Zonentransfers gelten, da normalerweise kein unbekannter Außenstehender Zugriff auf die komplette Zonendatei haben muß.ACLs können für verschiedene Mechnismen global und pro Zone benutzt werden und werden definiert wie folgt ("localhost", "any" und "none" sind schon vordefiniert):
acl nsfirmasecondary { 1.2.3.4; };
acl intranet { 192.168.0.0/16; };
Global gültige (in Abschnitt "options" spezifiziert) durch
ACLs einschränkbare Mechanismen sind
- wer darf Anfragen stellen:
allow-query { localhost; intranet; }; - wer darf rekursive Anfragen stellen:
allow-recursion { localhost; leualphacom; }; - wer darf Zonentransfers durchführen:
allow-transfer { none; };
- wer darf Anfragen stellen:
allow-query { any; }; - wer darf Zonentransfers durchführen:
allow-transfer { nsfirmasecondary; }; - wer darf dynamische Updates durchführen (z.B. mit "nsupdate")
allow-update { none };
Bei der Erstellung von ACLs in Zusammenhang mit der Registierung von lobal gültigen Zonen natürlich beachtet werden, daß definierte Secondary-DNS-Server und die Registrare Zugriff auf die Daten bekommen, sonst verweigern die Roboter dort die Arbeit.
Für Secondary-DNS-Hosting bei der Deutsche Telekom (DTAG) sollten folgende Server/Netze in entsprechende ACLs aufgenommen werden:
# Einganspruefung 62.156.153.47 www.t-domain.de # Pruefung manuell vom Bearbeiter 62.156.152.59 miraculix.dns-oldenburg.de # Diagnoseautomat fuer Secondaryeinrichtung 194.25.1.113 limes.NIC.DTAG.DE # Diagnose bei Fehlerbearbeitung allgemein 194.25.15.217 194.25.0.125 pns.dtag.de 194.25.0.121 pns1.DTAG.DE 194.25.0.122 pns2.DTAG.DE 194.25.0.44 secondary.DTAG.DE 194.25.0.45 secondary1.DTAG.DE 194.25.0.46 secondary2.DTAG.DE 195.244.245.0/24 # secondaryXXX.dtag.net # DTAG's Secondary im WiN 129.70.132.100 techfac.techfak.uni-bielefeld.de
Bei *.de-Domains zusätzlich das Netz der DeNIC
194.246.96.0/24 # Diagnose DeNIC
Forwarders
Forwarders können dazu eingesetzt werden, um z.B. aus Sicherheitsgründen den DNS-Verkehr zu kanalisieren (unterstützt durch entsprechende Filter) oder DNS-Caching des ISPs zu nützen. Sie werden auch in "options" konfiguriert, hier als Beispiel die drei von der Deutschen Telekom vorgeschlagenen:
forwarders {
194.25.0.68; // resolv-F.dtag.de
194.25.0.52; // resolv-L.dtag.de
194.25.0.60; // resolv-H.dtag.de
};