Um dem ein wenig vorzubeugen, habe ich mich mal auf die Suche nach ein paar Möglichkeiten gemacht, WordPress sicher(er) zu machen.

WordPress Exploit Scanner

Zuallererst sollte man einmal überpruefen, ob vielleicht schon ein Hacker bei der eigenen WordPress-Installation am Werk war. Dabei hilft einem das Plugin WordPress Exploit Scanner von Donncha O Caoimh. Es macht nichts anderes, als die Dateien und die Datenbank-Einträge der WordPress-Installation nach Texten zu durchsuchen, die in der Regel von Hackern und Spammern verwendet werden, wenn diese die Webseite bereits kompromittiert haben.

Findet der Exploit Scanner solche Textpassagen, kann entsprechend gehandelt werden. Gerade ältere und grosse Blogs profitieren von diesem Plugin, da eine manuelle Suche nach solchen Textpassagen praktisch unmöglich ist.

WordPress Suche deaktiveren

Frank Bültge stellt auf seiner Seite bueltge.de eine einfache Anleitung zur Verfügung, wie man die in WordPress eingebaute Suchfunktion deaktivieren kann, wenn sie nicht benötigt wird. Das “Gemeine” an der Suche von WordPress ist naemlich, dass sie auch verwendet werden kann, wenn die Suchbox gar nicht in den Templates oder im eigenen Theme eingebaut ist. Dazu muss man leidglich die WordPress-Installation mit dem Paremeter “?s=” aufrufen, bspw. http://www.wordpress-magazin.de/?s=sicherheit

Dadurch wird die Suche ausgefuührt. Eine XSS Injection (Cross Site Scripting) benötigt ein Formular-Feld, um eine Seite hacken zu können. Ein solches Formular-Feld findet sich auf der Such-Seite eines jeden out-of-the-box WordPress. Wer nicht alle seine WordPress-Installation auf dem neuesten Sstand halten kann, sollte also die Anpassung von Frank durchführen – natürlich nur wenn auch auf die Suchfunktion verzichtet wird.

Secure WordPress

Und nochmal Frank Bültge, dessen Arbeit für WordPress ich sehr schätze, mit dem Plugin Secure WordPress. Dieses Plugin wurde im Zusammenhang mit dem Entfernen der WordPress-Versionsnummer aus dem Quelltext schon einmal erwähnt. Nebenbei sorgt es aber auch für weitere Sicherheits-Features:

1. Error Informationen aus dem Login-Bereich entfernen
2. Erstellt eine virtuelle index.html im Plugin-Verzeichnis, um eventuell das Listen des Inhaltes zu verhindern.
3. Entfernt Link für Windows Live Writer
4. Entfernt Link zum Really Simple Discovery Service
5. Entfernt die Update-Info zur WordPress Version für Nicht-Admins
6. Entfernt die Update-Info zu Plugin Updates für Nicht-Admins

In diesen Zusammenhang sei auch nochmal der Beitrag aus Frank’s WordPress-Buch erwähnt, der noch weitere Vorschlaege fuer eine sichere WordPress-Installation bereithält.

Bei allem Sicherheits-Eifer sollte übrigens auch nicht vergessen werden, regelmaessig die Datenbank zu sichern.

Fazit

Ich kann mir gut vorstellen, dass viele Leser jetzt denken: Danke, der tausendste Eintrag zum Thema WordPress und Sicherheit (und auf wordpress-magazin.de sogar schon der zweite), aber wie eingangs erwähnt, kann man nicht oft genug darüber schreiben, zumal ich selbst auch ohne böse Absichten immer wieder WordPress-Blogs entdecke, die nicht aktuell sind und/ oder Sicherheitslücken aufweisen. Gerade wenn einem die eigene Website bzw. das eigene Blog am Herzen liegt, weil man sicherlich viel Arbeit hineingesteckt hat, wäre es doch schade, wenn man nicht ein paar Minuten Zeit findet und die einfachen Mittel zur Verbesserung der Sicherheit durchführt.

Ich freue mich wie immer ueber Kommentare und Meinungen zu diesem Thema und bin gespannt auf weitere Tipps und Links!

Das Plugin einfach downloaden, aktivieren und die selbsterklärenden Einstellungen vornehmen.

Noch ein Tipp: Sergej von wpSEO.de hat noch weitere hilfreiche Anleitungen wie ihr euer WordPress sicherer machen könnt.

In erster Linie schliesst das Sicherheitsupdate eine Lücke die Blogs betreffen welche die offene Benutzerregistrierung erlauben. Doch auch davon ab, ist das Update für Alle empfehlenswert.

Download auf wordpress.org

Download von WordPress Deutschland (noch nicht verfügbar)

Upgrade Anleitung

Es gibt sicherlich die Möglichkeit das Passwort durch PHPMyadmin wieder zu ändern, doch für einen unerfahrenen Benutzer kann dies schwierig sein. In jedem Fall sollte man vorher ein komplettes Backup machen.

Eine sehr einfache Möglichkeit, ist das Skript “WordPress Emergency Password Script“. Dies setzt voraus, dass ein Zugriff auf den Webspace vorhanden und der Admin-Username bekannt ist.

Anleitung:

1. Skript herrunterladen.

2. ZIP-Archiv entpacken.

3. Die Datei “emergeny.php” in das Hauptverzeichnis des Blogs hochladen. Nicht in das Pluginverzeichnis.

4. Über einen Browser www.deine-domain.de/emergency.php aufrufen.

5. Admin-Username und das neue Passwort eintragen – senden.

6. Unbedingt die Datei “emergency.php” wieder löschen!!!

7. Einloggen – glücklich sein.

Das Passwort wird noch zusätzlich an die eingetragene E-Mail Adresse vom Admin-User gesendet. Man sollte auf keinen Fall vergessen die Datei “emergency.php” wieder zu löschen. Sonst kann Jeder das Passwort ändern.

Hinweis: Ich persönliche habe das Skript mit den WordPress Versionen 2.6.1 und 2.7 (Stand: 29. August 2008) getestet. Im Zweifelsfall ein BackUp vorher via FTP und/oder PHPMyadmin runterladen.

Es wurde wohl ein Performance Problem im Backend behoben und einige Bugs für IIS-User. Eine genaue Liste gibt es hier.

Die deutsche Version steht auf noch nicht zur Verfügung, aber wie wir WordPress-Deutschland.org kennen, sollte das nicht lange dauern und ihr könnt auch dort die neue Version runterladen.

Update: Die deutsche WordPress Version ist nun auch verfügbar.

Natürlich bietet die Entwickler-Gemeinde hier hervorragende Plugins. Eines davon ist WP-DBManager von lesterchan. Ich weiß, dass ich die Seite schonmal erwähnt habe – aber die Jungs (und Mädels) da machen einfach super Plugins.

Die Vorgehensweise ist WordPress-like gewohnt einfach: WP-DBManager herunterladen und entpacken. Den entpackten Ordner in das Verzeichnis /wp-content/plugins hochladen und im Plugin-Menü aktivieren.

Man sieht dann in der Hauptnavigation einen neuen Eintrag “Database”, über den man unter dem Punkt DB Options weitere Einstellungen vornehmen muss. Bei meinem Hoster funktionerte der Schalter “Auto Detect” für den Pfad-Eintrag zur mysqldump und mysql Datei. Falls es hier Probleme geben sollte, schaut euch mal in der FAQ eures Hosters um – dort sollte ein Hinweis zu den Pfaden zu finden sein. Im Zweifelsfall kann man ja auch immer noch den Support kontaktieren.

Wenn die Einstellungen funktioneren, kann man unter Backup DB ein erstes Backup anlegen. Ihr solltet die GZip-Funktion vorher auf Yes schalten, wenn euer Hoster das unterstützt, dann werden die Backup-Dateien komprimiert und sind wesentlich kleiner. Unter Manage Backup DB wird die dann erzeugte Backup-Datei mit Name und Zeitpunkt des Backups angezeigt. Hier sieht man auch die Größe der Backup-Datei, was für das automatisierte Zuschicken per E-Mail eine wichtige Information ist.

Wieder zurück bei DB Options kann die Einstellung für ein automatisiertes Datenbank-Backup vorgenommen werden.

Automatic Scheduling

Man kann sich theoretisch jede Minute ein Backup erstellen lassen. Allerdings würde das nicht viel Sinn ergeben. Ich habe mich einfach an meiner Posting-Frequenz orientiert und lasse mir derzeit nur alle zwei Wochen ein Backup an eine E-Mail-Adresse schicken. Ihr solltet vorher überprüfen, wie groß die Backup-Dateien sind (findet man unter Manage Backup DB heraus).

