Warum ist das Ausführen von named (bind) in chroot für die Sicherheit so wichtig? Oder vielleicht doch nicht?

Ich spiele mit Binden und frage mich, warum diese Software beispielsweise in CentOS in Chroot ausgeführt wird. Versteht mich nicht falsch, ich weiß, was Binden ist und wofür Chroot (Gefängnis) ist. Aber meine Hauptfrage ist, dass das Binden ohne Chroot so sehr unsicher ist?

Ist es wirklich schädlich, es ohne Gefängnis einzurichten (mehr als jeder andere Dienst oder jede andere Software)? In Systemen werden viele Prozesse ohne Chroot ausgeführt, und ich halte die Kompromittierung eines dieser Prozesse für sehr gefährlich. Aber was macht Named gefährlicher als andere Software, die ohne Chroot ausgeführt wird?

Wie @Some Guy bereits erwähnt hat, muss man sich das aus historischer Sicht überlegen.

Die historische Perspektive war, dass ein einziges Hardwareteil ein Dutzend verschiedener Dienste unter einem einzigen Betriebssystem umfasste. Wenn ein Dienst kompromittiert wurde, wurde alles auf dieser Hardware kompromittiert.

Bei der Virtualisierung ist dies weitaus weniger ein Problem. Obwohl es nicht unmöglich ist, aus einer VM herauszukommen, ist dies alles andere als trivial. Es ist sicherlich schwieriger, aus einer VM auszubrechen, als wenn ein Prozess, der mit Root-Rechten ausgeführt wird, aus einer Chroot ausbricht. Meine Bindeserver laufen also auf einer eigenen VM. In diesem Fall hat eine Chroot nicht viel Sinn, da der Schaden bereits dadurch begrenzt ist, dass es sich um eine VM handelt.

Eine Chroot ist ein sehr schwacher Versuch, so etwas wie eine VM zu erstellen. Chroots können jedoch von jedem Prozess mit Root-Rechten entkommen. Eine Chroot ist nicht vorgesehen und funktioniert nicht als Sicherheitsmechanismus. Ein Chroot mit einem BSD-Jail oder LXC bietet Virtualisierung auf Betriebssystemebene und Sicherheitsfunktionen. Da es heutzutage so einfach ist, eine neue VM einer gesamten Maschine hochzufahren, lohnt es sich möglicherweise nicht mehr, sie einzurichten oder zu lernen, wie die Virtualisierungstools auf Betriebssystemebene für diesen Zweck verwendet werden.

Frühere Versionen von bind haben keine Berechtigungen verworfen. Unter Unix kann nur das Root-Konto Ports unter 1024 öffnen, und Bind muss, wie wir alle wissen, auf udp / 53 und tcp / 53 lauschen. Da Bind als Root gestartet wird und keine Berechtigungen fallen lässt, kann das gesamte System kompromittiert werden. Heutzutage öffnet fast jede Software ihre Sockets und erledigt alle anderen Dinge, die Root-Berechtigungen erfordern. Anschließend wird der Benutzer, den sie ausführen, in ein nicht privilegiertes Konto geändert. Sobald die Berechtigungen fallengelassen wurden, ist die Auswirkung einer Gefährdung für das Hostsystem viel geringer.

Die anderen Antworten sind ziemlich gut, lassen aber das Konzept der Sicherheit in Schichten außer Acht. Jede Sicherheitsebene, die Sie Ihrem System hinzufügen, ist eine weitere Ebene, die ein Gegner überwinden muss. Das Einfügen von BIND in eine Chroot ist ein weiteres Hindernis.

Angenommen, es liegt eine ausnutzbare Sicherheitslücke in BIND vor, und jemand kann beliebigen Code ausführen. Wenn sie in einer Chroot sind, müssen sie das beenden, bevor sie auf etwas anderes im System zugreifen können. Wie bereits erwähnt, sind Root-Rechte für das Brechen von Chroots erforderlich. BIND wird nicht als root ausgeführt, und es sollen nur minimale Tools in der Chroot verfügbar sein, die die Optionen weiter einschränken und im Wesentlichen nur Systemaufrufe belassen. Wenn es keinen Systemaufruf zur Eskalation von Berechtigungen gibt, kann der Gegner Ihre DNS-Einträge nicht mehr durchsuchen.

