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)
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.
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!
„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.
Magst Du uns (UD Media, http://www.udmedia.de) hinzufügen?
Da wir mittlerweile PHP standardmäßig via PHP-FPM ausführen, ist eine Anpassung der Standard-Wordpress-Installation seitens des Kunden nicht notwendig. Läuft somit out-of-the-box.
Viele Grüße,
Ronny
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?
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.
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
Hallo, liebes WebhostOne Team,
danke für die Rückmeldung! Dann hat der Support-Mitarbeiter damals wohl nicht alle Möglichkeiten Ihres Panels gekannt. Um so besser – mich freut es, wenn Webhoster eine Option geben. 🙂
Beste Grüße,
Ernesto Ruge
Hallo Ernesto,
ja, leider war das wohl nicht ganz klar.
Danke für das Verschieben in Kategorie 2. Der Text müsste jedoch evt. noch angepasst werden.
Viele liebe Grüsse
A.Weigert
Hallo,
anbei eine bebilderte Anleitung, wie die Trennung des FTP und PHP User machbar ist, um ein sicheres WordPress zu erhalten:
https://www.webhostone.de/faq-webpakete/wie-kann-ich-mein-wordpress-absichern.html
Ich bitte nochmals darum, den Beschreibungstext bei unserer Firma anzupassen, da dieser ja nicht stimmt, da die Trennung möglich ist.
Vielen lieben Dank
A.Weigert
[…] 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. […]
In der Liste fehlt ganz klar raidboxes.de ! Artikel ist zwar älter, aber um einen Nachtrag würde ich mich freuen. Und die Jungs mit Sicherheit auch!
Hast Du da Infos, wie es dort um die Systemnutzertrennung steht – oder soll ich anfragen?
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!
Exakt. Außerhalb von upload und ggf. cache dann 755 und 644. Siehe Urspungs-Artikel https://binary-butterfly.de/2014/07/dateirechte-warum-eigentlich/
Auch von meiner Seite aus vielen Dank für deine super Artikel.
Hätte zu All-inkl allerdings auch noch eine Frage. Dort kann man ja CHOWN auf den PHP-User oder auf den FTP-User legen. Sollte man also die Dateirechte so einstellen wie du geschrieben hast und zusätzlich die Ordner wp-content/uploads etc. CHOWN auf den PHP-User und den Rest auf den FTP-User?
Check das nicht so ganz…
Die Frage von Flo würde mich auch interessieren.
[…] Dateirechte: Wie stelle ich das bei meinem Hoster ein? […]
[…] Dateirechte, wie stelle ich das bei meinem Hoster ein: https://binary-butterfly.de/2014/11/dateirechte-wie-stelle-ich-das-bei-meinem-hoster-ein/ […]
[…] Wie man Dateirechte je nach Hoster einstellt findet Ihr in einem weiteren Artikel. […]
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
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
Support anhauen und bitten, auf einen neueren Server umzuziehen. Machen sie dann meist in einer der nächsten Nächte.
[…] 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? […]
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.
Hallo Ernesto, danke für die tolle Beschreibung. Ich bin Kunde bei All-Inkl – was bedeutet das jetzt konkret für mich? Sind meine ftp-Dateien automatisch sicher oder was muss ich unternehmen?
Mit den FTP-Daten hat das alles wenig zu tun. Nur damit, ob ein PHP-Script andere Scripte ändern kann oder eben nicht.
1und1 bietet in seinem Webhosting Paket auch einen SSH Zugang an. Den würde ich gegenüber einem FTP Zugang absolut empfehlen. SSH überträgt von Haus aus verschlüsselt, was bei FTP auf den Provider ankommt, ob er überhaupt eine Verschlüsselung anbietet. Dann muß man natürlich auch noch den passenden FTP-Client haben um überhaupt die Verschlüsselung zu nutzen. In den heutigen Zeiten wegen der Sicherheit würde ich nur noch SSH als Zugang verwenden. Und hat außerdem den Vorteil, daß man vollen Zugriff auf die Rechte auf dem Webspace hat und sie ganz beliebig mit chmod setzen kann. Einfach per SSH einloggen und wie gewohnt in einer Linux Shell arbeiten.
Wenn du die Updates dann via wp-cli installierst, kannst du das natürlich gerne machen – ist nur nichts für den normalen Nutzer.
Bei den sicheren Dateirechten braucht das FTP Login allerdings keine verschlüsselung, die Verbindung ist ja auf localhost. Da kann niemand auf dem Wege mithören, weil es keinen Weg gibt.
Super Artikel, Danke dafür!
Kannst Du zufällig sagen, ob bei Hosting-Anbietern, die cPanel für die Verwaltung der Hosting-Accounts einsetzen, sichere Dateirechte unterstützt werden?
Leider nein … ich fürchte, dass es das auch nicht geben wird, weil cPanel das nicht können dürfte. Aber ich lasse mich gerne eines besseren belehren.
Sind wir die Freaks oder sind es die Anderen?
Ich bin neu im Webhostingzirkus. Bin Techniker, nicht ganz blöd und kann mit Linux-Zugriffsrechten was anfangen. Vor 2 Monaten wurde ich privat gebeten, eine Website zu bauen. Bislang nur theoretische Vorstellungen, jetzt ein kleines muckeliges Projekt. Ja klar. WordPress. Seit dem bin ich am lernen, anfangs mit WordPress rumgespielt, treibt mich nun seit Wochen die Recherche wie man so ein WordPress halbwegs gescheit ’sicher‘ bekommt. Im Zuge dieser Recherche auch deine Seite gefunden und die Informationen als „natürlich so, wie denn sonst?“ empfunden. Nach vielen Mails, Telefonaten und Testaccounts stelle ich fest, die Realität ist gänzlich anders. Und nun wundert es mich nicht, wenn irgendwelche Youtube-Kids Videos wie „WordPress Homepage ind 2 Stunden“ zusammen klicken erstellen. Danke Prost, bis zum nächsten Hack.
Spricht man mit den Providern, dann kommt eher so: „Du musst dein WordPress und die Theme/Plugins aktuell halten, dann passiert dir schon nichts“. Ja – das ist nicht falsch. Aber IMHO etwas zu kurz gesprungen. Am besten sind die Ratschläge, für dieses und jenes zusätzliche Plugins zu installieren.
Noch mehr Code, noch mehr Fehlerquellen. Warum bitte, wenn es eigentlich brauchbare Bordwerkzeuge gibt? CHMOD!
Will wohl keiner, ist uncool.
OK, ich betreibe keinen Webserver und kann nicht einschätzen wie schwierig die Realisierung ist. Einige Provider bekommen es doch hin. Dummerweise haben die bislang DKIM nicht implementiert. Ein weiteres must-have in meinem Pflichtenheft. Oder es klemmt anderswo.
Somit geht die Suche weiter….. und wieder Frage ich mich…. bin ich der Freak oder sind es die Anderen?
Aus jetzt vielen Mails mit Hostern weiß ich: wir sind die Freaks. Und die, dessen Seiten nicht dauernd wegen Angriffen offline sind / denen nicht dauernd Kundendaten abhanden kommen.
Aber muss halt alles mega-einfach sein. Mittlerweile gehts ja z.B. bei Amazon Servern dazu über, ganze Root-Kisten unbetreut zu vermieten. Weil … naja, viel Power für billig! Und wenn dann mal Kundendaten wegkommen, ach, das passiert halt einfach. Sind die „Hacker“ schuld.
Ich hab ja mittlerweile ne recht hübsche Config auch online gestellt, in der Hoffnung, irgendwer würd dann mal Hosting für Nerds machen: https://binary-butterfly.de/artikel/das-perfekte-php-wordpress-setup/ . Bislang ohne Erfolg. Nu ja. Vielleicht muss ich / meine GmbH das irgendwann machen … *seuft
[…] Setze korrekte Dateirechte ein, um zu vermeiden, dass jemand deine PHP-Dateien ändern und Schadcode einfügen kann (das ist ein etwas größeres Thema auf Serverseite, was hier ganz gut beschrieben ist). […]
[…] innerhalb des HTTP-Dienstes läuft oder beide Dienste unter einer Gruppe (www-data) laufen (hier wird das Problem noch etwas genauer beleuchtet). Die Konfiguration sieht dann in etwa so […]