Falls die Dateien auf eurem Webspace abgespeichert werden sollen, müsst ihr einfach die E-Mail-Adresse weglassen.

Etwas weiter unten kann man auch einstellen, dass in regelmäßigen Abständen eine Optimierung der Datenbank durchgeführt werden soll. Dies ist genau wie in Backup sehr sinnvoll. Ich lasse meine Datenbank derzeit einmal im Monat optimieren – die Häufigkeit hängt wiederum davon ab, wie stark euer Blog frequentiert ist. Bei der Optimierung werden die Overheads, die beim ständigen Lesen und Schreiben in der Datenbank entstehen gelöscht. Im Grunde ist das so ähnlich wie die Defragmentierung einer Festplatte.

Allerdings ist dieser Eintrag auch ein gefundenes Fressen für Hacker-Angriffe. Es gibt ja viele Seiten, die sich mit Sicherheitslücken in verschiedenen Applikationen beschäftigen. So findet man auf diesen Seiten auch den Exploit, also die Beschreibung der Sicherheitslücke und Versionen der Software, innerhalb der die Lücken angewendet werden können. Jemand, der sich solche Lücken zu Nutze machen will, muss also lediglich nach der Versionsnummer im Quelltext suchen und kann so sehr schnell entscheiden, ob sich ein Angriff lohnt oder nicht.

Was kann man dagegen tun? Im Grunde ist es ganz einfach: Selbstverständlich sollte man WordPress immer aktuell halten. Das heisst, sobald ein Update verfügbar ist, sollte man es schnellstmöglich auch einspielen. Anleitungen dazu finden sich natürlich auch hier unter “Upgrade“.

Um zumindest die Möglichkeit zu unterbinden, im Quelltext nach der Versionsnummer zu suchen, kann man ein Plugin verwenden, welches dafür sorgt, dass der Eintrag

<meta name="generator" content="Wordpress 2.x">

nicht mehr ausgegeben wird. Dazu erstellt man sich einfach ein kleines Plugin:

<?php
/*
Plugin Name: No more generator meta-Tag
Plugin URI: http://blog.ftwr.co.uk/archives/2007/10/06/improving-
the-wordpress-generator/
Description: Hides the meta-Tag generator in all templates for
security reasons Version: 1.0
Author: Peter Westwood
Author URI: http://blog.ftwr.co.uk/archives/2007/10/06/improving-
the-wordpress-generator/

$Revision$
*/

function i_want_no_generators() 
{ 
    return ''; 
} 
add_filter('the_generator','i_want_no_generators'); 
?>

Ich habe das Plugin bzw. den Quelltext von Peter Westwood kopiert. Der obige Text muss einfach in eine Text-Datei gespeichert werden. Der Name der Datei spielt keine Rolle, sinnvoll wäre aber so etwas wie “no-meta-generator-tag.php”. Wichtig ist die Endung .php dabei. Diese Datei dann einfach in den Ordner /wp-content/plugins laden und unter dem Reiter “Plugins” aktivieren. Ab sofort wird dann die Versionsnummer bzw. der meta-Eintrag nicht mehr im Quelltext ausgegeben. Dies gilt übrigens auch für alle bereits geschrieben Beiträge und Seiten, sofern sie beim Besuch der Seite dynamisch aus der Datenbank geladen werden und nicht durch ein Plugin statisch geschriebene HTML-Dateien sind.

In der aktuellen WordPress Version 2.6 funktioniert dieses Skript übrigens immer noch.

Stefan merkte in den Kommentaren an, dass der Name des admin-Users aus Sicherheitsgründen geändert werden sollte. Dies ist natürlich richtig und lässt sich offensichtlich auf zwei unterschiedliche Arten umsetzen:

Der direkte Eingriff in die Datenbank. Dazu muss man per PHPMyadmin in der Datenbank des WordPress Blogs zur Tabelle der User browsen und dort in “user_login” den Namen des admin-Users ändern. (Hier eine Anleitung in Englisch)

Die zweite Möglichkeit ist hier beschrieben. Dort geht es darum einfach den admin-User zu löschen und sich einen neuen admin-User unter einem beliebigen Namen zu erstellen. Für unerfahrene Benutzer die sich mit Mysql nicht so auskennen sicherlich die bessere Lösung.

Auf alle Fälle gilt wie immer: Vorher ein Backup machen!

Danke an Stefan und Ute für diese Hinweise.