Die oben genannte Situation ist, wie SomeGuy erwähnt, eher unwahrscheinlich. BIND weist derzeit nur wenige Schwachstellen auf und ist hauptsächlich auf DoS-Szenarien und nicht auf die Remote-Ausführung beschränkt. Auf einigen Betriebssystemen ist das Ausführen in einer Chroot-Umgebung die Standardkonfiguration. Es ist daher unwahrscheinlich, dass Sie irgendwelche Anstrengungen unternehmen, um die noch so geringfügig erhöhte Sicherheit beizubehalten.

Präambel

Ich höre immer wieder Leute, die falsche Vorstellungen aus dem ganzen Internet wiederholen. Daher werde ich versuchen, Klarheit zu schaffen

erst einmal; Wie viele zufällige Entdeckungen gab es, die einfach aufgrund von Ursache und Wirkung für etwas anderes als den beabsichtigten Zweck verwendet wurden?

Was war und was ist ein Chroot-Gefängnis?

Chroot wurde ursprünglich entwickelt, um das Stammverzeichnis für den Prozess oder den Benutzer zu ändern (ideal zum Kompilieren von Software aus unbekannten Quellen). Dies bot Sicherheit für das Basissystem sowie ein schnelles Prüfstandsgerät mit einfacher Reinigung. Jahre sind vergangen, und das Konzept und die implizierten Verwendungen haben sich sicherlich ebenfalls geändert.

chroot wurde effektiv genutzt und befindet sich direkt in der Codebasis für verschiedene Programme und Bibliotheken (z. B. openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot und vieles mehr ). Die Annahme, dass all diese Mainstream-Anwendungen fehlerhafte Sicherheitslösungen implementiert haben, ist einfach nicht wahr

chroot ist eine Lösung für die Dateisystemvirtualisierung: Nicht weniger, nicht mehr. Die Annahme, dass Sie leicht aus einer Chroot ausbrechen können, trifft auch nicht zu ... solange Sie die Richtlinien für die Ausführung von Prozessen innerhalb des Chroot-Gefängnisses einhalten.

Einige Schritte, um Ihr Chroot-Gefängnis zu sichern

dh Prozesse NICHT als ROOT ausführen. Dies könnte einen Wurzeleskalationsvektor eröffnen (der auch innerhalb oder außerhalb der Chroot gilt). Führen Sie keinen Prozess innerhalb der Chroot aus und verwenden Sie denselben Benutzer wie einen anderen Prozess außerhalb der Chroot. Trennen Sie jeden Prozess und Benutzer in einen eigenen Chroot, um die Angriffsfläche zu begrenzen und die Privatsphäre zu schützen. Hängen Sie nur die erforderlichen Dateien, Bibliotheken und Geräte ein. Schließlich ist Chroot KEIN Ersatz für die Sicherheit des Basissystems. Sichern Sie das System in seiner Gesamtheit.

Ein weiterer wichtiger Hinweis: Viele Leute denken, dass OpenVZ Broken ist oder dass es im Vergleich zur vollständigen Systemvirtualisierung nicht gleich ist. Diese Annahme wird getroffen, da es sich im Wesentlichen um eine Chroot handelt, deren Prozesstisch sterilisiert werden muss. mit Sicherheitsmaßnahmen auf Hardware und Geräten. Die meisten davon können Sie in einer Chroot implementieren.

Nicht jeder Administrator verfügt über die erforderlichen Kenntnisse, um alle erforderlichen Kernelparameter auf einem dedizierten Server oder bei vollständiger Systemvirtualisierung zu sichern. Dies bedeutet, dass Ihre Kunden durch die Bereitstellung von OpenVZ weniger Angriffsfläche haben, um sich vor der Bereitstellung ihrer Anwendungen abzusichern. Ein guter Host leistet gute Arbeit bei der Sicherung dieser Parameter, und dies ist wiederum besser für nicht nur alle auf dem Node oder im Rechenzentrum, sondern für das Internet als Ganzes.

Wie bereits erwähnt, ermöglicht die Chroot die Virtualisierung von Dateisystemen. Sie müssen sicherstellen, dass keine setuid-ausführbaren Dateien, unsicheren Anwendungen, Bibliotheken, herabhängenden inhaberlosen Symlinks usw. vorhanden sind. Wenn der Angreifer die Bindung gefährden KÖNNTE, müsste er das virtuelle Dateisystem nach etwas durchsuchen, um einen Pufferüberlauf zu verhindern, mit Dateideskriptoren zu spielen oder auf andere Weise kann etwas, das sich in der Chroot befindet und aus dem Gefängnis entweicht, gefährdet werden, in der Regel durch die Eskalation von Privilegien oder durch die Injektion seiner Nutzlast in das Basissystem.

