Nachdem ich mir die halbe letzte Nacht um die Ohren geschlagen habe und auch direkt heute Morgen an dieses Thema gedacht habe, dachte ich so bei mir, dass ich meine Erkenntnisse und Gedanken eigentlich prima in einem Howto verpacken könnte.

Worum geht es eigentlich? Es geht um sichere Webserver. Dabei allerdings weniger um Gefahren von außen, sondern um die Gefahr, die von innen kommt. Zwar gibt es immer mehr Nutzer, die einen eigenen Server verwalten und somit genau kontrollieren können, welche Informationen nach außen dringen, aber noch immer macht das Massenhosting einen Großteil der Homepages aus.

Massenhosting bedeutet, dass ein physikalischer Server von mehreren Homepages gleichzeitig genutzt wird, die allesamt parallel auf dem Server existieren. Zwar ist es kein großes Sicherheitsproblem, wenn die Nutzer per FTP ihre Daten hochladen und über HTTP abrufen können, problematisch wird es aber dann, wenn die hochgeladenen Daten Programme jeglicher Art sind, die auf dem Server ausgeführt werden können.

Gerade mit der unglaublich steigenden Bekanntheit von PHP, stiegen auch die Sicherheitsprobleme. Und ich habe nun einmal einige Gedanken zusammengetragen, wie man einen möglichst sicheren Webserver mit PHP-Unterstützung realisieren kann, da ich bei meiner Suche im Internet bisher leider noch nichts vergleichbares finden konnte.

Das Problem

Sicherheit steht immer im Gegensatz zur Bequemlichkeit. Eine Alarmanlage im Haus bringt große Sicherheit, stört mich aber sehr, wenn ich in der Nacht etwas erledigen muss und sie erst deaktivieren muss. Bodyguards bringen mir auch große Sicherheit nur schirmen sie mich eventuell unnötig ab und ich habe kaum noch Privatspäre.

Daher muss ein Kompromiss gefunden werden, der zum einen eine gute Sicherheit bietet, zum anderen aber auch dem Kunden sowenig Schwierigkeiten macht wie nur möglich.

Das grundlegende Problem ist folgendes:

Die meisten Webserver, auf denen PHP als Scriptsprache angeboten wird, nutzen das PHP-Modul für den Apache. Dieses Modul wird zentral in den Apache-Webserver eingebunden und steht danach allen Homepages, respektive Virtual-Hosts, zur Verfügung. Der Vorteil: Die Ausführung der PHP-Programme ist sehr schnell und die Konfiguration ist sehr einfach. Außerdem sind die PHP-Programme in dieser Konfiguration sehr flexibel und können nahezu jegliche Arbeiten verrichten, die gefordert werden.

Genau hier liegt das Problem. PHP-Programme, die über das Apache-Modul ausgeführt werden, werden im Linux/Unix-System unter dem Benutzer ausgeführt, unter dem auch der Apache ausgeführt wird. Natürlich muss der Apache auf sämtliche Dateien zugreifen können, die er an die Besucher der Internetseiten ausliefern möchte. Das bedeutet, sämtliche Dateien, die ausgeliedert werden sollen oder als PHP-Programm ausgeführt werden sollen, müssen für den Apache lesbar sein.

Im Umkehrschluss bedeutet das dann, ein PHP-Script, egal an welcher Stelle im System, welches über das Internet aufgerufen wird, hat Zugriff auf sämtliche Dateien, die vom Apache gelesen oder vom PHP-Modul ausgeführt werden sollen. Das umschließt die PHP-Programme selbst im Quelltext (jemand anderes kann also das geistige Eigentum stehlen), .inc-Dateien, die zb. Passwörter für den SQL-Zugriff enthalten oder .htpasswd-Dateien, die von Apache zum Schutz von Verzeichnissen genutzt werden.

Und genau diese Sicherheitslücke werden wir uns nun vornehmen.

Der Weg

Es gibt einige Möglichkeiten, das Problem zu lösen:

1. PHP wird nicht mehr angeboten: Zugegeben, ein drastischer Schritt, den kein Anbieter von Webhosting gehen wird, aber sicher der wirksamste
2. Safe-Mode: Safe-Mode sind verschiedene Funktionen innerhalb von PHP, die diese Sicherheitsprobleme gezielt angehen sollen. Zwei Funktionen werde ich in meiner Lösung einsetzen. Generell ist der Safe-Mode allerdings eher unwirksam, da er mehr Probleme erzeugt, denn löst. So streuben sich einige sehr bekannte PHP-Applikationen unter Safe-Mode zu laufen, da zb. populäre Funktionen, wie der Upload von Dateien immer wieder zu Problemen führen.
3. abgespeckter Safe-Mode + disable_functions: Dies dürfte die beste Lösung für Administratoren sein, die einigermaßen “humane” Kunden haben. Der Safe-Mode wird generell ausgeschaltet. Mit der open_basedir-Richtlinie setzt man die PHP-Funktionen für den Dateizugriff auf das eigene Verzeichnis fest, so dass hier nur noch Dateien der eigenen Homepage angezeigt werden können. Schließlich werden mit disable_functions alle PHP-Funktionen ausgeschaltet, die normale Unix-Befehle ausführen können und somit dennoch fremde Dateien ausspionieren können.

   Leider gibt es hier allerdings auch den Haken, dass manche Applikationen diese Funktionen zwingend benötigen, da sie auf externe Software angewiesen sind. Ein Beispiel ist Gallery. Hinzu kommt, dass disable_functions leider nur sehr unflexibel ist, da es nur global definiert werden kann.

4. PHP-CGI + suexec: Fast meine Lösung. PHP wird als externe Software über einen sog. suexec-wrapper ausgeführt. Die genaue Bedeutung kommt später. Allerdings bietet diese Lösung eine generell schlechtere Performance als die Nutzung von PHP als Modul.

Die Lösung

Zunächst, warum PHP als CGI ausführen?

Nun, zusammen mit suexec wird PHP als der Benutzer ausgeführt, dem der virtuelle Webserver gehört. Das bedeutet natürlich, dass ich nur auf Dateien Zugriff habe, die ich mit meinen eigenen Berichtungen lesen darf. Die PHP-Scripte meines “Server-Nachbarn” werden mit seinen Berechtigungen ausgeführt. Sind die Berechtigungen sorgfältig gesetzt, kann diese Lösung als sicher erachtet werden.

Daher ist zu beachten, dass gerade auf die Berechtigungen ein großes Augenmerk gelegt werden. Diese ganze Lösung ist nämlich dann für die Katz, wenn Dateien trotzdem von jedem gelesen werden können.

Um die Abarbeitung der PHP-Scripte auch schnell zu machen, kommt noch eine Komponente hinzu: FastCGI FastCGI ist ein Apache-Modul mit sehr guten Caching-Möglichkeiten, bei dem PHP als Server gestartet wird und so die Aufträge schnell abgearbeitet werden können. Es gibt sogar die Möglichkeit, externe PHP-Server zu nutzen und so zb. ein Loadbalancing der PHP-Last zu erreichen.

Dieses Howto richtet sich weniger an die grundlegende Installation von Apache, FastCGI und PHP, da sie sich unter Gentoo, welches ich nutze, recht einfach gestaltet. Wer von Source installiert, findet dazu einige Howtos im Netz, die dann allerdings meiner Meinung nach zuwenig auf die Berechtigungen der Nutzer eingehen. Wichtig ist nur, dass beim Apache die suexec-Möglichkeiten eingebunden werden und PHP mit FastCGI-Unterstützung kompiliert wird.

Unter Gentoo reicht dazu ein:

emerge -v apache php-cgi mod_fastcgi

Natürlich sollte man sich noch seine entsprechenden USE-Variablen zusammensuchen, gerade PHP bietet da eine sehr umfangreiche Liste:

emerge -pv php-cgi

Wichtig ist natürlich mitlerweile auch USE=”apache2″, da wir für den Apache Version 2 kompilieren werden.

Nach der Installation der drei Komponenten müssen wir in der /etc/conf.d/apache2 das FastCGI-Modul aktivieren:

APACHE2_OPTS="-D SSL -D DAV -D FASTCGI"

Hier ist natürlich nur der Part “-D FASTCGI” der notwendige.

