%20in%20chroot%20so%20wichtig%20f%C3%BCr%20die%20Sicherheit%3F%20Oder%20vielleicht%20auch%20nicht%3F.png)
Ich spiele mit Bind und frage mich, warum diese Software beispielsweise in CentOS in Chroot läuft. Verstehen Sie mich nicht falsch, ich weiß, was Bind ist und wozu Chroot (Jail) da ist. Aber meine Hauptfrage ist, ob Bind ohne Chroot so unsicher ist?
Ist es wirklich schädlich, es ohne Jail einzurichten (mehr als jeder andere Dienst oder jede andere Software). In Systemen laufen viele Prozesse ohne Chroot und ich denke, dass die Kompromittierung eines dieser Prozesse sehr gefährlich ist, aber was macht Named gefährlicher als andere Software, die ohne Chroot läuft?
Antwort1
Wie @Some Guy erwähnt hat, müssen Sie dies aus historischer Perspektive betrachten.
Aus historischer Sicht war eine einzelne Hardware ein Dutzend oder so verschiedener Dienste unter einem einzigen Betriebssystem. Wenn ein Dienst kompromittiert wurde, war die gesamte Hardware kompromittiert.
Bei der Virtualisierung ist dies weit weniger ein Problem. Es ist zwar nicht unmöglich, aus einer VM auszubrechen, aber es ist alles andere als trivial. Es ist sicherlich schwieriger, aus einer VM auszubrechen, als für einen Prozess mit Root-Rechten aus einem Chroot auszubrechen. Meine Bind-Server laufen also auf ihrer eigenen VM. In diesem Fall macht ein Chroot wirklich nicht viel Sinn, da der Schaden allein dadurch, dass es sich um eine VM handelt, bereits begrenzt ist.
Ein Chroot ist ein sehr schwacher Versuch, so etwas wie eine VM zu erstellen. Chroots können jedoch von jedem Prozess mit Root-Rechten verlassen werden. Ein Chroot ist nicht als Sicherheitsmechanismus gedacht und funktioniert auch nicht als solcher. Ein Chroot mit einem BSD-Jail oder LXC bietet Ihnen Virtualisierung auf Betriebssystemebene und stellt Sicherheitsfunktionen bereit. Aber da es heutzutage so einfach ist, eine neue VM einer ganzen Maschine zu starten, lohnt sich der Aufwand für die Einrichtung oder das Erlernen der Verwendung der Virtualisierungstools auf Betriebssystemebene für diesen Zweck möglicherweise nicht.
Frühere Versionen von Bind haben keine Privilegien verloren. 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 verliert, würde jede Kompromittierung bedeuten, dass das gesamte System gefährdet sein könnte. Fast jede Software öffnet heutzutage ihre Sockets und führt andere Dinge aus, die Root-Privilegien erfordern. Anschließend wird der Benutzer, mit dem sie ausgeführt wird, in ein nicht privilegiertes Konto geändert. Sobald die Privilegien verloren sind, sind die Auswirkungen einer Kompromittierung für das Hostsystem viel geringer.
Antwort2
Die anderen Antworten sind ziemlich gut, erwähnen aber nicht das Konzept der Sicherheit in Schichten. Jede Sicherheitsschicht, die Sie Ihrem System hinzufügen, ist eine weitere Schicht, die ein Angreifer überwinden muss. Wenn Sie BIND in ein Chroot-System einfügen, entsteht ein weiteres Hindernis.
Angenommen, es gibt eine ausnutzbare Schwachstelle in BIND und jemand kann beliebigen Code ausführen. Wenn er sich in einem Chroot befindet, muss er aus diesem ausbrechen, bevor er irgendetwas anderes im System erreichen kann. Wie erwähnt sind Root-Berechtigungen zum Aufbrechen des Chroots erforderlich. BIND läuft nicht als Root und im Chroot sollen nur minimale Tools verfügbar sein, was die Optionen weiter einschränkt und im Wesentlichen nur Systemaufrufe übrig lässt. Wenn es keinen Systemaufruf zur Rechteausweitung gibt, muss der Angreifer Ihre DNS-Einträge einsehen.
Die oben genannte Situation ist, wie SomeGuy erwähnt, eher unwahrscheinlich. BIND weist heutzutage nur noch wenige Schwachstellen auf und diese sind meist auf DoS-Szenarien und nicht auf Remote-Ausführung beschränkt. Allerdings ist die Ausführung in einem Chroot auf vielen Betriebssystemen die Standardkonfiguration, sodass Sie wahrscheinlich keine Anstrengungen unternehmen müssen, um die leicht erhöhte Sicherheit aufrechtzuerhalten.
Antwort3
Präambel
ich höre immer wieder, wie Leute Missverständnisse aus dem ganzen Internet wiederholen.. deshalb werde ich versuchen, etwas Klarheit zu schaffen
erst einmal;wie viele zufällige Entdeckungen gab es, die einfach... aufgrund vonUrsache und Wirkung, wurde schließlich für etwas verwendetandereals sein beabsichtigter Zweck?
Was war und was ist ein Chroot-Jail?
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 ermöglichteSicherheitzum Basissystem sowie ein schnelles Testgerät, einschließlich einfacher Reinigung. Seitdem sind Jahre vergangen und das Konzept und die damit verbundenen Verwendungszwecke haben sich sicherlich ebenfalls geändert.
chroot wurde verwendeteffektivund befindet sich direkt in der Codebasis fürmehrereProgramme und Bibliotheken (z. B. openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot,und so viel mehr). Die Annahme, dass alle diese Mainstream-Anwendungen fehlerhafte Sicherheitslösungen implementiert haben, ist nurnicht wahr
Chroot ist eine Lösung zur Dateisystemvirtualisierung: nicht weniger und nicht mehr. Auch die Annahme, dass man leicht aus einem Chroot ausbrechen kann, ist nicht wahr ... solange man sich an die Richtlinien zum Ausführen von Prozessen innerhalb des Chroot-Jails hält.
einige Schritte zum Sichern Ihres Chroot-Jails
d.h. tunNICHTFühren Sie Prozesse als ROOT aus. Dies könnte einen Root-Eskalationsvektor öffnen (was sowohl innerhalb als auch außerhalb des Chroots zutrifft). Führen Sie keinen Prozess ausinnendas Chroot, mit dem gleichen Benutzer wie ein anderer Prozessdraußendas Chroot. Trennen Sie jeden Prozess und Benutzer in seinem eigenen Chroot, um Angriffsflächen zu begrenzen und Privatsphäre zu gewährleisten. Mounten Sie nur notwendige Dateien, Bibliotheken und Geräte. Und schließlich ist Chroot KEIN Ersatz für die Basissystemsicherheit. Sichern Sie das System in seiner Gesamtheit.
noch ein wichtiger Hinweis:Viele Leute denken, dass OpenVZ kaputt ist oder dass es einer vollständigen Systemvirtualisierung nicht ebenbürtig ist. Sie gehen zu dieser Annahme über, weil es sich im Wesentlichen um ein Chroot mit einer Prozesstabelle handelt, die sterilisiert werden muss und auf der Hardware und den Geräten Sicherheitsmaßnahmen vorhanden sind.am meistendavon können Sie in einem Chroot implementieren.
nicht jeder Administrator verfügt über das erforderliche Wissen, um alle notwendigen Kernel-Parameter auf einem dedizierten Server oder bei vollständiger Systemvirtualisierung zu sichern. Das bedeutet, dass Ihre Kunden durch die Bereitstellung von OpenVZ eine viel geringere Angriffsfläche haben, die sie abdecken und sichern müssen, bevor sie ihre Anwendungen bereitstellen. Ein guter Host wird diese Parameter gut sichern, und das wiederum ist nicht nur für alle auf dem Node oder im Rechenzentrum besser, sondern für das gesamte Internet ...
wie gesagt, das Chroot ermöglicht die Virtualisierung des Dateisystems. Sie müssen sicherstellen, dass keine „Setuid“-ausführbaren Dateien, unsicheren Anwendungen, Bibliotheken, hängenden, besitzerlosen symbolischen Links usw. vorhanden sind. Wenn der Angreifer Bind kompromittieren KÖNNTE, müsste er das virtuelle Dateisystem nach etwas absuchen, das einen Pufferüberlauf verursachen könnte, mit Datei-Deskriptoren spielen oder auf andere Weise etwas kompromittieren, das sich innerhalb des Chroot befindet. Dabei entkommt er dem Jail normalerweise durch eine Rechteausweitung oder durch Einschleusen seiner Nutzlast in das Basissystem.
Wenn dies passiert, ist es normalerweise das Ergebnis eines fehlerhaften Updates, eines Zero-Day-Exploits oderidiomatischer menschlicher Fehler.
warum chroot immer noch verwendet wird, im Gegensatz zur vollständigen Systemvirtualisierung
Stellen Sie sich folgendes Szenario vor: Sie betreiben einen virtuellen privaten Server, wobei auf dem Hostknoten OpenVZ läuft. Siekann nichtalles ausführen, was auf Kernel-Ebene funktioniert. Dies bedeutet auch, dass Sie die Betriebssystemvirtualisierung nicht verwenden können, um Prozesse zu trennen und zusätzliche Sicherheit bereitzustellen. SieMUSSVerwenden Sie zu diesem Zweck chroot.
darüber hinaus ist chroot auf jedem System nachhaltig, unabhängig von den verfügbaren Ressourcen. Einfach ausgedrückt weist es den geringsten Overhead aller Virtualisierungstypen auf. Dies bedeutet, dass es auf 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 größtmögliche Privatsphäre zwischen Endbenutzern zu gewährleisten. Dies hilft auch dabei, das Sammeln von Geheiminformationen zu verhindern und bietet eine weitere Sicherheitsebene.
Einfach ausgedrückt ist es wichtig, Sicherheit inLagen. Chroot ist möglicherweise einer davon. Nicht jeder und jedes System hat den Luxus, Zugriff auf den Kernel zu haben. Daher ist ChrootTROTZDEMdient 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 unbedingt, weiß aber, dass Bind jetzt seine Privilegien vor Operationen aufgibt. Ich würde jedoch aufgrund der zahlreichen Angriffsmethoden und potenziellen Schwachstellen annehmen, dass Bind chrootet.
außerdem ... ist es sinnvoller, diese Anwendung automatisch zu chrooten, als es nicht zu tun, da nicht JEDER Zugriff auf die vollständige Virtualisierung auf System-/Betriebssystemebene hat. Dies wiederum trägt theoretisch dazu bei, die Sicherheit der CentOS-Benutzerbasis zu gewährleisten:
Anbieter von Betriebssystemen gehen nicht einfach davon aus, dass alle dasselbe System verwenden. Auf diese Weise können sie dazu beitragen, insgesamt eine zusätzliche Sicherheitsebene bereitzustellen ...
es gibt einen Grund dafürso viele Anwendungen nutzen dies, und warum Ihr Betriebssystem dies offensichtlich standardmäßig tut: weil es als Sicherheitsfunktion verwendet WIRD und FUNKTIONIERT. Bei sorgfältiger Vorbereitung ist es, wie bereits erwähnt, eine weitere Hürde, die der potenzielle Angreifer überwinden muss – wodurch der Schaden in den meisten Fällen nur auf das Chroot-Jail beschränkt wird.
Antwort4
Dies hat teilweise historische Gründe, da ältere Versionen von Bind häufig schwerwiegende Sicherheitslücken aufwiesen. Ich bin diesbezüglich nicht wirklich auf dem Laufenden, würde aber wetten, dass es seit den schlechten alten Zeiten viel besser geworden ist.
Der andere, eher praktische Grund besteht darin, dass es typischerweise in einer internetbasierten Rolle eingesetzt wird und als solche stärker Angriffen, Ausspähungen und allgemeinem Unfug ausgesetzt ist.
Daher gilt in Sicherheitsfragen oft die Faustregel: Vorsicht ist besser als Nachsicht, insbesondere, da der Aufwand für das Chroot-Verfahren relativ gering ist.