Dateirechte: warum eigentlich?

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.
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.
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
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.
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.
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
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.
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.
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. [table style=“1, 2 or 3″]

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

[/table] 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.
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://binary-butterfly.de/chmod-test.php. Das Script gibt dir dann Informationen, wie bei Dir die Dateirechte gesetzt sind und wo du etwas ändern kannst.

Disclaimer

Selbstverständlich helfen Dateirechte nicht gegen alle Angriffsarten. Gegen Angriffe auf die Datenbank sind sie ebenso machtlos wie gegen Kapern von FTP-Zugangsdaten. Aber viele Angriffe auf WordPress gehen auf Dateien, sei es über Sicherheitslücken in Themes oder Plugins, sei es durch das Kapern eines Logins und dem Nutzen der Datei-Schreibfunktionen im Adminbereich. All diese dateibezogenen Angriffe hindert man mit Dateirechten. Die kann auch von keinem Sicherheitsplugin erledigt werden, ein Sicherheitsplugin arbeitet letztlich auch nur mit Rechten von PHP – und je mehr Rechte das Sicherheitsplugin bekommt, desto mehr Rechte hat dann auch der Angreifer.

Außerdem freue ich mich über konstruktive Kritik. Ich habe oft einen allzu technisch-professionellen Blick auf derartige Themen, so dass ich mich über Fragen und Verbesserungsvorschläge freue.

Als vorletzten Satz noch etwas an Menschen, die in Linux und Serverumgebungen zu Hause sind: ja, ich habe in dem Tutorial einige Dinge etwas verkürzt dargestellt und z.B. den Webserver komplett weggelassen. Aber das Tutorial ist so schon lang genug, und so habe ich all das weggelassen, was nicht unbedingt für das Verständnis nötig ist. Für technischere Artikel klickt einfach weiter, die habe ich auch im „Angebot“.

Und zu allerletzt möchte ich mich bei der Open Icon Library und seinen Autoren für die tollen CC-0 Icons bedanken.

