PHP Setup und Konfiguration – Sicherheit vs. Performance

PHP wird den Ruf der unsicheren Bastlerumgebung einfach nicht los. Selbst wenn einige Sicherheitsprobleme in der Tat gravierend waren – wurde der wirkliche Schaden durch ein falsches Setup der PHP-Umgebung noch verschlimmert oder ausgeweitet.

Dieser Artikel soll konzeptionell aufzeigen wie Serverseitig eine möglichst ideale Umgebung bereitgestellt werden kann. Die Sicherheit innerhalb von PHP Scripts wird hier nicht behandelt.


Setup
PHP kann grundsätzlich auf 2 Arten installiert/betrieben werden.

  • Als Modul eigebunden in den Webserver (z.B. Apache). Somit läuft der PHP-Interpreter sammt seinen Modulen persistent und logischerweis unter demselben User wie der Webserver selbst. Dadurch hat PHP grundsätzlich auch dieselben Rechte wie der Webserver auf dem System. Von PHP erstellte Dateien gehören somit danach auch dem „Webserver“ – und nicht dem User. Diese können danach möglicherweise per FTP z.B. nicht gelöscht oder geändert werden.
    Ein paar spezifische Manipulationen an der Konfigurationsdatei php.ini sind pro vHost möglich.

    Diese Variante eignet sich primär für einzelne Webprojekte – auf keinen Fall für Shared Hosting.

  • Als CGI. Wenn ein PHP-Script „interpretiert“ werden muss – wird dazu ein neuer Prozess gestartet, der zuerst PHP initialisiert, die Module lädt – und dann erst seine Arbeit startet. Defaultmässig läuft die CGI-Variante auch unter dem User des Webservers.
    Der Resourcenverbrauch gegenüber der Modul-Variante ist natürlich massiv höher – da neben dem Overhead durch das starten des Threads die Module nicht geshared werden können.

Auf den ersten Blick hat somit Variante 2 eigentlich nur Nachteile. ABER: Durch zusätzliche Wrapper können die Threads unter dem eigentlichen User des vHosts ausgeführt werden. Hier gibt es aktuell suExec und suPHP. Ersteres simuliert näherungsweise die Modul Variante – da die Threads noch künstlich am Leben erhalten werden können für allfällige weitere Aufgaben. suPHP startet und beendet dagegen den Thread bei jeder „Interpretation“

Pro vhost kann hier eine komplett eigene php.ini verwendet werden – sowie (wenn erwünscht) eine eigene PHP-Versionen. Von PHP erstelle Files gehören danach vHost-User und können problemlos per FTP mutiert werden.

Somit hätte man also Grundsätzlich die „Sicherheit“ durch den Thread sichergestellt – und hat eigentlich bereits ansatzweise eine chroot() Umgebung für PHP.

Als Systemadmin hat man durch diese Variante zudem den grossen Vorteil, das sofort ersichtlich ist wem welche Threads gehören.

Konfiguration
Weiter ist die Konfiguration von PHP vorsichtig zu definieren. Folgende Funktionen sollten wirklich nur bei Bedarf aktiviert werden:

–>Einzelne Funktionen können gezielt mittels der php.ini gesperrt werden.

open_basedir
Sehr wichtig ist ausserdem das open_basedir. Leider werden die Sicherheitsmassnahmen nicht selten ganz alleine auf diese Einstellung beschränkt. Man muss sich aber bewusst sein dass das open_basedir lediglich für Filehandles berücksichtigt wird – nicht aber für exec, system etc..

safe_mode?
Der safe_mode war ein etwas unglücklicher Ansatz, die PHP Umgebung abzusichern. In der Praxis sind dadurch mehr Probleme als Lösungen entstanden. Da der safe_mode zukünftig wieder komplett wegfällt – sollten wir diesen nicht weiter berücksichtigen.

Kontrolle
Als Anwender kann das PHP-Setup über ein einfaches phpinfo() jederzeit ermittelt werden.

Der Parameter „Server API“ zeigt z.B. auf – wie PHP installiert worden ist.

  • Apache-Modul: Apache 2.0 Handler
  • CGI: CGI/FastCGI

Fazit
PHP als Modul eignet sich primär für Einzelprojekte. Im Shared Hosting Bereich ist diese Variante nur für den Betreiber interressant, da effizient und somit lukrativ. Als Kunde (Shared Hosting) sollten sie eine solche Dienstleistung auf keinen Fall unterstützen.

Schlagworte: , , , , , , , ,

Kommentieren


Social Widgets powered by AB-WebLog.com.