Webdev

Im ersten Teil meiner WordPress Security Serie ging es darum das Backend gegen Brute Force Angriffe abzusichern. Im heutigen Teil soll es darum gehen die WordPress Sicherheitslücken im Core zu sichern.

WordPress Sicherheitslücken im Core absichern

Viele werden sich nun sicherlich Fragen: „Was kann ich denn gegen Sicherheitslücken im WordPress Core machen?“. Das ist auch tatsächlich eine gar nicht so leicht zu beantwortende Frage. Der „Enduser“ von WordPress oder der reine Blog-User kann sicherlich nichts gegen Sicherheitslücken im WordPress Core anrichten. Auch wir als WordPress Profis haben da nur eingeschränkte Mittel.

Der reguläre WordPress User schaut in den Core in der Regel gar nicht rein. Er wird also möglicherweise erst durch die Medien von einer Sicherheitslücke in Kenntnis gesetzt. Wenn ein User erfolgreich angegriffen wurde, werden meist wir Profis gerufen und dann geht es in erster Linie um Schadensbegrenzung.

• Lücke finden
• Lücke schließen
• Lücke melden
• auf Update warten

Das sind für uns Profis die begrenzten Werkzeuge die wir haben. Der Core ist und bleibt heilig. Er darf auf keinen Fall angepasst werden (dafür ist das Core Team zuständig).

Nun gut, warum schreibe ich heute einen zweiten Teil über ein Thema, wo man so wenig machen kann? Wie bereits erwähnt können wir an den Sicherheitslücken im WordPress Core sehr wenig machen. Wir können aber verhindern dass die Sicherheitslücken größeren Schaden anrichten.

Security vs. Usability

Ich muss mal einen kurzen Abschnitt zur WordPress Security einwerfen. Security vs. Usability ist immer ein großes Thema. Ich bin schon in „WordPress Security Teile #1“ bei den sicheren Passwörtern auf diese Problematik eingegangen.

Je sicherer ein System ist, je schlechter ist die Usability!

Spätestens morgen werden einige Kommentare auf mich hereinprasseln, wie ich so was in die Welt setzen kann. Es gibt auch sichere benutzerfreundliche Systeme werden andere Blogger sagen. Nein wird meine Antwort sein, die gibt es nicht. Es ist immer eine individuelle Meinung. Es wird sicherlich hunderte von Menschen geben, die ein 12 Zeichen langes Passwort mit Sonderzeichen für benutzerunfreundlich halten; Und die die am lautesten schreien, werden spätestens nach dem 10 mal eintippen auf dem iPad meiner Meinung sein.

Also um es kurz zu fassen.
Wir müssen uns zwischen Sicherheit und Benutzerfreundlichkeit entscheiden oder einen guten Kompromiss finden.

WordPress Schreib- & Leserechte

Ich werde ganz häufig gefragt wie ich die Schreib- & Leserechten des Dateisystems einer WordPress Installation handhabe. Das kann so global nicht beantwortet werden und hängt sehr von dem Kunden und dessen Anforderungen an Komfort und Usability ab. Am liebsten würde ich Allen alle Schreibrechte entziehen. Geht aber leider nicht immer. Schauen und diskutieren wir die einzelnen Verzeichnisse mal durch:
Anmerkung: Ich gehe in den Beispielen davon aus, dass der Web-Server-User ein anderer ist, als der SFTP (FTPS-User).

/wp-admin/*, /wp-includes/*

Es gibt nur eine einzige Situation, wo ins wp-admin Verzeichnis geschrieben werden muss. Nämlich beim Update. Wenn der Webserver-Prozess in das Verzeichnis schreiben darf, kann ein Angreifer Dateien modifizieren oder neue anlegen. Wenn wir die WordPress Installation via FTPS oder SFTP auf den Webserver kopiert haben, dann kann man dem Ordner also eine 7-5-5 Berechtigung geben (so der FTPS/SFTP User ein anderer ist, wie der Webserver-User).

Vorteil:

Ein potentieller Angreifer kann keine Dateien im wp-admin-Ordner verändern oder neue anlegen.

Nachteil:

Das automatische Update funktioniert nicht mehr, weil eben der Web-Prozess die Dateien selber nicht überschreiben darf. Hier ist ein kurzer Klick zum Update notwendig, sowie die Eingabe des SFTP/FTPS User / Passwortes. (Sicherheit vs. Usability)

/wp-content/uploads/*, /wp-content/cache/

Der Webserver muss in diese beiden Verzeichnisse rein schreiben dürfen. Wir müssen Ihm (leider) ein Schreibrecht einräumen. Diese beiden Ordner bekommen also eine 7-7-5 Berechtigung. Nun haben wir hier einen potentiellen Angriffspunkt geschaffen. Ein Angreifer könnte in Zusammenhang mit einer Sicherheitslücke PHP-Dateien in diesen Ordner ablegen und ausführen. Wir verbieten deshalb gleichzeitig den direkten Zugriff auf die .php Dateien.

Dazu legen wir eine .htaccess Datei mit folgendem Inhalt in die betreffenden Ordner:


<Files *.php>
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Files>


Die Zeile „Allow from 127.0.0.1“ ist übrigens dafür, damit z.B. CRON-Jobs in den Ordnern vom localhost dort ausgeführt werden dürfen.

Alle anderen Ordner

Alle anderen Ordner benötigen meines Erachtens keinen Schreibzugriff. Auch der Theme-Ordner oder die Plugin-Ordner nicht! Natürlich das Update muss jetzt von Hand durchgeführt werden. Aber dafür ist es sicherer. (Security vs. Usability)

Was haben jetzt die Schreibrechte mit dem WordPress Core absichern zu tun?

Es passte gerade an diese Stelle. Es hat nicht direkt etwas mit dem WordPress Core absichern zu tun. Es verhindert aber, dass sich ein Angreifer unkontrolliert im selbigen ausbreitet.

Updates

Das wichtigste sind Updates. Sehen Sie zu, dass Sie zeitnah alle Updates installieren. Gerade solche, die als „Kritisch“ getagt sind. In der Regel ist es so, dass wenn Sicherheitslücken bekannt werden, diese im Security Team besprochen und so lange „geheim gehalten“ werden. Es wird ein fix entwickelt und mit der Veröffentlichung der Sicherheitslücke steht auch ein Update bereit.

Es währe ja Wahnsinn alle Sicherheitslücken von WordPress zu veröffentlichen, ohne vorher einen FIX anzubieten. Das wäre ja eine Einladung an alle Hacker, nach dem Motto:

Ihr braucht keine Lücken zu suchen, wir sagen Euch wo die sind!

WordFence

Durch die Installation und richtige Konfiguration von Plugins wie z.B. WordFence wird auch im WordPress Core ein großer Bereich überprüft. Das WordFence Plugin prüft die WordPress Installation gegen das WordPress Repository und meldet veränderte Dateien. So werden zumindest erfolgreiche Angreife sehr schnell erkannt und können bekämpft werden. Das Plugin prüft aber noch viel mehr, darauf gehe ich aber in den einzelnen Teilen weiter drauf ein.

Natürlich prüft WordFence auch die Version der Core-Files und meldet via Mail ob Updates zur Verfügung stehen.

So, genug für heute, im nächsten Teil geht es um die Absicherung der Themes.