DNS:Sicherheit

Aus KissDoc

Inhaltsverzeichnis 1 Allgemein 2 Versionsnummer 3 Chroot 4 TSIG 5 Zonentransfers 6 Views 7 Black-Lists

Allgemein

Sicherheit im DNS ist ein umfangreiches und kompliziertes Thema und sollte sehr ernst genommen werden. Ich erinnere: dieser Server antwortet der Welt und ein Admin-C einer Domain ist verantwortlich für Spam!

Bei der ISC sind bekannte Sicherheitslücken, zugehörige Workarounds und Behebungsinfos für die gängigen BIND Versionen erhältlich. Der Server sollte von Zeit zu Zeit aktualisiert werden.

Versionsnummer

Ein Verschleiern der Versionsnummer gibt einen zusätzlichen Schutz. Somit sind keine offenen Exploids verwendbar. Eine Abfrage wie dig @212.80.247.158 txt chaos version.bind. antwortet z.Bsp. recht großzügig mit folgender Antwort:

; <<>> DiG 9.3.4-P1.1 <<>> @212.80.247.158 txt chaos version.bind.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41963
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind.			CH	TXT

;; ANSWER SECTION:
version.bind.		0	CH	TXT	"9.4.2-P2"

;; AUTHORITY SECTION:
version.bind.		0	CH	NS	version.bind.

;; Query time: 20 msec
;; SERVER: 212.80.247.158#53(212.80.247.158)
;; WHEN: Tue Jan  6 08:07:39 2009
;; MSG SIZE  rcvd: 65

Chroot

Wenn der DNS Server bereits komprimitiert wurde, stellt ein Käfig ein weiteres Hindernis dar. Der DNS ist an dieser Stelle bereits vergessen, aber das Restsystem soll noch geschützt werden. Der Daemon wird vom Rest des Systemes isoliert. Ein chroot stellt aber kein Wundermittel dar. Folgende Voraussetzungen sind zu erfüllen:

• User (homedir, shell) und Gruppe, unter welchem der DNS läuft
• Verzeichnisstruktur, Daten und Rechte anpassen
• Bei slave Zonen Schreibrechte vergeben
• Den syslog Socket einrichten (wenn gewünscht)
• Startparameter -t, -u und -c setzen (/etc/init.d/bind9)
• Da das Start/Stop Script einer Deb-Distri bei einer chroot Konfiguration etwas umgeschrieben werden muß, kann auch die Datei /etc/default/bind9 entfernt werden (ist zwar nicht deb-komform aber einfacher).

Bei der Konfiguration sind dabei im wesentlichen folgende Punkte zu beachten:

• Das chroot Verzeichnis wirkt vor der named.conf Parsung!
• Die Konfigurationsdatei wird hingegen noch mit root Rechten gelesen bevor der User gewechselt wird.
• Bind erzeugt selbst ein PID File (nicht der Debian start-stop-daemon). Da es kein Binaryargument gibt, dürfte der dusselige Path /var/run/bind/run/named.pid eine Kompileroption sein. Das Verzeichnis muss also auch im chroot existieren, oder die Distribution muß neu übersetzt werden. Das originale Debian Start/Stop Script stellt das Verzeichnis sicher (hm). Auch muß bei Verwendung des Debian start-stop-daemon's in der "normalen" Verzeichnisstruktur ein Link auf dieses PID Verzeichnis existieren (ln -s /var/lib/bind/var/run/bind/ /var/run/bind), damit Debian's start-stop-daemon den Spaß auch auslesen kann; oder das PID Argument des start-stop-daemon in /etc/init.d/bind9 setzt sich aus "$CHROOTPATH/var/run/bind/run/named.pid" zusammen!
• Weiterhin sucht in einer Debian Distri das Binary rndc<code> die Dateien <code>/etc/bind/rndc.key und/oder /etc/bind/rndc.conf. Wenn man nicht immer die Parameter übergeben möchte oder das Bin neu übersetzen will, sollte noch der Symlink ln -s /var/lib/bind/etc/bind /etc/bind angelegt werden. Anderenfalls kann rndc nicht verwendet werden. Dieser Link ist auch aus Gründen der Konfigurationsarchivierung (über /etc) sinnvoll.

Die Symlinks im "normalen" FS sind also /etc/bind, /var/log/bind und /var/run/bind. Das virtuelle chroot Verzeichnis könnte so aussehen:

/var/lib/bind/
|-- dev
|   |-- log
|   |-- null
|   `-- random
|-- etc
|   |-- bind
|   |   |-- RCS
|   |   |-- *.key
|   |   |-- *.conf
|   |   |-- *.rev
|   |   `-- *.hosts
|   `-- localtime
`-- var
    |-- cache
    |   `-- bind
    |       `-- named.stats
    |-- log
    |   `-- bind
    |       |-- client.log
    |       |-- config.log
    |       |-- database.log
    |       |-- default.log
    |       |-- dispatch.log
    |       |-- dnssec.log
    |       |-- general.log
    |       |-- lame-servers.log
    |       |-- network.log
    |       |-- notify.log
    |       |-- queries.log
    |       |-- resolver.log
    |       |-- security.log
    |       |-- unmatched.log
    |       |-- update.log
    |       |-- xfer-in.log
    |       `-- xfer-out.log
    `-- run
        `-- bind
            `-- run
                `-- named.pid

TSIG

Mittels TSIG könnte ein verschlüsselter Zonentransfer zum secundary DNS mit Zeitstempel durchgeführt werden. Derzeit unterstützt dies aber unser DNS Provider nicht.

Zonentransfers

Bei den Zonentransfers ist eigentlich nur wichtig, daß ausschließlich unsere Secodary DNS Server komplette Transfers durchführen dürfen. Dazu wird einfach eine ACL mit diesen Servern eingerichtet. Die Anweisung allow-transfer kann in jeder Zone oder in options notiert werden. Sie benötigt lediglich eine ACL.

Die Anzahl der gleichzeitig bedienten Zonentransfers kann mittels transfers-out 4 vom Vorgabewert (10) abweichend in den options beschränkt werden. Auch die maximale Zeit für einen Zonentransfer kann in options oder einer Zone mittels max-transfer-time-out 60; (Selkunden) eingestellt werden.

Views

Von Hause aus gibt der Nameserver allen anfragenden Clients die gleiche Ergebnismenge. Da wir aber eine Domain verwenden, in welcher sowohl die internen Hosts als auch die externen Namen geführt werden, ist eine Aufteilung der Ergebnismenge ratsam. Mittels Views können für externe Clients andere Ergebnismengen ausgeliefert werden. Auch eine veränderte Arbeitsweise des Namesservers für die einzelnen views ist konfigurierbar (z.Bsp. NOTIFY). Wird keine View eingerichtet, ist das Verhalten mit der folgenden Konfiguration gleichartig:

view "world" { match-clients {any;};

Zunächst soll für externe Rechner die rekursive Auflösung deaktiviert werden. Die internen Rechner hingegen benötigen dieses Privileg. Anschließend werden zwei Hostdateien der selfdelve.com Domain angelegt, eine mit den internen Hosts und eine für das externe Device.

Wichtig ist bei den Views, dass nun alle Zonen innerhalb einer View stehen. Auch die Reihenfolge der Views ist entscheidend. Die erste Entsprechung eines IP Matchings wird angewandt. Die View any sollte also am Ende stehen.

Black-Lists

Für harte Fälle oder fehlerhafte Nameserver kann auch eine Blacklist gepflegt werden. Die blackhole Anweisung ist eine options Anweisung:

options {
	blackhole {
		10/8;
		192.168/16;
	};
};

Offene Listen gibt es einige; z.Bsp. die Distributed Sender Blackhole List. Von allzuviel Paranoia halte ich jedoch nix.