Erweiterte Konfiguration
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Standardmäßig lauscht der Bind-Daemon auf allen verfügbaren Netzwerkschnittstellen. Dies kann unerwünscht sein, wenn man ihn bspw. auf einem Gateway betreibt, ohne die interne Zone im Internet preisgeben zu wollen. Wie man das ändern kann, wird nachfolgend beschrieben.
Netzwerkschnittstellen¶
Zur Änderung der Netzwerkschnittstellen muss man in einem Editor mit Root-Rechten [2] die Datei named.conf.options bearbeiten und die folgende Zeile in den options-Block eintragen:
listen-on { 127.0.0.1; 192.168.0.10; };Die Angabe der IP-Adresse 192.168.0.10 muss natürlich an die IP-Adresse des Bind-Servers im lokalen Netzwerk angepasst werden. Wichtig ist auch, den Localhost, also 127.0.0.1, nicht zu vergessen, sowie auf die korrekte Verwendung der Semikolons zu achten.
Clientzugriff beschränken¶
Hinweis:
Dieser Abschnitt ist nur dann wirklich relevant, wenn der Server aus dem Internet erreicht werden kann. Wer seinen Nameserver in einem lokalen Netz betreibt, das durch einen NAT-Router vom Internet getrennt ist, kann auf diese Absicherung getrost verzichten.
Wer seinen Nameserver nicht für das gesamte Internet betreiben will, sondern nur für seine eigenen Rechner, der wird den Zugriff darauf beschränken wollen. Auch hierfür gibt es eine Option, die bspw. wie folgt in die Datei /etc/bind/named.conf.options eingetragen wird:
allow-query { 192.168.1.0/24; };Hierbei ist es auch möglich, mehrere Netze oder auch einzelne Hosts in die Direktive einzubeziehen.
Wer selber eine öffentliche Zone für das Internet bedient, darf natürlich entfernten Rechnern nicht den Zugriff versperren. Andererseits möchte man aber sicher auch nicht, dass Fremde den eigenen Nameserver evtl. als Standard eintragen und dadurch unnötigen Traffic zu eigenen Lasten verursachen. Mit der folgenden Direktive erlaubt man deshalb nur den eigenen Clients, reguläre (rekursive) Anfragen an den Nameserver zu stellen, während allen anderen Clients nur Anfragen über die eigene Zone beantwortet werden:
allow-recursion { 192.168.1.0/24; };In größeren Installationen ist es oft sogar sinnvoll, die Funktionen zu trennen, indem man den eigenen Clients einige mit allow-query zugriffsbeschränkte Nameserver zur Namensauflösung zur Verfügung stellt, und für die Verwaltung der eigenen Zone andere verwendet. Bei diesen kann man dann die rekursive Auflösung ganz abstellen:
recursion no;
Forwarders¶
Normalerweise fragt sich ein Nameserver auf der Suche nach der gewünschten IP-Adresse rekursiv, von den sogenannten Root-Servern ausgehend, durch, bis er den Server gefunden hat, der ihm die richtige Antwort geben kann. Manchmal ist dieses Verhalten jedoch nicht erwünscht und der Server soll stattdessen lieber alle Anfragen, die er nicht direkt selber beantworten kann, einfach nur an bestimmte Nameserver weiterleiten, bspw. die des eigenen Providers, oder die Hauptnameserver eines Intranets.
In diesem Fall muss man die betreffenden Server, wie im Folgenden beschrieben, im options-Block der Datei /etc/bind/named.conf.options eintragen:
forwarders { a.b.c.d; w.x.y.z; };Antworten die Forwarder aus irgendwelchen Gründen nicht, so fällt Bind automatisch auf das erstgenannte Verfahren zurück und versucht "auf eigene Faust" die Anfrage zu befriedigen. Das kann man aber auch verhindern, in welchem Fall stattdessen eine Fehlermeldung zurückgegeben würde:
forward only;
Chroot-Umgebung¶
Nameserver sind leider überdurchschnittlich häufig Angriffen aus dem Internet ausgesetzt, und in der Geschichte von Bind gab es auch schon mal die eine oder andere Sicherheitslücke. Deswegen kann man auf einem exponierten Server einen gewissen Sicherheitsgewinn erlangen, indem man den Bind-Daemon in einer chroot-Umgebung [4] laufen lässt. Praktischerweise ist eine chroot-Funktion bereits in den Server integriert, so dass man auf die aufwendige Vollausstattung der chroot-Jail, wie im Artikel chroot beschrieben, verzichten kann. Ein wenig Mehrarbeit gegenüber einer herkömmlichen Installation muss man aber trotzdem in Kauf nehmen.
Hinweis:
Da die folgenden Schritte alle als root ausgeführt werden müssen, und man als normaler Benutzer teilweise nicht mal die entsprechenden Verzeichnisse betreten darf, empfiehlt sich die Benutzung von sudo -s.
Die Existenz einer funktionierenden Bind9-Installation [3] wird vorausgesetzt.
Einrichten der Umgebung¶
Als erstes braucht man ein Verzeichnis, in dass der Server dann "chrooted" wird, und das sowohl die Konfigurationsdateien, als auch alle Laufzeitdaten aufnimmt. Ein geeigneter Ort wäre bspw. ein Verzeichnis namens /var/named. Die variablen Daten, bspw. die Process-ID (normalerweise in /var/run zu finden) und Slave-Zonen (/var/cache/bind), sollten dort ihre eigenen Verzeichnisse bekommen, damit man dem Daemon keine Schreibrechte auf das normale Konfigurationsverzeichnis einräumen muss. Mit den geeigneten Besitzverhältnissen und Rechten sollte das dann nach diversen chown- und chmod-Befehlen exakt so aussehen:
ls -ld /var/named/
Ausgabe:
drwxr-x--- 4 root bind 1024 2006-08-15 22:26 /var/named/ root@server:~# ls -l /var/named/ drwxrwx--- 2 root bind 1024 2006-08-15 21:55 cache drwxrwx--- 2 root bind 1024 2006-08-15 22:30 pid
Nun müssen noch alle Dateien aus /etc/bind in dieses Verzeichnis verschoben werden.
Anpassen der Konfiguration¶
Die Pfade in den Konfigurationsdateien stimmen natürlich jetzt alle nicht mehr, und müssen angepasst werden. Durch die Art, wie eine chroot-Umgebung funktioniert [4], ist das Verzeichnis /var/named dem Daemon im chroot jetzt nur noch als / bekannt.
In der Datei named.conf müssen deswegen alle Vorkommen von /etc/bind durch / ersetzt werden. Beispiel:
include "/named.conf.options";
Auch in named.conf.local und, nicht zu vergessen, in der named.conf-default-zones sind entsprechende Anpassungen vorzunehmen. Bei relativen Pfadangaben, wie back/domainname.bak, wird der komplette Pfad entfernt:
file "domainname.bak";
Die größten Anpassungen sind in der Datei named.conf.options vorzunehmen. Im options-Block ist die directory-Direktive in geeigneter Form abzuändern und ein Pfad für die Process-ID-Datei festzulegen:
directory "/cache";
pid-file "/pid/named.pid";Achtung!
Die folgenden Direktiven sind im Gegensatz zu allen bisherigen Änderungen an der options-Datei am Ende der Datei, unterhalb der geschweiften Klammer, die den options-Block abschließt, einzutragen.
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
include "/rndc.key";AppArmor¶
Abschließend muss noch das AppArmor-Profile von BIND angepasst werden. Dieses findet man unter /etc/apparmor.d/usr.sbin.named. In dieser Datei fügt man unter:
/etc/bind/** r,
nun den Eintrag mit dem chroot-Verzeichnis
/var/named/** r,
mit ein und lädt das AppArmor-Profile mit dem Befehl
sudo aa-enforce /etc/apparmor.d/usr.sbin.named
neu.
Umstellung des Servers¶
Da das Hilfstool rndc, das von den Startskripten verwendet wird, den zugehörigen Schlüssel im Verzeichnis /etc/bind erwartet, sollte als erstes dort im inzwischen leeren Verzeichnis ein symbolischer Link auf die Datei /var/named/rndc.key angelegt werden.
Dann muss man ein paar zusätzliche Optionen in der Datei /etc/default/bind9 eintragen:
OPTIONS="-u bind -t /var/named -c /named.conf"
Und zum Abschluss muss der Server neu gestartet werden:
/etc/init.d/bind9 restart
In der Datei /var/log/daemon.log kann man dann nachsehen, ob alles auch reibungslos geklappt hat. Außer den folgenden zwei Zeilen, die man ignorieren kann, sollten dort keine Fehler auftauchen:
could not open entropy source /dev/random: file not found using pre-chroot entropy source /dev/random
Dass der Server wirklich im chroot läuft, kann man durch ein Auflisten des zur Bind-Pid gehörigen /proc-Unterverzeichnisses kontrollieren (Ausgabe gekürzt):
ls -l /proc/`ps aux | grep '\/usr\/sbin\/[n]amed' | awk '{ print $2; }'` Ausgabe:
lrwxrwxrwx 1 root root 0 2006-08-16 00:17 cwd -> /var/named/cache lrwxrwxrwx 1 root root 0 2006-08-16 00:17 exe -> /usr/sbin/named lrwxrwxrwx 1 root root 0 2006-08-16 00:17 root -> /var/named
Links¶
DNS-Server Bind - Hauptartikel