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
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.
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.
Haben denn die besagten Plugins nicht auch einen Schutz eingebaut, dass der Login mit dem benutzten Usernamen für eine gewisse Zeit gesperrt ist? Z.b. eben der klassische „admin“? Das würde solche bots definitiv ausbremsen, die ja auf der Basis von enorm vielen Versuchen agieren. Eine Sperrung für 5 Minuten alle 3 Fehlversuche macht die Erfolgschancen eines Brute Force Bots ja eigentlich schon zunichtte, wenn der „admin“ nicht gerade „1234567“ als Passwort benutzt.
Gegen den Verzeichnisschutz könnte man einwenden, dass der genauso per Brute Force geknackt werden kann wie der admin Login an sich.
Der Beitrag ist schon etwas älter und den Schutz per .htpasswd nutze ich kaum noch. Mittlerweile setze ich auf fast allen Websites die NinjaFirewall ein und nutze die integrierte „Login Protection“ für die Absicherung des Anmeldeformulars. Funktioniert sehr zuverlässig und ist etwas benutzerfreundlicher, da es auch mit Passwort-Managern funktioniert.
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?
Wenn das Verstecken der Login-URL wirkungslos ist, würde ich darauf verzichten und dann den Zugriffsschutz wie oben beschrieben einrichten.
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.
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
Vielleicht stimmt der Pfad nicht? Es muss der komplette Pfad angegeben werden, so wie ihn der Webserver verwendet. Nicht nur der Pfad ab dem Verzeichnis, das per FTP aufrufbar ist (Benutzerverzeichnis).
Daran hat es tatsächlich gelegen (hab leider eine Stelle im Pfad nicht mit kopiert). Klappt jetzt einwandfrei! Grossartige Sache.
Danke für den Tip.
Es freut mich, wenn ich helfen konnte.
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.
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.