Den Nameserver BIND sicherer machen

Vorwort

In dieser Folge unserer kleinen DNS-Serie geht es darum, wie man den DNS-Server möglichst sicher macht. Sicherheit des DNS ist ein heikles Kapitel, denn die Sicherheit von anderen Diensten kann davon abhängen, daß DNS ordnungsgemäß funktioniert. Zudem bedeutet ein sicheres DNS einen Angriffspunkt für Cracker weniger auf dem Server.

DNS ist auch deshalb problematisch, weil es schon vom Ansatz her ein unsicheres Protokoll ist. In das Protokoll ist keinerlei Sicherheit eingebaut. Das soll sich mit DNSsec ändern, das aber noch lange nicht weit genug verbreitet ist.

Der DNS-Server BIND, bei weitem die weitestverbreitete Implementierung von DNS, hat eine lange Historie von Sicherheitslücken. Diese waren teilweise besonders übel, weil DNS mit Root-Rechten lief. Das war notwendig, da der Port des DNS-Protokolls, Port 53, nur von Root geöffnet werden kann.

Dieser Artikel zeigt, wie man BIND die Root-Rechte nimmt, und wie man andere Aspekte des Servers sicherer macht.

Die Wurzel ziehen

Sollten Sie noch nicht die Version 8.2.3 von BIND laufen haben, dann ist es höchste Zeit für einen Update. Version 8.2.3 ist derzeit die einzige Version 8.x, die keine bekannten Sicherheitslücken hat. Es gibt zwar bereits die Versionen 9.0 und 9.1, doch sind diese im Moment noch nicht zu empfehlen. BIND 9.x ist eine komplette Neuimplementierung mit seinen eigenen Kinderkrankheiten.

Seit Version 8.2 ist BIND in der Lage, nach dem Binden von Port 53 die Root-Rechte abzugeben und als normaler Benutzer weiterzumachen. Zusätzlich kann er in ein bestimmtes Directory wechseln und dort ein chroot ausführen, um dieses Directory niemals mehr zu verlassen.

Ersteres ist ohne nennenswerten Aufwand machbar. Wir legen einen Benutzer und eine Gruppe dns an und starten named mit der Option -u dns. Das einzige Problem, dem wir nun gegenüberstehen könnten, ist, daß named nun nicht mehr ausreichende Rechte in seinen Verzeichnissen hat. Deswegen schieben wir noch ein chown-Kommando nach:

groupadd -g 150 dns
useradd -u 150 -g 150 -M -s /bin/false dns
chown -R dns.dns /var/named

Wenn nun noch die Datei /etc/named.conf für dns lesbar ist, sollte es das gewesen sein. Achten Sie auf die Log-Ausgaben in /var/log/messages, um zu sehen, ob nichts schiefgegangen ist. In den obigen Kommandos bin ich davon ausgegangen, daß BIND die Standard-Pfade verwendet. Die Nummern für Benutzer und Gruppe dns sind natürlich nur Beispiele.

Entwurzelung

Die obige Schnellmaßnahme schützt uns davor, daß ein Angreifer unmittelbar Root-Rechte erlangen kann, doch das ist nicht genug. Nun wollen wir named aus seinen Standard-Pfaden entfernen und in eine chroot-Umgebung einsperren. Die chroot-Umgebung ist nichts anderes als eine abgemagerte Dateihierarchie, in der sich nur named und die von ihm benötigten weiteren Dateien befinden. Durch den Systemaufruf chroot(2) kann sich ein Programm selbst in dieser Umgebung einsperren und dann nie mehr daraus entweichen. Dies kann allenfalls auf sehr trickreichen Wegen gelingen, wenn das Programm root-Rechte hat. Doch diese werden wir ihm selbstverständlich nehmen, wie oben beschrieben.

Die chroot-Umgebung muß in irgendeinem Verzeichnis im normalen Dateisystem ihren Ursprung haben. Ich habe dafür /home/dns gewählt. Wenn wir »von außen« eine Datei /home/dns/etc/localtime sehen, dann sieht ein Programm nach Ausführen von chroot /home/dns diese als /etc/localtime.

