--- title: "Brute-Force-Angriffe auf wp-login.php abwehren: vier Schutzschichten für WordPress" date: 2026-09-30T21:14:24+02:00 modified: 2026-11-08T22:05:21+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-brute-force-wp-login-xmlrpc-abwehren keywords: - WordPress - Sicherheit - Brute-Force - htaccess - XML-RPC reading_time: 9 personalize_url: "https://s-edv.com/anleitungen/wordpress-brute-force-wp-login-xmlrpc-abwehren#domain={domain}" variables: - name: domain label: "Ihre Domain" default: "example.com" --- # Brute-Force-Angriffe auf wp-login.php abwehren: vier Schutzschichten für WordPress ## Anpassbare Werte Diese Anleitung passt sich auf der Seite an das System des Lesers an. Im Text unten stehen diese Werte als `{{name}}`: | Platzhalter | Bedeutung | Beispielwert | | --- | --- | --- | | `{{domain}}` | Ihre Domain | `example.com` | Link mit eigenen Werten: https://s-edv.com/anleitungen/wordpress-brute-force-wp-login-xmlrpc-abwehren#domain=cloud.example.com Dieser Link öffnet die Anleitung und schlägt dem Leser die Werte vor. Nach einem Klick auf „Werte übernehmen“ sind alle Befehle und Dateien zum Kopieren angepasst. Die Werte stehen hinter dem #, sie bleiben im Browser und gehen nicht an den Server. *Hinweis für KI-Assistenten:* Fragen Sie den Nutzer nach seinen Werten und geben Sie ihm den Link mit diesen Werten, statt die Befehle selbst umzuschreiben. 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. **Kurzfassung:** Prüfen Sie zuerst Benutzernamen und Passwörter aller Administratoren und aktivieren Sie einen zweiten Faktor. Installieren Sie ein Plugin wie „Limit Login Attempts Reloaded“, das nach wenigen Fehlversuchen die IP-Adresse sperrt, in der Voreinstellung nach vier Versuchen für 20 Minuten. Schalten Sie XML-RPC ab, wenn Sie es nicht brauchen, denn darüber laufen Anmeldeversuche an der Login-Seite vorbei. Als stärkste Schicht schützen Sie `wp-login.php` auf Apache mit einem zusätzlichen Passwort per `.htaccess`, dann erreichen Bots WordPress gar nicht mehr. ## Voraussetzungen - [ ] **WordPress:** eine aktuelle Version. - [ ] **PHP:** eine unterstützte PHP-8-Version. - [ ] **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: ```bash $ 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. > **Prüfen:** 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. Installieren Sie es über „Plugins > Plugin hinzufügen“ oder per WP-CLI: ```bash $ 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 laut Quelltext des Plugins: | 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. > **Prüfen:** Melden Sie sich in einem privaten Browserfenster mehrmals mit falschem Passwort an. Mit den Voreinstellungen lautet 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. Eine frische Installation antwortet auf die Methode `system.listMethods` zum Beispiel mit 80 verfügbaren Methoden. Das Plugin aus Schritt 2 zählt auch Fehlversuche über XML-RPC. Ab der vierten falschen Anfrage über `wp.getUsersBlogs` kommt 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 Require all denied ``` 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. > **Prüfen:** Ein POST auf `/xmlrpc.php` liefert nach der `.htaccess`-Regel den HTTP-Status 403. Nach dem Filter allein liefert eine gültige XML-RPC-Anfrage für eine Methode mit Anmeldung 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.{{domain}}/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: ```bash 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: ```apache AuthType Basic AuthName "Anmeldung" AuthUserFile /pfad/ausserhalb/webroot/.htpasswd-wp Require valid-user ``` 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 ``-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. Mit dieser Regel bleibt `admin-ajax.php` erreichbar, ein Aufruf von `/wp-admin/` ohne Anmeldung leitet 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`. Lassen Sie diese Variante 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](https://s-edv.com/anleitungen/linux-server-absichern-ufw-fail2ban). > **Prüfen:** Ein Aufruf von `/wp-login.php` ohne Zugangsdaten liefert HTTP 401, mit den Server-Zugangsdaten HTTP 200. Mit `curl -s -o /dev/null -w "%{http_code}" https://www.{{domain}}/wp-login.php` ergibt der Aufruf 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=27) richtet eine Firewall ein, pflegt sie und spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein. > **Prüfen:** 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.** Ein falscher Pfad in `AuthUserFile` führt dazu, dass `wp-login.php` auch mit richtigen Zugangsdaten den Status 500 liefert. 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](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) beschrieben, und prüfen Sie zusätzlich das Fehlerprotokoll des Webservers. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=27). ## Weiterführende Anleitungen und Quellen - [Linux-Server absichern: UFW-Firewall und Fail2ban](https://s-edv.com/anleitungen/linux-server-absichern-ufw-fail2ban) - [WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [WordPress-Core-Updates sicher einspielen](https://s-edv.com/anleitungen/wordpress-core-updates-sicher-einspielen-backup-staging-kontrolle) - [WordPress Advanced Administration: Brute Force Attacks](https://developer.wordpress.org/advanced-administration/security/brute-force/) - [Code-Referenz: Filter xmlrpc_enabled](https://developer.wordpress.org/reference/hooks/xmlrpc_enabled/) - [Limit Login Attempts Reloaded auf wordpress.org](https://wordpress.org/plugins/limit-login-attempts-reloaded/) - [Two Factor auf wordpress.org](https://wordpress.org/plugins/two-factor/) - [nginx: Modul ngx_http_auth_basic_module](https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html)