RootForum Community

Hallo allerseits,

ich habe mal wieder eine Sicherheitsfrage:
Man liest ja ständig, dass es fast kein Problem ist ein chroot jail zu knacken und auf das eigentliche Dateisystem zuzugreifen.
Da ich eine chroot Umgebung eigens für Benutzer SSH zugänge habe (für root gibt es einen eigenen Zugang auf einem anderen port) würde ich gerne wissen welche möglichkeiten man hat diese Umgebung vor solchen ausbrüchen zu sichern?

Faulerweise besteht das chroot Dateisystem aus einem minimal debian system, so dass ich dort auch apt zum installieren von software verwenden kann.
Daher würde ich gerne ein paar Sachen wissen:
Wie kann man z.B. die Verwendung des root Benutzers in der Umgebung komplett verhindern? Die einzige möglichkeit als root dort zu agieren soll es sein von ausserhalb in die Umgebung hinnein zu chroot'en. Innerhalb der Umgebung soll man diese Möglichkeit nicht haben.
Wenn man in der Umgebung keinen Zugriff mehr auf den root Benutzer hat, kann man es dann als größtenteils sicher ansehen? Oder gibt immer noch Möglichkeiten aus der Umgebung heraus zu kommen? Und vor allem: Wie kann ich das verhindern/erschweren?

Danke :)
Dennis

GRSecurity beinhaltet einige schöne Erweiterung für denn chroot(2) Systemaufruf. Ebenso RSBAC, wobei ich mit letzterem keine Erfahrungen habe.

Man kann z.B. die GRSecurity Patches verwenden, die bringen nochmal einen Schutz mit. Ob er reicht ist jetzt mal dahingestellt, aber 99% der Scriptkiddies werden verzweifeln.
http://www.securityfocus.com/infocus/1551

Alternativ bleibt nur das Virtualisieren und dort die Chroots bauen. So bleibt wenigstens das Hostsystem unberührt und das Backup einspielen geht dank Snapshots schneller wenn doch mal jemand aus dem Chroot ausgebrochen ist. Xen und Co. sind an sich so was wie Jails in denen ein eigenes OS läuft. Wenn ich auf dem Hostsystem alles so einrichte, das nur die freigegebenen Ports funktionieren, kein Mailer darin läuft und das Nachinstallieren von Software freigeschaltet werden muss, also freischalten der Online Repositorys und sonst keine ausgehende Verbindung wenn es nicht sein muss, dann dürfte die Chance gegen Null laufen das etwas schlimmes passiert. Im Grunde genommen setze ich das Hostsystem nur mit der SSH auf und alle Dienste laufen in einer Xen Domain, die Ports werden über die Bridge geleitet und das Hostsystem gibt an welche Ports und Adressen angefahren werden dürfen. Das wäre der härteste Aufwand, aber ich kann das System abkapseln.

Bei beidem solltest du aber nicht vergessen die Dienste anständig einzurichten, Chroots, Jails und Virtualisierung sind keine Freifahrtscheine für Fahrlässigkeit

Ob er reicht ist jetzt mal dahingestellt

Er reicht.

aber 99% der Scriptkiddies werden verzweifeln

Setz mal ein Komma und ein paar Neuner dahinter. Dann liegst du erheblich besser.

Danke für die Antworten.

Das mit Xen habe ich mir auch schon überlegt, aber das wäre mir doch ein wenig zu viel Aufwand. Zumal man dann direkt mehrere Systeme zu pflegen hat, die chroots kann man z.B. automatisiert updaten, das wird bei virtualisierten systemen schwierig wenn ich das richtig sehe.

Aber die GRSecurity Patches werde ich mir auf jeden Fall anschauen danke für den link :D

Natürlich achte ich auf auf die Konfiguration der Services, die chroots sollen ja nur zur Schadensbegrenzung im Extremfall da sein.

Zuletzt noch eine Frage:
Wie sieht das mit dem "deaktivieren" des root Benutzers in den chroots. Ein 128 stellen langes Zufallspasswort, das selbst ich nicht mehr weiß sollte schwer zu knacken sein, aber ich würde mich sicherer fühlen, wenn man innerhalb des chroots generell nicht zum root mutieren kann.
Genügt es für SSH die shell in /etc/passwd auf /bin/false zu setzen um ein login allgemein zu verhindern (root login kann man ja explizit verbieten, aber es geht ums verbieten spezieller benutzer).

danke danke, wirklich ein tolles Forum hier :)
Dennis

xardias wrote:Das mit Xen habe ich mir auch schon überlegt, aber das wäre mir doch ein wenig zu viel Aufwand. Zumal man dann direkt mehrere Systeme zu pflegen hat, die chroots kann man z.B. automatisiert updaten, das wird bei virtualisierten systemen schwierig wenn ich das richtig sehe.

Deshalb habe ich mich für openVZ entschieden. Auf meinem Testsystem läuft es inzwischen ganz gut (da aber noch ohne jede Last). Auf meinem Root werde ich es dann wohl in den nächsten Wochen einrichten und sehe dann wie es sich in der Praxis bewährt.

xardias wrote: Das mit Xen habe ich mir auch schon überlegt, aber das wäre mir doch ein wenig zu viel Aufwand. Zumal man dann direkt mehrere Systeme zu pflegen hat, die chroots kann man z.B. automatisiert updaten, das wird bei virtualisierten systemen schwierig wenn ich das richtig sehe.

Das wäre auch nur für Gameserver oder IRC Sachen gedacht, wenn ich ausgereifte Software einsetze kann da sowisso nur wenig passieren. Psybnc und Co würde ich aber wirklich lieber in eine Virtuelle Umgebung stecken, kann ich einfacher wiederherstellen wenn da was passiert, und dort kann ich ja mein Chroot einrichten.

xardias wrote: Wie sieht das mit dem "deaktivieren" des root Benutzers in den chroots. Ein 128 stellen langes Zufallspasswort, das selbst ich nicht mehr weiß sollte schwer zu knacken sein, aber ich würde mich sicherer fühlen, wenn man innerhalb des chroots generell nicht zum root mutieren kann.
Genügt es für SSH die shell in /etc/passwd auf /bin/false zu setzen um ein login allgemein zu verhindern (root login kann man ja explizit verbieten, aber es geht ums verbieten spezieller benutzer).

Naja, in einem Chroot benötige kein Rootuser, dort steht nur der Benutzer, mit dem der Dienst läuft, in der /etc/passwd und /etc/shadow und gut isses. Im Hauptsystem würde ich ganz einfach Rootlogin in der SSH sperren und einen User mit Preshared Keys anlegen und einem normalen Passwort, es bricht sowisso niemand über die SSH ein, das ist immer verwendung von Ressourcen wenn das einer versucht.

So Long