In diesem Fall ist dies normalerweise das Ergebnis eines fehlerhaften Updates, eines Zero-Day-Exploits oder eines idiomatischen menschlichen Fehlers .

warum chroot immer noch verwendet wird, im Gegensatz zur vollständigen Systemvirtualisierung

Stellen Sie sich das folgende Szenario vor: Sie führen einen Virtual Private Server aus, auf dem der Hostknoten OpenVZ ausführt. Sie können einfach nichts ausführen, was auf der Kernel-Ebene funktioniert. Dies bedeutet auch, dass Sie die Betriebssystemvirtualisierung nicht verwenden können, um Prozesse zu trennen und zusätzliche Sicherheit bereitzustellen. Daher MÜSSEN Sie chroot für diesen Zweck verwenden.

Darüber hinaus ist chroot auf jedem System unabhängig von den verfügbaren Ressourcen nachhaltig. Einfach ausgedrückt, hat es den geringsten Overhead aller Virtualisierungstypen. Dies bedeutet, dass es bei vielen Low-End-Boxen immer noch wichtig ist.

Stellen Sie sich ein anderes Szenario vor: Apache wird in einer virtualisierten Umgebung ausgeführt. Sie möchten jeden Benutzer trennen. Die Bereitstellung eines virtualisierten Dateisystems über ein chroot-Add-On für Apache (mod_chroot, mod_security usw.) ist die beste Option, um die größtmögliche Privatsphäre zwischen den Endbenutzern zu gewährleisten. Dies hilft auch, das Sammeln von Informationen zu verhindern, und bietet eine weitere Sicherheitsebene.

Einfach ausgedrückt ist es wichtig, Sicherheit in Schichten zu implementieren . Chroot ist möglicherweise einer von ihnen. Nicht jeder und jedes System hat den Luxus, Zugriff auf den Kernel zu haben, daher erfüllt chroot STILL einen Zweck. Es gibt eine Vielzahl von Anwendungen, bei denen die vollständige Systemvirtualisierung im Wesentlichen übertrieben ist.

Als Antwort auf Ihre Frage

Ich benutze nicht besonders CentOS, aber ich weiß, dass Bind jetzt seine Privilegien vor Operationen fallen lässt. Ich würde jedoch davon ausgehen, dass Bind aufgrund seiner Geschichte von Angriffsvektoren und potenziellen Schwachstellen chrooted ist.

Außerdem ist es sinnvoller, diese Anwendung automatisch zu chrooten, als nicht, da nicht JEDER Zugriff auf die vollständige Virtualisierung auf System- / Betriebssystemebene hat. Dies wiederum und theoretisch hilft dabei, der CentOS-Benutzerbasis Sicherheit zu bieten:

Betriebssystemanbieter gehen einfach nicht davon aus, dass jeder das gleiche System ausführt. Auf diese Weise können sie dazu beitragen, eine zusätzliche Sicherheitsebene auf ...

Es gibt einen Grund, warum so viele Anwendungen dies verwenden , und warum offensichtlich Ihr Betriebssystem dies standardmäßig tut: weil es als Sicherheitsmerkmal verwendet wird und funktioniert. Wie bereits erwähnt, ist es eine weitere Hürde, die der potenzielle Angreifer bei sorgfältiger Vorbereitung meistens überwinden muss, um den Schaden auf das Gefängnis der Chroot zu beschränken.

Dies ist teilweise auf historische Gründe zurückzuführen, als ältere Versionen von Bind schwere, häufige Sicherheitslücken aufwiesen. Ich habe mich nicht wirklich über das Thema auf dem Laufenden gehalten, aber ich wette, dass es seit den schlechten alten Tagen viel besser geworden ist.

Der andere Grund, der praktischere, ist, dass er in der Regel in einer internetbasierten Rolle eingesetzt wird und als solcher mehr Angriffen, Ermittlungen und allgemeinem Unfug ausgesetzt ist.

Daher gilt in Sicherheitsfragen oft die Faustregel: Sicher ist sicher, zumal der Aufwand für das Chrooten relativ gering ist.