Hello Marco,

ich habe auf meinem Server aktuell 5 produktive Webseiten laufen. Außerdem gibt es noch eine Reihe weiterer Subdomains, die ich für mich brauche. Insgesamt sind damit über 20 VHosts aktiv. Nun ist es ja so, dass der Apache immer unter _einem_ Benutzer läuft. PHP ist meistens auch aktiviert, da es für die Wordpress-Systeme beispielsweise nötig ist.

Damit bräuchte ein Hacker aber nur ein schädliches PHP-Skript auf _einen_ der VHosts bringen und könnte damit den Server lahm legen, inklive _aller_ anderen Seiten. Nun kann man schlecht 20 Apache-Instanzen auf einem Server laufen lassen, und ich kann innerhalb des Servers auch keine 20 VMs anlegen. Die Frage ist aber dennoch: Wie kann ich das Risiko, dass mir jemand alles zerlegt minimieren?

Massenhoster müssen ja das selbe Problem haben: Viele Kunden auf einem Server. Wenn eine Seite gehackt wird (oder der Kunde selbst auf den Kopf gefallen ist) dürfen die anderen Kundenseiten davon nicht betroffen sein.

Weiß jemand wie das bei Strato & Co. gelöst wird? Weiß jemand wie eventuell eine Lösung für mich aussehen könnte?

Der Apache kann mit unterschiedlichen Verfahren das Scripting bereitstellen.

• Scriptinterpreter als Modul des Webservers (bei PHP weit verbreitet)
• Zugriff über CGI,
• Zugriff per Fast-CGI

Die CGI-Varianten erlauben den Zugriff aus einer Change-Root-Umgebung heraus. Jedem VirtHost wird also ein eigener User zugewiesen. Dies ermöglicht eine Abgrenzung gegeneinander.

Die Modul-Variante von PHP hat dafür die Einstellung "open_basedir" eingeführt, die nur dann zuverlässig arbeitet, wenn man sie für alle Virtual Hosts auch benutzt und zwar in der Admin-Variante, also per htaccess keine Änderungen mehr zulässt. Außerdem müssen die Verzeichnisse für tmp und sessions und möglichst auch logs auch getrennt werden, was über entsprechende Einstellungen ebenfalls geht.

Jeder Request führt bei allen Varianten zu einem eigenen Worker-Thread, also einem eigenen Child. Die Speichernutzung ist damit auch gegeneinander abgegrenzt.

Den Children kann man im Apachen ebenfalls Limitationen auferlegen, sodass ein Child nicht alle anderen platt machen kann.

Spannend wird es jetzt erst bei Benutzung von Websockets, die der Apache noch nicht kennt und die daher parallel installiert werden müssen. Um die Kontrolle aber trotzdem per Apache-Einstellungen (wenigstens teilweise) durchführen zu können, kann man das Modul mod_proxy_wstunnel benutzen, das dann wenigstens ein kontrollierbares Routing auf den parallel laufenden Websocket-Server ermöglicht.

Da ist die Entwicklung aber noch in den Startlöchern.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg