Bei Brute Force-Attacken wird automatisiert versucht, sich in die WordPress-Administration zu hacken, indem immer wieder neue Benutzername/Passwort-Kombinationen ausprobiert werden. Hierbei spielt die Tatsache eine Rolle, dass der frühere Standardbenutzer „admin“ in vielen älteren WordPress-Installationen immer noch vorhanden und mit allen Rechten ausgestattet ist, so dass in diesem Fall nur das richtige Passwort erhackt werden muss.

Den Benutzer „admin“ sollte es aus Sicherheitsgründen daher gar nicht mehr geben. Umbenennen über die Profil-Einstellungen ist nicht vorgesehen, kann jedoch direkt in der Datenbank geändert werden (Anmeldung dann unter neuem Usernamen und altem Passwort) oder mit Hilfe eines Plugins (z.B. Better WP Security bietet das an).

Um den alten Administrator auf konventionelle Weise loszuwerden, einen neuen Administrator und einen Autoren oder Redakteur registrieren, letzterem die admin-Beiträge übergeben, und den alten „admin“ dann löschen. Derjenige der WordPress (oft) redaktionell betreut und nach „außen“ aufscheint, ist dann jemand der nur über die Rechte eines Autoren oder allenfalls Redakteurs verfügt.

Bei der Passwortstärke empfiehlt es sich auf WordPress zu hören, und Passwörter einzusetzen die als strong bewertet sind.
Die Administration über SSL mach Logindaten abhörsicher (allerdings wenn man schon SSL hat, warum auf die Administration beschränken?).

Als nicht sehr beruhigend erwies es sich allerdings, die Anzahl von Loginversuchen je IP-Adresse und innerhalb einer definierten Zeitspanne zu beschränken. Die Angriffe hörten nach dem Blocken nicht auf, sondern setzten sich (je nach Szenario) über eine neue IP-Adresse fort, oder kamen ohnedies schon über mehrere IP-Adressen gleichzeitig.

Was dem entgegenwirkte war, die Loginseite gezielt vor direkten Aufrufen schützen.

Wer mit fixer IP-Adresse unterwegs ist und sein WordPress nur über diese aktualisiert, kann die wp-login.php global sperren und den Aufruf nur durch die eigene IP-Adresse erlauben.

Hinweis: vorher eine Sicherungskopie der .htaccess-Datei machen.

in die .htaccess-Datei kommt:

<files wp-login.php>
order deny,allow
Deny from all
Allow from xxx.xxx.xx.xx
</files>

(xxx.xxx.xx.xx durch IP-Adresse oder IP-Adressbereich ersetzen)

Mehrere IP-Adressen zulassen:

<files wp-login.php>
order deny,allow
Deny from all
Allow from xxx.xxx.xx.xx
Allow from yyy.yyy.yy.yy
</files>

Nicht autorisierten IP-Adressen wird das Betreten des Login-Formulars verwehrt.

Forbidden
You don't have permission to access /wp-login.php on this server.

Die Logik der Maßnahme ist simpel: ohne Erreichbarkeit des Login-Formulars keine Brute Force Attacken mehr.

IP-Adressen-unabhängig ist hingegen die Passwortschutz-Variante (der Inhalt von .htpasswd kann auf der Site „htpasswdgenerator“ generiert werden – falls md5 nicht funktioniert sha1 und crypt testen). Die Passwort-Datei dann in ein Verzeichnis auf dem Webserver schieben – idealerweise außerhalb der öffentlichen Webbereichs.

<files wp-login.php>
AuthName "administration"
AuthType Basic
AuthUserFile /file/directory/yourweb/ordner/.htpasswd
require valid-user
</files>

Bevor der Login-Bildschirm zu sehen ist, müssen nun Username und Passwort angegeben werden. Wer nicht über die Anmeldedaten verfügt, wird abgewiesen mit

Authorization Required
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.

Hinweis: Leser die auf einzelne Seiten oder Artikel die durch ein Passwort geschützt sind Zugriff bekommen sollen, müssen über die wp-login.php. In solchen Fällen sind andere Methoden besser geeignet.

Nachtrag 21.03.2021: es hat sich mittlerweile sehr bewährt, die Loginseite an einen geheimen Ort zu verschieben. Das geht einfach mit dem Plugin WPS Hide Login. In diesem Fall einfach den Loginlink mit den Zugangsdaten speichern und ihn nirgendwo zu veröffentlichen.