Der Nachteil einer chroot-Umgebung ist die Duplizierung einiger Dateien, darunter auch libc. Dies belegt zusätzlichen Platz auf der Festplatte, doch auf einem Nameserver dürfte davon genug zur Verfügung stehen.

Mit folgenden einfachen Schritten legen wir die komplette chroot-Umgebung an:

mkdir -m 0700 /home/dns
mkdir -m 0755 /home/dns/etc
mkdir -m 0755 /home/dns/lib
mkdir -m 0755 /home/dns/dev
mkdir -m 0755 /home/dns/usr
mkdir -m 0755 /home/dns/usr/sbin
mkdir -m 0755 /home/dns/var
mkdir -m 0755 /home/dns/var/named
mkdir -m 0755 /home/dns/var/run
mknod -m 666 /home/dns/dev/null c 1 3
cp /etc/localtime /home/dns/etc/
cp /etc/named.conf /home/dns/etc/
cp /var/named/* /home/dns/var/named
chown -R dns.dns /home/dns/var/named /home/dns/var/run
cp /usr/sbin/{named,named-xfer} /home/dns/usr/sbin
cp /lib/libc.so.6 /home/dns/lib
cp /lib/libpthread.so.0 /home/dns/lib
cp /lib/libnsl.so.1 /home/dns/lib
cp /lib/ld-linux.so.2 /home/dns/lib
cp /usr/local/lib/libdns.so.3 /home/dns/lib
cp /usr/local/lib/libisc.so.3 /home/dns/lib
cp /usr/local/lib/liblwres.so.1 /home/dns/lib
cp /usr/local/lib/libomapi.so.3 /home/dns/lib

Die letzten cp-Befehle verweisen auf symbolische Links, doch das Kopieren bewirkt, daß die echte Library-Datei kopiert wird. Wer noch etwas Platz sparen will, führt als letzten Befehl noch

strip /home/dns/lib/*

aus. Das verkleinert libc auf etwa 1,3 MB und die anderen Libs entsprechend.

Nun müssen wir noch syslog präparieren. Programme schreiben ins Syslog, indem sie in die Pipe /dev/log schreiben. Diese wird von syslog angelegt. Unser eingesperrtes BIND kann aber nicht auf /dev/log zugreifen. Doch zum Glück kann man syslog dazu bringen, mehrere solche Pipes anzulegen. Da wir eine in /home/dns/dev benötigen, fügen wir in dem rc-Skript, in dem syslog gestartet wird (z.B. /etc/init.d/syslog), die Argumente -a /home/dns/dev/log hinzu (bei SuSE kann man auch die Variable SYSLOGD_PARAMS nutzen, die in /etc/rc.config gesetzt wird). Dann syslog stoppen und wieder starten. Die Änderung ist nun aktiv.

Der Start von BIND in der neuen Umgebung ist unspektakulär. Wir stoppen BIND, sofern er noch läuft und ändern dann das rc-Skript, in dem BIND gestartet wird. Wir fügen dem Aufruf die Argumente -u dns -t /home/dns hinzu, speichern die Datei und starten dann BIND neu. Prüfen Sie /var/log/messages. Dort muß sich BIND gemeldet haben und erklären, daß er bereit sei. (Bei manchen Distributionen ist es stattdessen /var/log/daemon.log).

Weitere Maßnahmen

Hier sind noch ein paar weitere Maßnahmen, die die Sicherheit verbessern können.

Zone Transfer einschränken

Zone Transfer ist nötig zum Datenabgleich zwischen den DNS-Servern. Wenn Sie DNS nur für das Intranet verwenden, dann sollte ein Zone Transfer ins Internet überhaupt nicht möglich sein. Dies können Sie mit Bindung an spezifische Netzwerk-Interfaces und Paketfiltern (s.u.) erreichen. Am wirksamsten ist die Kombination dieser Maßnahmen.

Ist ein Zone Transfer zu einem Partner-DNS-Server nötig, so erlauben Sie diesen Transfer nur den jeweiligen Servern. Deren IP-Adressen sind ja ohnehin bekannt. Tragen Sie in /home/dns/etc/named.conf ein (die IP-Adresse ersetzen Sie natürlich durch die Adressen Ihrer Partner-Server):

options {
 ...
 allow-transfer {
 217.17.17.17;
 }
 ...
};