WordPress-Login absichern

Tipps zur Absicherung von WordPress gibt es wie Sand am Meer. Ich habe auch noch einen. Den ultimativen. Zumindest für mich.

Nutzlose Tipps first

Kissenknicker-Tipp 1: Benutzer admin umbenennen

Das ist Unsinn. Warum? Weil in jedem WordPress-Blog, der nicht mit viel Liebe abgedichtet wurde, die Anmeldenamen der Autoren gewöhnlich im HTML-Quelltext bei deren Artikeln und Kommentaren stehen (auch wenn sie visuell nicht wahrnehmbar sind) und es nur eine Frage der Zeit ist, bis die bösen Botnets intelligenter werden und den oder die Benutzernamen einfach auslesen, anstatt bloß zu raten und den „admin“ aus alten Zeiten zu verwenden. Ist die Wiese einmal gemäht, werden sie das auch tun.

Hast du etwa mod_rewrite aktiviert und nutzt schöne URL’s? Pech gehabt: dann kann jeder auf deine Site gehen und zugucken, wie aus dem von Hand eingegebenen http://www.example.com/?author=1 durch Life-Umleitung dieses wird: http://www.example.com/author/admin – wobei „admin“ jetzt für deinen tatsächlichen Anmeldenamen steht. So kannst du dir wirklich helfen, falls du einmal deinen mühsam geänderten Anmeldenamen „admin“ vergessen hast.
Autoren-Archive führen in dieser Weise generell den Backend-Anmeldenamen in der URL. Cool.

Kissenknicker-Tipp 2: wp-admin mit der .htaccess absichern

Vergesst das benutzerfreundliche Verzeichnisschutz-Tool eures Providers. Das hilft bei WordPress nicht. Denn wenn du den Ordner /wp-admin/ per HTTP-Authentifizierung komplett absicherst, hast du zwar schon, wie überall auch versprochen, mehr Arbeit beim Anmelden durch zusätzliches Eintippen, aber die Botnet-Skripte funktionieren weiterhin. Doch nicht nur das, Ärger hast du dazu auch noch, weil nämlich unverhofft gewisse Javascript-Dinge auf der Website nicht mehr funktionieren. Warum? – Weil

1. die Datei wp-login.php das Herz der Anmeldung ist und im Hauptverzeichnis liegt, welches natürlich nicht gesperrt sein darf und
2. weil im Ordner /wp-admin/ der AJAX-Handler für das Frontend untergebracht ist und mit der vermeintlichen Sicherheit erst einmal gleich dein AJAX auf der Website nicht mehr funktioniert.
   Hast du gewusst, dass Angreifer ihre Brute-Force-Attacken auf die Datei wp-login.php ungehindert durchführen können, auch wenn der Ordner wp-admin per .htaccess geschützt ist? – Das sieht richtig gut durchdacht aus.

Es nützt insofern wenig, als Apache-Config-Guru bestimmte Ausnahmen in der .htaccess-Datei für einzelne Dateien wie die admin-ajax.php unterhalb von /wp-admin/ zu definieren. Über bloßes Klicken im Tool deines Providers ist das leider nicht mehr lösbar. – Also wird es jetzt doch kompliziert?

Kissenknicker-Tipp 3: Blogartikel (wie diesen hier) befolgen

Es sind irre viel Halbwahrheiten unterwegs. Wirklich. Und nur weil etwas funktioniert, heißt das nicht, dass du es auch so machen solltest. Es kann immer sein, dass ein unbedachter „Seiteneffekt“ (ich liebe dieses Wort) dir deine Installation richtig um die Ohren haut. Es gibt ja sogar Leute, die Atomkraftwerke bauen, sogar dann, wenn sie am Ende auf tektonischen Plattenrändern stehen – was kann da erst alles in WordPress passieren … – Gewöhnlich sagen dir die Profis: schau zuerst in der Dokumentation auf codex.wordpress.org nach, nicht in der Blogosphäre! – Das ist auch prinzipiell eine sehr gute Idee und der WordPress Codex ist eine erstklassige Ressource, selbst wenn du nicht Englisch kannst. Doch auch dort finden wir weniger Nachhaltiges:

Rename the administrative account: On a new install you can simply create a new Administrative account and delete the default admin account.

Hardening WordPress

Meine kleinen Halbwahrheiten nun noch dazu

Ich verbunkere meinen Admin-Account in dieser Weise:

1. Über die Datei .htaccess im Hauptordner meiner WordPress-Installation. Da steht drinnen:

   <Files wp-login.php>
     AuthType Digest
     AuthName "Verzeichnisschutz"
     AuthDigestProvider file
     AuthUserFile /www/web777/.htdigest
     Require user maxmuetze
   </Files>

   und in der /www/web777/.htdigest (das ist bei mir außerhalb des DOCUMENT_ROOT):

   maxmuetze:Verzeichnisschutz:2b03f99e3aee9361311cbd5967e23d98

   Erzeugt hatte ich die Datei wie folgt:

   htdigest -c /www/web777/.htdigest "Verzeichnisschutz" maxmuetze

   Wirklich nett daran ist, dass Benutzername und Passwort de facto verschlüsselt übertragen werden. Damit ist das bei mir quasi eine Art SSL-Ersatz: wer auch immer den Netzwerk-Traffic im Klartext mitlesen kann, hat gar nicht beim WordPress-Login, sondern eigentlich davor, nämlich beim Login per HTTP-Digest, um zum eigentlichen WordPress-Login zu gelangen, seine Hürde.

2. Und zusätzlich habe ich mir ein kleines Plugin geschrieben, dass nur meine eigene IP-Adresse durchlässt (da ich eine statische habe, kann ich das so machen):

   <?php
   /*
   Plugin Name: Send them home
   Plugin URI: #
   Description: Nur die statische Heimat-IP ist erlaubt. Oder ein gaaaanz bestimmtes GET-Pärchen ...
   Author: Me
   Version: 1.0
   Author URI: #
   */
   
   function sendthemhome_login_guard() {
     if ( $_SERVER['REMOTE_ADDR'] == '1.2.4.4') return;
     
     // Not at home? Remember Schrödinger's cat's name.
     if ( md5( $_GET['pass'] ) == '02388b01e4a40534a94f0b716ce9afca' ) return;
   
     // What's up?
     $info  = count($_POST) ? "\n\nPOST-Vars:\n" . print_r($_POST, 1) : '';
     $info .= count($_GET) ? "\n\nGET-Vars:\n" . print_r($_GET, 1) : '';
   
     // Mail me.
     mail( 
       'max@muetze.com', 
       'Hacking Attempt: maxmuetze.de Login', 
       'http://www.utrace.de/?query=' . $_SERVER['REMOTE_ADDR'] . $info
     );
   
     // Send them home.
     header( 'Location: http://localhost' );
     exit();
   }
   add_action('login_init', 'sendthemhome_login_guard');
   ?>

   Die 2. Zeile der Funktion habe ich nur aktiv, falls ich auch einmal von anderen Rechnern unterwegs einloggen muss, dann lässt mich nämlich auch der Aufruf http://www.example.com/wp-login.php?pass=passwort passieren.

Fazit

Die Vorteile dieser beiden eingebauten Hürden sind klar. HTTP Digest ist der Basic HTTP Authentication klar der Vorzug zu geben. Mein Provider unterstützt das. Warum sollte ich es also nicht nutzen? Denn nicht nur, dass sogar verteilte Brute-Force-Attacken jetzt kein Problem mehr sind; auch den Kauf eines SSL-Zerfifikats nur zum Absichern meiner Login-Daten spare ich mir auf diese Weise.

Sollte einmal mit der .htaccces versehentlich etwas schieflaufen, dann steht als Fallback ein zweiter Soldat da: nur meine häusliche IP-Adresse geht durch. Stimmt die nicht und es versucht aber ein Schurke dennoch, habe ich gleich eine E-Mail auf meinem Handy. So bekomme ich auch umgehend mitgeteilt, dass wahrscheinlich meine .htaccess offenbar nicht mehr funktioniert.

Das alles ist übrigens gut und schön, wenn du allein auf deiner Installation werkelst. Völlig unpraktikabel ist es, wenn mehrere Benutzer mit einer WordPress-Installation arbeiten. Da ist mir bislang nur eingefallen, das Login über ein Captcha abzusichern. Captchas sind schon unbequem genug für die meisten Leute, aber wenigstens bekannt und nicht irritierend. –

Hey, jetzt interessiert mich aber: wie macht Ihr das? Habt ihr euch ähnliche Sachen einfallen lassen, die nicht in aller Munde sind? Je individueller, desto interessanter, finde ich …