Wie sicher ist ein webserver rootjail?

[mattiass]

@MatthiasS
Also an sich dürfte die Frikelei ja wie bei jedem BSD sein oder? Wie es halt bei BSD Crew mal beschrieben wurde.

Nein. Eher wie bei der Vorbereitung eines Images für CF-Karten:

http://devcorner.old.mattiasschlenker.de/cms.24.html

Außer dass man halt eine normale Welt statt einer minimalen installiert...

[captaincrunch]

@CC
Hast du schonmal mit RSBAC gearbeitet?

Im Zuge meiner "Entwicklertätigkeit" bei Adamantix habe ich mich oft mit RSBAC auseinandersetzen müssen, war dort aber auch in der glücklichen Lage, direkt "an der Quelle" zu sitzen, da Amon Ott (der Initiator und Hauptentwickler von RSBAC) sehr stark dort involviert ist / war. Dort habe ich dann auch entsprechend gesicherte System "gesehen", und war mächtig beeindruckt.
Leider habe ich mich selbst zu enig pratkisch damit beschäftigt, werde das aber sicherlich bei Gelegenheit noch einmal ganz massiv nachholen.

[tomotom]

Ich fasse dann mal die Aussagen der interessanten Diskussion zusammen:

* chroot ist kein sicherer Weg seine Daten zu schützen. Nach einem Angriff landet der Angreifer mit webserver Rechten im chroot. Von dort kann er auf Netzwerkverbindungen und Gerätedateien zugreifen und evt. auch die Dateisystemgrenze des chroos überschreiten.

* Unklar ist ob ein Ausbruch auch ohne root Rechte also auch mit webserver Rechten stattfinden kann.

* Chroot BSD-jails sind wesentlich sicherer. Weitere sichere allerdings sehr speicherintensiche Alternativen wären Xen Konzepte.

* Mit RBAG Konzepten wie Rsecurity, RSBAC oder SElinux können auch Linux chroots sicher sein.

* Das chroot bzw. RBAG Konzept kommt erst nach einem erfolgten Einbruch zum Einsatz und kann dem nach nur ein Teil eines vernünftigen Sicherheitskonzeptes sein.

* Von 10.000 Angreifern werden 9.999 bereits von einer Level-5-Firewall wie mod_security gestoppt.

* Manche Forenteilneher haben „anständiges Shellcode Verzeichnisse" mit unterschiedlichen Versionen von braek roots rumliegen... Anderen können c und besteln solche scripte „recht fix zusammen". Fix zusammen gebalstelte Sripte können auch als Forenservice verstanden werden. Dieser Service existiert jedoch immer nur für 1 Stunde. :-)

* Mathias und jfreund testen in Nürnberch wie man FreeBSD 6.1 auf einem Rootie auf einem Rootie ohne RemoteCKonsole installiert. Mathias schreibt über dieses Thema auch noch ein Howto.

Braucht man, um aus einem Linux chroot auszubrechen, tatsächlich erst einmal rootrechte :?:

...Insgesamt darf aber wohl behauptet werden, dass SELinux zur Zeit (gerade was Debian angeht) noch die beste "Unterstützung" genießt.

Also welches Debian meinst Du denn? So weit ich weiß gibt es eine Debian Unterstützung erst ab etch.

...Hier standen für ca 1h ca 10 Zeilen c-code mit deren Hilfe aus einer Chroot ausgebrochen werden kann...

Verständlich, dass Du die Anleitung zum break chroot wieder weggenommen hast - verwendest Du selber chroots auf Deinen Servern? :-)

[aldee]

* Unklar ist ob ein Ausbruch auch ohne root Rechte also auch mit webserver Rechten stattfinden kann.

Kann er nicht.

...Hier standen für ca 1h ca 10 Zeilen c-code mit deren Hilfe aus einer Chroot ausgebrochen werden kann...

Verständlich, dass Du die Anleitung zum break chroot wieder weggenommen hast - verwendest Du selber chroots auf Deinen Servern? :-)

Nach allem, was "lucki2" zu diesem Thread beigetragen hat, handelte es sich hier wohl leider lediglich um einen Trollversuch.

[lucki2]

Antwort: Ja ich verwende chroot viel und oft. Es ist schon ein Schutz, aber nicht der Bunker, der manchmal erhofft wird. Das sind Eigenschaften einer Chroot, die nichts schlechtes oder fehlerhaftes einer Chroot sind, mehr ihr Charakter. Chroot setze ich auch recht häufig für andere Dinge als zum sichern ein etwa als Compilierumgebung oder als Testumgebung um Probleme reproduzieren zu können oder trivial um geschraddelte Systeme wiederzubeleben - da bin ich über Eigenschaften von chroot dankbar.
Zur Sicherheit ist Chroot auch geeignet. Ihre Aufgabe ist in meinen Augen dabei mehr einen Enbrecher möglichst wenig Werkzeug zur Verfügung zu stellen als die, einer unüberwindbaren Hürde. Das ist aber imho schon sehr viel. Allein auf diesen Unterschied aufmerksam zu machen war mein Ziel.

