WordPress-Dateiberechtigungen: 644, 755 und Eigentümer

WordPress-Dateiberechtigungen: der sichere Standard in einem Absatz

Der sichere Standard für WordPress-Dateiberechtigungen lautet: 755 für Verzeichnisse, 644 für Dateien und strengere 640 oder 600 für wp-config.php. 777 verwenden Sie nie. Diese Zahlen schützen Sie aber nur, wenn die Dateien dem richtigen Benutzer gehören. Ein tadelloses 644 auf Dateien mit dem falschen Eigentümer führt zu einem von zwei Problemen: Uploads und Updates schlagen fehl, oder der Webserver bekommt unbemerkt mehr Rechte, als er braucht. Lesen Sie deshalb den Abschnitt zum Eigentümer, bevor Sie Modi ändern.

Eigentümer, Gruppe und andere: 755 und 644 richtig lesen

Wenn Sie im WordPress-Hauptverzeichnis ls -l ausführen, sehen Sie Zeilen wie diese:

drwxr-xr-x  5 deploy www-data  4096 Oct 30 09:12 wp-content
-rw-r--r--  1 deploy www-data   405 Oct 30 09:12 index.php
-rw-r-----  1 deploy www-data  3214 Oct 30 09:12 wp-config.php

Das erste Zeichen zeigt den Typ (d für Verzeichnis, - für Datei). Danach folgen drei Gruppen mit je drei Buchstaben: eine für den Eigentümer (deploy), eine für die Gruppe (www-data) und eine für alle anderen. r steht für Lesen, w für Schreiben und x für Ausführen. Jeder Buchstabe hat einen Wert: r = 4, w = 2, x = 1. Zählen Sie die Werte je Gruppe zusammen, erhalten Sie den Oktalmodus. Aus rwxr-xr-x wird so 7-5-5.

