symlink auf root trotz cgiwrap?

  • Hi


    - Welche Version von pd-admin wird eingesetzt? 4.18
    - Welche Version der Serverumgebung wird eingesetzt? 3-0.225
    - Welche Fehlermeldung erhalten Sie? symlink auf root
    - Wie sind die problematischen Dienste konfiguriert? standard
    - Welche Logfile-Einträge (zB. Webserver- oder Mail-Logfile) gibt es? http Access_log


    Ich betreibe für die Verwandtschaft einen kleinen Webserver (erst vor 1-2 Wochen frisch installiert da Upgrade des alten zu mühsam gewesen wäre) und letztens wurde eine nicht gepatchte Joomla Website defaced.


    Was mich stutzig macht ist, dass ich unter /home/<userverzeichnis>/sym einen symlink auf / gefunden habe der (getestet mit phpshell) auch funktioniert. ich kann mich im filesystem frei bewegen und werde nur (fast überall) durch filesystem Berechtigungen aufgehalten. meistens aber erst beim öffnen von Dateien d.h. ich kann in die meisten Verzeichnisse hinein. im joomla rootverzeichnis gibt's die .htaccess und dort steht Options +FollowSymLinks drin, ich weiß jetzt nicht ob das bei joomla schon von haus aus so ist oder ob das ein teil des wegs zum defacement (oder zu schlimmerem) war.


    das OS ist centos 6.4 mit deaktiviertem selinux (spielt das in dem zusammenhang eine rolle oder ist das nur so etwas wie die UAC unter Windows?).


    Dass der Angreifer über eine Joomla Lücke reingekommen ist, davon geh ich jetzt mal aus. Was mir aber überhaupt nicht schmeckt ist, dass er theoretisch auch auf Teile des Servers zugegriffen haben könnte die eigentlich nicht zugänglich sein sollten - oder hab ich da was verpasst? Wenn ich einen shared Server betreibe mit 100en Kunden drauf kann ich die ja nicht zwingen ständig Joomla aktuell zu halten und so ein Hoster installiert sicher auch nicht alle paar Wochen seine Server neu...?


    lg

  • Was pd-admin angeht, werden die Rechte aller Dateien und Verzeichnisse so gesetzt, dass keine fremden Daten ausgespäht werden können, sofern cgiwrap oder FastCGI zur Ausführung von PHP verwendet wird. Es kommt aber keine chroot-Umgebung zum Einsatz, die den Kunden in seinem Homeverzeichnis einsperren würde.


    Viele Grüße
    Daniel Bradler

  • Vielen Dank für die Antwort!
    Welche Möglichkeit gibt es denn im Rahmen einer Standardinstallation mit pd-admin SE die User daran zu hindern mittels z.B. einer PHP Shell auf Verzeichnisse außerhalb des eigenen Verzeichnisses einzusperren?


    Wäre eine chroot Lösung praktikabel? Ich nehme an ich bin ja nicht der einzige der sich darüber Gedanken macht, oder? Ich möchte nicht das Rad neu erfinden sondern würde gerne auf eine bewährte Vorgehensweise setzen...


    Kunden können z.B. lesend auf /etc/passwd zugreifen, securitytechnisch ist das eher fragwürdig, auch wenn es "nur" eine Userliste ist.



    edit: ich nutze PHP nur mit cgiwrap.


    lg

  • Zitat

    Original von nemail
    Vielen Dank für die Antwort!
    Welche Möglichkeit gibt es denn im Rahmen einer Standardinstallation mit pd-admin SE die User daran zu hindern mittels z.B. einer PHP Shell auf Verzeichnisse außerhalb des eigenen Verzeichnisses einzusperren?


    Das ist schnell beantwortet: Keine


    Zitat

    Wäre eine chroot Lösung praktikabel?


    pd-admin unterstützt derzeit keine chroot-Umgebungen. Sie müssten wahrscheinlich den PHP-Wrapper und ggf. die Apache-Konfiguration anpassen.


    Viele Grüße
    Daniel Bradler

  • OK, das bedeutet: wer die SE nutzt und nicht herumbastelt der nimmt dieses Problem eben in Kauf und ich bin nicht der einzige - sehe ich das richtig?


    Darf ich fragen wieso das so implementiert ist? Ich habe die SE immer als stabile, sichere Umgebung gesehen an der ja auch rege weiterentwickelt wird. Ist das kein "großes" Sicherheitsproblem oder ist der Aufwand einfach zu groß? Oder würde man zu viele daraus resultierenden Probleme in Kauf nehmen wenn so etwas implementiert werden würde?


    Mir ist absolut klar, dass die SE auf freiwilliger Basis entwickelt wird und dass hier kein Anspruch auf irgendwas besteht, ich frage nur aus reinem Interesse. Ich bin froh dass es überhaupt eine SE in dieser Form gibt.

  • Linux ist prinzipiell ein Mehrbenutzer-System und nutzt das Unix-übliche Dateirechte-System (http://de.wikipedia.org/wiki/Unix-Dateirechte). Die Dateirechte werden von pd-admin wiederum so gesetzt, dass es nicht möglich ist, die Inhalte eines anderen Benutzers auszuspähen.


    Die Benutzerliste (/etc/passwd) muss dabei unprivilegiert lesbar sein, da es ansonsten zu Fehlfunktionen kommen kann. Da hier keine relevanten Daten gespeichert sind (Passwörter werden in der Shadow-Datei abgelegt, und es ist i.d.R. auch kein Rückschluss auf die gehosteten Domains möglich), sehen wir den freien Zugriff als eher unproblematisch an.


    Die Erstellung und Pflege einer eigenen chroot-Umgebung für jeden Benutzer wäre sehr aufwendig ohne einen erheblichen Sicherheitsgewinn zu liefern. Wir haben daher darauf verzichtet.


    Viele Grüße
    Daniel Bradler

  • Zitat

    Original von Daniel Bradler
    Die Benutzerliste (/etc/passwd) muss dabei unprivilegiert lesbar sein, da es ansonsten zu Fehlfunktionen kommen kann.


    Vielen Dank für diese Info, das wusste ich nicht.


    Zitat

    Original von Daniel Bradler
    Da hier keine relevanten Daten gespeichert sind (Passwörter werden in der Shadow-Datei abgelegt, und es ist i.d.R. auch kein Rückschluss auf die gehosteten Domains möglich), sehen wir den freien Zugriff als eher unproblematisch an.


    Wenn ich eine Brute force Attacke starten wollte hätte ich dann zumindest schon ein paar Usernamen. Dass pd-admin nur relativ kurze Kennwörter unterstützt und es meines Wissens auch nicht möglich ist eine Kennwortrichtlinie betreffend Mindestkomplexität zu erzwingen macht die Sache auch nicht unbedingt besser.
    Gibt es einen Schutz bezüglich Brute force, wird ein Konto gesperrt bzw. erhält der Hostmaster Warnungen von pd-admin oder verschiedenen Services (smtp, pop3, imap, ftp) wenn eine Brute force Attacke stattfindet?


    Verstehen Sie mich nicht falsch ich möchte nur konstruktive Vorschläge in den Raum stellen und nicht meckern. Ich denke die eine oder andere Sache ließe sich ja mit mittlerem Aufwand implementieren, oder?


    Zitat

    Original von Daniel Bradler
    Die Erstellung und Pflege einer eigenen chroot-Umgebung für jeden Benutzer wäre sehr aufwendig ohne einen erheblichen Sicherheitsgewinn zu liefern. Wir haben daher darauf verzichtet.


    Diese Entscheidung kann ich grundsätzlich nachvollziehen. Wenn der Gewinn in keiner vernünftigen Relation zum Aufwand steht würde ich es in der Regel auch nicht machen.


    lg

  • Zitat

    Original von Eisenherz
    Auch auf die Gefahr hin, dass es jetzt Off-Topic wird, aber gegen Brute force Attacken sollte man idealerweise auf dem Server ein Tool wie Fail2ban installieren, das den Server gegen so was absichert.


    Da stimme ich zu aber ich finde es auch nicht verkehrt eine entsprechende Funktion (wo es möglich ist) direkt in die Software einzubauen die das "Einfallstor" für Brute force bietet. Warum erst etwas drumherumstricken?


    pd-admin kriegt es als allererster mit wenn jemand versucht sich am Webinterface anzumelden...