Network Security

AERAsec
Network Security
Internet-Dienste
BIND

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.11.1-P2, 9.10.5-P2 und 9.9.10-P2 sind die aktuellen und vom ISC empfohlenen Versionen. Sie erhalten Patches gegen Fehler und Sicherheitslücken.
Ältere Versionen von BIND 9 werden nicht mehr gepflegt.

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.

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)
Detaillierte Erklärung der Werte gibt es unter RIPE/ripe-203.

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"
udp        0      0 0.0.0.0:53              0.0.0.0:*
Ein "named", gebunden nur an die "localhost" und eine interne IP-Adresse
# 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:*
Dies hindert externe automatisch, Kontakt mit diesem DNS-Server aufzunehmen.

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

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; };
Pro Zone gültige (jeweils im  Abschnitt "zone" spezifiziert) durch ACLs einschränkbare Mechanismen sind
  • 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
};