Limit Login Attempts und Login LockDown: kein effektiver Schutz

In einigen WordPress-Blogs wird immer noch der Einsatz von Limit Login Attempts (Reloaded) oder Login LockDown empfohlen, wenn es darum geht, Brute-Force-Attacken – also das massenhafte Ausprobieren von Zugangsdaten – abzuwehren. Ich rate vom Einsatz solcher Plugins ab und empfehle eine sehr viel effektivere Maßnahme.

Das WordPress-Anmeldeformular wp-login.php ist eines der beliebtesten Angriffsziele bei WordPress-Websites. Leider benutzen immer noch sehr viele WordPress-Benutzer/innen ein zu einfaches Passwort für ihren Zugang zum WordPress-Backend. Das macht es Hackern leicht, sich durch das Erraten des Passworts Zugang zum Backend zu verschaffen und im schlimmsten Fall die Website zu übernehmen.

Was kann man also tun, um das Anmeldeformular sicher zu machen?

Sichere Passwörter verwenden

Das A und O ist ein sicheres Passwort. Was ein sicheres Passwort ist, habe ich vor einigen Jahren in meinem Beitrag Sichere Passwörter – nicht nur in WordPress thematisiert.

Leider ist das noch nicht ausreichend. Bei einer Website mit nur einem Benutzerkonto mag man mit einem sicheren Passwort für das Admin-Konto auf der sicheren Seite sein aber was ist mit Websites, die viele Benutzer/innen haben? Hier kann man leider nicht sicher sein, dass alle ein sicheres Passwort verwenden, da sie für Admins natürlich nicht einsehbar sind.

Limit Login Attempts (Reloaded) und Login LockDown bieten keinen effektiven Schutz mehr

Vor einigen Jahren war man gut beraten, wenn man sein Anmeldeformular mit einem der oben genannten Plugins absicherte. Die Funktionsweise beider Plugins ist nahezu identisch: Nach einer definierten Anzahl von fehlerhaften Login-Versuchen von einer bestimmten IP-Adresse wurde selbige für eine bestimmte Zeit gesperrt. Das funktionierte lange Zeit gut, ist heute aber oftmals wirkungslos. Heute laufen Brute-Force-Attacken zum Großteil über Botnetze (Zusammenschluss tausender kompromitierter PCs, Server oder Webanwendungen) und jeder Versuch, ein Passwort zu erraten, wird von einer anderen IP-Adresse gesendet. Und hier liegt das Problem: die besagten Plugins können solche Angriffe nicht erkennen, da sie nur vergleichen, wie viele Versuche von einer bestimmten IP-Adresse durchgeführt werden.

Zugriffsschutz über HTTP Authentifizierung als Alternative

WordPress-Login mit HTTP Authentifizierung im Browser Safari

Eine effektive Methode, Brute-Force-Attacken auf das WordPress-Anmeldeformular abzuwehren, bietet ein zusätzlicher Passwortschutz für die Datei wp-login.php. Die HTTP-Authentifizierung sollte von jedem Webserver unterstützt werden und wird bei Apache Webservern über zwei kurze Einträge in den Dateien .htaccess und .htpasswd realisiert.

Hierfür erstellt man sich zunächst eine sichere Benutzername/Passwort-Kombination und lässt das Passwort mit einem htpasswd-Generator verschlüsseln. Das Ergebnis trägt man in eine Datei .htpasswd ein, die man im Rootverzeichnis der WordPress-Installation ablegt. Nun muss noch die bereits vorhandene Datei .htaccess erweitert werden:

# Auth protect wp-login.php
<Files wp-login.php>
  AuthName "Passwortgeschützter Bereich"
  AuthType Basic
  AuthUserFile /pfad/zu/meinem/wordpress/.htpasswd
  Require valid-user
</Files>

Bitte den Pfad zur WordPress-Installation anpassen. Der Pfad ist üblicherweise im Konfigurationsbereich eures Webhosters ablesbar. Falls nicht, hilft diese kleine PHP-Datei (Nach Benutzung wieder löschen!).

