Durch­dachtes Webdesign & ziel­gerichtete Online Marketing Strategien
Moderne Websites & starke SEO Optimierung
Flexible Gestaltungs­möglich­keiten & schnelle Umsetzung
Hohe Kunden­zufriedenheit & höchste Service­orientierung
bFlow ist Ihr Partner für professionelle Web & Online Marketing Projekte
Durch­dachtes Webdesign & ziel­gerichtete Online Marketing Strategien
Moderne Websites & starke SEO Optimierung
Flexible Gestaltungs­möglich­keiten & schnelle Umsetzung
Hohe Kunden­zufriedenheit & höchste Service­orientierung
bFlow ist Ihr Partner für professionelle Web & Online Marketing Projekte

Dateirechte CHMOD

Facebook
Twitter
LinkedIn

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:

  1. 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.
  2. Hoster, bei denen man die Trennung zwischen PHP- und FTP-Nutzer manuell umstellen muss; danach funktionieren sie wie die Kategorie 1)
  3. Hoster, bei denen chmod wirkungslos ist, die aber ein gesondertes Interface in ihrem Kundenbereich haben, um PHP- und FTP-Nutzer zu trennen
  4. 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.

War dieser Artikel hilfreich?
Nach oben scrollen