Zu Deiner Zusammenfassung: wenn es Dir gelingt aus einer Chroot auszubrechen hast Du danach normalerweise root Rechte.

Das ich den Code nicht so hier stehen lassen wollte, ist weniger um ein Geheimnis draus zu machen. Wer so etwas sucht findet das - ich denke aber Werbeanzeigen muß man mit sowas auch nicht Schalten. Dieses Forum ist a) sehr gut Indiziert b) auch von Leuten, die so was einfach auf spaßeshalber ausprobieren, weil sie gerade drüberstolpern besucht.

@aldee: so funktionierts bei mir nicht, ich mache keinen Finger für jemanden krumm, der mich so von der Seite anmacht(von der Seite anmachen: meinetwegen - aber dann bitte nicht erwarten, daß ich mich groß kümmere). schon zu viel der Worte.

[tomotom]

Es sei nur nebenbei angemerkt, dass für das Ausbrechen aus einem chroot Rootrechte erforderlich sind. Ist dein Perl-Binary setuid root?

* Unklar ist ob ein Ausbruch auch ohne root Rechte also auch mit webserver Rechten stattfinden kann.

Kann er nicht.

Zu Deiner Zusammenfassung: wenn es Dir gelingt aus einer Chroot auszubrechen hast Du danach normalerweise root Rechte.

Was denn nun?
Brauch man Rootreche, um aus einem chroot ausbrechen zu können, also schon vor der Bruch, man hat ja noch webserver Rechte oder bekommt man die während des Bruchs durch das script oder wie?

Ich muss das wohl doch mal selber ausprobieren. Wie war noch mal der Code lucki2? :-)

[mattiass]

Ich muss das wohl doch mal selber ausprobieren. Wie war noch mal der Code lucki2? :-)

Lucki fängt schon an, sich selbst zu widersprechen. Die zwei Aussagen:

a) es benötigt nur ein paar Zeilen C, um auszubrechen

b) nach einem Ausbruch hat man i.d.R. Rootrechte

würden zusammen betrachtet bedeuten, dass man ohne Chroot sicherer fährt, da ja ein einfacher Ausbruch gleich Rootrechte beschert. Ohne Chroot ist aber kein Ausbruch und damit keine Rootrechte für den gehackten Webserver möglich. 80

Anyway, hier um dieses Detail weiter lange herum zu diskutieren macht wenig Sinn, da ein normaler Chroot eben so ziemlich alles zulässt außer den direkten Dateisystemzugriff. Da zudem Chroots ursprünglich nicht für Sicherheitszwecke bestimmt waren, sollten sie vorzugsweise mit Erweiterungen eingesetzt werden, die potentiell gefährliche Syscalls sperren.

[Roger Wilco]

Für den Democode von lucki2 sind schon vorher Rootrechte bzw. die Capability CAP_SYS_CHROOT (siehe chroot(2)) notwendig, sonst funktioniert es nicht.

Aber mal ehrlich, wieviele Kisten mit alten Kerneln sind derzeit noch unterwegs? Es ist sicherlich nicht trivial aber auch nicht unmöglich, die UID 0 in einer chroot-Umgebung zu erhalten (je nach Fähigkeit des Administrators und des Angreifers). Aber wenn ein Angreifer diese Hürde gemeistert hat, kommt er i. d. R. auch aus der chroot-Umgebung raus, wenn diese nicht weiter gehärtet ist.

[sledge0303]

Was meinst du wie viele Server mit altem Kernel unterwegs sind ohne jemals aktualisiert oder ein Patch gesehen zu haben. Darauf eine Chroot Umgebung schaffen ist zwar eine Hürde, jedoch nicht schwer UID 0 für den Angreifer zu erreichen.
mod_security ist eine Option zu verhindern das jemand was installieren kann (siehe Beispiel 10.000-9.999).
Es gilt also für den User des Apachen oder Lighty restriktiven einzustellen und entsprechend zu sichern. Darunter u.a. das Sperren einiger Befehle für diesen User.

Um das alles zu erreichen, gilt es im Voraus Sicherheitslücken zu erkennen und zu beheben. Beim <neuen> Kernel fängt es an...
Man kann seinen Server und dessen Konfiguration wunderbar testen, indem man sich auf diverse Seiten unserer "Gegner" umsieht. Dort kann man i.d.R. die neusten Exploits runterladen und auf einer lokalen Testumgebung die Auswirkungen feststellen.
Aus diesem Grund läuft jeweils eine 1:1 Kopie, natürlich ohne Kundensites ;), auf meinem lokalen Testrechner.
Die Virtualisierungstechniken und BSD könnten Alternativen sein.
XeN, openVZ und FreeBSD sind derzeit ebenfalls auf einer Testumgebung installiert, um sich aber direkt ein Urteil bilden zu können muss man alle 3 Alternativen ausgiebig testen und urteilen in wie fern diese ggü. zur Sicherheit meiner bisherigen Chroots stehen.
Jetzt ein allgemeines Urteil zu treffen wäre engstirnig, denn ich lasse mich gerne eines besseren belehren. Dafür sind Testumgebungen und Diskussionen wie diese da, oder?

