Lösung 1:
Wie @Some Guy erwähnt hat, muss man dies aus historischer Perspektive betrachten.
Aus historischer Sicht war eine einzelne Hardware ein Dutzend verschiedener Dienste unter einem einzigen Betriebssystem. Wenn ein Dienst kompromittiert wurde, wurde alles auf dieser Hardware kompromittiert.
Mit der Virtualisierung ist dies weitaus weniger ein Problem. Es ist zwar nicht unmöglich, aus einer VM zu entkommen, aber alles andere als trivial. Es ist sicherlich schwieriger, aus einer VM auszubrechen, als für einen Prozess, der mit Root-Rechten läuft, aus einer Chroot auszubrechen. Meine Bindungsserver laufen also auf einer eigenen VM. Es macht in diesem Fall wirklich nicht viel Sinn für eine Chroot, da der Schaden bereits dadurch begrenzt wird, 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 werden. Eine Chroot ist nicht als Sicherheitsmechanismus gedacht und funktioniert nicht. Ein Chroot mit einem BSD-Gefängnis oder LXC bietet Ihnen eine Virtualisierung auf Betriebssystemebene und stellt Sicherheitsfunktionen bereit. Aber heutzutage, da es so einfach ist, eine neue VM einer ganzen Maschine hochzufahren, lohnt es sich möglicherweise nicht, die Einrichtung vorzunehmen oder zu lernen, wie man die Virtualisierungstools auf Betriebssystemebene für diesen Zweck verwendet.
Frühere Versionen von bind haben keine Berechtigungen gelöscht. 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 startet und keine Privilegien aufgibt, würde jede Kompromittierung bedeuten, dass das gesamte System kompromittiert werden könnte. Fast jede Software wird heutzutage anfangen, ihre Sockets zu öffnen und andere Dinge zu tun, die Root-Rechte erfordern, dann ändern sie den Benutzer, den sie ausführen, in ein nicht privilegiertes Konto. Sobald die Privilegien gelöscht werden, ist die Auswirkung einer Kompromittierung für das Hostsystem viel geringer.
Lösung 2:
Die anderen Antworten sind ziemlich gut, erwähnen aber das Konzept der Sicherheit in Schichten nicht. Jede Sicherheitsebene, die Sie Ihrem System hinzufügen, ist eine weitere Ebene, die ein Angreifer überwinden muss. Das Einfügen von BIND in eine Chroot fügt ein weiteres Hindernis hinzu.
Angenommen, es gibt eine ausnutzbare Schwachstelle in BIND und jemand kann beliebigen Code ausführen. Wenn sie sich in einer Chroot befinden, müssen sie aus dieser ausbrechen, bevor sie zu irgendetwas anderem im System gelangen. Wie bereits erwähnt, sind Root-Rechte für das Chroot-Breaking erforderlich. BIND läuft nicht als root, und es sollen minimale Tools in der Chroot verfügbar sein, die die Optionen weiter einschränken und im Wesentlichen nur Systemaufrufe übrig lassen. Wenn es keinen Systemaufruf zur Eskalation von Berechtigungen gibt, bleibt der Angreifer beim Durchsehen Ihrer DNS-Einträge hängen.
Die oben erwähnte Situation ist etwas unwahrscheinlich, wie SomeGuy erwähnt, BIND hat heutzutage ziemlich wenige Schwachstellen und sie sind meistens eher auf DoS-Szenarien als auf Remote-Ausführung beschränkt. Das Ausführen in einem Chroot ist jedoch die Standardkonfiguration auf einigen Betriebssystemen, daher ist es unwahrscheinlich, dass Sie sich anstrengen müssen, um die immer noch so leicht erhöhte Sicherheit aufrechtzuerhalten.
Lösung 3:
Präambel
Ich höre immer wieder, wie Leute aus dem ganzen Internet Missverständnisse wiederholen. Daher werde ich versuchen, etwas klarzustellen
zunächst; wie viele zufällige Entdeckungen gab es, die einfach ... auf Ursache und Wirkung zurückzuführen sind , wurde schließlich für etwas anderes verwendet als der beabsichtigte Zweck?
was war und was ist ein Chroot-Gefängnis
Chroot wurde ursprünglich entwickelt, um das Stammverzeichnis für den Prozess oder Benutzer zu ändern (ideal zum Kompilieren von Software aus unbekannten Quellen). dies sorgte für Sicherheit zum Basissystem, sowie ein schnelles Prüfstandsgerät, inklusive einfacher Reinigung. Seitdem sind Jahre vergangen, und das Konzept und die implizierten Verwendungen haben sich sicherlich ebenfalls geändert.
chroot wurde effektiv verwendet , und ist direkt in der Codebasis für mehrere Programme und Bibliotheken (z.B. openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot, und so viel 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 Virtualisierung von Dateisystemen:nicht weniger und nicht mehr. Die Annahme, dass Sie leicht aus einer Chroot ausbrechen können, ist ebenfalls nicht wahr ... solange Sie sich an die Richtlinien zum Ausführen von Prozessen innerhalb des Chroot-Gefängnisses halten.
einige Schritte, um Ihr Chroot-Gefängnis zu sichern
d.h. NICHT Prozesse als ROOT ausführen. dies könnte einen Root-Eskalationsvektor öffnen (was auch innerhalb oder außerhalb der Chroot zutrifft). keinen Prozess innerhalb ausführen die Chroot, wobei derselbe Benutzer wie ein anderer Prozess außerhalb verwendet wird die Chroot. Trennen Sie jeden Prozess und Benutzer in seinen eigenen Chroot, um Angriffsflächen einzuschränken und Privatsphäre zu gewährleisten. Mounten Sie nur notwendige Dateien, Bibliotheken und Geräte. schließlich ist chroot KEIN Ersatz für die Basissystemsicherheit. System in seiner Gesamtheit sichern.
noch ein wichtiger Hinweis: Viele Leute denken, dass OpenVZ defekt ist oder dass es im Vergleich zur vollständigen Systemvirtualisierung nicht gleichwertig ist. Sie gehen von dieser Annahme aus, weil es sich im Wesentlichen um einen Chroot mit einem sterilisierten Prozesstisch handelt. mit Sicherheitsmaßnahmen auf Hardware und Geräten. die meisten davon können Sie in einer Chroot implementieren.
nicht jeder Admin hat das erforderliche Wissen, um alle notwendigen Kernel-Parameter auf einem dedizierten Server oder unter vollständiger Systemvirtualisierung zu sichern. Das bedeutet, dass die Bereitstellung von OpenVZ bedeutet, dass Ihre Kunden viel weniger Angriffsfläche haben, die sie versuchen, abzudecken und abzusichern, bevor sie ihre Anwendungen bereitstellen. Ein guter Host wird gute Arbeit leisten, diese Parameter zu sichern, und das wiederum ist nicht nur für alle auf dem Knoten oder im Rechenzentrum besser, sondern für das Internet als Ganzes ...
Wie bereits erwähnt, bietet die Chroot Dateisystemvirtualisierung. Sie müssen sicherstellen, dass es keine ausführbaren Setuid-Dateien, unsichere Anwendungen, Bibliotheken, baumelnde Besitzerlose Symlinks usw. gibt. Wenn der Angreifer eine Kompromittierungsbindung eingehen könnte, müsste er das virtuelle Dateisystem nach Pufferüberlauf durchsuchen, mit Dateideskriptoren spielen oder auf eine andere Art und Weise etwas kompromittieren, das sich innerhalb der Chroot befindet – normalerweise durch Privilegien-Eskalation oder durch Einschleusen seiner oder ihrer Nutzlast in das Basissystem aus dem Gefängnis entkommen.
Wenn dies passiert, ist es normalerweise das Ergebnis eines fehlerhaften Updates, eines Zero-Day-Exploits oder eines idiomatischen menschlichen Fehlers .
warum immer noch Chroot verwendet wird, im Gegensatz zur vollständigen Systemvirtualisierung
Betrachten Sie dieses Szenario:Sie betreiben einen Virtual Private Server, wobei der Hostknoten OpenVZ ausführt. Sie können einfach nicht Führen Sie alles aus, was auf Kernel-Ebene funktioniert. Dies bedeutet auch, dass Sie die Betriebssystemvirtualisierung nicht verwenden können, um Prozesse zu trennen und zusätzliche Sicherheit zu bieten. Sie müssen also MÜSSEN Verwenden Sie zu diesem Zweck chroot.
Darüber hinaus ist chroot auf jedem System nachhaltig, unabhängig von den verfügbaren Ressourcen. Einfach ausgedrückt, es hat 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:Sie haben Apache 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.) wäre die beste Option, um ein Höchstmaß an Privatsphäre zwischen Endbenutzern zu gewährleisten. Dies hilft auch, das Sammeln von Informationen zu verhindern, und bietet eine weitere Sicherheitsebene.
Einfach gesagt, es ist 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, deshalb chroot STILL dient einem Zweck. Es gibt eine Vielzahl von Anwendungen, bei denen eine vollständige Systemvirtualisierung im Wesentlichen übertrieben ist.
Als Antwort auf Ihre Frage
Ich verwende CentOS nicht besonders, aber ich weiß, dass Bind jetzt seine Privilegien vor dem Betrieb aufgibt. 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 trägt theoretisch dazu bei, der CentOS-Benutzerbasis Sicherheit zu bieten:
Betriebssystemanbieter gehen einfach nicht davon aus, dass alle dasselbe System verwenden. Auf diese Weise können sie dazu beitragen, eine zusätzliche Sicherheitsebene bereitzustellen...
Es gibt einen Grund, warum so viele Anwendungen dies verwenden , und warum Ihr Betriebssystem dies offensichtlich standardmäßig tut:weil es als Sicherheitsfunktion verwendet wird und funktioniert. Bei sorgfältiger Vorbereitung ist dies, wie bereits erwähnt, eine weitere Hürde, die der potenzielle Angreifer überwinden muss – meistens beschränkt er den Schaden auf das Chroot-Gefängnis.
Lösung 4:
Dies ist teilweise auf historische Gründe zurückzuführen, als ältere Versionen von Bind schwerwiegende, häufige Sicherheitslücken aufwiesen. Ich habe mich über das Thema nicht wirklich auf dem Laufenden gehalten, aber ich würde wetten, dass es seit den schlechten alten Tagen viel besser geworden ist.
Der andere, praktischere Grund ist, dass es normalerweise in einer Rolle mit Internetzugriff eingesetzt wird und als solche für mehr Angriffe, Sondierungen und allgemeines Unheil anfällig ist.
Daher gilt wie so oft in Sicherheitsfragen die Faustregel:sicher ist sicher, zumal der Aufwand für das Chrooten relativ gering ist.