| Den Nameserver BIND sicherer machen |
|
|
|
|
Von Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst
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. 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:
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. 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:
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). Hier sind noch ein paar weitere Maßnahmen, die die Sicherheit verbessern können. 4.1. 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):
4.2. Binden nur an die nötigen Netzwerk-Interfaces Standardmäßig bindet BIND an alle vorhandenen Netzwerk-Interfaces. Dies können Sie mit einem Eintrag in /home/dns/etc/named.conf einschränken:
Die Adressen sind natürlich nur Beispiele. Wenn Sie irgendwo den Eintrag 127.0.0.1 als DNS-Server haben, sollten Sie auch 127.0.0.1 zu der Liste hinzufügen - ich sehe allerdings wenig Sinn in solch einer Konfiguration. Wenn Sie DNS nur für das Intranet verwenden, dann sollte das Netzwerk-Interface, das zum Internet führt, nicht in der Liste enthalten sein. Paketfilter können unerwünschte Zugriffe auf den DNS-Server verhindern. Wie diese aussehen sollten, ist aber stark von der individuellen Netzwerk-Topologie und der Plazierung des DNS-Servers abhängig. Wenn Sie DNS nur für das Intranet verwenden, dann sollte er von außen nicht erreichbar sein. Man würde in diesem Fall also alle auf Port 53 ankommenden UDP-Pakete verwerfen. Zone Transfers sollten auch unterbunden werden. Das bedeutet, sämtliche TCP-Pakete von oder nach Port 53 zu verwerfen. Soll der DNS-Server dagegen aus dem Internet erreichbar sein, kann man mit Paketfiltern wenig machen. Es empfiehlt sich dann, für Intranet und die nach außen sichtbaren Rechner separate DNS-Server aufzusetzen. Doch dies führt hier zu weit, das ist Stoff für ein Firewall-Lehrbuch. Wie man die Paketfilter einrichtet, können Sie in unseren Artikeln für Kernel 2.2.x und Kernel 2.4.x nachlesen. Wer BIND in einem lokalen Netz benutzt, das über eine Wählleitung ans Internet angeschlossen ist, und keine Flatrate besitzt, den könnten die beiden folgenden Optionen interessieren, die unter »options« in /home/dns/etc/named.conf eingetragen werden. Allerdings ist mir auch nicht ganz klar, ob sie einen merklichen Effekt haben. Diese Optionen haben jedenfalls nichts mit Sicherheit zu tun, sondern sollen nur unerwünschte Verbindungs-Anforderungen unterdrücken. dialup yes; reduziert die Aktivitäten bei Zone Transfers. notify no; sendet keine NOTIFY-Nachrichten bei Konfigurationsänderungen.
|
||||||||||
| < Zurück | Weiter > |
|---|