WordPress gegen Angriffe schützen / WordPress absichern

WordPress ist, wie andere Software auch, immer wieder gezielten Angriffen ausgesetzt. Grade jetzt, im April 2013, macht eine neue Angriffswelle von sich Reden. Dabei wird über ein Botnetz versucht, Zugang über das Standard Administratoren Konto, mit dem User-Namen „admin“ zu erhalten.

Dieses Konto, bzw. der Name wird bei der Installation vorgeschlagen, eingerichtet und in vielen Installationen einfach weiter verwendet – somit ist die erste Hürde für einen Angreifer schon einmal genommen – kennt er doch den Usernamen schon – in Verbindung mit einem zu einfach gewählten Passwort ist man im aktuellen Fall einer „Brute Force Attacke“ relativ schutzlos ausgeliefert.

Jeder Admin sollte versucht sein, möglichst viele Hindernisse zu konfigurieren, damit ein Angriff zeitaufwändig und somit möglicherweise „unattraktiv“ wird – und nicht einfach von Maschinen ausgeführt werden kann.

Wie man seine WordPress Installation schützen kann

1. Für die redaktionelle Arbeit kein Administratoren Konto verwenden

Wer von Anfang an unter einem Autorenkonto postet, veröffentlicht und kommentiert, der vermeidet, daß das Adminkonto nach Außen namentlich bekannt wird. Im Übrigen ist dieses Verhalten kein Novum.

Außerdem sollte man ungenutzte Accounts löschen.

Einstufung: dringend zu empfehlen

2. Das Benutzerkonto „admin“ gegen eines mit anderem Namen ersetzen

Bei bereits mit Inhalt gefüllten Instanzen würde ich im ersten Schritt eine Sicherung der Datenbank durchführen !

Im Anschluss wird im Adminbereich ein neuer Benutzer mit der Rolle „Administrator“ und einem nicht leicht zu erratenden Namen angelegt (und einem starken Passwort, siehe Tipp 3); im Anschluss ab- und mit dem neu angelegten Admin Benutzer wieder anmelden.

Ein Hinweis vor dem nächsten Schritt: Bereits vorhandene Beiträge können übernommen, bzw. einem anderen User (am besten einem Autor und keinem Admin, siehe unter Punkt 1.) zugeordnet werden. Nun löscht man den User „admin“ – bereits vorhandene Beiträge sollte man dabei übernehmen.

Alternativ sollte man schon bei der Installation (ab wp 3.0) darauf achten, den Namen des Admin Kontos zu ändern.

Einstufung: dringend zu empfehlen

3. Ein sicheres Passwort für das Backend verwenden

Gegen „Brute Force Attacken“ schützt ein halbwegs komplexes und nicht zu kurzes Passwort WordPress Tipps für sichere Passwörter

Und immer daran denken: Nimm nicht für jedes Onlinetool, jeden Account und Zugang die gleiche Kombination von Mailadresse, Benutzername und Passwort. Je mehr Variationen Du hast um so besser – ein gutes Passwortkonzept macht es auch nicht zu komplex.

Einstufung: alternativloses – absolutes Muss

