Chroot Alternative

[hasch]

Wollte jetzt auf meinen Fedora Core 5 und Apache 2.2.2 mod_security oder mod_chroot installieren. Leider geht beides nicht so recht, da Plesk im Spiel ist und die "korrekten" Pfade angibt. Sind euch Alternativen zum Absichern des Apache mit/ohne chroot mit bsw. anderen Modulen o.Ä. bekannt? :)

[Joe User]

Stecke den kompletten Webserver (inklusive Plesk) in ein Jail/Chroot/vServer/etc...

[hasch]

Nunja, es ist sc hon ein V-Server :) Gibt es keine einfacherere Möglichkeit, als Plesk mit ins chroot zu nehmen? (Zumal ich es dann auch lassen kann, da Plesk alle steuert (Bind, Mailserver, MySQL, usw.)...

[sledge0303]

Nunja, es ist sc hon ein V-Server :) Gibt es keine einfacherere Möglichkeit, als Plesk mit ins chroot zu nehmen? (Zumal ich es dann auch lassen kann, da Plesk alle steuert (Bind, Mailserver, MySQL, usw.)...

Bei einem Vserver würde ich komplett auf Plesk verzichten.

[cirox]

Hast Du fcgi im Einsatz (scheint ja langsam in Mode zu kommen :)), wenn ja würde mich auch mal interessieren, wie man nur die Fast-CGI Prozesse in ein Chroot steckt?

Ich empfehle dir erstmal folgenden Link (Apache Security). Dort steht zumindestens ansatzweise was über das Chroot. Eigentlich lohnt sich auch das ganze Buch ... Wenn Du dabei bist kannste gleich PHP Sicherheit kaufen (Buch von Christopher Kunz, Peter Prochaska und Stefan Esser).

Warum soll mod_security mit Plesk nicht funktionieren? Versteh ich nicht.

Hat dein Nick eigentlich irgendwelche Zweideutigkeiten?

[hasch]

Das Buch PHP Sicherheit habe ich :) Wie man FCGI-Prozesse in ein Chroot steckt weiß ich nicht. Aber mod_security an sich funktioniert ja schon, aber die Pfade werden von Plesk dynmaisch gesetzt bsw. /var/www/vhosts/x.de/... wenn Apache aber im Chroot ist, ist wenn bsw. /var/www das ChrootDir ist das Plesk VHost Verzeichnis ja gfalsch, da es dann ja im Chroot unter /vhosts/x.de/... liegt ;)

[sledge0303]

Du musst Plesk mit all seinen Abhängigkeiten, Libs usw ins chroot packen, sonst wird es sich beschweren bzw. es läuft gar nicht erst.
Die Anwendungen im Chroot (Apache, Plesk, Mailserver) werden per Initskript von außen im chroot gestartet.
Dafür gibt es genügend Dokumentationen und Tuts im Netz ;)

Mit so einem kleinen Befehl kann man Libs, als Beispiel PHP5, in ein Chroot stecken.

Code: Select all

ldd /usr/bin/php5* | awk '{if ($3 ~ /^[^ (]/) print $3}' | cpio -pdvuL /pfad/zum/chroot

optisch dargestellt

Code: Select all

/pfad/zum/chroot/lib/tls/libcrypt.so.1
/pfad/zum/chroot/usr/lib/libz.so.1
/pfad/zum/chroot/usr/lib/i686/cmov/libssl.so.0.9.8
/pfad/zum/chroot/usr/lib/libpcre.so.3
/pfad/zum/chroot/usr/lib/libdb-4.4.so
/pfad/zum/chroot/lib/libbz2.so.1.0
/pfad/zum/chroot/lib/tls/libresolv.so.2
/pfad/zum/chroot/lib/tls/libm.so.6
/pfad/zum/chroot/lib/tls/libdl.so.2
/pfad/zum/chroot/lib/tls/libnsl.so.1
/pfad/zum/chroot/usr/lib/libgssapi_krb5.so.2
/pfad/zum/chroot/usr/lib/libkrb5.so.3
/pfad/zum/chroot/usr/lib/libk5crypto.so.3
/pfad/zum/chroot/lib/libcom_err.so.2
/pfad/zum/chroot/usr/lib/libxml2.so.2
/pfad/zum/chroot/lib/tls/libc.so.6
/pfad/zum/chroot/usr/lib/i686/cmov/libcrypto.so.0.9.8
/pfad/zum/chroot/usr/lib/libkrb5support.so.0

So gehst nach und nach mit den Abhängigkeiten durch, aber alles wird so nicht in das chroot kopiert. Bei einigen musst manuell jedes Verzeichnis bzw. jede Datei kopieren.
Zum Bleistift

Code: Select all

cp /usr/lib/libmysqlclient.so.15 /pfad/zum/chroot/usr/lib

HTH bei deinem Vorhaben ;)

[daemotron]

Bei Plesk und dessen Kontrollwut hast Du mit diesem sauberen Vorgehen wahrscheinlich ein Ergebnis, dass einem kompletten Linux im chroot entspricht 8) Ob FC dafür irgendwelche Tools mitbringt, weiß ich allerdings nicht. Jedenfalls viel Glück && Geduld bei Deinem Vorhaben...