47 Kommentare zu “Dateirechte: warum eigentlich?

  1. Super Text. Wäre toll wenn Du noch für Doofies schreiben könntest, wie man Dateirechte praktisch abändert. Ich persönlich fand den Beitrag top, vor allem tolle Grafiken. Super gemacht Ernesto

  2. Hallo, Ernesto. Ich habe deinen Beitrag gelesen und habe noch eine Frage dazu:
    Du schreibst
    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!
    Ich habe ein Plugin für Backup im Einsatz, das einen Ordner in wp-content angelegt hat und dort volle Schreibrechte (777) verlangt. Kann ich/soll ich diesem Ordner die Rechte 777 geben oder nicht? Es ist ja nicht „überall“, sondern nur dieser Ordner.

    1. Das geht schon in Ordnung. Sinnvoll wäre es, in diesem Ordner dann das Ausführen von PHP zu verbieten (geht via .htaccess). Und man sollte das Backup aus diesem Ordner regelmäßig in eine Dropbox / auf den privaten Rechner sichern. Aber das sollte man eh. 🙂

      1. Danke für die Antwort.
        Das Backup wird in dem Ordner eh nur zwischengespeichert und von dort von dem Programm in meine Dropbox geschrieben.
        Ich schau mal, ob ich das mit .htaccess geregelt bekomme.

      2. Ich habe festgestellt, dass das Backup-Plugin in dem Ordner bereits eine .htaccess angelegt hat.
        Deren Inhalt ist schlicht: deny from all.
        Das sieht doch schon mal gut aus. Oder?

          1. Danke.
            Dass das Plug-in das so gemacht hat, schafft Vertrauen. Da hat sich jemand offensichtlich Gedanken gemacht und sorgfältig gearbeitet. So soll es sein.

  3. Da bin ich doch echt froh, root auf meinem Server zu sein und mir die Berechtigungen so vergeben zu können, wie ich sie brauche.

    99,9% der Zeit haben meine WP-Installationen 750 / 640 (sftp:www) Berechtigungen – nur /upload und /cache haben www als Owner.
    Im Moment eines Updates ändere ich den Besitzer der gesamten WP-Projekts auf www, was per Shellscript binnen Sekunden erledigt ist.

    Ich will gar nicht wissen, wie viele Blogs da draußen mit 777 laufen und Angreifen nach Bedarf dort ein und ausgehen …

  4. Hallo Ernesto,

    schönen Dank für Dein Script „chmod-test.php“.
    Anhand des Scripts habe ich in meiner WordPress-Installation die Zugriffsrechte so gesetzt, dass dass Script letztlich in allen Bereichen „grün“ meldet.
    Es funktioniert, wenn ich UID und GID der Dateien auf „root“ setze.
    Wenn ich die Eignerschaft der Dateien auf UID und GID des FTP-Users „foo:bar“ setze, hagelt es rote Einträge.
    Ist das so im Sinnes des Erfinders?
    Oder wo liegt mein Denkfehler?
    Anders gesagt: Wem sollten die Dateien einer WordPress-Installation gehören?

    Gruß,

    Eckhard

    1. Die Idee ist, dass der FTP-Server unter einem anderen User läuft als der PHP-Nutzer. Das ist oftmals nicht machbar bei einem Server mit Plesk / Confixx, da dieses nur einen Systemnutzer anlegt für beide zusammen. Die Grundidee ist aber die Trennung. Wenn du chown root:bar setzt dürfte es gehen – dann fungiert root als zweiter Nutzer. Das ist allerdings schädlich bei Updates, weil dann eben niemand mehr (außer root) die Dateien manipulieren kann.

  5. Hi Ernesto,

    toller Artikel den du hier anbietest und dazu auch noch ein passendes Script mit zu liefern macht den auch noch perfekt.
    Den sollten sich alle Hobbyblogger mal durchlesen und ihre WP-Installation prüfen.

    Vielen Dank
    Chris

    1. Das ist ein Grundcharakteristikum der Linux (und Windows übrigens auch) Benutzerverwaltung. Es gibt nicht nur Systemnutzer, sondern auch Systemgruppen. Nutzer können Mitglieder in Gruppen sein. Zudem ermöglicht dies eine genauere Steuerung der Zugriffsrechte. In diesem Fall kann der Nutzer FTP eine Datei lesen und schreiben, der Nutzer PHP aber nur lesen (die 7 am Anfang). Die Datei gehört dann zudem der Gruppe PHP. Der Nutzer PHP ist in der Gruppe PHP. So kann man über die Gruppenrechte entscheiden, ob PHP nur Lese- oder auch Schreibrechte haben soll. Einen etwas längeren Artikel dazu gibt es hier: http://wiki.ubuntuusers.de/Benutzer_und_Gruppen .

  6. Hey Ernesto,
    danke für das Skript! Ich habe es hochgeladen und es zeigt einige rote „Fehler“ an, obwohl die wp_config und .htaccess z.B 644 haben. Eine Idee woran das liegen könnte? Gibt es einen Unterschied ob ich das im FTP Programm, im cPanel File Manager oder sonst wo mache?
    Danke und Gruß,

    1. Dann sind bei dir PHP Nutzer = FTP Nutzer. Wie du die beiden trennst ist hosterabhängig. Wenn du einen eigenen (v)Server hast kannst du das machen, musst aber ggf. auf das Admin Panel verzichten. Plesk zum Beispiel verhindert eine Trennung der Nutzer recht effektiv.

  7. Ich habe festgestellt, dass wenn man das gesamte Verzeichnis mit
    sudo chown -R www-data:www-data versetzt, trotz der 655 Dateirechte ein automatisches Update möglich ist. Elemente wie bspw. das Themes Dir, dass man per SFTP bearbeiten möchte kann man dann ja wider zurück auf user:www-data setzen.

    Ist das eine gute oder ein doofe Idee?

    1. Dann arbeitet dein Apache mit mod_php, PHP hat immer Schreibrechte und du hast bei Sicherheitslücken „Spaß“. Du kannst ja mal mein Testscript drüberlaufen lassen und schauen was das ausgibt. 655 macht übrigens als Rechtekombination keinen Sinn, entweder 644 oder 755.

  8. btw. FTP halte ich und andere auch für sehr gefährlich. Deswegen läuft das gar nicht mehr auf dem Server. Um die sauberen Dateirechte wie hier beschrieben nicht anzufassen, könnte man ja zum Update einfach www-data als User der Dateien setzen und nach dem Update wieder zurück auf den eigentlichen User stellen, oder?

    1. Klar geht das. Aber die wenigsten Menschen haben Shellzugang. Abgesehen davon ist FTP nicht gefährlich. Gefährlich ist es, wenn man von extern ohne Verschlüsselung darauf zugreift. Aber ebenso gefährlich ist es, wenn man auf wp-admin ohne Verschlüsselung zugreift. Würde ich beides nicht machen.

  9. Hallo Ernesto,
    super, wie schön du das alles erklärt hast und sogar ein Skript zum Testen bereitstellst. Vielen Dank!
    Doch ich musste feststellen, auf meiner Seite steht alles offen.
    Jetzt bin ich als Bloggerin, die von IT-Technik nur wenig Ahnung hat, natürlich sehr interessiert, wie ich das möglichst schnell ändern kann. Über das Plugin Wordfence Security kann ich nämlich gut beobachten, wie meine Seite eifrig getestet wird, im Moment besonders eifrig aus Italien.
    Ich würde mir sehr freuen über Tipps.

    1. Okay, inzwischen habe ich mich mit dem Thema mehr auseinander gesetzt und werde das bald mit Hilfe meines Webhosters Webhostone lösen. Danke für diesen sehr hilfreichen und wichtigen Artikel.

  10. Vielen vielen Dank. Total guter Beitrag. Das erste Mal habe ich das nun halbwegs verstanden mit den Dateirechten. Gleich morgen werde ich meine Dateien und Ordner kontrollieren. Bisher hat mich das immer total angenervt, ich musste bei meinem Hoster sogar immer die Besitzrechte ändern, wenn ich mal wieder mit dem FTP Programm ran wollte. Jetzt verstehe ich warum das so ist.
    Deine Grafiken finde ich auch sehr gut verständlich.
    Also nochmals vielen Dank!!!

  11. Hallo Ernesto,
    wirklich tolle Informationen verständlich verpackt! Auch dein Tool ist klasse. Habe allerdings bei einer Webseite die bei 1&1 gehostet ist das Problem, dass trotz korrekt eingestellter Rechte (755 Ordner, 644 Dateien) dein Tool sagt dass einige Dateien und Ordner noch beschreibbar sind. Laut FileZilla sind sie das aber nicht.
    Hast Du einen Tipp woran das liegen könnte? Auf anderen Webseiten funktioniert das wirklich klasse und ist eine große Hilfe bei der Absicherung des Systems!!!
    Danke für deinen tollen Beitrag!

  12. Hi,
    ich habe gerade Dein Tool auf unterschiedlichen WordPress-Seiten ausprobiert. Bei einer Seite zeigt er mir an, dass sowohl .htaccess als auch die wp_config falsch konfiguriert seien. Die Dateien haben CHMOD 644. Auf einer anderen Seite sind die Dateien ebenfalls mit chmod 644 konfiguriert, hier wird das Ganze aber als korrekt angesehen.. hast Du da eine Idee?

    1. Das hängt vom Hoster ab. Bietet er nur einen Systemnutzer, funktioniert das ganze System nicht, Erklärung habe ich ja oben versucht. Ganz oben ist auch noch verlinkt, welcher Hoster was kann. Vielleicht hilft dir das auch weiter. 🙂

  13. Hallo Ernesto, bei meinem Hoster kann ich gar keine Dateirechte setzen. Wenn ich höhere Rechte wie 644 oder 755 setze gibt es einen Server Error 500. Nach Aussagen meines Hosters, läuft das System mit suPHP und stelle somit eine Lösung dar die auch ohne Dateirechte sicher sei. ist das so korrekt oder erzählen die mir da was? Alternativ kann man dies aber auch umstellen, man empfohl mir jedoch bei der suPHP Konfiguration zu bleiben.

    1. suPHP hat wenig mit der Nutzung von Dateirechten innerhalb der Webapplikation zu tun. Das ist auch sinnvoll, um Webspaces untereinander zu trennen. Das Test-Script dürfte bei dir überall Schreibrechte finden, und Dateirechte sind damit bei deinem Hoster so nicht ohne weiteres möglich.

  14. Danke für die Antwort Ernesto.

    Ja, dass Testscript findet überall Schreibrechte. Also ist es unsicher und ich sollte auf eine andere Konfiguration umsteigen? Warum sagen die mir dann es sei in dem Fall sicher?

    1. Nun, wenn du die zusätzliche Sicherheit der oben beschriebenen zwei Systemnutzer nutzen willst, solltest du das wohl tun, ja. Und warum sie das behaupten? Nun, Dateirechte machen Arbeit, weil viele Website-Betreiber das nicht so recht verstehen. Das bedeutet mehr Support-Aufwand. Ich kann verstehen, dass man als Hoster das dann nicht will. Aber dann kann man als Hoster versierten Kunden eben auch nicht dieses kleine Extra an Sicherheit bieten. Allerdings finde ich es nicht in Ordnung, dann derartigen Unsinn zu erzählen, wie dein Hoster es scheinbar tut. Wenn, dann sollte man schon zu seiner Strategie stehen.

  15. Hallo Ernesto!
    Danke für deine tolle Anleitung. Find ich sehr verständlich und einfach richtig gut.
    Ich hab an meinem Testsystem jetzt gearbeitet und die Einstellungen geändert. In deiner chmod-test bekomme ich eine Meldung nicht weg. Meine Core-Dateien soll ich noch unbeschreibbar machen.
    In meinem FTP-Programm (hab jetzt sogar drei installiert, falls ein Dateityp nicht angezeigt wird) werden jedoch keine core – Dateien angezeigt. Ich stehe total auf dem Schlauch und hab sicherlich n Pfund Tomaten auf den Augen.
    Google hat mir leider auch nicht wirklich weiter geholfen. Wo sind die Core-Dateien, die ich noch verändern muss?
    Danke schonmal jetzt für deine Hilfe und Geduld!

  16. Hallo Ernesto,

    schöner Beitrag, danke! Ich habe eine Frage dazu:

    Meine Dateirechte sind 644 (files) und 755 (dir), owner ist in allen Fällen der FTP User.

    Ich bin mit meiner Seite bei All-Inkl und die haben mir gesagt, ich könnte auch …

    AddHandler php56-cgi .php

    … in die .htaccess eintragen. Ist das korrekt oder was hat es damit auf sich?

    Ich würde mich riesig über eine Antwort freuen. Viele Grüße!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.