4. Das Backend-Login per SSL (https://) absichern und aufrufen

Somit werden auch die Logindaten verschlüsselt übertragen. Und allen anderen Verlautbarungen zum Trotz: Auch der SSL Proxy Deines Hosters ist besser als gar kein SSL – besonders, wenn man WLAN nutzt und Skriptkiddies in der Nachbarschaft wohnen 😉

Nutzt man SSL muss man einen Eintrag in der wp-config.php ergänzen:

define(‚FORCE_SSL_ADMIN‘, true);

Einstufung: sinnvoll und wichtig, aber im Verhältnis teuer, wenn kein SSL Proxy geboten wird

5. Das wp-admin Verzeichnis mit Username / Passwort absichern

Auf einem apache Server z.B. durch Verwendung einer entsprechenden .htaccess Konfiguration und einer Passwort Datei (.htpasswd); die meisten Hoster bieten auch die Einrichtung eines Verzeichnis Passwortschutz per Assistent.

Dabei sollte ein anderes User / Passwort Paar verwendet werden, als für das Login, besonders, wenn keine verschlüsselte Übertragung erfolgt.

Anlage einer .httpasswd

Nach Anlage dieses Verzeichnisschutzes muss man sich zweimal „anmelden“: Einmal um Zugriff auf  das Verzeichnis zu erhalten und ein Weiteres mal um sich an WordPress anzumelden. Vorteil: Ein Bot kommt erstmal nicht zum WordPress Login bzw. den wp-admin-php Dateien durch.

Einstufung: dringend und wichtig (auch wenn es lästig beim Login ist), mit einem Assistenten leicht einzurichten

Update 23.04.2013

Nicht alle Plugins funktionieren mit dieser Konfiguration. Nach Aktivierung des Verzeichnisschutz versagen sie den Dienst. Lässt der Hoster kein Finetuning zu, muss man programmatisch in die Trickkiste greifen, siehe Tipp 25.

6. Keine Standardpfade verwenden

Z.B. kann man den Ordner „wordpress“ nach Entpacken und vor Installation umbenennen; die WordPress Dateien gehören sowieso nicht auf oberste Ebene des Verzeichnisbaums (sonst kann man auch Punkt 7. nicht durchführen). Um die Website trotzdem unter seiner URL zu erreichen, konfiguriert man im Zuge der Installation oder vorher über die wp-config.php auf den angepassten Pfad.

Übrigens unterscheidet WordPress in den allgemeinen Einstellungen WordPress-Adresse und Blog-Adresse – somit kann diese Änderung auch später über das Backend durchgeführt werden (Ordner umbenennen nicht vergessen).

Einstufung: sollte nicht der erste Schritt zu mehr Sicherheit sein, trotzdem sollte man nicht darauf verzichten

7. Die Datei wp-config.php verschieben

Und zwar eine Ebene höher, als die WordPress „Installation“. Betreibt man mehr als eine WordPress Instanz, benötigt man zudem eine weitere Ebene, sonst lässt sich das nur für eine Instanz durchführen (man kann verständlicherweise nicht mehrere wp-config.php in einen Ordner packen).

WordPress schaut automatisch eine Ebene höher ob die wp-config.php vorhanden ist. Im Verzeichnis sollte das Auflisten von Dateien verboten sein, die Rechte sind möglichst restriktiv einzuschränken, leg zudem eine „leere / Hello World “ index.html dazu und verbiete die Ausführung von php Skripten (Siehe Tipp 21).

Da man sich über die Domain / Subdomain nicht einfach eine Ebene höher hangeln kann, ist die wp-config.php nicht einfach herunterzuladen, selbst, wenn der Interpreter mal ausfällt.

Einstufung: etwas aufwändig aber kostenlos 

8. Den Zugriff auf die Datei wp-config einschränken

Und zwar über einen Eintrag in der .htaccess Datei (im Speicherort der wp-config.php):

# PROTECT wpconfig.php
<files wp-config.php>
Order deny,allow
deny from all
</files>

Einstufung: auf apache Webservern ein absolutes Muss

9. Keine Login Fehlermeldungen ausgeben

In der modernen Welt ist alles so schön und ausführlich – und somit erfährt der potentielle Anmelder auch ganz genau warum sein Loginversuch fehlgeschlagen ist. Das ist doch zuviel der Hilfestellung und somit sollte man die functions.php eines jeden eingesetzen Themes um folgende Zeile ergänzen:

add_filter(‚login_errors‘,create_function(‚$a‘, „return null;“));

Nun werden keine Hinweise mehr gegeben, ob Nutzername oder Passwort falsch waren.

Einstufung: wichtig und mit wenig technischem Verstand leicht umzusetzen

10. Regelmäßig Updates einspielen

Auch das ist keine wirkliche Neuigkeit – es wird immer jemand geben, der schneller ist – vielleicht bist Du das!

Einstufung: diese Medaille hat viele Seiten, aber gepatchte Versionen einzusetzen ist ein Muss, Nachteil sind u.U. Probleme mit Theme- und Plugin-Inkompatibilitäten

11. Die „Codebasis“ klein halten

Es gibt ja auch andere Gründe auf Plugins zu verzichten, aber die Sicherheit ist ein gewichtiger. Weniger Plugins bedeutet weniger potentielle Schwachstellen und bei der Auswahl von Plugins sollte man ebenfalls eine gewisse Sorgfalt walten lassen – nimm nicht jede Beta und manchmal ist ein gutes, aber eher unbekanntes Plugin die bessere Alternative.

Bist Du Dir sicher bei der Herkunft Deiner Plugins? Man muss nicht jedes Plugin direkt über das Backend installieren, lad es doch erst einmal runter und prüf es mit einem Virenscanner.

Ungenutzte Ressourcen, nicht gelöschte Fragmente und Artefakte unsauberer De-Installationsroutinen (auch in der Datenbank) sollte man löschen.

Einstufung: zeitaufwändig und zum Teil muss man schon mehr über die Ordner- und Datenbankstruktur von WordPress wissen  

12. Das Plugin „Limit Login Attempts“ einsetzen

Und damit IP-Adressen protokollieren und ggf. sperren lassen, von denen aus irregulär Loginversuche erfolgen (es sei denn man verwendet den unter Punkt 5 beschriebenen Verzeichnisschutz).

Einstufung: leicht zu erreichen und für technisch weniger versierte Nutzer eine sinnvolle Alternative

13. Den Tabellen Prefix anpassen

Der Standard Prefix für Tabellen Namen bei der Installation ist “wp_”, dieser sollte bei der Installation möglichst „kryptisch“ geändert werden, dabei gilt es zu beachten, daß Datenbanksysteme nicht alle Sonderzeichen im Tabellennamen unterstützen.

Ist die Installation bereits mit dem Prefix “wp_” erfolgt, wird es schwieriger. Schließlich müssen neben der Konfiguration alle Tabellen z.B. über phpMyAdmin oder die mysql admin Konsole umbenannt werden.

Einstufung: wichtig und im Zuge der Installation sehr leicht umzusetzen; nach der Installation sollte man bei Änderungen am Prefix genau wissen was man tut

14. Sicherheitsschlüssel in der wp-config.php eintragen

Diese dienen der Verschlüsselung von Daten in Cookies, welche beim Login übertragen und abgelegt werden. Im WordPress Deutschland Forum erfährst Du, wie das geht.

Einstufung: absolutes, unbedingtes Muss, ein wenig technisches Verständnis ist aber erforderlich

15. Den Überblick behalten

Wer sich eine Sicherheitskopie seiner WordPress Verzeichnisstruktur und Dateien anlegt, hat die Möglichkeit zu prüfen, ob Veränderungen vorgenommen wurden, die keinen gewollten Uploads, Caching Vorgängen oder manuellen Anpassungen entsprechen.

Um Verzeichnisse und Dateien zu vergleichen, gibt es eine große Menge Tools und wer Zugriff darauf hat, kann auch die Shell / Kommandozeile nutzen.

Es ist auch nicht verkehrt, ab und zu einen Virenscanner über die Ressourcen laufen zu lassen.

Einstufung: aufwändig aber sichere Alternative um Veränderungen zu erkennen

16. Das Meta Tag Generator entfernen

Dazu gibt es ein paar versionsabhängige / Theme-abhängige Möglichkeiten:

  • entferne oder modifiziere den entsprechenden Teil in der header.php Deines Themes
  • installiere ein Plugin wie z.B. Secure WordPress
  • füge der funtions.php Deines Themes folgende Zeile hinzu

remove_action(‚wp_head‘, ‚wp_generator‘);

Hintergrund ist, daß jede WordPress Version unterschiedliche Schwachstellen besitzt und wir wollen bei der Suche danach ja keine Unterstützung leisten. Es ist also von Vorteil, wenn der Generator gänzlich „unbekannt“ ist, oder zumindest die Version nicht mit ausgegeben wird (da auch Plugins Kommentare wie „BEGIN WORDPRESS PLUGIN“ ergänzen und andere Wege existieren, die Version herauszubekommen, ist die Hürde klein, aber sie ist da).

In diesem Zusammenhang sollte man auch gleich die mitgelieferte readme.html löschen – auch hier wird die Version ausgewiesen.

Einstufung: leicht zu erreichen aber keine große Hürde für versierte Angreifer 

18. Prüfe Verzeichnis- und Dateirechte

Gebe so wenig Rechte wie möglich und nur so viel wie nötig. Auf wordpress.org findest Du unter dem Stichwort „File Permissions“ ein paar Tipps zum Thema Datei- und Verzeichnisrechte für WordPress.

Einstufung: lästiges aber alternativloses Muss

19. Schalte den Theme Editor aus

Das erreichst Du mit folgender Zeile in der wp-config.php:

define(‚DISALLOW_FILE_EDIT‘, true);

Im Anschluss kann man im Backend keine php und Layoutdateien mehr verändern.

Einstufung: wer eh „Online“ nichts ändert „schaltet“ sofort „ab“, sehr zu empfehlen, wenn man mehrere Autoren auf dem System hat

20. Nutze SFTP und SSH

Der Zugang / Zugriff zu den Ressourcen sollte immer über eine gesicherte Verbindung laufen. Die meisten FTP Clients unterstützen das und ein Hoster der kein SFTP bietet sollte nicht in die engere Wahl kommen.

Einstufung: absolutes Muss

21. Die Ausführung von php Skripten in Verzeichnissen verhindern

Mit einer Ergänzung in der .htaccess Datei lässt sich verhindern, daß z.B. in den Ordnern wp-includes oder „upload“ (wo auch immer Dein upload Ordner liegt) php Skripte ausgeführt werden können:

#PROTECT [Verzeichnisname]
<Files *.php>
Order Allow, Deny
Deny from all
</Files>

Ähnlich sind wir schon bei der wp-config.php vorgegangen, nur hier wird das Ausführen aller php Dateien im Verzeichnis unterbunden. Wenn Du mutig bist, kannst Du das in weiteren Ordnern ausprobieren – möglicherweise ist aber dann z.B. Dein Template oder ein Plugin nicht mehr funktionstüchtig.

Einstufung: kann man machen und hat im falschen Ordner unerwünschte Nebenwirkungen

22. Seite Online prüfen

Google bietet mit den Webmaster Tools die Möglichkeit, die Seite auf die Verbreitung von Malware zu prüfen und immer mehr Hoster bieten Zusatzpakete für den Schutz Deiner Ressourcen an, wobei hier zusätzliche Kosten anfallen.

Außerdem kannst Du bei folgenden Diensten unter Angabe Deiner URL Online eine Prüfung durchführen:

http://sitecheck.sucuri.net/scanner/

http://unmaskparasites.com/

Es ist auch nicht verkehrt, die eigene Website regelmäßig aufzurufen, bringt ja auch mehr Besucher in die Statistik 😉

Spätestens wenn einer der bekannten Virenscanner den Besuch Deiner Seite mit seinem Internetfilter als „gefährlich“ einstuft, solltest Du Dir ein paar Gedanken machen.

Einstufung: von kostenlos bis kostenpflichtig – leicht durchzuführen

23.  deaktiviere die Windows LiveWriter und XMLRPC Schnittstelle

Wer die Schnittstellen nicht verwendet, sollte sie dicht machen. Ab Version 2.6 sind diese zwar schon deaktiviert, trotzdem würde ich in der functions.php des Themes folgende Zeilen ergänzen:

remove_action(‚wp_head‘, ‚wlwmanifest_link‘);
remove_action(‚wp_head‘, ‚rsd_link‘);

Zudem kann an die Datei xmlrpc.php im WordPress Stammverzeichnis löschen bzw. umbenennen.

Einstufung: trivial, leicht zu erreichen

24.  Registrierung neuer Nutzer deaktivieren

Wer keine neuen Nutzer „benötigt“ kann die Registrierung im Backend unterbinden.

Einstufung: trivial, leicht zu erreichen

25. zusätzliche Passwortabfrage per php

In verschiedenen Fällen ist kein Verzeichnisschutz möglich (Tipp 5.). Dann lässt sich der Aufruf der Loginseite z.B. über einen get Parameter erweitern. Nur wenn dieser angehangen ist, wird die Loginseite korrekt ausgeliefert – fehlt der Parameter, erfolgt keine Auslieferung. Die Loginseite ist dem Admin Frontend „vorgeschaltet“ und dieses ist ohne gültige Anmeldung nicht erreichbar (es erfolgt ein redirect).

Zur weiteren Verwendung kann der get Parameter in einer Session Variable gespeichert werden, welche mit dem Logout wieder „zerstört“ werden muss. Alternativ kann ein individuelles Loginformular eingesetzt werden, welches der Loginseite vorgeschaltet ist und einen post Parameter verwendet. 

Für diese Lösung wird die Datei wp-login.php so modifiziert, daß der jeweilige Parameter ausgewertet wird – fehlt dieser, oder ist er falsch gesetzt wir die Auslieferung der Seite unterbunden – oder z.B. ein redirect auf eine 404 Fehlerseite ausgelöst – das hält Bots und Spider von der Loginseite fern und lässt keine Bruteforce Attacken zu.

Bei einem WordPress Update muss die Änderung im Programmcode u. U. nachgezogen werden.

Einstufung: Alternative zum Verzeichnisschutz, auch für Menschen eine hohe Hürde, Programmierkenntnisse erforderlich

Zusammenfassung

Die Tipps lassen sich mit Ausnahmen einzeln umsetzen – dabei sollte man nicht zu sparsam sein 🙂

Sind die technischen Voraussetzungen gegeben, benötigt man für die Umsetzung aller Maßnahmen nur wenige Stunden – für die Wichtigsten sogar nur wenige Minuten.

Einige Maßnahmen müssen ggf. beim Einspielen von Updates oder der Installation von Plugins noch einmal kontrolliert werden. Das gilt natürlich auch bei einer Migration oder einem Umzug der Seite.

 

 

VN:F [1.9.22_1171]
Rating: 5.0/5 (12 votes cast)
WordPress gegen Angriffe schützen / WordPress absichern, 5.0 out of 5 based on 12 ratings