Sicherheit ist kein Zustand, der zu Erreichen ist, sondern eine Einstellung.

Webworker wie wir sollten Sicherheit immer als Prozess sehen, der dauerhaft bearbeitet wird. Jede Änderung am Quellcode, jeder veröffentlichte Artikel kann eine Sicherheitslücke darstellen. Alle Maßnahmen, die dazu führen, dass ein System sicherer wird, sind daher sinnvoll. Sie sind aber nie abschließend. Den Zustand: „Jetzt ist dein Blog sicher.“ gibt es nicht. Monitoring verkürzt die Reaktionszeit bei einem Ernstfall, aber verhindert nicht das Problem. Im folgenden führe ich ein paar Maßnahmen auf, die dabei helfen ein Blog abzusichern. Solche Listen sind nie vollständig. Weiterführende Quelle habe ich am Ende zusammen getragen.

01 – WordPress-Core, Themes und Plugins aktuell halten!

Der wichtigste Punkt überhaupt ist das aktuell halten der WordPress-Installation auf allen Ebenen. Alte Versionen enthalten Sicherheitslücken, die bei Veröffentlichung der Nachfolge-Version (und der darin enthalten Fixes) bekannt gemacht werden. Somit können diese bei veralteten Blogs ausgenutzt werden. Die Nachrichtenagentur Reuters ist ein bekanntes Beispiel für so einen Hack.

02 – Sicherheitsschlüssel in der wp-config-php

Um die Passwörter einer WordPress-Installation noch besser zu schützen, sollten die Sicherheitsschlüssel alle vorhanden sein (aktuelle bei Version 3.4.1 sind es acht) und die Schlüssel sollten per angebotenen Generator erstellt worden sein:
http://codex.wordpress.org/Editing_wp-config.php#Security_Keys

03 – WP-Präfix ändern

Bei einem Angriff per SQL-Injection wird meist aus Gründen der Vereinfachung davon ausgegangen, dass die Standardwerte nicht geändert wurden. Insofern erreicht man Sicherheitsvorteil, wenn man von diesem Wert abweicht und den Datenbank-Präfix ändert. Bei der Installation erreicht man dies ganz einfach durch Änderung der entsprechenden Zeile in der wp-config.php.

Nach der Installation ist das auch sonst zu empfehlende Plugin WP Security Scan eine Möglichkeit um schnell den Präfix zu ändern. Praktischerweise enthält das Tool auch ein Backup-Werkzeug, von dem man natürlich vorher Gebrauch machen sollte!

04 – „admin“ als Administrator-Benutzername ist keine gute Idee

Früher konnte man bei der Installation den Usernamen „admin“ gar nicht ändern, daher greifen viele Angriffsskripte mit dem Usernamen „admin“ an. In vielen Fällen ist dieser Nutzer vorhanden und Administrator des Blogs. So muss „nur noch“ das Passwort geknackt zu werden, um den Blog komplett zu übernehmen. Im Idealfall ist dieser Nutzer also nicht vorhanden oder heißt anders und hat auch am besten nicht die User-ID 1.

Hat man den Usernamen des Administrators geändert, dann sollten mit dieser Kennung keine Artikel veröffentlicht werden. Im Profil kann dazu ein Name ausgewählt werden, der öffentlich angezeigt werden soll. Im Theme sollte dazu allerdings nicht der Autoren-Link genutzt werden, da so immer der Autor herausgefunden werden kann. dazu gibt es auch bereits einen Bugreport.

05 – per htaccess die wp-config.php schützen

Um zu verhindern, dass die wichtige Konfigurationsdatei wp-config.php eingesehen werden kann (z.B. bei einem PHP-Problem auf dem Server), kann man per htaccess-Datei den Zugriff darauf verhindern. Um zusätzlich zu verhindern, dass die Readme-Datei und ihre ggf. vorhandene Übersetzung eingesehen werden können (und damit die darin stehende Versionsnummer der WordPress-Installation) werden die Dateien readme.html und liesmich.html ebenfalls geschützt.

<FilesMatch "(wp-config.php|liesmich.html|readme.html)">
  order deny,allow
  deny from all
</FilesMatch>

06 – Brute Force-Attacken verhindern

Um zu verhindern, dass jemand einfach über einen längeren Zeitraum versucht den Login zu erraten, (BruteForce-Attacke), womöglich automatisiert durch einen Wörterbuchangriff, sollten die Loginversuche per Plugin beschränkt werden. Limit Login Attempts ist ein solches Plugin, das auch noch zusätzlich verhindert, dass als Feedback angezeigt wird, ob nur das Passwort oder nur der Benutzername falsch ist.

Wer das Plugin nicht nutzen möchte, kann letzteres durch folgende Zeile in der functions.php erreichen:

add_filter('login_errors',create_function('$a', "return null;"));

07 – Generator-Meta-Tag herausnehmen

Da wir dem potentiellen Hacker keine hilfreichen Infos geben möchten, verhindern wir die Ausgabe der Versionsnummer im Head der Webseite mit folgender Zeile in der functions.php:

remove_action('wp_head', 'wp_generator');

Um die Version herauszufinden gibt es noch andere Wege, siehe Punkt 5!

08 – Sicherheitsscanner

