Brute-Force-Angriffe auf wp-login.php abwehren: vier Schutzschichten für WordPress

Jede öffentlich erreichbare WordPress-Website erhält automatisierte Anmeldeversuche auf wp-login.php und xmlrpc.php. Bots probieren dabei gängige Benutzernamen und Passwörter aus Datenlecks durch. Ein einzelner Versuch ist harmlos, in der Masse belasten die Anfragen den Server und treffen früher oder später ein schwaches Passwort. WordPress selbst begrenzt die Zahl der Fehlversuche nicht. Diese Anleitung zeigt vier Schutzschichten, die sich ergänzen: starke Zugangsdaten mit zweitem Faktor, eine Begrenzung der Anmeldeversuche per Plugin, das Abschalten von XML-RPC und einen vorgeschalteten Passwortschutz auf Serverebene. Alle Schritte wurden auf WordPress 7.1.2 mit Apache getestet, die Meldungen im Text stammen aus diesem Test.

Voraussetzungen

• WordPress: eine aktuelle Version, getestet mit WordPress 7.1.2 auf Deutsch.
• PHP: eine unterstützte PHP-8-Version, im Test PHP 8.4.
• Webserver: für Schritt 4 Apache mit erlaubter .htaccess, wie bei den meisten Webhosting-Paketen. Unter nginx gelten die Hinweise in Schritt 4.
• Zugang: Benutzerkonto mit der Rolle Administrator sowie FTP-, SFTP- oder SSH-Zugang, um .htaccess zu bearbeiten und sich bei einer Fehlkonfiguration wieder Zutritt zu verschaffen.
• Backup: eine aktuelle Sicherung von Datenbank und Dateien, insbesondere eine Kopie der .htaccess, bevor Sie sie ändern.
• Passwortmanager: für die neuen Passwörter und die Wiederherstellungscodes des zweiten Faktors.

Schritt 1: Konten und Passwörter prüfen

Die wirksamste Abwehr gegen Brute-Force-Angriffe ist ein Passwort, das sich nicht erraten lässt. Alle weiteren Schritte verringern nur die Zahl der Versuche. Prüfen Sie deshalb zuerst, wer sich überhaupt als Administrator anmelden kann:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Im Backend finden Sie dieselbe Liste unter „Benutzer > Alle Benutzer“ mit dem Filter „Administrator“. Entfernen Sie Konten ehemaliger Mitarbeiter oder Agenturen und stufen Sie Konten herunter, die keine Administratorrechte brauchen. Jedes Administratorkonto ist ein mögliches Ziel.

Setzen Sie für alle verbleibenden Administratoren lange, zufällige Passwörter aus dem Passwortmanager. Ein Benutzername wie admin ist nicht das eigentliche Problem, er erleichtert Bots aber die Arbeit. WordPress zeigt Benutzernamen an mehreren Stellen, etwa in Autorenarchiven. Verlassen Sie sich daher nie auf einen geheimen Benutzernamen, sondern immer auf das Passwort.

Ergänzen Sie einen zweiten Faktor. WordPress enthält keinen eingebauten zweiten Faktor. Das Plugin „Two Factor“, auf wordpress.org mit WordPress.org als Autor eingetragen, bietet unter anderem Einmalcodes per Authenticator-App. Jeder Benutzer richtet es selbst unter „Benutzer > Profil“ ein. Auch mit zweitem Faktor lohnen sich die folgenden Schritte, weil sie die Serverlast durch Bots senken.

Verifizieren: Die Liste der Administratoren enthält nur aktive, bekannte Personen, und jedes Konto hat ein Passwort aus dem Passwortmanager sowie einen eingerichteten zweiten Faktor.

Schritt 2: Anmeldeversuche begrenzen

WordPress zählt Fehlversuche nicht. Diese Aufgabe übernimmt ein Plugin. Weit verbreitet ist „Limit Login Attempts Reloaded“, laut wordpress.org auf mehr als einer Million Websites aktiv, im Test in Version 3.3.10. Installieren Sie es über „Plugins > Plugin hinzufügen“ oder per WP-CLI:

wp plugin install limit-login-attempts-reloaded --activate
wp language plugin install limit-login-attempts-reloaded de_DE

Nach der Aktivierung erscheint der Menüpunkt „Limit Login Attempts“ mit den Unterseiten „Dashboard“, „Einstellungen“, „2FA“, „Protokolle“, „Debug“ und „Hilfe“. Unter „Einstellungen“ im Bereich „Lokale App“ legen Sie die Regeln fest. Die Voreinstellungen im Quelltext der getesteten Version:

Einstellung	Vorgabe	Bedeutung
erlaubte Versuche	4	Fehlversuche pro IP-Adresse bis zur Sperre
Minuten Aussperrung	20	Dauer der ersten Sperre
Aussperrungen erhöhen die Aussperrzeit auf	4 Sperren, dann 24 Stunden	längere Sperre für hartnäckige Adressen
Stunden bis zum Zurücksetzen der Loginversuche	24	nach dieser Zeit beginnt die Zählung neu
Vertrauenswürdige IP-Adressen	REMOTE_ADDR	Quelle der Besucher-IP

Für die meisten Firmenwebsites passen die Vorgaben. Das Feld „Vertrauenswürdige IP-Adressen“ ändern Sie nur, wenn die Website hinter einem Proxy oder CDN steht. Das Plugin warnt selbst, dass andere Quellen als REMOTE_ADDR leicht gefälscht werden können. Ein Angreifer könnte dann mit jeder Anfrage eine andere Adresse vortäuschen und die Sperre umgehen.

Unter „Benachrichtigung über Aussperrung“ lässt sich eine E-Mail-Benachrichtigung einstellen. Bei einer viel angegriffenen Website führt das schnell zu vielen Mails. Der Bereich „Protokolle“ zeigt dieselben Informationen ohne Postfachflut.

Verifizieren: Melden Sie sich in einem privaten Browserfenster mehrmals mit falschem Passwort an. Im Test lautete die Meldung nach dem vierten Fehlversuch: „FEHLER: Zu viele fehlgeschlagene Anmeldeversuche. Bitte versuche es in 20 Minuten noch einmal.“ Testen Sie das nicht von der IP-Adresse, von der Sie sich anschließend selbst anmelden müssen, oder setzen Sie Ihre Büro-IP vorher auf die „Freigabeliste“.

Schritt 3: XML-RPC abschalten

Die Schnittstelle xmlrpc.php stammt aus der Zeit vor der REST-API und erlaubt unter anderem das Veröffentlichen aus externen Programmen. Sie nimmt ebenfalls Benutzername und Passwort entgegen und ist deshalb ein zweiter Weg für Anmeldeversuche. Im Test antwortete eine frische Installation auf die Methode system.listMethods mit 80 verfügbaren Methoden.

Das Plugin aus Schritt 2 zählt auch Fehlversuche über XML-RPC. Im Test kam ab der vierten falschen Anfrage über wp.getUsersBlogs dieselbe Sperrmeldung wie auf der Login-Seite. Brauchen Sie XML-RPC nicht, schalten Sie die Anmeldung darüber trotzdem ganz ab. WordPress stellt dafür den Filter xmlrpc_enabled bereit. Legen Sie eine kleine Datei als Must-Use-Plugin an, damit ein Theme-Wechsel sie nicht entfernt:

<?php
// wp-content/mu-plugins/xmlrpc-aus.php
add_filter( 'xmlrpc_enabled', '__return_false' );

Der Filter sperrt laut Code-Referenz nur Methoden, die eine Anmeldung erfordern. Die Datei xmlrpc.php bleibt erreichbar. Im Test lautete die Antwort danach mit Fehlercode 405: „Die XML-RPC-Dienste sind auf dieser Website deaktiviert.“ Die WordPress-Dokumentation nennt xmlrpc.php als häufiges Angriffsziel. Wer auch die Anfragen selbst vom Server fernhalten will, sperrt die Datei unter Apache in der .htaccess:

<Files "xmlrpc.php">
  Require all denied
</Files>

Prüfen Sie vorher, ob etwas XML-RPC nutzt. Das kann die ältere WordPress-App, ein Veröffentlichungswerkzeug oder ein Plugin wie Jetpack sein. Die Anleitung des jeweiligen Anbieters nennt, ob es XML-RPC oder die REST-API verwendet.

Verifizieren: Ein POST auf /xmlrpc.php liefert nach der .htaccess-Regel den HTTP-Status 403, nach dem Filter allein die Meldung „Die XML-RPC-Dienste sind auf dieser Website deaktiviert.“ Mit curl -s -o /dev/null -w "%{http_code}\n" -d x https://www.example.com/xmlrpc.php prüfen Sie das von außen.

