Wie sicher ist ein webserver rootjail?

[tomotom]

Auf der Suche nach einem vernünftigen Sicherheitskonzept bin ich immer wieder auf einen webserver im chroot gestoßen. Die Grenzen des rootjails sollen jedoch knackbar sein.

Schafft es nun ein Angreifer durch einen software Fehler (cms,foren etc.) in das System einzudringen bekommt er webserver Rechte. Er kann kann dann doch auch im rootjail scripte evt. ausführen oder weitere laden und diese nutzen?

Ein webserver im rootjail schützt im Idealfall also nur davor, daten außerhalb des rootjails nicht zu lesen oder mit ihnen anderen freundlichen Dinge tun zu können?

Landet so ein Angreifer der einen webserver knacke bzw. Rechte des webservers erhalten hat in jedem Fall im rootjail des webservers?

Sprich, die beste Absicherung eines Webservers ist das Filtern von Port 80 z.B. mit mod_secrurity?

[mattiass]

Ein webserver im rootjail schützt im Idealfall also nur davor, daten außerhalb des rootjails nicht zu lesen oder mit ihnen anderen freundlichen Dinge tun zu können?

Landet so ein Angreifer der einen webserver knacke bzw. Rechte des webservers erhalten hat in jedem Fall im rootjail des webservers?

Ja, der Angreifer landet im Jail. Wenn der aber als normales "chroot" ausgeführt ist, kann er auf Netzwerkverbindungen und Gerätedateien zugreifen. Unter Umständen schafft er es so, Daten außerhalb auszuspähen oder zu manipulieren.

Sicherer ist es, Chroot-Erweiterungen zu verwenden, die in Richtung Pseudovirtualisierung gehen. Das können die RSBAC-Erweiterungen sein, aber auch OpenVZ oder Vserver. Ich verwende auf einigen meiner Server FreeBSD und mache dort intensiv von BSD-Jails Gebrauch. Auf anderen gehe ich weiter und setze auf echte Virttualisierung mit Xen-Instanzen, die jeweils für einen Kunden oder eine Aufgabe zuständig sind.

[sledge0303]

Ich hab relevante Dienste wie Web-, Mail, SSH, Datenbankserver sowie Bind jeweils in einem chroot zu laufen auf beiden Kisten. Bin zufrieden damit, man muss nur drauf achten nichts unnötiges reinzustecken in das Jail.

Auf dem nächsten Server wird dann, wie MatthiasS beschrieben hat, auf Virtualisierung gesetzt per openVZ oder XeN.

[lucki2]

Lieber tomtom: es ist viel schlimmer.
Schafft es ein Einbrecher Perl-Scripte oder Binaries aufzuspielen und auszuführen(das ist der trickie part), kann er raus. Perl sei explizit genannt, da recht oft in Mächtigkeit unterschätzt und für CGI genutzt.

[mattiass]

Lieber tomtom: es ist viel schlimmer.
Schafft es ein Einbrecher Perl-Scripte oder Binaries aufzuspielen und auszuführen(das ist der trickie part), kann er raus. Perl sei explizit genannt, da recht oft in Mächtigkeit unterschätzt und für CGI genutzt.

Man sollte hier unterscheiden zwischen dem Überschreiten der Dateisystemgrenze zwischen Chroot und restlichem System und dem Zugriff auf das Netzwerk. Ersteres ist deutlich schwieriger.

[lucki2]

Ich habe unterschieden und ersteres gemeint. Läuft über Bufferoverflow.

[mattiass]

Ich habe unterschieden und ersteres gemeint. Läuft über Bufferoverflow.

Das sollte nicht der Fall sein. Kannst Du mir den dafür relevanten Bug zeigen?

[aldee]

Ich habe unterschieden und ersteres gemeint. Läuft über Bufferoverflow.

Das ist in dieser Pauschalität ausgedrückt einfach nur Käse.

[daemotron]