Just my2ct

[mattiass]

Die Virtualisierungstechniken und BSD könnten Alternativen sein.
XeN, openVZ und FreeBSD sind derzeit ebenfalls auf einer Testumgebung installiert, um sich aber direkt ein Urteil bilden zu können muss man alle 3 Alternativen ausgiebig testen und urteilen in wie fern diese ggü. zur Sicherheit meiner bisherigen Chroots stehen.

Die Sicherheit der genannten Technologien gegenüber Chroots dürfte weniger Thema einer großen Diskussion sein: die Isolierung der Instanzen steigt in der Reihenfolge Chroot, BSD-Jail, OpenVZ, Xen. In dieser Reihenfolge steigt aber auch der Overhead beim Arbeitsspeicher und der potentielle Overhead bei Festplattenbedarf und Speicherbedarf.

Da man nicht alles auf einmal haben kann, muss man Kompromisse eingehen, beispielsweise Xen-Domains, die ihrerseits wieder (gehärtete?) Chroots enthalten.

[aldee]

Was meinst du wie viele Server mit altem Kernel unterwegs sind ohne jemals aktualisiert oder ein Patch gesehen zu haben. Darauf eine Chroot Umgebung schaffen ist zwar eine Hürde, jedoch nicht schwer UID 0 für den Angreifer zu erreichen.

Och ja. Aber die Wahrscheinlichkeit, dass sich jemand eine chroot-Umgebung baut und danach hoffnungslos veraltete Kernel auf der Kiste rennen lässt, ist doch bedeutend geringer, als dass überhaupt kein Sicherheitskonzept existiert.

[grandcat]

Aber was mich noch interessieren würde, ist, was überhaupt dann mit den ganzen vServern ist, denn bei diesen kann man ja z.B. den Kernel nicht antasten, so ist ein Kernelupdate ja nicht möglich. Sind die Anbieter nun verpflichtet, die neuen Versionen selber aufzuspielen oder dürfen diese den Kernel "vergammeln" lassen? :?

[Joe User]

Sind die Anbieter nun verpflichtet, die neuen Versionen selber aufzuspielen oder dürfen diese den Kernel "vergammeln" lassen? :?

Nein, Ja. (Sofern es im Vertrag nicht explizit geregelt ist...)

[mattiass]

Nein, Ja. (Sofern es im Vertrag nicht explizit geregelt ist...)

Nunja, jeder Vermieter hat dafür zu sorgen, dass die Mietsache einen ordentlichen Zustand hat. Beim vServer kann man daraus schon implizit ableiten, dass der Hoster kritische Kernel updaten muss, wenn Stabilität oder Sicherheit akut gefäherdet sind.

[grandcat]

Bei meinem Hoster steht der Kernel noch bei Version 2.6.7 (Virtuozzo). Das ist natürlich hinsichtlich der Sicherheit "ganz toll" :roll: . Ist aber der Anbieter eigentlich gezwungen, den Kernel zu erneuern, wenn der Kunde es ausdrücklich wünscht? :? (Tut mir leid, aber diese vServer regen mich langsam auf)

[mattiass]

Bei meinem Hoster steht der Kernel noch bei Version 2.6.7 (Virtuozzo). Das ist natürlich hinsichtlich der Sicherheit "ganz toll" :roll: . Ist aber der Anbieter eigentlich gezwungen, den Kernel zu erneuern, wenn der Kunde es ausdrücklich wünscht? :? (Tut mir leid, aber diese vServer regen mich langsam auf)

Es kann durchaus sein, dass dieser Kernel gegen kritische Fehler gepatcht wurde. Nur aufgrund neuer Features und mäöglicherweise etwas besserer Performance kannst Du keinen neuen Kernel verlangen.

Und aus einem "kaputten" Kernel, der kompromitierte Daten etc. zur Folge hat, lässt sich bestenfalls ein Sonderkündigungsrecht ableiten.

[tomotom]

...Dann testen wir mit "jfreund" in Nürnberch und dann schreibe ich ein Howto.
..

Du solltest besser ein Hotow über den Einsatz von RSBAC unter Debian schreiben und wie man sicheres chroot mit Linux hinbekommt...
Hatte ich ganz vergessen zu erwähnen :)

Was ich Dich auch noch fragen wollte ist hier irgendwo untergegangen:
Klappt das mit den Kernelpatches von RSBAC auch für die xenkernel?

Und weiter: Wie sieht es mit den Resourcen und der Performance eines mit RSBAC laufenden systems aus?

Aber ich hoffe ja, Du schreibst das alles in dein bald erscheinendes Howto...