Kurz gesagt: Bei den Dateirechten auf dem Webserver gilt ein Grundsatz: Der Benutzer, unter dem PHP läuft, darf den eigenen Code lesen, aber nicht ändern. Schreibrechte bekommen nur Upload-, Cache- und Temp-Ordner, und dort wird kein PHP ausgeführt. Rechte wie 777 haben auf einem Produktivserver nichts zu suchen.
Warum Dateirechte nach einem Einbruch den Unterschied machen
Wenn Angreifer über eine Lücke Code auf einem Server ausführen, läuft dieser Code mit den Rechten des PHP-Prozesses. Was dieser Benutzer darf, darf auch der Angreifer. Genau hier entscheidet sich, ob aus einem Einbruch eine dauerhafte Hintertür wird.
Mit PHP2Shell ist dieses Szenario im Oktober 2026 sehr konkret geworden. Die Lücken CVE-2026-109618 und CVE-2026-109619 erlauben die Ausführung von Schadcode ohne Anmeldung. Behoben sind sie seit dem 21.10.2026 in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Gute Dateirechte verhindern keinen Angriff, aber sie verhindern, dass eingeschleuster Code Ihre Anwendung dauerhaft umschreibt.
In vielen Installationen gehört der gesamte Code dem Webserver-Benutzer, damit Updates per Knopfdruck funktionieren. Das ist bequem, aber genau die Konstellation, die Angreifer suchen.
Das Grundprinzip: Eigentümer und Laufzeitbenutzer trennen
Sinnvoll ist eine Aufteilung in zwei Rollen. Ein Eigentümer, etwa ein Deploy-Benutzer, besitzt die Dateien und spielt Updates ein. Der PHP-Prozess läuft unter einem anderen Benutzer und ist nur über die Gruppe lesend berechtigt.
| Bereich | Eigentümer : Gruppe | Rechte Dateien | Rechte Ordner |
|---|---|---|---|
| Programmcode | deploy : seite1 | 640 | 750 |
| Konfiguration mit Passwörtern | deploy : seite1 | 640 | – |
| Uploads, Cache, Temp | seite1 : seite1 | 640 | 750 |
| Logs | root oder seite1 | 640 | 750 |
Der Webserver selbst, etwa Nginx, braucht bei PHP-FPM nur Lesezugriff auf statische Dateien wie Bilder und CSS. Diesen erhalten Sie über die Gruppe oder eine gezielte Zugriffsregel. Wer mehrere Websites betreibt, gibt jeder einen eigenen Laufzeitbenutzer; wie das mit Pools zusammenspielt, steht im Ratgeber open_basedir und Isolation pro Website.
Dateirechte auf dem Webserver prüfen
Bevor Sie etwas ändern, verschaffen Sie sich einen Überblick. Die folgenden Befehle verändern nichts.
# Unter welchem Benutzer laufen die PHP-Prozesse?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Für alle beschreibbare Dateien und Ordner
find /var/www -perm -o+w -ls
# Dateien, die dem Webserver-Benutzer gehören (Beispiel www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Rechte der Konfigurationsdateien
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Für alle beschreibbare Einträge sind fast immer ein Fehler. PHP-Dateien, die dem Laufzeitbenutzer gehören, zeigen, dass dieser seinen Code ändern kann. Auffällig sind außerdem einzelne Dateien, deren Eigentümer oder Rechte von den Nachbardateien abweichen. Das kann ein Hinweis auf eingeschleuste Dateien sein, wie im Ratgeber Webshells erkennen und entfernen beschrieben.
Rechte korrigieren: Schritt für Schritt
Ändern Sie Rechte nur nach einer Sicherung und möglichst zuerst auf einer Testumgebung. Wenn der Verdacht auf einen Einbruch besteht, sichern Sie vorher die Spuren, denn Eigentümer und Zeitstempel sind dann Beweismittel.
SITE=/var/www/seite1
# Eigentümer: Deploy-Benutzer, Gruppe: Laufzeitbenutzer
sudo chown -R deploy:seite1 "$SITE"
# Ordner 750, Dateien 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Nur diese Ordner darf PHP beschreiben (Pfade an die Anwendung anpassen)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Prüfen Sie danach die Website vollständig: Startseite, Login, Formulare, Bild-Upload, Caches. Welche Ordner eine Anwendung beschreiben muss, steht in den Systemanforderungen des Herstellers auf dessen offizieller Seite.
Ein chmod -R 777, um ein Problem schnell zu lösen, öffnet den Server für jeden lokalen Benutzer und jeden eingeschleusten Prozess. Korrigieren Sie stattdessen Eigentümer und Gruppe.
PHP-Ausführung in beschreibbaren Ordnern verhindern
Schreibrechte sind nur halb so gefährlich, wenn dort kein Code laufen kann. Sperren Sie die Ausführung von PHP in Upload- und Cache-Ordnern auf Ebene des Webservers. Für Apache in der VirtualHost-Konfiguration:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Für Nginx genügt ein location-Block, der Anfragen auf PHP-Dateien in diesen Ordnern ablehnt. Die Regel gehört in die Serverkonfiguration, nicht in eine .htaccess im Upload-Ordner, die ein Angreifer mit Schreibrechten wieder ändern könnte.
Ergänzend lohnt ein Blick auf die umask des Deploy-Benutzers, damit neue Dateien nicht automatisch zu offen angelegt werden. Ein Wert von 027 führt zu 640 für Dateien und 750 für Ordner. Auf eigenen Servern liegt diese Verantwortung vollständig bei Ihnen; was dort sonst noch dazugehört, beschreibt Root-Server und vServer selbst absichern.
Sonderfälle: Hosting-Panels, Shared Hosting und Deployments
Nicht jeder Server lässt sich nach Lehrbuch einrichten. Hosting-Panels wie Plesk oder cPanel legen eigene Benutzer und Rechte an und setzen diese bei manchen Aktionen zurück. Ändern Sie Rechte dort möglichst über die Funktionen des Panels oder prüfen Sie nach Panel-Updates, ob Ihre Einstellungen noch gelten.
Bei Shared Hosting haben Sie meist nur einen Benutzer für alles. Eine Trennung von Eigentümer und Laufzeitbenutzer ist dann nicht möglich. Umso wichtiger sind knappe Rechte auf Konfigurationsdateien, keine 777-Rechte und das Abschalten der PHP-Ausführung in Upload-Ordnern, soweit der Hoster das zulässt.
Wer mit automatischen Deployments arbeitet, sollte die Rechte im Deployment-Skript selbst setzen. Sonst stellt jede neue Version den alten, zu offenen Zustand wieder her. Eine kurze Prüfung am Ende des Deployments, etwa mit dem Befehl für beschreibbare Dateien von oben, fängt solche Rückschritte zuverlässig ab und lässt sich ohne großen Aufwand in jede Pipeline einbauen.
Wie hilft PHP SOS konkret?
- Wir erfassen Eigentümer, Rechte und Laufzeitbenutzer aller Websites auf dem Server.
- Wir legen ein Rechtekonzept fest, das zu Ihrer Anwendung und Ihrem Update-Weg passt.
- Wir setzen Rechte und Ausführungssperren um und testen die Website danach vollständig.
- Wir dokumentieren das Konzept, damit Deployments und Updates es nicht wieder aufweichen.
Wie das in eine dauerhafte Absicherung eingebettet ist, beschreibt die Leistung Server-Härtung für PHP-Webserver.
Häufige Fragen
Sind 777-Rechte jemals in Ordnung?
Auf einem Produktivserver praktisch nie. Mit 777 darf jeder Benutzer des Systems Dateien anlegen und ändern. Wenn eine Anwendung ohne 777 nicht läuft, ist meist der Eigentümer falsch gesetzt, nicht die Rechte zu knapp.
Warum soll der Webserver seine eigenen Dateien nicht ändern dürfen?
Weil eingeschleuster Code mit den Rechten des Webservers läuft. Darf der Webserver PHP-Dateien schreiben, kann ein Angreifer bestehende Skripte manipulieren oder neue Hintertüren anlegen. Trennt man Eigentümer und Laufzeitbenutzer, bleibt der Code schreibgeschützt.
Wie aktualisiere ich ein CMS, wenn der Webserver nicht schreiben darf?
Updates laufen dann über den Eigentümer, etwa per WP-CLI, Composer oder Deployment, nicht über den Update-Knopf im Backend. Das ist etwas aufwendiger, dafür kann eingeschleuster Code keine Programmdateien ändern.
Welche Rechte braucht die Konfigurationsdatei mit Datenbankpasswort?
So wenige wie möglich: lesbar für den PHP-Benutzer, für niemanden sonst. Üblich sind 640 mit passender Gruppe oder 400, wenn der PHP-Benutzer selbst Eigentümer ist.