Ich finde es übrigens nett, dass sich die WordPress-Entwickler so sehr um die Sicherheit von WordPress-Installationen kümmern. Sie geben jetzt ab der Version 3.7 sogar einen kostenlosen Hinweis, wenn man eine unsichere Installation hat, formulieren diesen allerdings in einer sehr skurrilen Art und Weise.
Wenn man im Dashboard unter Aktualisierungen den Text »Künftige Sicherheitsupdates werden automatisch durchgeführt« lesen kann, weiß man, dass mit den Zugriffsrechten des Webservers im Datensystem der WordPress-Intallation beliebig Dateien der WordPress-Installation manipuliert werden können. Darüber freut sich jeder Angreifer, der es über irgendeine Lücke schafft, Code mit den Rechten des Webservers auszuführen – denn was könnte schöner sein, als den Schadcode oder die Backdoor direkt in die Installation einer Software unterzubringen. Und irgendeine Lücke findet sich immer, oft schon im WordPress-Kern, noch öfter in irgendwelchen naiv (oder wirklich schlecht) programmierten Plugins oder Themes.
Wer sein WordPress auf 3.7 geupdatet hat und die Meldung liest, dass sich WordPress nun automatisch die Updates holt, sollte unbedingt und so schnell wie möglich die Zugriffsrechte für alle Dateien der Installation so setzen, dass der Webserver nur lesend darauf zugreifen kann. (Die einzige Ausnahme ist das Upload-Verzeichnis wp-content/uploads, dort muss der Webserver auch schreiben können. Hier kann und sollte man allerdings über eine .htaccess die Ausführung von PHP- und sonstigen Skriptcode unterbinden.) Alles andere macht es einem eventuellen späteren Angreifer sehr einfach. Die Angriffe werden natürlich nicht aus persönlichen Gründen vorgetragen, sondern es werden skriptgesteuert große Teile des Webs auf Schwächen durchprobiert, deshalb sage sich niemand so etwas wie »Mein kleines Blog interessiert doch eh niemanden, wer soll das also hacken«! Spätestens, wenn es für den Spamversand, für Phishing, für Sabotage, für irgendeinen Betrug, für die Verbreitung von Kinderpornografie oder andere kriminelle Aktivitäten von irgendwelchen Löchern missbraucht wurde, interessiert sich jemand für das kleine Blog, und dieser jemand ist die Staatsanwaltschaft, die gegen den Betreiber eines kleinen, uninteressanten Blogs ermittelt – oder auch mal die Anwaltskanzlei eines Rechteverwerters, wenn der Webspace für Urheberrechtsverletzungen… ähm… genutzt wird. Der Hack kann also schnell lästig und sogar teuer werden.
Insofern ist das »Sicherheitsfeature« einer automatischen WordPress-Aktualisierung ja wirklich ein Beitrag zur Erhöhung der Sicherheit. Ein Blog, in dessen Installation Zugriffsrechte so restriktiv vergeben wurden, dass dieses Feature nicht mehr funktionieren kann, ist viel sicherer vor Angriffen – und der einzige Mehraufwand, den man bei diesem Maß an Sicherheit hat, ist, dass man hin und wieder von Hand die Installation aktualisieren muss und dafür ein FTP-Passwort angeben muss, damit WordPress an die benötigten Zugriffsrechte kommt…
Dass hingegen ein vollautomatisches Aktualisieren einer Web-Anwendung die Sicherheit dieser Web-Anwendung verbessern könne, ist ein von buntem Feenstaub durchhauchtes Märchen, das man nur Dummen, Unwissenden und Tagträumern erzählen kann. Ich befürchte allerdings, von denen gibt es unter den WordPress-Nutzern eine ganze Menge. Und diese freuen sich jetzt vermutlich sogar darüber, dass sie sich mit einer unsicheren Installation ihres Blogsystems sicherer fühlen…
Gruß auch an die WordPress-Entwickler mit ihrer moppeligen Bloatware und ihren kranken Beglückungsideen!
Wie sichere »Zugriffsrechte für alle Dateien der Installation so setzen, dass der Webserver nur lesend darauf zugreifen kann.« Also chmod 444 auf alle Ordner / Dateien um Root Verzeichnis / Untervz. außer Upload-Ordner? Wenn diese »nur« Lese-Rechte haben, dann funktioniert das automatische Update nicht mehr??
Es ist schwierig, dazu ganz allgemeine Aussagen zu machen, weil natürlich jede Serverinstallation ein bisschen anders ist. (Und manche ist sogar sehr anders…)
Der Webserver wird in der Regel mit den Rechten eines technischen Useraccounts laufen (häufig so etwas wie
www-data, aber das ist nur eine Konvention), die Dateien der WordPress-Installation werden in der Regel einem echten Nutzeraccount gehören (nennen wir ihn maluser), der sie hochgeladen hat. Der echte Nutzeraccount soll natürlich Vollzugriff haben, die Benutzergruppe vonuserbenötigt in der Regel keine Rechte (außer man hat eine sehr spezielle Installation, die von mehreren Leuten mit mehreren Accounts, aber in der gleichen Benutzergruppe gepflegt werden soll) und der Rest der Welt (einschließlich des Webservers) soll nur lesen dürfen.Das heißt: Gewöhnliche Dateien bekommen
0604(oder etwas weniger paranoid0664), Verzeichnisse, die auch noch gelistet werden müssen (in einer schlechten Unix-Metapher ist das zum »Ausführen« geworden), bekommen0705(oder0775) – mit Ausnahme des Upload-Ordners, der0707(oder0777) zugewiesen bekommt. Und ja, man muss sich um Dateien und Ordner gesondert kümmern, die Pedanterie eines Computers hirnt immer ein bisschen… 😉Damit sind sämtliche Dateien der eigentlichen WordPress-Installation für den Webserver nicht schreibbar, was ein großer Zugewinn für die Sicherheit ist.
Das unterbindet allerdings auch – wie weiter oben beschrieben – die Möglichkeit, dass sich WordPress mit den Rechten des Webservers selbst aktualisieren kann. Hierfür steht aber immer noch der händische Update im Dashboard zur Verfügung, der dann allerdings die Daten eines FTP- oder SFTP-Zuganges benötigt, um die erforderlichen Rechte für den Update eines Plugins oder der ganzen Installation erlangen zu können.
Ich hoffe, dass es ein bisschen klarer geworden ist. Ansonsten hilft das große, weite Internet…