Schritt 4: wp-login.php mit einem Server-Passwort schützen

Die bisherigen Schritte laufen innerhalb von WordPress. Jede Anfrage startet also PHP und die Datenbank. Ein Passwortschutz auf Serverebene hält Bots davor ab: Ohne das zusätzliche Passwort antwortet der Webserver mit HTTP 401, WordPress wird nicht geladen. Die WordPress-Dokumentation zu Brute-Force-Angriffen empfiehlt, Schutz möglichst vor PHP anzusetzen, also am Webserver, Proxy oder einer Web Application Firewall.

Legen Sie zuerst eine Passwortdatei außerhalb des Webverzeichnisses an. Viele Hoster bieten dafür im Kundenmenü einen „Verzeichnisschutz“ an. Per SSH erstellen Sie die Datei mit htpasswd, die Option -B wählt das Verfahren bcrypt:

htpasswd -c -B /pfad/ausserhalb/webroot/.htpasswd-wp chef

Sichern Sie danach die .htaccess im WordPress-Stammverzeichnis und ergänzen Sie außerhalb des Blocks # BEGIN WordPress, den WordPress selbst verwaltet:

<Files "wp-login.php">
  AuthType Basic
  AuthName "Anmeldung"
  AuthUserFile /pfad/ausserhalb/webroot/.htpasswd-wp
  Require valid-user
</Files>

Arbeiten alle Administratoren von festen IP-Adressen aus, etwa aus dem Büro, zeigt die WordPress-Dokumentation als Alternative eine Freigabe nur für diese Adressen mit Require ip im selben <Files>-Block. Das Server-Passwort ist flexibler, wenn Sie auch unterwegs arbeiten.

Schützen Sie nur wp-login.php und nicht den ganzen Ordner wp-admin. Viele Plugins und Themes rufen wp-admin/admin-ajax.php auch für Besucher auf, zum Beispiel für Formulare. Im Test blieb admin-ajax.php mit dieser Regel erreichbar, ein Aufruf von /wp-admin/ ohne Anmeldung leitete wie gewohnt auf wp-login.php weiter, wo der Browser dann nach dem Server-Passwort fragt.

Unter nginx wird die .htaccess nicht ausgewertet. Dort übernehmen die Direktiven auth_basic und auth_basic_user_file aus dem nginx-Modul ngx_http_auth_basic_module dieselbe Aufgabe in einem location-Block für wp-login.php. Diese Variante wurde nicht getestet, lassen Sie sie von Ihrem Hoster oder Server-Admin einrichten. Wer eigene Server betreibt, kann wiederholte Fehlversuche zusätzlich mit Fail2ban auf Firewall-Ebene sperren, siehe Linux-Server absichern: UFW-Firewall und Fail2ban.

Verifizieren: Ein Aufruf von /wp-login.php ohne Zugangsdaten liefert HTTP 401, mit den Server-Zugangsdaten HTTP 200. Im Test ergab curl -s -o /dev/null -w "%{http_code}" https://www.example.com/wp-login.php die Werte 401 und mit -u chef:PASSWORT den Wert 200.

Schritt 5: Wirkung beobachten und dauerhaft pflegen

Schutzmaßnahmen veralten. Neue Administratoren kommen hinzu, ein Plugin-Update setzt Einstellungen zurück, eine Agentur legt ein Konto mit schwachem Passwort an. Planen Sie deshalb eine regelmäßige Kontrolle ein: die Administratorliste aus Schritt 1, den Bereich „Protokolle“ des Plugins und einen kurzen Test der Sperren von außen.

Die Protokolle zeigen, von welchen Adressen und mit welchen Benutzernamen Angriffe kommen. Taucht dort ein echter Benutzername Ihrer Website auf, ist er bekannt. Das ist kein Grund zur Panik, aber ein Anlass, dessen Passwort und zweiten Faktor zu prüfen.

Diese Punkte gehören zur laufenden Pflege der Website, genau wie Updates, die bekannte Sicherheitslücken in Plugins schließen. Wer das nicht selbst im Kalender halten möchte, kann es abgeben: Die WordPress-Wartung von wordpressupdate.de richtet eine Firewall ein, pflegt sie und spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein.

Verifizieren: Ein Termin für die monatliche Kontrolle steht im Kalender, und die Protokolle des Plugins zeigen, dass Sperren tatsächlich greifen.

Typische Fehler