Ist das Kind in den Brunnen gefallen, hat man im Idealfall ein Backup (Punkt 09!) und ein paar Helfer auf seiner Seite. Diese Sicherheitsscanner helfen auch zu überprüfen ob ein Theme aus fragwürdiger Quelle ein Sicherheitsrisiko ist.
AntiVirus for WordPress, WP Security Scan, Secure WordPress, Exploit Scanner, Timthumb Vulnerability Scanner, Bulletproof Security und viele mehr …

WP Security Scan und andere Plugins dieser Art überprüfen auch, ob die Dateiberechtigungen auf dem Server korrekt gesetzt sind. Zuwenig Berechtigungen fallen meist schneller auf als zuviele. Und wenn die ausgenutzt werden, ist das Problem schon da. Also vorher mal testen!

Ein guter Startpunkt für den Ernstfall ist natürlich auch immer der Codex: http://codex.wordpress.org/FAQ_My_site_was_hacked

09 – Backups machen!

Egal für welchen Weg man sich entscheidet: Eine Backup-Strategie sollte immer vorhanden sein. Für die FTP-Dateien sowieso und natürlich auch für die Datenbank:

Mit WP DB Backup kann man sich regelmäßig Backups per Mail zuschicken lassen. Andere Wege können auch andere Dienste einbinden, wie zum Beispiel Dropbox

Wer viele Datenbanken auf dem Server hat, der möchte vielleicht seine Backup-Lösung zentralisieren. Das richtige Tool dazu heißt MySQL-Dumper.

10 – Gute Passwörter!

Mit guten Passwörtern steht und fällt natürlich die gesamte Sicherheit. WordPress bietet ein automatisches Tool, welches anzeigt, wie sicher ein Passwort ist. Nutzt es! Ein Passwort sollte eine Mindestlänge haben, aber muss nicht megakryptisch daher kommen …

11 – SSL-Verschlüsselung!?

In den vielen Sicherheit & WordPress-Artikeln im Netz findet man auch immer wieder den Tipp die SSL-Verschlüsselung (https) zu aktivieren. Das macht natürlich nur dann Sinn, wenn man sein SSL-Zertifikat hat. Aber selbst die ca. 60 EUR im Jahr für ein Zertifikat wird wohl kaum ein Hobby-Blogger ausgeben.

Und der Befehl alleine in der wp-config.php:

define('FORCE_SSL_LOGIN', true);

verhindert noch keinen Man-in-the-Middle-Angriff, da das Zertifikat ja nicht vorhanden ist und somit auch nicht geprüft werden kann. Prinzipiell ist aber die SSL-Verschlüsselung des Logins bzw. des gesamten Adminbereiches durchaus sinnvoll.

Manche Hoster (z. B. bei DomainFactory) bieten SSL-Proxies an, so genannte Shared SSL-Lösungen. Dabei wird die Seite einfach hinten an den Proxy gehängt, z.B. so:
https://sslsites.de/torstenlandsiedel.de/

Leider unterstützt WordPress so eine Proxy-Lösung nicht und das einzige Plugin, welches genau für diesen Zweck gedacht ist (WordPress https) scheint nicht richtig zu funktionieren. Vor allem die externen Links der Dashboard-Widgets machen Probleme, aber auch bei den Ajax-gestützten Speicher-Aktionen der Plugin-Einstellungen versagt das Plugin und wird somit untauglich für diesen Zweck.

Schade. Wenn das funktionieren würde, könnte man über die SSL-Proxies zumindest den Login-Prozess (wenn nicht das gesamte Backend) absichern.

12 – Was nicht da ist, kann auch nicht missbraucht werden …

Sollte tatsächlich ein fremder Zugang zum Blog haben, dann hilft es, wenn die Möglichkeiten des Nutzers, der geknackt wurde, nicht zu weitreichend ausfallen. Das bedeutet: Immer nur die Zugriffsrechte einräumen, die benötigt werden. Es müssen nicht alle Benutzer eines Blogs Administratoren sein …
Auch der Editor kann komplett deaktiviert werden, um zu verhindern, dass über diesen Weg Template-Dateien verändert werden können:

define('DISALLOW_FILE_EDIT',true);

Entscheidend bleibt, dass man sich weiterhin über neue Angriffsmöglichkeiten, Sicherheitslücken und best practices informiert. Ein spannender Artikel zum Thema Sicherheit von WordPress findet sich auf CodePoet.

Plugin- und Theme-Autoren sollten sich unbedingt mit dem Thema Daten-Validierung beschäftigen.

Eine umfassende Einführung in das Thema findet sich auch im Codex.

Und natürlich gibt es zahlreiche Blogs zum Thema Sicherheit, hier zwei als Beispiel:
http://blog.sucuri.net/category/wordpress
http://googleonlinesecurity.blogspot.de/

Quellen:

• http://www.wpbuch.de/2010/01/wordpress-installieren-und-sicherer-machen/
• http://playground.ebiene.de/adminbereich-in-wordpress-schuetzen/
• http://playground.ebiene.de/initiative-wordpress-sicherheit/
• http://wp.smashingmagazine.com/2010/07/01/10-useful-wordpress-security-tweaks/
• https://bueltge.de/wordpress-login-sicherheit-plugin/652/
• http://www.wp-magazin.info/wordpress-sicherer-machen/
• http://www.wp-magazin.info/wordpress-noch-sicherer-machen/
• http://www.wp-magazin.info/den-namen-des-users-admin-aendern/