Bei einem Verzeichnis bedeutet `x** „darf betreten werden“. Fehlt es, kann PHP die darin liegenden Dateien nicht öffnen, selbst wenn diese lesbar sind. Deshalb brauchen Verzeichnisse 755, Dateien dagegen nur 644. In einer normalen WordPress-Installation benötigt keine einzige Datei das Ausführungsbit.

Der Eigentümer zählt genauso viel wie der Modus

Finden Sie zuerst heraus, unter welchem Benutzer PHP läuft. Auf einem eigenen Server prüfen Sie die laufenden Prozesse:

ps -eo user,comm | grep -E 'php-fpm|apache2|httpd' | sort | uniq

Bei PHP-FPM läuft der Master-Prozess als root, die Worker laufen als Pool-Benutzer. Diesen Benutzer legt die Pool-Datei fest. Unter Debian und Ubuntu liegt sie meist unter /etc/php/<version>/fpm/pool.d/:

grep -R -E '^(user|group) *=' /etc/php/*/fpm/pool.d/

Die Konfigurationsdokumentation zu PHP-FPM beschreibt diese Einstellungen. Mit Apache und mod_php läuft PHP als Apache-Benutzer selbst: www-data unter Debian/Ubuntu, apache auf RHEL-basierten Systemen. Alle Websites auf diesem Server teilen sich dann eine Identität. Gutes Shared Hosting trennt die Websites dagegen voneinander, sodass PHP für jedes Konto unter dessen eigenem Benutzer läuft. Wenn Sie ps nicht ausführen können, sehen Sie unter Werkzeuge > Website-Zustand > Bericht > Dateisystem-Berechtigungen nach. Dort steht, ob WordPress in sein Hauptverzeichnis, in wp-content, in die Uploads sowie in die Plugin- und Theme-Verzeichnisse schreiben kann.

Sobald Sie den PHP-Benutzer kennen, entscheiden Sie sich für eines von zwei Eigentümermodellen.

Modell A: Dem PHP-Benutzer gehört alles. Das ist auf isoliertem Shared Hosting üblich, wo Ihr Kontobenutzer und der PHP-Benutzer identisch sind. Updates aus dem Dashboard, Plugin-Installationen und Uploads funktionieren problemlos. Der Nachteil: Jeder Code, der als PHP läuft, kann auch jede Datei überschreiben, einschließlich Core, Plugins und wp-config.php.

Modell B: Ein Deploy-Benutzer besitzt die Dateien, PHP liest nur. Die Dateien gehören zum Beispiel deploy:www-data, mit 755/644. PHP kann alles lesen, aber nur dort schreiben, wo Sie es erlauben: in wp-content/uploads und in etwaigen Cache-Verzeichnissen. Aktualisiert wird dann per WP-CLI oder SFTP als Deploy-Benutzer, nicht über das Dashboard. Das begrenzt den Schaden, macht aber mehr Arbeit. Wenn Sie das Dashboard zusätzlich dauerhaft sperren wollen, lesen Sie DISALLOW_FILE_MODS und seine Vor- und Nachteile.

Modell B erklärt auch ein verbreitetes Rätsel: WordPress fragt nach FTP-Zugangsdaten, sobald Sie auf „Aktualisieren“ klicken. WordPress prüft, ob neu angelegte Dateien denselben Eigentümer hätten wie die eigenen Dateien. Ist das nicht der Fall, weicht es auf FTP aus. FS_METHOD auf direct zu erzwingen, kaschiert das Symptom, behebt aber nicht die Ursache. Entscheiden Sie sich für ein Modell und setzen Sie den Eigentümer passend dazu.

WordPress-Dateiberechtigungen sicher zurücksetzen

Erstellen Sie zuerst ein Backup von Dateien und Datenbank. Wechseln Sie dann ins WordPress-Hauptverzeichnis und vergewissern Sie sich, dass Sie am richtigen Ort sind:

cd /var/www/example.com/public
ls wp-config.php

Findet ls die Datei wp-config.php nicht, brechen Sie ab. (Manche Setups legen sie eine Ebene über dem Web-Root ab, prüfen Sie also Ihre Verzeichnisstruktur.) Danach setzen Sie die Modi zurück:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Bei großen Websites ist die Variante mit + deutlich schneller, weil sie jedem chmod-Aufruf viele Dateien auf einmal übergibt:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

Den Eigentümer ändern Sie nur auf einem Server, den Sie selbst kontrollieren. Für Modell B sieht das so aus:

sudo chown -R deploy:www-data /var/www/example.com/public

Das Zurücksetzen bügelt auch die unten beschriebenen Ausnahmen glatt. Setzen Sie diese also sofort wieder. Prüfen Sie anschließend das Ergebnis mit stat -c '%a %U:%G %n' wp-config.php wp-content/uploads, laden Sie ein Testbild hoch und rufen Sie ein paar Seiten auf.

Ausnahmen: wp-config.php, Uploads und .htaccess

wp-config.php enthält Ihr Datenbankpasswort, „andere“ bekommen deshalb gar keine Rechte. Verwenden Sie 600, wenn die Datei dem PHP-Benutzer gehört (Modell A). Verwenden Sie 640, wenn ein Deploy-Benutzer der Eigentümer ist und PHP die Datei über die Gruppe liest (Modell B). Setzen Sie unter Modell B 600, kann PHP die Datei nicht lesen, und die Website fällt aus. Zu Salts, Debug-Einstellungen und vergessenen Sicherungskopien lesen Sie wp-config.php absichern.

wp-content/uploads und die Cache-Verzeichnisse müssen für den PHP-Benutzer beschreibbar sein. Unter Modell B machen Sie entweder den PHP-Benutzer zum Eigentümer dieser Verzeichnisse, oder Sie ordnen sie der PHP-Gruppe zu und geben der Gruppe Schreibrechte (775 für Verzeichnisse, 664 für Dateien). Beschränken Sie Schreibrechte auf genau diese Pfade, nicht auf ganz wp-content.

Unter Apache ist .htaccess ein Sonderfall. Ist die Datei beschreibbar, aktualisiert WordPress die Rewrite-Regeln, sobald Sie die Permalinks speichern, und Cache- oder Sicherheits-Plugins fügen eigene Blöcke ein. Ist sie nicht beschreibbar, zeigt WordPress Ihnen die Regeln an, damit Sie sie von Hand einfügen. Eine schreibgeschützte .htaccess kostet etwas Komfort. Dafür kann Code, der als PHP läuft, dort keine Weiterleitung und keine auto_prepend_file-Zeile einschleusen.

Warum 777 nie einen Upload-Fehler behebt

Mit 777 darf jedes Konto und jeder Prozess auf dem Server in die Datei oder das Verzeichnis schreiben. Auf Shared Hosting gehören dazu unter Umständen auch kompromittierte Skripte anderer Kunden. Der Upload-Fehler mag damit verschwinden, aber nur, weil der Schutz entfernt wurde, nicht weil die Ursache behoben ist. Prüfen Sie die tatsächlichen Ursachen in dieser Reihenfolge:

1. Falscher Eigentümer. Die Meldung „Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?“ bedeutet fast immer, dass der PHP-Benutzer nicht Eigentümer der Uploads ist (oder nicht hineinschreiben kann). Das passiert häufig nach einer Migration oder einer Wiederherstellung, die als root durchgeführt wurde.
2. Festplatte oder Kontingent voll. Prüfen Sie auf dem eigenen Server df -h, ansonsten das Kontingent in Ihrem Hosting-Panel.
3. Temporäres Verzeichnis oder Pfadbeschränkungen. „Missing a temporary folder“ deutet auf upload_tmp_dir hin. Auch eine open_basedir-Beschränkung, die den temporären Pfad ausschließt, kann Uploads blockieren.
4. Größenlimits. „The uploaded file exceeds the upload_max_filesize directive“ heißt: Sie müssen upload_max_filesize und post_max_size erhöhen oder eine kleinere Datei hochladen.

Auf Shared Hosting können Sie chown meist nicht selbst ausführen. Bitten Sie Ihren Hoster, den Eigentümer in Ihrem Konto auf den richtigen Benutzer zu setzen. Das ist eine Routineanfrage.

Wovor korrekte Berechtigungen nicht schützen

Berechtigungen begrenzen, was ein Benutzer tun darf. Gegen Code, der bereits als dieser Benutzer läuft, richten sie nichts aus. Erlaubt ein verwundbares Plugin einem Angreifer, PHP auszuführen, hat sein Code die Rechte des PHP-Benutzers. Unter Modell A heißt das: alles. Unter Modell B immer noch die Uploads, die Cache-Verzeichnisse und alles andere, was Sie beschreibbar gemacht haben. Genau deshalb nehmen Angreifer bevorzugt uploads ins Visier, wie in Web-Shells in wp-content/uploads beschrieben.

Auch das Zurücksetzen der Berechtigungen nach einem Hack entfernt keine Hintertür. Die Schaddatei bleibt, nur eben mit ordentlichen Modi. Arbeiten Sie zuerst einen sauberen Plan zur Malware-Entfernung ab und korrigieren Sie die Berechtigungen dann im Rahmen der Härtung. Im Sinne der DSGVO können korrekte Berechtigungen zu den technischen Maßnahmen zählen, die Integrität und Vertraulichkeit personenbezogener Daten schützen (Art. 32, EUR-Lex). Wirksam sind sie aber nur als Teil eines umfassenderen Maßnahmenbündels.

Berechtigungen regelmäßig prüfen

Berechtigungen verschieben sich mit der Zeit. Die üblichen Auslöser sind Migrationen, Backup-Wiederherstellungen, ein Hosterwechsel und der schnelle Fix mit sudo. Führen Sie die folgenden zwei Prüfungen nach jedem dieser Ereignisse im WordPress-Hauptverzeichnis aus, und zusätzlich alle paar Monate:

find . -perm -o+w ! -type l
find . ! -user deploy

Der erste Befehl listet alles auf, was für alle beschreibbar ist (symbolische Links sind ausgenommen, weil sie immer 777 anzeigen). Der zweite listet Dateien, die nicht dem erwarteten Eigentümer gehören. Ersetzen Sie deploy unter Modell A durch Ihren PHP-Benutzer. Beide Befehle sollten nichts ausgeben, oder nur Pfade, die Sie erklären können. Der Leitfaden zu Dateiberechtigungen auf WordPress.org beschreibt dieselbe Grundlinie aus Sicht des Core-Teams.

Für den Blick aufs Ganze führt das Plugin Security Audit & Compliance von secaudit.eu Härtungs- und Konfigurationsprüfungen durch und überwacht zusätzlich die Dateiintegrität. So fallen geänderte oder neue Dateien auch zwischen Ihren manuellen Kontrollen auf → secaudit.eu

FAQ

Sollte wp-config.php auf 400 oder 440 stehen?

Das funktioniert ebenfalls, solange PHP die Datei noch lesen kann: 400, wenn PHP der Eigentümer ist, 440, wenn PHP sie über die Gruppe liest. Der Haken: Zum Bearbeiten müssen Sie den Modus jedes Mal zurückändern. 600 oder 640 ist der übliche Kompromiss.

Ist 755/644 auf Shared Hosting sicher?

Ja, sofern der Hoster die Konten voneinander isoliert und Ihr PHP unter Ihrem eigenen Benutzer läuft. Mit 644 könnten andere Konten Ihre Dateien technisch gesehen lesen. Eine saubere Isolation verhindert das. Deshalb kommt es mehr auf das Setup Ihres Hosters an als auf die Ziffern.

Muss ich die Berechtigungen nach jedem Update zurücksetzen?

Nein. WordPress legt neue Dateien mit sinnvollen Modi an. Führen Sie stattdessen die Prüfungen oben aus, und setzen Sie nur zurück, wenn diese Probleme zeigen.