HTTP 500 nach dem Einfügen des Passwortschutzes. Im Test führte ein falscher Pfad in AuthUserFile dazu, dass wp-login.php auch mit richtigen Zugangsdaten den Status 500 lieferte. Prüfen Sie den absoluten Pfad der Passwortdatei. Der Pfad im Kundenmenü des Hosters weicht oft vom Pfad ab, den Sie per FTP sehen. Mit der gesicherten .htaccess stellen Sie den alten Zustand sofort wieder her.

Sich selbst ausgesperrt. Die Sperre des Plugins gilt pro IP-Adresse, das ganze Büro teilt sich meist eine. Warten Sie die Sperrzeit ab oder benennen Sie per FTP den Plugin-Ordner wp-content/plugins/limit-login-attempts-reloaded kurz um. WordPress deaktiviert das Plugin dann. Mit WP-CLI geht es schneller: wp plugin deactivate limit-login-attempts-reloaded.

Alle Besucher teilen sich eine IP-Adresse. Steht die Website hinter einem Proxy oder CDN, sieht WordPress in REMOTE_ADDR nur dessen Adresse. Dann sperrt ein einzelner Angreifer alle. Tragen Sie in „Vertrauenswürdige IP-Adressen“ nur den Header ein, den Ihr Proxy nachweislich setzt, und nur, wenn Anfragen ausschließlich über den Proxy kommen.

Formulare funktionieren nicht mehr. Wer den ganzen Ordner wp-admin mit einem Server-Passwort schützt, blockiert admin-ajax.php. Schützen Sie nur wp-login.php wie in Schritt 4.

Häufige Fragen

Reicht es, die Login-Adresse zu ändern?

Eine andere Login-Adresse senkt die Zahl der Bot-Anfragen, ist aber kein Schutz. Die Adresse lässt sich oft auf anderem Weg herausfinden, und XML-RPC bleibt davon unberührt. Als Ergänzung ist sie möglich, als einzige Maßnahme nicht.

Brauche ich zusätzlich ein großes Sicherheits-Plugin?

Nicht zwingend. Die vier Schritte decken Brute-Force-Angriffe ab. Umfangreiche Sicherheits-Plugins bringen weitere Funktionen, aber auch mehr Code, der gepflegt werden muss. Mehrere Plugins mit Login-Sperre gleichzeitig zu betreiben, führt leicht zu Konflikten.

Was ist mit der REST-API?

Für Zugriffe externer Dienste über die REST-API gibt es seit WordPress 5.6 Anwendungspasswörter. Sie lassen sich einzeln widerrufen, ohne das Benutzerpasswort zu ändern. Legen Sie Anwendungspasswörter nur an, wenn ein Dienst sie wirklich braucht.

Wie finde ich Fehler beim Login?

Aktivieren Sie das Debug-Log, wie in WordPress Debug-Modus aktivieren beschrieben, und prüfen Sie zusätzlich das Fehlerprotokoll des Webservers.

Testumfang

Wir haben alles in einer Testumgebung mit WordPress 7.1.2 und Apache durchgespielt. Die Sperre nach Fehlversuchen funktionierte, sowohl beim Login als auch über XML-RPC. Auffällig war, dass eine falsche Angabe bei AuthUserFile für den Basic-Auth-Schutz einen Fehler 500 auslöst.

Nginx, das Plugin „Two Factor“ und den Betrieb hinter einem CDN haben wir nicht geprüft, deshalb testen Sie in solchen Fällen bitte zuerst auf einer Kopie.

Fazit

Brute-Force-Angriffe lassen sich nicht verhindern, wohl aber wirkungslos machen. Starke Passwörter mit zweitem Faktor schützen die Konten, die Begrenzung der Anmeldeversuche und das Abschalten von XML-RPC nehmen Bots die Masse, und der Passwortschutz auf Serverebene hält sie ganz von WordPress fern. Wenn Sie Firewall und Updates dauerhaft betreuen lassen möchten, übernimmt das eine WordPress-Wartung mit Firewall-Pflege.

Weiterführende Anleitungen und Quellen

• Linux-Server absichern: UFW-Firewall und Fail2ban
• WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben
• WordPress-Core-Updates sicher einspielen
• WordPress Advanced Administration: Brute Force Attacks
• Code-Referenz: Filter xmlrpc_enabled
• Limit Login Attempts Reloaded auf wordpress.org
• Two Factor auf wordpress.org
• nginx: Modul ngx_http_auth_basic_module