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!
Wie man Dateirechte je nach Hoster einstellt findet Ihr in einem weiteren Artikel.
WordPress im Normalbetrieb
Um zu verstehen warum Dateirechte so wichtig sind, muss man verstehen, wie ein Aufruf einer WordPress-Seite eigentlich funktioniert.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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
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.
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. 🙂
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.
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?
Yep. Das ist perfekt. Dann kann da niemand dran.
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.
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 …
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
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.
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
Eine Empfehlung je nach Hoster ist auch noch in Vorbereitung. Mails gingen heute raus. 🙂
Danke für die ausführliche Beschreibung; was ich aber nie verstanden habe: wer oder was sind „Gruppen“?
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 .
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ß,
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.
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?
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.
Herzlichen Dank! Aus der PHP Sicht habe ich das noch nie betrachtet! War natürlich alles rot.
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?
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.
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.
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.
[…] Ordnern und Dateien zuweisen solltest (mehr Infos dazu gibt es in diesem Artikel beschrieben: Dateirechte warum eigentlich). Um auf deinen FTP zugreifen zu können lädst du dir am Besten Filezilla […]
[…] https://binary-butterfly.de/2014/07/dateirechte-warum-eigentlich/ […]
Richtig guter Artikel und vielen Dank für das Script.
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!!!
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!
[…] Jeder WordPress Nutzer sollte sich eigentlich mit Dateirechten beschäftigen, denn sie sorgen dafür, dass dein WordPress sicher bleibt. Dazu habe ich hier eine schöne Erklärung für dich gefunden. Darin erfährst du, was Dateirechte sind und als Extra bietet Ernesto Ruge auf seiner Seite sogar ein kleines Script, mit dem du testen kannst, ob bei dir alles ok ist. Ab zum Artikel. […]
[…] Achtung. Wer seine Installation über eingeschränkte PHP-Nutzerrechte absichert wie in Ernestos Artikel zur WordPress Sicherheit erwähnt, der schaltet diese Sicherung mit dem .htaccess Eintrag wieder […]
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?
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. 🙂
[…] man z.B. darauf achtet, dass der Server korrekte Schreibrechte hat – das hat Ernesto Ruge hier mal genauer beschrieben. Das geht aber technisch schon sehr weit und ist nur für erfahrene […]
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.
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.
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?
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.
[…] Im besten Fall sollten so wenig Dateien wie möglich keine Schreibrechte besitzen. Versehe all kritischen Dateien mit den Rechten »644«. Um die Funktionalität von WordPress zu wahren, gibt es ein paar Ausnahmen. Um Medien hochzuladen benötigt /wp-content/uploads/ Schreibrechte. Gleiches gilt für /wp-content/cache/ solltest Du ein Caching-Plugin verwenden. Ansonsten sei bitte sparsam mit der Vergabe von Schreibrechten. Wenn ein Plugin oder ein Theme zu viele Rechte einfordert um zu funktionieren, solltest Du nach einer alternative suchen. Eine leicht verständliche und teilweise bebilderte Anleitung findest Du HIER. […]
[…] FTP-Benutzer und dem PHP-Benutzer trennt. Ernesto Ruge hat auf seinem Blog in dem Beitrag „Dateirechte – warum eigentlich“ sehr schön beschrieben warum das eine absolut sinnvolle Vorgehensweise […]
[…] den Anfänger tatsächlich etwas schwer zu verstehen ist, verlinke ich hier einmal die sehr schöne Erklärung von Ernesto Ruge zu Dateirechten und ihrer Rolle bei […]
[…] sollte nur von erfahrenen Nutzern durchgeführt werden. Eine ausführliche Anleitung gibt es auf Sectio Aurea.Von Stefan Reinpold|2016-01-25T19:25:14+00:00 17. Oktober […]
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!
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!
Mit „AddHandler php56-cgi .php“ deaktivierst du die Dateirechte auf All Inkl. Ist nicht so empfehlenswert. 😉
[…] Anweisungen von Ernesto Ruge […]
[…] Verlassen Sie sich aber nicht einfach nur auf Plugins, sondern sehen Sie zu, dass WordPress gleich von vornherein gut installiert wurde. Ernesto Ruge schreibt dazu einiges in seinem Blog. […]
[…] Wer sich noch weitergehend mit dem Thema auseinandersetzen möchte, kann das in diesem serh ausführlichen Artikel über Dateirechte tun: „Dateirechte: Warum eigentlich“ […]
[…] Dateirechte, warum eigentlich?: https://binary-butterfly.de/2014/07/dateirechte-warum-eigentlich/ […]
Hallo Ernesto,
ist es sinnvoll die Rechte wie von dir beschrieben zu setzen. (ftpuser:www-data mit den Rechten 755 (Ordner) und 644 (Dateien) und in der wp-config.php folgendes hinzuzufügen:
define(‚FTP_HOST‘, ‚ftp.example.org‘);
define(‚FTP_USER‘, ‚username‘);
define(‚FTP_PASS‘, ‚password‘);
Oder sind wir dann wieder bei dem oben beschriebenen Problem, das im Falle eines Angriffs der Angreifer über die PHP Datei mit Sicherheitslücke Zugriff auf die Core files bekommt?
Gruß
Tom
Hallo, Tom,
das ist besser als gar keine Dateirechte und hilft gegen die meisten automatisierten Angriffe, aber richtig schön ist es nicht. Die oben beschriebenen Methoden basieren ja auf Informationsmangel: das Linux-Dateisystem verweigert schlichtweg den Schreibvorgang, wenn man sich nicht via FTP einloggt. Wenn du die Daten in der wp-config.php hinterlegst, kann der Angreifer über Sicherheitslücken an die FTP-Daten drankommen und so Schreibrechte erlangen. Richtig schön ist das also nicht.
Beste Grüße,
Ernesto
Hi Ernesto,
danke für deine Rückmeldung.
Und wie schaut es mit folgender Zeile aus:
define(‚FS_METHOD‘, ‚direct‘);
Ich such einfach eine Möglichkeit möglichst wenig Angriffsfläche zu bieten, aber dennoch automatische WP Sicherheitsupdates und Plugin Updates komfortable zu gestalten ohne jedesmal die FTP Daten einzugeben. DIE perfekte Lösung wird es wohl nicht geben.
Gruß
Tom
Wenn FS_METHOD direct funktioniert, sind sichere Dateirechte nicht aktiv – damit befiehlst Du WordPress, direkt zu schreiben.
Und: du suchst einen Widerspruch in sich. Die Schreibrechte basieren auf Informationsmangel. Eben NUR durch die FTP-Daten sind Änderungen an Dateien möglich. Wenn die FTP-Daten irgendwo dauerhaft vorliegen, brichst du das Konzept.
Hallo Ernesto,
vielen Dank für die ganzen Infos.
Ich bin erst seit vorgestern bei Allinkl und versuche gerade das ganze Prozedere zu verstehen (war vorher bei Domainfactory).
Also wenn ich es richtig verstehe sollten die Besitzrechte prinzipiell beim FTP-User sein, richtig?
Ich nutze W3Total Cache und das funktioniert dann nicht weil es Schreibrechte braucht. Habe die Rechte für den cache und W3TC-Ordner auf 775 gesetzt, aber das reicht auch nicht, sie müssen scheinbar echt auf 777 stehen.
Nun frag ich mich ob das eine gute Lösung ist (ich habe immer ein ungutes Gefühl wenn ich Ordner auf 777 setze) oder ob ich sie besser auf 755 lasse und dafür dem cache un dem W3TC-Ordnern als Besitzer den PHP-User zuteile. Für Updraft und den Uploads Ordner könnte ich dann auch so vorgehen:
Statt die Dateiberechtigungen zu ändern könnte ich die Besitzrechte ändern – oder macht das überhaupt irgendeinen Unterschied?! Ich blicke da noch nicht ganz durch und wäre dir für eine Info sehr dankbar.
Liebe Grüße, Lina
Hi, Lina,
> Also wenn ich es richtig verstehe sollten die Besitzrechte prinzipiell beim FTP-User sein, richtig?
Yep.
> Ich nutze W3Total Cache und das funktioniert dann nicht weil es Schreibrechte braucht. Habe die Rechte für den cache und W3TC-Ordner auf 775 gesetzt, aber das reicht auch nicht, sie müssen scheinbar echt auf 777 stehen.
Das ist bei All Inkl so und auch nicht weiter schlimm. 777 ist nur dann gefährlich, wenn der Hoster die Webspaces nicht sauber voneinander trennt. Das tut All Inkl aber sauber.
Wenn du alle Dateien dem PHP-Nutzer zuordnest, kann halt jedes Script überallhin schreiben. Das ist weit gefährlicher als ein chmod 777.
Beste Grüße,
Ernesto,
der diese Panik vor chmod 777 immer ein bisschen lustig findet, weil chmod nur im Kontext der Hostereinstellungen wirkt – ein chmod 755 auf Domainfactory hat halt denselben Effekt wie ein chmod 777 bei All Inkl.
[…] Dateirechte: warum eigentlich? […]
[…] Wer sich noch weitergehend mit dem Thema auseinandersetzen möchte, kann das in diesem serh ausführlichen Artikel über Dateirechte tun: „Dateirechte: Warum eigentlich“ […]
Hey,
wie sieht es aus, wenn man dennoch automatische Updates machen möchte und nicht manuell. Wäre es möglich, die Dateirechte einfach kurzzeitig zurück zusetzen, das Update durchzuführen und dann wieder die Dateirechte ändern?
Gruß,
Phil
Klar geht das. Ist aber umständlich. Was hindert dich daran, einfach die FTP-Zugangsdaten einzugeben? WordPress bietet das ja von sich aus an.
Wenn du vorher die Dateirechte anpassen musst, ist das ja aber nur noch ein Update. Kein Auto-Update.
[…] des WordPress-Kerns und der installierten Plugins, automatischer Backups und korrekter Datei-/Verzeichnisrechte, gibt es einige sinnvolle Einstellungen bei der […]
Vielen Dank für den sehr guten Artikel!
Mich hat WordPress und auch dein Script beinahe zur Verzweiflung gebracht…
Laut deinem Script war alles in Ordnung. Doch ein Bilderupload war nicht möglich, für WordPress war der Upload-Ordner, trotz 775, nicht beschreibbar.
Die Lösung ist vermutlich für Techis glasklar:
Der Ordner hatte falsche Besitzrechte!
Anders als alle anderen Ordner, muss der Upload Ordner nicht nur mit 775 versehen werden, sondern auch dem PHP als Besitzer zugeordnet werden.
Die Besitzrechte (chown) Funktion ist in All-Inkl’s WebFTP direkt unter der chmod Funktion.
Vielleicht hilft dieser kleine Hinweis einige dazu nicht zu verzweifeln 🙂
Beste Grüße!
Da hättest du dir viel Aufwand erspart, indem du ganz oben die Einleitung gelesen hättest: da steht drin, dass All Inkl chmod 777 braucht, dies aber absolut ok ist, da All Inkl sauber jailed. 😉 Auf den PHP-User für den Upload-Ordner wechseln geht aber natürlich auch, selber Effekt.
[…] Bei solchen Rundum-Sicherheits-Plugins wird oft über den Sinn und Zweck gestritten, da manche Plugins eher Sicherheitslücken öffnen, anstatt sie zu schließen und dazu sehr performancehungrig sind. Die Sicherheit deiner WordPress-Website erhöhst du schon drastisch durch ein langes, kompliziertes Passwort für den Admin-Bereich und das richtige setzen von Dateirechten (mehr dazu auf https://binary-butterfly.de/artikel/wordpress-login-security-eine-stahltuer-in-der-wellblechhuette/ und https://binary-butterfly.de/artikel/dateirechte-warum-eigentlich/) […]
[…] und Nutzerrechte Entsprechend: Implementiert Nutzer und Dateirechte. Ernesto Ruge hat hierzu einen schönen Artikel. Ein weiterer Vorteil von Dateirechten, wenn richtig gemacht, ist, dass ein erfolgreicher Angreifer […]
[…] setzen. Wenn du mehr Informationen zum Thema Dateirechte haben möchtest, schau doch mal beim Binary Butterfly […]
[…] Wir empfehlen auch die übrigen Duplicator-Dateien aus dem Root-Verzeichnis vom WordPress-Projekt zu entfernen. Neben dem ZIP-Archiv mit allen Dateien von WordPress sind dies in der Regel *.sql und Logdateien. Generell sollten nicht mehr benötigte Plug-ins und Themes immer deaktiviert und gelöscht werden. Die Sicherheitslücke wurde ab der Version 1.2.42 für neu generierte Dateien geschlossen, bestehende Duplicator-Dateien im Hauptverzeichnis sollten jedoch immer nach Abschluss entfernt werden. Ein informativer Artikel warum Besitzer-Rechte von Dateien und Verzeichnissen wichtig sind und die meisten Hacks verhindern können: https://binary-butterfly.de/artikel/dateirechte-warum-eigentlich/ […]
[…] zu lösen bietet es sich an, mit ausgefeilten Dateirechten und verschiedenen Benutzern zu arbeiten. Ernesto hat das in einem ziemlich alten und Beitrag ausführlich erklärt, leider fehlt mir da aber der Tiefgang, weshalb ich die Empfehlungen an dieser Stelle noch etwas […]
Was mich wundert, dass WordPress bei mir nicht nach FTP-Daten fragt. Muss ich das irgendwo einstellen? Die Dateirechte sind alle so eingestellt, dass ich im Backend keine Plugins installieren oder updaten kann, es kommen entsprechende Fehlermeldungen, dass die Verzeichnisse nicht angelegt werden können.
WordPress fragt aber auch nicht nach FTP-Daten. So muss ich jedes Mal für ein Update kurzfristig den Besitzer der Ordner/Dateien ändern, um die Updates zu machen.
Gruß
Kai
Das liegt häufig daran, dass in der wp-config.php
> define(‚FS_METHOD‘,’direct‘);
festgeschrieben ist. Dann versucht WordPress es trotzdem, auf die Dateien zu schreiben, was zwangsweise fehlschlägt.
[…] Wer keine Möglichkeit hat, fail2ban für WordPress zu verwenden, sollte trotzdem ein Minimum an Sicherheitshinweisen befolgen: der Username sollte nicht unbedingt „admin“, „root“, „Administrator“ lauten, dass Passwort sollte mindestens 10 Zeichen inkl. Sonderzeichen & Zahlen lang sein und die Dateirechte für WordPress sollten möglichst restriktiv gesetzt sein. Für den letzten Punkt gibt es auf binary-butterfly.de eine sehr gute Anleitung: Dateirechte: warum eigentlich? […]
Hi Ernesto,
kannst du bitte mal deinen Input zur Anleitung von Hosteurope geben(Seite 8)?
https://www.hosteurope.de/fileadmin/faq/documents/Webhosting/SecurityTipps/security_tipps_wordpress.pdf
Könnte so aufgefasst werden, dass bei einzelne Dateien auch 770 gefordert wird so wie sie das hier angeben oder 🙂 Im Screenshot ist außerdem PHP Owner oder versteh ich das falsch? (oben geben sie FTP als Owner an?)
danke!
Grüße
Lars
Das sind genau die beiden User, die ich meine, FTP und PHP.
Ob man Dateien 770 oder 660 gibt ist bei einem Webspace eher egal, da kann man eh nicht von außen das Execute-Bit nutzen. Bringt einem aber auch nix, so dass du die Dateien in der Liste auch problemlos 660 setzen kannst.
Generell schlägt HostEurope dort ziemlich viele Dateien vor. Das ist eigentlich gar nicht nötig, dringend nötig sind nur uploads und cache, wenn man keine schrottigen Plugins einsetzt,
[…] Einsteiger-Artikel zum Thema habe ich bis jetzt nicht gefunden. Aber der Artikel von Ernesto "Dateirechte: Warum eigentlich?" erklärt diese Thematik sehr […]
[…] Sichere Dateirechte mit zwei Systemnutzern pro Webspace, so dass man sauber steuern kann, auf welche Dateien es nur Lese- und auf welche es Lese- und Schreibrechte gibt […]
[…] Wenn noch kein Webspace / Domain vorhanden sind, kann ich für den Start All Inkl ab dem Premium-Paket empfehlen, wenn es schneller (aber auch teurer) werden darf TimmeHosting oder Raidboxes. Ich selbst administriere auch hochgradig auf WordPress spezialisierte Server, bin aber mehr technischer Dienstleister und kein Hoster mit Hotline. Dafür kann mein Setup sichere Dateirechte. […]