Dateirechte: wie stelle ich das bei meinem Hoster ein?

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)

hostNET

Sichere Standardkonfiguration, chmod funktioniert wie erwartet.

Website: https://www.hostnet.de/
Quelle: Support.

JP Berlin

Sichere Standardkonfiguration, chmod funktioniert wie erwartet.

Website: https://www.jpberlin.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)

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!

Achtung! All Inkl hat sich leider dazu entschlossen, bei neuen Webspaces keinen zweiten Systemuser mehr anzubieten, so dass keine sicheren Dateirechte mehr möglich sind.

Website: http://all-inkl.com/
Quelle: Support, eigene Tests.

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.

WebGo

Mit der Nutzung der zusätzlichen FTP-Nutzer erhält man auch einen zusätzlichen Systemnutzer, mit dem dann sichere Dateirechte möglich sind. Die zusätzlichen FTP-Nutzer gibt es ab dem Tarif Webhosting Profi.

Website: https://www.webgo.de/
Quelle: Support

(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

1und1

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und korrekte Dateirechte nicht realisierbar.

Website: http://www.1und1.de/
Quelle: Nutzererfahrung. Support behauptet, der Webspace würde Dateirechte per default nutzbar haben, was aber nicht zu stimmen scheint.

1blu

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere Dateirechte nicht realisierbar.

Website: https://www.1blu.de/
Quelle: Support.

5hosting

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere Dateirechte nicht realisierbar.

Website: http://www.5hosting.com/
Quelle: Support.

Alfahosting

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere Dateirechte nicht realisierbar.

Website: http://alfahosting.de/
Quelle: Facebook Support

checkdomain

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere 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 sichere Dateirechte nicht realisierbar.

Website: http://df.eu/
Quelle: Support.

easyname

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere Dateirechte nicht realisierbar.

Website: http://www.easyname.com/
Quelle: Support.

goneo

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere Dateirechte nicht realisierbar.

Website: https://www.goneo.de/
Quelle: Support.

Hetzner

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere Dateirechte nicht realisierbar.

Website: http://www.hetzner.de/
Quelle: Support.

Hostpoint

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere 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 sichere Dateirechte nicht realisierbar.

Website: https://www.lima-city.de/
Quelle: Support.

Manitu

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere Dateirechte nicht realisierbar.

Website: https://www.manitu.de/
Quelle: Produktbeschreibung.

TimmeHosting

Keine Trennung von PHP- und FTP-Nutzer möglich, daher chmod wirkungslos und sichere Dateirechte nicht realisierbar.

Website: https://timmehosting.de/
Quelle: Support.

26 Antworten zu “Dateirechte: wie stelle ich das bei meinem Hoster ein?”

  1. Danke für deine Arbeit und den hilfreichen Artikel! Werde demnächst meine eigene Seite auf WP umstellen und beschäftige mich gerade mit Sicherheit. Da hilft deine Webseite auch sehr gut weiter!

  2. „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.“

    Und was gilt, wenn man diesen doch benutzt hat? 🙂 Vielen Dank für die informative Seite und auch die häufige Hilfe auf FB.

    • Gerne. Aber: was bedeutet „via PHP-FPM ausführen“? Das heißt, dass der FTP- gleich der PHP-Systemnutzer ist? Wie ist die Konfiguration genau? Also nutzt ihr die PHP-FPM Pools? Aus „Läuft somit out-of-the-box“ interpretiere ich mal, dass dann keine Dateirechte mit Trennung von PHP- und FTP-Systemuser möglich sind?

  3. Hey Ernesto,
    nachdem ich gerade erst in einem anderen Beitrag von dir etwas über die Vergabe von Dateirechten gelernt habe, freut es mich, in diesem Artikel zu erfahren, wie es bei den verschiedenen Webhostern aussieht. Ich bin bei Webhostone und somit keine Dateirechtevergabe von mir einstellbar. Nun überlege ich, ob ich zu einem anderen Hoster wechsle. Vorher werde ich mal bei Webhostone nachfragen, was sie dazu meinen. Bisher war ich eigentlich sehr zufrieden mit Webhostone.
    Ich danke dir sehr, für deine hilfreichen Infos.

  4. Hallo,

    vielen Dank für Ihre Pionierarbeit und das Aufzeigen von Schwachstellen.
    Auch bei uns ist eine Trennung des FTP und PHP Nutzers möglich.

    Die Installation erfolgt manuell oder per 1Click in ein Verzeichnis. Im Adminpanel wird für diesen Ordner einen Zusatz-FTP User eingerichtet und diesen Ordner ggf. als Zielordner für die entsprechende Domain eingerichtet.
    Für die Ordner uploads und cache müssen ggf. die Rechte noch manuell geändert werden (CHMOD), damit PHP da hineinschreiben kann.
    Fertig!

    Eine bebilderte Anleitung werden wir auch in den nächsten Tagen in unserer FAQ veröffentlichen.
    Gerne stellen wir auch einen Testaccount zur Verfügung.

    Ich möchte daher bitten, uns aus der Kategorie 4 zu entfernen und in Kategorie 2 (meiner Meinung nach) zu verlegen.

    Mit freundlichen Grüssen
    A.Weigert

  5. […] Um das oben angesprochene Problem eine Kontaminierung durch Sicherheitslücken in Plugins o.Ä. zu minimieren, solltest du deinen Server so einstellen, dass PHP er keine Schreibrechte hat. So kannst du die meisten Angriffe eindämmen. Denn selbst wenn eine Sicherheitslücke einem Angreifer erlaubt eine PHP-Shell o.Ä. auf deinen Server zu laden, wird es nicht gehen wenn die Dateirechte entsprechend gesetzt sind. Hierzu der verweis auf einen super Artikel zum Theme Schreibrechte. […]

  6. Super Artikel, leider werde ich nicht schlauer draus ;-).

    Ich bin bei All-inkl.com und muss die Ordner wp-content/uploads bzw. wp-content/cache auf 777 einstellen? Dateien auf 666?

    Danke an dieser Stelle für die erhellenden Artikel!

  7. Hallo Ernesto,
    der Hoster Ehrenwert IT kann aus der Liste unter Punkt 2 gestrichen werden. Ich habe jetzt mehrere Emails mit denen ausgetauscht, die wollen oder können es nicht hinbekommen. Ich habe sogar auf die Seite hier verwiesen, ich habe sogar versucht denen das Konzept von getrennten FTP und PHP User zu erklären, es nutzt nix. Die verraten mir nicht, was ich einstellen müsste im Plesk, damit ich sichere Dateirechte habe. Augenverdreh. WordPress mit sicheren Dateirchten geht dort nicht.
    Aber danke für die Liste, gibt ja noch einige andere Hoster zur Auswahl.
    Gruß, Anabell

  8. Moin Ernesto,
    Ich hab da mal eine kleine Detailfrage zu All-Inkl.

    Du schreibst „Aber Achtung: wenn man via .htaccess die CGI-Version von PHP lädt, ist chmod wirkungslos!“. OK, so weit komme ich mit und kapiere auch warum das so ist.

    Jetzt habe ich das Phänomen dass ich auf Shared-Hosting 1 (Live-Seite) PHP 7.0 im KAS als Apache-Modul konfigurieren kann. Fein. Wollte das mit Dateirechten am WP aber zuerst am Testsystem versuchen…
    Auf Shared-Hosting 2 habe ich neben zwei statischen Uralt-Seiten besagtes Testsystem laufen. Dort kann ich im KAS aber maximal PHP 5.5 als Apache-Modul laufen lassen. PHP 7.0 bzw. bis hoch zu 7.2 lassen sich nur als CGI konfigurieren.

    Habe ich hier jetzt auch das von Dir angesprochene Problem? Ich meine, ich lade die CGI-Version ja nicht über die .htaccess, zumindest über keine auf die ich Zugriff habe.

    Grüße Lando

  9. […] 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: wie stelle ich das bei meinem Hoster ein? […]

  10. Ich fürchte, dass hier eine extrem wichtige Komponente gar nicht berücksichtigt wurde: wenn PHP- und FTP-User getrennt sind, unter welchem Benutzer genau wird PHP dann ausgeführt?
    Weiter oben wird bei einem Hoster „open_basedir“ als Sicherheitsmaßnahme erwähnt. Das ist ein gewaltiger Irrglaube, dass das (alleine) für Sicherheit sorgt. Wird PHP als Apache-Modul ausgeführt, dann läuft das unter den Rechten des Webservers („www-data“ o.ä., je nach Distribution/Konfiguration). Dieser Benutzer hat zwangsweise Zugriff auf alle Webspace-Verzeichnisse (also per se *mehr* Zugriff als die jeweiligen FTP-Benutzer, die auf ihre Home-Verzeichnisse begrenzt sind). open_basedir sorgt zwar prinzipiell dafür, dass ein PHP-Benutzer nicht in „fremde“ Verzeichnisse darf, es gab aber unzählige Sicherheitslücken in PHP um das zu umgehen (und je nachdem was PHP noch so darf gibt es noch ganz andere Gefahren).
    Im Shared Hosting mod_php sicher zu betreiben ist fast unmöglich (sofern der Hoster nicht sowas wie mpm_itk oder CloudLinux einsetzt, sollte man da dringend die Finger von lassen).

    Fazit: es ist wesentlich gefährlicher, PHP für mehrere User unter den selben Rechten laufen zu lassen (mod_php) als PHP- und FTP-Benutzer zu trennen.

    Last but not least vermeidet man mit der Trennung der Benutzer lediglich einzelne Symptome (z.B. Modifikation von Dateien), die Gefahren einer nicht gesicherten Installation werden dadurch aber nicht behoben! (Information Leakage ist dennoch möglich, und das kann wesentlich „schlimmer“ sein als wenn Malware ins WordPress eingeschleust wird).

    • Hallo, Klaus,

      wenn PHP- und FTP-User getrennt sind, dann läuft PHP unter dem PHP-User. Alles andere würde ja keinen Sinn ergeben.

      Du hast Recht, dass open_basedir nur der erste Schritt ist. Der saubere Weg wäre eine echte Jail. Aber auch dort funktioniert das Kontept einwandfrei.

      Zu mod_php: das mag man ja auch nicht so wirklich nutzen, das beschreibst du ja richtig. Aber das hat doch gar nichts mit einer Trennung von Systemnutzern in Lese- und Schreibrechte zu tun. Wenn pro Website zwei Systemnutzer existieren, einer für PHP und einer für Schreibzugriffe (SSH, FTP, you name it), dann funktioniert das Konzept. Sinnvollerweise mit php-fpm, weil man da ohne Hazzle PHP-Prozesse den jeweiligen Systemnutzern zuordnen kann.

      Wo ich aber deutlich widersprechen möchte ist Dein letzter Absatz: wenn Du mit eine Remote Shell platzieren kannst, dann hast Du den Webspace in Deiner Hand. Mit der Remote Shell kann man dann alles andere machen, auch ein Information Leakage auslösen. Dateien hochladen bedeutet im Kontext von PHP Code hochladen, und Code hochladen bedeutet Remote Code Execution. Das ist das schlimmste, was Dir überhaupt passieren kann.

      Natürlich muss es trotzdem ein Anliegen sein, Sicherheitslücken grundlegend zu schließen, aber sichere Dateirechte sind ein wirkungsvoller zweiter Schutz gegen eine besonders häufige Form der RCE-Lücke in PHP-Anwendungen, wenn der erste Schutz – die PHP-Software selbst – versagt. Und wenn ich mir die Sicherheitslücken der letzten Jahre so anschaue, dann versagt die erste Hürde ziemlich häufig, was man dann auch an den realen Infektionen da draußen sehen kann.

      • Wenn wirklich zwei Systembenutzer pro Webspace existieren, dann geht das auf – aber nicht mit mod_php (was leider noch viel zu oft verwendet wird).
        Und mein letzter Absatz war dann vielleicht falsch formuliert: man darf sich halt nicht in Sicherheit wiegen, nur weil keine Modifikation der Dateien mehr möglich ist. Ein Datenleck ist ein Ergebnis, ein RCE aber nur *ein* möglicher Weg dorthin.

Schreibe einen Kommentar

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