Es gibt diverse Exploits, um aus einer nicht gehärteten chroot-Umgebung auszubrechen - chdir()-Hack und setuid seien nur stellvertretend genannt (wohlgemerkt - bei beiden erhält man nicht nur Zugriff auf Gerätedateien, sondern auf das gesamte Dateisystem außerhalb des Jails).

Allerdings stehen auch genügend Mittel zur Verfügung, die chroot-Funktionalität unter Linux zu härten und sich so einen Ersatz für die FreeBSD-Jails zu schaffen, der sich nicht unbedingt zu verstecken braucht. Stichwörter hier seien GRSecurity-Patch oder RSBAC.

[lucki2]

Das ist kein Bug das ist chroot. Ich sheue keine Mühen um guten Service zu geben. Getestet. Tut.

Code: Select all

.... leider zu spät ...

Hier standen für ca 1h ca 10 Zeilen c-code mit deren Hilfe aus einer Chroot ausgebrochen werden kann. Code für eines der auch von jfreud genannten Verfahren.
Das habe ich wieder rausgenommen, weil ich finde, das muß nicht der Meute zun fraß vorgeworfen werden. Wer c kann bastelt sich so was recht fix zusammen.

[tomotom]

Ok, es sieht so aus, da "mod_secrurity" bei meiner Frage nicht aufgegriffen wurde, dass mod_secrurity keine bedeutende Aufgabe bei der Verhinderung von Exploits hat. Spielt es nicht doch eine Rolle, wenn auch evt. eine geringe, weil es die erste Hürde ist die genommen werden muss, um überhaupt auf das System zu kommen?