[sledge0303]

Ich an seiner Stelle würde entweder komplett auf Plesk verzichten, wegen Vserver, oder er muss da halt durch.
Es muss noch ein bissel mehr gemacht/bedacht werden als 'nur' alles in das chroot zu kopieren... 8)

[hasch]

Danke für eure Postings, dann kann ich es doch aber gleich ganz lassen mit dem Chroot, ich meine es ist ein VServer und es würde somit wirklich einem Linux im VServer entsprechen :)
Plesk benötige ich aber, da ich gerne eine Accounts zentral verwalten möchte, auf meinem Entwicklungsserver habe ich auch alles von hand eingerichtet und verwalte dies dort, aber auf dem produktivserver ist Plesk unabdingbar :)

[cirox]

Es muss doch in diesem ganzen Rootforum, der Fast-CGI einsetzt jemanden geben der weiss, wie man einzelne Fast-CGI Prozesse in ein Chroot stecken kann?

Oder soll ich das ganze PHP Zeugs in ein gesamtes Chroot stecken? Bringt doch keinen Sinn ....

Mein Ziel: confixx, mod_security, fcgi, 2 mal php, fcgi-starter, suexec ;) und chroot für jeden vhost.

Wenn ich danach in google suche find ich nix ..... Leider wird es in Büchern und der Doku immer nur erwähnt am Rande.

Oder muss ich hier doch genauso vorgehen, wie bei Plesk?

[sledge0303]

http://www.bsi.bund.de/gshb/deutsch/m/m04198.htm

Es muss doch in diesem ganzen Rootforum, der Fast-CGI einsetzt jemanden geben der weiss, wie man einzelne Fast-CGI Prozesse in ein Chroot stecken kann?

Wie man sauber vorgehen kann steht oben erklärt. Entweder man ist bereit sich Zeit ans Bein zu binden um die Kiste sicher zu machen oder man lässt es bleiben. Unabhängig davon, beim Lighttpd kann man sehr bequem das Docroot in eine chroot Umgebung stecken - ähnlich wie mit Postfix.
Dazu noch ein gut gebauter Kernel und man hat schon etwas getan für die Sicherheit seiner Kiste.
Wer Sicherheit liebt muss den Aufwand mögen - quite simple!

[cirox]

jupp, thx, aber ich versteh das hier nicht:

• The internal chroot feature should be treated as somewhat experimental. Due to the large number of default and third-party modules available for the Apache web server, it is not possible to verify the internal chroot works reliably with all of them. You are advised to think about your option and make your own decision. In particular, if you are using any of the modules that fork in the module initialisation phase (e.g. mod_fastcgi, mod_fcgid, mod_cgid), you are advised to examine each Apache process and observe its current working directory, process root, and the list of open files.

Quelle mod_sec Doku

Was meint er damit?

[daemotron]

mod_security bringt selbst die Möglichkeit mit, Apache-Prozesse in ein chroot zu sperren. Allerdings kann es sein, dass andere Module, die ebenfalls während des Forkens neuer Prozesse aktiv werden, dazwischengrätschen. Daher der Hinweis in der Doku, man möge bitte selbst prüfen, ob der Chroot-Schutz auch mit der eigenen gewählten Modulkombination zuverlässig funktioniert.

[cirox]

ok, das heisst - man keine fast-cgi Prozesse alleine in ein chroot stecken, man muss hier ein komplettes jail bauen. Ich dachte ich habe hier mal ne Aussage gelesen, das es reicht fast-cgi Prozesse in ein chroot zu stecken, dann war das wohl falsch ...

Aber mit lighty scheint es zu gehen ......

[daemotron]

Natürlich kannst Du PHP-Fastcgi-Prozesse in ein chroot stecken - Du musst sie nur ggf. dann händisch erzeugen und dem Webserver nur erzählen, wo er den Socket dazu findet (z. B. mit lighttpd und spawn-fcgi gar kein Problem) und die chroot-Umgebung wie von sledge0303 beschrieben manuell erzeugen. Nur bezweifle ich, dass Du das mit der chroot-Funktion von mod_security erreichen kannst (auch wenn ich das mangels eigener Erfahung damit nicht genau sagen kann).

[sledge0303]

Bei Etch, bei anderen weiß ich nicht ob es enthalten ist, gibt es ein Tool namens 'makejail'. Da kannst alle Pakete zusammenfassen die ins chroot kopiert werden sollen. Trotzdem muss dann noch manuell die eine oder andere Lib noch ins chroot reinkopiert werden.
Bei Etch hat die Sache aber einen Haken: /dev/null wird vom 'makejail' nicht mit den notwendigen Rechten versehen, da muss nachgearbeitet werden.
Für den erfahrenen Admin kein Problem, jemand mit weniger Erfahrung wird verzweifeln. Mod_security lief in diesem chroot problemlos. Du musst halt den Dienst bzw. in dem Fall das Modul außerhalb des chroots bauen und danach in die Apachelibs vom chroot kopieren - wo die anderen Module liegen.
Außerdem müssen alle Dienste von außen im chroot gestartet werden, da müssen die Initskripte bearbeitet werden.