Regelmäßig findet man zum Thema WordPress Sicherheit Tips zu Dateirechten. Aber was hat es eigentlich damit auf sich? Was ist dieses chmod 664 und 775? Dieser Post soll dies aufklären. Zielgruppe sind hierbei WordPress-Admins, die ein wenig Erfahrung mit WordPress haben, schon einmal ein WordPress-Security-Tutorial gelesen haben, jedoch noch nie etwas mit Linux-Dateirechten zu tun hatten.
Achtung! Korrekt gesetzte Dateirechte verhindern das Auto-Update. Zudem benötigt man die FTP-Daten bei einem Update. Dateirechte richten sich also nur an Admins, die sich auch wirklich um ihre Installation kümmern, z.B. im Unternehmen oder bei wichtigen privaten Blogs – denn Updates selbst einspielen ist dann Pflichtprogramm!
[UPDATE]Wie man Dateirechte je nach Hoster einstellt findet Ihr in einem weiteren Artikel.[/UPDATE]
WORDPRESS IM NORMALBETRIEB
Um zu verstehen warum Dateirechte so wichtig sind, muss man verstehen, wie ein Aufruf einer WordPress-Seite eigentlich funktioniert.
Aufruf einer WordPress-Seite.
Das Grundprinzip ist wie folgt: Der Nutzer ruft den Webserver mit PHP auf, PHP liest die index.php, dort steht drin, was PHP noch alles lesen und verarbeiten soll. PHP-Dateien werden (normalerweise) ausschließlich gelesen, in die Datenbank schreibt man auch öfter mal etwas – z.B. einen Kommentar. Wenn PHP alles abgearbeitet hat sendet es die fertig generierte Website an den Nutzer zurück.
Aufruf der WordPress-Adminoberfläche.
Genauso funktioniert auch der Adminbereich. Der Nutzer ruft PHP auf, dieses liest die index.php in wp-admin und danach viele weitere Daten. Geschrieben werden dabei außerhalb des Upload-Ordners keinerlei Dateien. Und im Upload-Ordner sind keine PHP-Dateien, sondern Bilder, PDFs und all das andere, was wir in unser Blog einbinden wollen. Wir lernen also: PHP-Dateien braucht man nicht schreiben können. Es reicht, sie lesen zu können. Mit einer Ausnahme: dem Update-Vorgang.
Update von WordPress ohne Dateirechte
Das Update von Themes, Plugins und Core (also dem WordPress Hauptsystem) erfordert Schreibrechte. Klar – die alte Version des Themes / Plugins / Cores soll ja gegen die neue ausgetauscht werden, d.h. die neue Datei muss geschrieben werden.
ANGRIFF AUF WORDPRESS: MISSBRAUCH DER SCHREIBRECHTE
Solange es keine Angreifer gibt, ist die Lösung oben perfekt weil absolut simpel und direkt. Das Problem ist – ein Angreifer kann dies für seine Zwecke missbrauchen.
Angriff auf eine WordPress-Seite ohne Dateirechte.
Für PHP besteht zunächst kein Unterschied, ob der Nutzer eingeloggt ist oder nicht. PHP führt die PHP-Datei, die man aufruft, aus. Wenn diese eine Sicherheitslücke hat, mit der man Dateien auf den Server schreiben kann, tut PHP das. Dagegen kann PHP nichts machen. PHP weiß nichts davon, dass das ein böser Angreifer ist – woher auch? Dass der Angreifer keine Rechte dazu hat – das sagt die PHP-Datei. Und die PHP-Datei hat nun einmal eine Sicherheitslücke, so dass die PHP-Datei keine Hilfe mehr ist.
DIE LÖSUNG: KEINE SCHREIBRECHTE AUF PHP-DATEIEN
Derartige Sicherheitslücken kommen insbesondere in Plugins und Themes häufiger vor und sind zum Teil wirklich schwer zu sehen. Man wird also immer das Restrisiko haben, eine PHP-Datei mit einer solchen Sicherheitslücke irgendwo in seinem WordPress zu haben. Also muss ein anderer Sicherheitsmechaniusmus her: Dateirechte. Dazu betrachten wir den einzigen Vorgang, wo Schreibrechte auf Dateien benötigt werden, noch einmal: das Update.
Update von WordPress mit Dateirechten.
Den Dialog habt ihr sicherlich schon irgendwann einmal gesehen – WordPress fragt dann beim Update die FTP-Zugangsdaten ab. Und vielleicht werden sich einige gefragt haben, warum sie diese dämlichen Zugangsdaten da eingeben müssen jedes mal. Das sei doch voll umständlich. Dazu zunächst die nächste Grafik, welche zeigt, was mit unserem Angreifer passiert, welcher auf ein WordPress mit eingerichteten Dateirechten stößt:
Angriff auf eine WordPress-Seite mit Dateirechten 1.
Die Sicherheitslücke ist noch da, aber dem Angreifer fehlen die Schreibrechte, um diese zu nutzen. Der einzige Weg, Schreibrechte zu erhalten, geht bei Nutzung von Dateirechten über den FTP-Server. Wenn der Angreifer das versucht passiert das folgende.
Angriff auf eine WordPress-Seite mit Dateirechten über FTP.
Der Angreifer hat keine Chance mehr, seinen Wordress-Virus zu plazieren. Ihm fehlen einfach Informationen, und er hat keine Chance, diese Informationen zu bekommen: er braucht die FTP-Zugangsdaten, um Dateien schreiben zu können. Diese Zugangsdaten sind aber nirgends auf der WordPress-Installation – denn der Admin gibt sie zum Zeitpunkt des Updates einfach im Browser ein, das Update läuft dann über den FTP-Server. Nach dem Update werden die Zugangsdaten gelöscht, der Angreifer schaut in die Röhre.
WIE BEKOMMT MAN SCHREIBSCHUTZ FÜR PHP-DATEIEN?
Nun müsstest Du verstanden haben, warum man einen Schreibschutz will. Aber wie erreicht man das? Hier kommen diese chmod 775, 664 und Co ins Spiel. Chmod ist eigentlich ein Kommoandozeilen-Befehl. Wirklich wichtig sind die drei Zahlen, welche dann immer mitgeliefert werden. Was bedeuten diese? Ein ganz kurzer Ausflug in Unix / Linux Dateirechte wird nötig.
Dateirechte Ziffern.
Nun wissen wir, welche Position was bedeutet. Ausserdem müssen wir wissen, was der Unterschied zwischen einer 4, einer 5 und einer 7 ist.
| ZIFFER | DATEIEN | ORDNER |
|---|---|---|
| 0 | keine Rechte | keine Rechte |
| 1 | ausführen | Inhalt auflisten |
| 2 | schreiben | schreiben |
| 3 | schreiben, ausführen | schreiben, Inhalt auflisten |
| 4 | lesen | lesen |
| 5 | lesen, ausführen | lesen, Inhalt auflisten |
| 6 | lesen, schreiben | lesen, schreiben |
| 7 | lesen, schreiben, ausführen | lesen, schreiben, Inhalt auflisten |
Wie Du siehst, haben die Zahlen bei Dateien und Ordnern unterschiedliche Bedeutungen. Relevant für WordPress sind bei Dateien 4 und 6 (lesen bzw. lesen und schreiben), bei Ordnern 5 und 7 (lesen und Inhalt auflisten bzw. lesen, schreiben und Inhalt auflisten). So wichtig, wie das Auflisten von dem Inhalt eines Ordners ist, so wichtig ist es auch, den Dateien nicht das Recht zum Ausführen zu geben, denn ausführbare Dateien sind ein potentielles Sicherheitsrisiko.
WIE FUNKTIONIEREN DATEIRECHTE?
Um letztlich zu verstehen, warum Dateirechte funktionieren, müssen wir noch verstehen, dass jede Datei auch einen Besitzer und eine Gruppe hat. Oftmals ist der Besitzer der FTP-Nutzer und die Gruppe der PHP-Nutzer.
Dateirechte Auswirkungen.
Chmod 644 bedeutet also, dass die Datei vom Besitzer = FTP geschrieben werden darf (6!), von der Gruppe = PHP aber nur gelesen werden darf (4!). Ein potentieller Angreifer wird nur via PHP kommen können (siehe oben), also hat er keine Chance, eine Datei zu schreiben. Bei Ordnern wollen wir zusätzlich den Inhalt lesen können. Also 755 für einen Ordner. Auf einige wenige Stellen will der Nutzer natürlich trotzdem schreiben können. Dort setzt er dann eine Datei 664, das bedeutet, dass die Datei vom Besitzer = FTP geschrieben werden darf (6!) ebenso wie von der Gruppe = PHP (6!). Bei Ordnern analog 775.
WO BRAUCHT WORDPRESS SCHREIBRECHTE?
Der Normalzustand für fast alle Dateien sollten keine Schreibrechte für PHP sein, also bei den meisten Hostern 644 für Dateien bzw. 755 für Ordner. An einige Orte muss der Nutzer aber trotzdem schreiben. In folgenden Ordnern bräuchte man also 664 für Dateien und 775 für Ordner:
- /wp-content/uploads/
- /wp-content/cache/ (bei Verwendung eines Caching-Plugins)
- /wp-content/blogs.dir/ (bei Verwendung von älterem WordPress Multisite)
- …
Einige Themes / Plugins benötigen noch weitere Ordner mit Schreibrechten. Aber Achtung: einige Themes oder Plugins wollen überall 664 / 775 oder gar 666 / 777. Wenn Das Voraussetzung für die Funktion des Themes / Plugins ist, ist das Theme / Plugin schlecht programmiert – ich rate sehr vom Einsatz ab!
TESTEN DER DATEIRECHTE-EINSTELLUNGEN
Wie teste ich nun, ob alle Dateirechte stimmen? Ganz einfach – mit einem kleinen PHP Script, das du hier downloaden kannst. Das entzippst Du und lädst die chmod-test.php in das Basisverzeichnis deines WordPress, also dort, wo auch die wp-config.php liegt. Dann rufst du http://deine-wordpress-adresse.de/chmod-test.php auf – bei mir wäre das https://sectio-aurea.org/chmod-test.php. Das Script gibt dir dann Informationen, wie bei Dir die Dateirechte gesetzt sind und wo du etwas ändern kannst.
Vorweg: Dieser Artikel behandelt nur Webspace, d.h. er gibt eine Übersicht über die Möglichkeiten auf Webspace bei verschiedenen Hostern. Es ist keine Übersicht über Managed Server. Bei Root-Servern seid ihr dagegen selbst für die Sicherheit eures Systems und damit auch für Dateirechte verantwortlich.
Leider gibt es beim Thema Dateirechte kein Universalrezept. Viele Anleitungen suggerieren, dass man einfach chmod 750 bzw 640 machen müsse, und schon sei alles sicher. Wenn FTP- und PHP-Nutzer allerdings identisch sind, ist chmod wirkungslos. Wieso das so ist, habe ich umfassend in einem vorangegangenen Post erläutert. Erschreckend viele Hoster weisen auf die völlige Sinnlosigkeit von chmod bei identischen Systemnutzern nicht einmal hin und wiegen so ihre Kunden in falscher Sicherheit.
Mit Hilfe der Facebook-Gruppe von DRWP habe ich eine ganze Reihe an Hostern gesammelt und diese angefragt. Grundsätzlich gibt es vier Kategorien von Hostern:
- Hoster, bei denen PHP- und FTP-Nutzer als Standardeinstellung unterschiedlich sind und chmod so wirkt, dass 750 / 640 nur Leserechte, 770 / 660 Lese- und Schreibrechte für PHP bedeuten.
- Hoster, bei denen man die Trennung zwischen PHP- und FTP-Nutzer manuell umstellen muss; danach funktionieren sie wie die Kategorie 1)
- Hoster, bei denen chmod wirkungslos ist, die aber ein gesondertes Interface in ihrem Kundenbereich haben, um PHP- und FTP-Nutzer zu trennen
- Hoster, bei denen chmod wirkungslos ist, und es keine Möglichkeit gibt, Dateirechte zu nutzen
In Folge liste ich alle Hoster in den vier Kategorien auf. Wenn Dir ein Hoster fehlt, schreibe mir das bitte – ich frage dann nach. Um den Webspace / die Aussagen des Supports zu testen, empfehle ich das Script aus dem Dateirechte-Post. Wenn dabei rauskommen sollte, dass der Support des jeweiligen Hosters Falschaussagen getroffen hat, freue ich mich sehr über eine Nachricht.
Disclaimer: Ich übernehme für die Auflistung keine Garantie – ich habe nur wenige der Hoster selbst getestet und fasse hier vor allem Aussagen des jeweiligen Supports zusammen. Manchmal waren die Aussagen des Supportes auch sehr interpretierungsbedürftig, so dass ich auch für die Interpretation keine Garantie übernehme.
(1) SICHERE STANDARD-KONFIGURATION (CHMOD)
ALL-INKL
Sichere Standardkonfiguration. Statt 770 bzw. 660 muss aber 777 bzw. 666 verwendet werden, statt 750 bzw. 640 jeweils 755 bzw 644. Dies ist kein Sicherheitsrisiko, da All Inkl open_basedir nutzt, um PHP einzusperren. Aber Achtung: wenn man via .htaccess die CGI-Version von PHP lädt, ist chmod wirkungslos!
Website: http://all-inkl.com/
Quelle: Support, eigene Tests.
JP BERLIN
Sichere Standardkonfiguration, chmod funktioniert wie erwartet.
Website: https://www.jpberlin.de/
Quelle: Support.
MANITU
Sichere Standardkonfiguration, chmod funktioniert wie erwartet.
Website: https://www.manitu.de/
Quelle: Support.
NOVAHOSTING
Sichere Standardkonfiguration, chmod funktioniert wie erwartet.
Website: http://www.novahosting.ch/
Quelle: Support.
WP WEBHOSTING
Sichere Standardkonfiguration, chmod funktioniert wie erwartet.
Website: http://www.wp-webhosting.de/
Quelle: Support.
(2) SICHERE KONFIGURATION NACH ÄNDERUNGEN (CHMOD)
1UND1
Sichere Standardkonfiguration, chmod funktioniert wie erwartet. Dies gilt aber nur, wenn man nicht den 1und1 WordPress Installer nutzt, sondern die WordPress Dateien via FTP hochlädt.
Website: http://www.1und1.de/
Quelle: Nutzererfahrung. Support behauptet, der Webspace würde Dateirechte per default nutzbar haben, was aber nicht zu stimmen scheint.
EHRENWERT IT
Bei der Standardkonfiguration ist chmod wirkungslos. Trennung von PHP- und FTP-Nutzer möglich durch Aktivierung von mod_php im Kundenbereich, dann funktioniert chmod wie erwartet.
Website: https://www.ehrenwert-it.de/
Quelle: Support.
HOSTEUROPE
Bei der Standardkonfiguration ist chmod wirkungslos. Trennung von PHP- und FTP-Nutzer möglich im Kundenbereich (der FTP-Nutzer muss von www auf ftp umgestellt werden, anschließend alle Dateien dem ftp-Nutzer zugeordnet werden). Dann funktioniert chmod wie erwartet.
Website: http://hosteurope.de/
Quelle: eigene Tests.
NETCUP
Mit Nutzung der zusätzlichen FTP-Nutzer (Verfügbar ab dem Expert-Tarif) hat man einen zweiten Systemnutzer. Wenn alle Dateien diesem Nutzer gehören, sind Dateirechte via chmod möglich.
Website: https://www.netcup.de/
Quelle: Support.
MITTWALD
Mit Nutzung des (zusätzlichen) FTP-Nutzer Typ 2 (pXXXXXXfyy) hat man einen zweiten Systemnutzer. Wenn alle Dateien diesem Nutzer gehören, sind Dateirechte via chmod möglich.
Website: https://www.mittwald.de/
Quelle: Support.
RSHOST
Bei der Standardkonfiguration ist chmod wirkungslos. Trennung von PHP- und FTP-Nutzer möglich durch Freischalten seitens des Supports, dann funktioniert chmod wie erwartet.
Website: http://www.rshost.eu/
Quelle: Support.
TOPHOSTER
Bei der Standardkonfiguration ist chmod wirkungslos. Trennung von PHP- und FTP-Nutzer möglich durch Freischalten seitens des Supports, dann funktioniert chmod wie erwartet.
Website: https://www.tophoster.de/
Quelle: Support.
WEBHOSTONE
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: https://www.webhostone.de/
Quelle: Kommentar unter diesem Artikel.
(3) SICHERE KONFIGURATION VIA INTERFACE IN KUNDENBEREICH
STRATO
Dateirechte sind im Kundenbereich einstellbar. Hierzu muss zunächst der Schreibschutz aktiviert werden und anschließend die Ausnahmen definiert werden. Via FTP eingestellte chmod-Werte sind wirkungslos, der Schreibschutz erfolgt über ACLs und eine SQLite Datenbank.
Website: http://www.strato.de/
Quelle: Support, eigene Tests.
(4) SICHERE KONFIGURATION NICHT MÖGLICH
1BLU
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: https://www.1blu.de/
Quelle: Support.
5HOSTING
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: http://www.5hosting.com/
Quelle: Support.
ALFAHOSTING
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: http://alfahosting.de/
Quelle: Facebook Support
CHECKDOMAIN
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: https://www.checkdomain.de/
Quelle: Support.
DOMAIN FACTORY
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: http://df.eu/
Quelle: Support.
EASYNAME
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: http://www.easyname.com/
Quelle: Support.
GONEO
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: https://www.goneo.de/
Quelle: Support.
HETZNER
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: http://www.hetzner.de/
Quelle: Support.
HOSTPOINT
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: https://www.hostpoint.ch/
Quelle: Support.
LIMA-CITY
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: https://www.lima-city.de/
Quelle: Support.
TIMMEHOSTING
Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.
Website: https://timmehosting.de/
Quelle: Support.