Xen ist natürlich eine schöne Lösung und optimal wäre es sicherlich für jeden Kunden eine dom0 laufen lassen zu können wären da nicht die Einschränkungen durch den RAM :-( Durch ein xen Konzept vervielfacht sich ja leider der Speicherbedaraf enorm.

Über GRSecurity, RSBAC, SElinux oder Apparmor habe ich bisher leider zu weinig gelesen gescheige denn ausprobiert. Nach Euren Antworten sich es und meinen "geheimen" Vermutungen sieht es wohl so aus, dass es bei einem ersthaften Sicherheits-Konezpt keinen weg an einer OS-Härtung vorbei gibt.

Ich gehe davon aus das die gerade genannten Härtungsmethoden alle ähnliche Aufgaben erfüllen. Es gab ja vor ein par Monaten eine Linux Magazin Artikel der SElinux oder Apparmor verglich. Das Ergebnis war:Apparmor ist einfacher zu bedienen und zu verstehen, SElinux ist komplizierter aber feinkörnier.

Wenn ich mich richtig erinnere bezieht GRSecurity RSBAC mit ein, dass man da nicht von einem entweder oder sprechen kann sondern man mit GRSecurity noch mehr Möglichkeiten der Kontrolle hat als alleine mit RSBAC.

Wie sieht es denn überhaupt mit der Konfiguration von GRSecurity und RSBAC aus läßt sich das bequem nachträglich in Debian einbauen?
Ich nehme auch an, dass beide Systeme einfacher zu konfigurieren sind als SElinux.Laufen die auch mit xen-kernels?

[captaincrunch]

Wenn ich mich richtig erinnere bezieht GRSecurity RSBAC mit ein

Falsch: GRSecurity bringt eine eigene RBAC (Rule Based Access Control) mit, RSBAC ist ein vollständig anderer Ansatz für ein solches Konzept (und stellt so ziemlich die mächtigste dieser Umsetzungen dar).

Bei allen hier besprochenen Methoden sollte aber auch der Aspekt der Schutzwürdigkeit nicht vegessen werden. Klar kann jemand, der über das nötige Hinterrgundwissen verfügt mit Hilfe von RSBAC und Co. sein System so absichern, dass selbst sehr erfahrene Angreifer sich die Zähne dran ausbeißen. Ob der Aufwand dafür gerechtfertigt ist, wage ich anhand des hier behandelten Themas stark zu bezweifeln.

Wie sieht es denn überhaupt mit der Konfiguration von GRSecurity und RSBAC aus läßt sich das bequem nachträglich in Debian einbauen?
Ich nehme auch an, dass beide Systeme einfacher zu konfigurieren sind als SElinux.Laufen die auch mit xen-kernels?

GRSecurity bringt einen "Lernmodus" mit, der zwar grundsätzlich funktioniert, jedoch niemals den Grad an Sichrheit erreichen wird, den ein geübter Admin konfigurieren könnte.
Sowohl RSBAC als auch SELinux sind ein ziemliches Faß ohne Boden: bevor du überhaupt anfangen kannst, irgendwas zu konfigurieren, musst du erst einmal die Konzepte und den Background intus haben.
Insgesamt darf aber wohl behauptet werden, dass SELinux zur Zeit (gerade was Debian angeht) noch die beste "Unterstützung" genießt. Wenn du dich hingegen für das (IMHO) mächtigere RSBAC interessierst, solltest du dir mal Adamantix anschauen. Der gute Peter hat anscheinend mal wieder Zeit und Lust, und bringt (mher oder weniger) einzelkämpferisch neue Pakete etc.

[grandcat]

So, Abend erst einmal zusammen. Anbei zu diesem Thema hätte ich auch einmal ein Frage:

Nicht jeder verfügt ja über einen richtigen, dedizierten Server, sondern nur über einen bestimmten Anteil, den sogenannten vServer. Ich selber verfüge über einen solchen "Server" und habe mir auch schon Gedanken über die Sicherheit gemacht. Daher laufen diverse Dienste wie Apache, MySQL und Postfix in einer Chrootumgebung. Da ich aber scheinbar keinerlei Zugriff auf den Kernel habe, kann ich infolgedessen keine Änderungen vornehmen, daher auch z.B. nicht "grsecurity" aufspielen.

Gibt es daher noch andere Sicherheitsansätze insbesondere für vServer ( Suse 10.0) oder ist das Standart "chrooten" + "mod_security" schon das Maximale an Sicherheit, was ein vServer zu bieten hat?

Ich freu mich schon auf Eure Fachkompetenz,

grandcat

[mattiass]

Das ist kein Bug das ist chroot. Ich sheue keine Mühen um guten Service zu geben. Getestet. Tut.

Mich würde interessieren, ob dieser Code auf jedem aktuellen Vanilla-Kernel läuft. Hast Du die getestet? Historisch betrachtet waren Chroots eine Wartungs- und Testhilfe, nie ein Sicherheitsfeature. Ich ging dennoch bislang davon aus, dass ein gewisser Aufwand zum Ausbrechen notwendig ist.

Anyway: Ich arbeite unter FreeBSD viel mit den Jails und wünschte mir ein ähnliches Feature im Linux-Kernel -- ohne Patches zu benötigen. OpenVZ und Co. bringen zwar einige zusätzliche Features wie Quota per Jail oder maximale CPU-Zyklen, aber das braucht man nicht so häufig.

Xen benötigt tatsächlich mehr RAM als Pseudovirtualisierung und deutlich mehr als normales Shared Hosting. Wer aber etwas mit den Einstellungen der Software in den DomUs spielt, bekommt diese in vielen Fällen auf 64MB runter -- kann man natürlich nicht pauschal sehen, aber oft wird RAM durch zuviele Apache-Module oder Instanzen verschenkt. Noch mal etwas lässt sich mit uClibc statt glibc herausholen -- da experimentiere ich gerade mit. Ich halte Euch natürlich auf dem Laufenden. :-)

In jedem Fall bewegen wir uns in einem Spannungsfeld zwischen Sicherheit, Ressourcenbedarf und Bequemlichkeit. Eine Lösung, die alle Ansprüche ideal erfüllt, gibt es nicht.

[daemotron]

(...) sieht es wohl so aus, dass es bei einem ersthaften Sicherheits-Konezpt keinen weg an einer OS-Härtung vorbei gibt.