Zusätzlich empfiehlt es sich, noch das nachfolgende Snippet in der Datei .htaccess einzufügen, um die 3 wichtigsten Dateien im WordPress-Root zu schützen.

# Deny access to important files - bis Apache 2.3
<FilesMatch "(\.htaccess|\.htpasswd|wp-config\.php)">
  order deny,allow
  deny from all
</FilesMatch>

# Deny access to important files - ab Apache 2.4
<FilesMatch "(\.htaccess|\.htpasswd|wp-config\.php)">
  Require all denied
</FilesMatch>

Das war es schon. Ab jetzt kann die Datei wp-login.php nur noch aufgerufen werden, wenn der Zugriffsschutz erfolgreich aufgehoben wurde. Ein nicht zu verachtender Nebeneffekt ist übrigens, dass bei massiven Brute-Force-Attacken somit auch die Serverlast deutlich reduziert wird und WordPress ohne Geschwindigkeitseinbußen weiter läuft.

Wer noch tiefer in das Thema einsteigen will und z.B. wissen möchte, wie der Zugriffschutz für nginx oder Lighttpd einzurichten ist, findet im Beitrag .htaccess Schutz – WordPress absichern Teil4 von Mike Kuketz hilfreiche Tipps. Die anderen Beiträge der Serie sind übrigens auch sehr lesenswert.

Noch ein Tipp zum Schluss: Idealerweise werden Passwörter nur über HTTPS – also eine verschlüsselte Verbindung – übertragen. Einen Überblick zur Einrichtung von HTTPS in WordPress gebe ich im Beitrag WordPress Website auf HTTPS umstellen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit * markiert.

Bitte verwende Pastie, Pastebin oder Gist, um größere Code-Schnipsel in deinem Kommentar zu veröffentlichen.

*

9 Kommentare

  1. Hallo.

    Ich habe bei meiner Webseite das Backend mit dem Plugin „iThemes Security“ versteckt. Leider verzeichne ich dennoch Mehrfach-Anmeldeversuche von anderen IPs.

    Statt meiner Anmeldeseite http://webseite.com/wp-login.php heißt sie bspw. http://webseite.com/logmein. Das einfache Umbenennen von wp-login.php in logmein scheint nicht zu funktionieren bzw. zumindest wird die Passwortabfrage der HTTP-Authentifizierung nicht ausgeführt.

    Inwieweit müsste man .htaccess anpassen, damit es funktioniert?

  2. Den 500er Fehler hatte ich auch. Habe mir fast den Wolf gesucht, bis ich den einfachen Editor verlassen habe und die .htaccess in bracket kopiert habe. Anführungszeichen angepasst. Schon funktioniert es. Der Fehler lag darin, dass beim Editor die Anführungszeichen unten/oben gesetzt wurden. Diese müssen aber oben/oben stehen. Geändert, hochgeladen, funktioniert.

  3. An sich ja ein richtig gute Sache. Resultiert aber leider in einem „500 Internal Server Error“ nachdem man Nutzername und PW im Browser eingegeben hat.

    Was könnte ich falsch gemacht haben???

    Beste Grüße

  4. Der Schutz über .htaccess funktioniert aber leider nicht bzw. ist nicht möglich, wenn man einen Mitgliederbereich bspw. mit DigiMember hat. Dann kann man die wp-config.php auf diesem Weg nicht schützen, weil man dann auch keinen Zugriff auf den Mitgliederbereich bekommt bzw. den Mitgliedern geben kann. Bzw. man müsste dann laufend sehr aufwändig die .htpasswd erweitern.

    1. Ja, bei einer Website mit vielen Benutzern und Benutzerinnen ist so ein Zugriffsschutz unter Umständen hinderlich. Hat man nur eine überschaubare Anzahl von Benutzer/innen und kennt alle „persönlich“, kann man ja allen das gleiche Passwort für die HTTP Authentifizierung geben. Bei Websites, für die sich Benutzer/innen selbst registrieren können, ist das natürlich schwieriger. Unmöglich ist es auch da nicht.