FastCGI unterscheidet zwischen drei Arten von Applikationsservern, also zb. drei Arten von PHP-Servern, die in Zukunft die Arbeit machen sollen.

1. statische Server werden beim Start des Webservers gestartet und stehen dann dauerhaft zur Verfügung.
2. dynamische Server werden dann gestartet, wenn eine Anfrage an den Server gestellt wird, die die Ausführung eines PHP-Scripts beinhaltet.
3. externe Server können per TCP/UDP angesprochen werden und so zb. freie Resourcen anderer Server mit nutzen.

Hier muss man nun entscheiden, ob man virtuelle Server hat, die mit einer hohen Besucherfrequenz einen nutzen aus statischen Servern ziehen würden oder ob man virtuelle Server hat, auf denen nur sehr wenige Besucher sind. Gerade im Massenhosting macht es eher Sinn auf dynamische Server zu setzen, da das Gästebuch des lokalen Taubenzüchtervereins vielleicht einmal pro Monat aufgerufen wird. Natürlich bringt ein dynamischer Server eine leichte Verzögerung bei der ersten Anfrage. Ist der Server geladen steht er auch für weitere Anfragen des gleichen Benutzers zur Verfügung, bis er nach einer konfigurierbaren Zeit stirbt.

Da der dynamische Server zunächst Grundlage auch für die statischen Server ist kümmern wir uns erstmal darum. Folgende Zeilen kommen in den VirtualHost der jeweiligen Webservers:


ScriptAlias /cgi-bin /var/www/private/blog.commy.de/cgi-bin

AddHandler php-fastcgi .php

SetHandler fastcgi-script

Action php-fastcgi /cgi-bin/php
DirectoryIndex index.html index.shtml index.cgi index.php
AddType application/x-httpd-php .php

SuexecUserGroup "matthias" "users"


Sämtliche Anfragen nach .php-Dateien werden auf ein Shellscript unter dem relativen Pfad /cgi-bin/php geleitet. Aus diesem Grunde benötigt man natürlich die Definition eines cgi-bin-Verzeichnisses. Ich nutze dafür die ScriptAlias-Angabe, euch stehen natürlich auch die anderen Möglichkeiten zur Verfügung.

Damit der Server auch unter den korrekten Benutzerdaten läuft, benötigt man die SuexecUserGroup-Angabe. Unter Gentoo funktioniert es nicht, das PHP unter dem Apache-Benutzer apache zu starten. Daher sollte man hier ohnehin den jeweiligen Benutzer des Webservers angeben und eine allgemeine Gruppe (alternativ kann man natürlich auch eine Gruppe webuser o.ä. anlegen).

Um PHP nun zu aktivieren, benötigt man nun auch das Shell-Script im cgi-bin-Verzeichnis. Dazu nutzt man folgendes:

#!/bin/sh
umask 027
PHPRC="/etc/php/cgi-php4/"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
exec /usr/bin/php-cgi

Die umask-Angabe werde ich später noch erklären.

PHPRC definiert den Ort, an dem der PHP-Server die PHP-Konfigurationsdateien finden kann. Hiermit ist es also sogar möglich, jedem Kunden zu ermöglichen, mit einer php.ini im entsprechenden Verzeichnis, eigene Parameter des PHP-Servers zu definieren.

PHP_FCGI_CHILDREN definiert die Anzahl von PHP-Instanzen, die initial gestartet werden sollen. Je nach Besucherfrequenz des Servers können dies mehr oder auch weniger sein.

exec startet schließlich PHP. Der Pfad sollte natürlich entsprechend angepasst werden. Hier zeigt sich aber ein weiterer Vorteil von fastcgi; Ohne andere Webserver auf dem Server zu stören, kann hierdurch eine neue PHP-Version getestet oder unterschiedliche PHP-Versionen auf einem physikalischen Server laufen.

In der /etc/apache2/httpd.conf fehlt nun noch die Angabe des zu nutzenden suexec-Wrappers:

FastCgiWrapper /usr/sbin/suexec2

Möchte man nun statische Server nutzen, richtet man diese unter Angabe des Pfades für das obige Shell-Script und der identischen Benutzer/Gruppen-Angaben mit folgenden Zeilen ein:

FastCgiServer /var/www/private/blog.commy.de/cgi-bin/php -user matthias -group users
FastCgiServer /var/www/_SERVICES/cgi-bin/php -user wwwsystem -group users


Mit diesen Zeilen würden dann beim Start von Apache zwei PHP-Server mit jeweils unterschiedlichen Benutzerdaten starten.

Nun wird es spannend. PHP läuft jetzt zwar soweit, aber in den Standardeinstellungen ist es wenig benutzer, weil wir immer noch Sicherheitsprobleme haben. Die können wir jetzt lösen, indem wir einige Dateiberechtigungen ändern.

Durch das suexec haben wir nun erreicht, dass PHP-Dateien und Dateien, die nur von PHP gelesen werden sollen, lediglich vom Benutzer gelesen werden brauchen. Die Gruppe oder alle anderen brauchen die Dateien nicht mehr lesen, was für PHP-Dateien schon einmal ein sehr großer Vorteil ist.

Um nun die größtmögliche Sicherheit zu erhalten, habe ich folgende Berechtigungen erarbeitet:

Es sollten alle Dateien und Verzeichnisse in dem Webserver-Verzeichnis eines Nutzers dem Nutzer gehören (klar). Die Gruppe sollte dem Webserver-Benutzer gehören (im Falle von Gentoo apache). Der Benutzer sollte alles können, die Gruppe sollte nur lesen und alle anderen sollten nichts können.

Das größte Problem sind hierbei Dateien, die durch PHP neu angelegt werden. Standardmäßig bekommen diese Dateien nämlich keine Rechte für Gruppen und alle anderen. Für geheime Daten ist das OK, für Daten die hochgeladen werden und wie bei der Gallery dann zb. resized werden, ist das aber sehr schlecht, da die dann nicht per Webbrowser angezeigt werden können.

Außerdem erhalten diese Dateien die Gruppenzugehörigkeit “users”, da wir unter “users” ja den PHP-Server laufen haben.

Letzteres können wir verhindern, in dem wir mit

chmod -R g+s

die entsprechenden Verzeichnisse mit dem SetGID-Bit versehen. Somit behalten alle Dateien, die inden Verzechnissen erzeugt werden die entsprechende Gruppenzugehörigkeit.

Das Problem der Berechtigungen haben wir schon gelöst. Die Angabe umask 027 im Shell-Script bewirkt, dass neue Dateien mit den entsprechenden Berechtigungen erzeugt werden.

Nun haben wir folgendes erreicht. Dateien gehören dem jeweiligen Benutzer und können so per PHP gelesen und geschrieben werden. Ebenso ist der FTP-Zugriff voll möglich. Die Gruppenzugehörigkeit liegt beim Apache-Server, somit können alle Dateien zwar per Apache gelesen werden, aber die PHP-Scripte, die unter der Gruppe “users” laufen, können nicht auf andere Verzeichnisse zugreifen.

Zusätzlich können wir sensible Daten, die für PHP-Scripte benötigt werden, in Dateien auslagern, die nur für den Benutzer lesbar sind. Somit kann das PHP des Benutzers zwar auf diese Datei zugreifen, Apache aber nicht mehr.

Alle anderen Schutzmechanismen kann der Nutzer mit .htaccess-Dateien selbst herstellen.

Ein Sicherheitsproblem besteht allerdings weiterhin. Es gibt standardmäßig eine Vielzahl von Dateien, die jeder lesen kann. Hier ist zu beachten, dass nicht jeder sie lesen muss. Eine sorgfältige Wahl der Berechtigungen, insbesondere vieler Konfigurationsdateien, ist hier die Lösung.

Größere Sicherheit bietet nur eine chroot-Umgebung, in der der Webserver abgeschlossen läuft.

Ich hoffe dieser Leitfaden hat euch ein wenig geholfen eure Webserver etwas sicherer zu machen.

Dieser Artikel wurde am 6. August 2005 um 20:14 erschaffen und im Bereich Arbeit, Commy online abgelegt. Die Reaktionen auf diesen Artikel kannst du über einen RSS 2.0 Feed verfolgen. Du kannst einen Kommentar verfassen oder einen Trackback von deiner eigenen Seite legen.