Klares "jein" an dieser Stelle. OS-Härtung, wie Du es nennst, bedeutet für mich nicht nur den Einsatz von Kernel-Patches und bestimmten Userspace-Tools (wie das bei GRSecurity und RSBAC der Fall ist). Im Zweifelsfall kann man ein Standard-System auch schon recht gut härten, indem man nicht benötigte Dienste deaktiviert oder besser gleich deinstalliert, die laufenden Dienste ordentlich konfiguriert, überflüssige User-Accounts schließt etc. Ein RBAC/MAC-Ansatz ist da nur noch das Tüpfelchen auf dem i...

Ok, es sieht so aus, da "mod_secrurity" bei meiner Frage nicht aufgegriffen wurde, dass mod_secrurity keine bedeutende Aufgabe bei der Verhinderung von Exploits hat. Spielt es nicht doch eine Rolle, wenn auch evt. eine geringe, weil es die erste Hürde ist die genommen werden muss, um überhaupt auf das System zu kommen?

Bingo! Von einem Sicherheitskonzept kann man IMHO nur sprechen, wenn es mehrere Bausteine umfasst, die gestaffelt und unabhängig voneinander einen Angreifer am Eindringen bzw. Anrichten von Schäden hindern. Gehärtete chroots oder BSD-Jails können genauso Bestandteil sein wie Application Level Filter à la mod_security.

Ein intelligentes Verteidigungskonzept geht nach dem ABC-Prinzip vor und fängt das Gros der Angriffe so früh wie möglich ab (Beispiel: RBL bei der Spamabwehr). Wie vielstufig die Barrieren aussehen sollen, hängt vom individuellen Sicherheitsbedürfnis und nicht zuletzt einer Kosten-/Nutzenanalyse ab. Würde jeder Angreifer ungehindert bis in meine Jails vordringen können und erst da gestoppt werden, hätte ich alle Hände voll zu tun, ständig die Jails zu erneuern, wohin gegen ein bereits durch die Level-5-Firewall gestoppter Angriff mich völlig kalt lässt. Also ist es unterm Strich für mich wirtschaftlich, Ressourcen für einen Level-5-Filter zur Verfügung zu stellen.

Auf Deine Frage bezogen: von 10.000 Angreifern bleiben 9.999 schon an mod_security hängen. Für den einen, der es da durchschafft, hab ich dann noch das Jail. Vielleicht gelingt es dem 1.000.000sten Angreifer, auch noch diese Hürde zu überwinden - dann kann ich nur beten, dass mein Berechtigungskonzept aufgeht und kein großer Schaden angerichtet wird - neu aufsetzen muss ich das System dann auf jeden Fall.

EDIT @MattiasS:
Kennst Du einen Weg, FreeBSD 6.1 auf einem Rootie zu installieren? Die Kiste verfügt zwar über ein Rescue-System, aber nicht über eine Remote Console (steht bei einem bekannten Nürnberger Provider)

[mattiass]

EDIT @MattiasS:
Kennst Du einen Weg, FreeBSD 6.1 auf einem Rootie zu installieren? Die Kiste verfügt zwar über ein Rescue-System, aber nicht über eine Remote Console (steht bei einem bekannten Nürnberger Provider)

Ja, dabei kann ich helfen. Wüst, aber mit "dd" bekommen wir das hin... :-)

[pennywize]

Ja, dabei kann ich helfen. Wüst, aber mit "dd" bekommen wir das hin... :-)

Mich würde das rein informatisch auch interessieren.

Gruss Jasmin

[mattiass]

Ja, dabei kann ich helfen. Wüst, aber mit "dd" bekommen wir das hin... :-)

Mich würde das rein informatisch auch interessieren.

Hmmm, ich würde sagen: Ich teste hier mal trocken. Solche Installationen mit "dd" habe ich bereits für CF-Karten vorbereitet, kann bei Festplatten nicht anders sein. Dann testen wir mit "jfreund" in Nürnberch und dann schreibe ich ein Howto.

So. Die verdammte Suse ist installiert. Ich brauche Anfang der Woche ein cleanes openSUSE 10.1 64Bit Image...

[aldee]

Hier standen für ca 1h ca 10 Zeilen c-code mit deren Hilfe aus einer Chroot ausgebrochen werden kann. Code für eines der auch von jfreud genannten Verfahren.
Das habe ich wieder rausgenommen, weil ich finde, das muß nicht der Meute zun fraß vorgeworfen werden. Wer c kann bastelt sich so was recht fix zusammen.

Es handelte sich doch nicht etwa um den geheimen ersten Google-Treffer bei der Suche nach chroot und break, oder? Derartiges Spezialwissen sollte man nämlich wirklich nicht "einfach so" verbreiten.

[daemotron]

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

Gerne! *freu*

So. Die verdammte Suse ist installiert. Ich brauche Anfang der Woche ein cleanes openSUSE 10.1 64Bit Image...

:D Ich muss auch noch "nachsitzen"... Bei mir ist's allerdings ein Gentoo.

[lord_pinhead]

Es handelte sich doch nicht etwa um den geheimen ersten Google-Treffer bei der Suche nach chroot und break, oder? Derartiges Spezialwissen sollte man nämlich wirklich nicht "einfach so" verbreiten.

Wer ein anständiges Shellcode Verzeichniss besitzt für seine Tests, der hat auch ein paar solcher Versionen rumliegen. Es ist nichts neues das man aus einem Chroot ausbrechen kann, das BSD Konzept der Jails ist viel besser als ein Chroot und einfacher einzurichten an sich. Chroots dienen ja wie schon erwähnt, nicht gerade dazu eine sicherheitsbarriere zu bilden die stark ist, nur ein paar Kids würden sich damit einschüchtern lassen. Dieses "spezialwissen" ist nicht schlimm, den wer nicht weiß wie man mit sowas umgeht, kann nichts anrichten. Manche Kids bekommen es nichtmal gebacken fertigen Payload zu kombinieren der dann auch am ende funktioniert.

@CC
Hast du schonmal mit RSBAC gearbeitet?

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

[lucki2]

Es handelte sich doch nicht etwa um den geheimen ersten Google-Treffer.

Nö, war kürzer(läuft das?). Ich bin zu faul -> vermute ähnlich.

Es ist nichts neues das man aus einem Chroot ausbrechen kann

Ja. Das war hier nur bezweifelt worden. Ok?
--
Und für Schlaumeier: ja selbstverständlich habe ich einfach nur das erstbeste lauffähig getrimmt - und?

Ich sage nicht das Chroots unnütz sind, damit sage ich nur, daß Leute durch eine Chroot Keine Sicherheit haben, wenn sie Beispielsweise auf ihre Variablen in Perl nicht aufpassen.

@Mathias: Nö, das mache ich jetzt nicht. Glauben oder sein lassen.

[aldee]

Ich sage nicht das Chroots unnütz sind, damit sage ich nur, daß Leute durch eine Chroot Keine Sicherheit haben, wenn sie Beispielsweise auf ihre Variablen in Perl nicht aufpassen.

Was hast du denn immer mit deinem Perl? Es sei nur nebenbei angemerkt, dass für das Ausbrechen aus einem chroot Rootrechte erforderlich sind. Ist dein Perl-Binary setuid root? Dass es möglich ist, chroots mit entsprechenden Kernelpatches auch gegen Ausbruchsversuche von Angreifern mit Rootrechten hinreichend abzusichern, wurde in diesem Thread bereits erörtert.

[lucki2]

....

Na, wenn Du meinst. Das habe ich schon beantworted. Widerholen will ich mich auch für Dich nicht.

[aldee]

....

Na, wenn Du meinst. Das habe ich schon beantworted. Widerholen will ich mich auch für Dich nicht.

Ja dann.