WordPress Brute-Force-Schutz: Was ein Plugin stoppen kann

Ein Sicherheits-Plugin bremst Passwortraten zuverlässig aus. Gegen eine Flut von Anfragen ist es machtlos. WordPress Brute-Force-Schutz und DDoS-Schutz sind zwei verschiedene Probleme, und jedes wird auf einer anderen Ebene gelöst: bei Ihren Benutzerkonten, in WordPress selbst, auf dem Webserver und am Netzwerkrand davor.

Dieser Artikel geht die Angriffe durch, die Sie mit hoher Wahrscheinlichkeit in Ihren Logs finden: fehlgeschlagene Logins an der wp-login.php, gehäufte Anfragen an xmlrpc.php, Benutzer-Enumeration über die REST-API und plötzliche Traffic-Spitzen. Zu jedem Angriff erfahren Sie, welche Ebene ihn tatsächlich stoppen kann. Und zu jeder Maßnahme einen Satz dazu, was sie nicht leistet.

WordPress Brute-Force-Schutz funktioniert in Schichten

Anfragen aus dem Internet durchlaufen mehrere Schichten, bevor sie Ihre Daten erreichen. Je weiter außen eine Anfrage gestoppt wird, desto weniger kostet sie Sie. Was ein CDN abweist, berührt Ihren Server nie. Was erst ein WordPress-Plugin abweist, hat bereits eine Netzwerkverbindung, einen Webserver-Prozess und einen PHP-Worker belegt.

Grob zugeordnet:

Login-Drosselung: Passwortraten an der wp-login.php ausbremsen

Eine Login-Drosselung zählt fehlgeschlagene Versuche und reagiert darauf: mit wachsenden Verzögerungen, einer vorübergehenden Sperre der Quelle oder einer zusätzlichen Prüfung (Challenge). WordPress selbst begrenzt ab Werk gar nichts. Ein Angreifer kann an der wp-login.php so schnell Passwörter durchprobieren, wie Ihr Server antwortet.

Limits pro IP-Adresse wirken gut gegen eine einzelne, laute Quelle. Gegen ein Botnetz, das seine Versuche auf Tausende Adressen verteilt und mit jeder einzelnen unter Ihrem Limit bleibt, wirken sie deutlich schlechter. Deshalb brauchen Sie zusätzlich Limits pro Benutzername. Zwanzig Fehlversuche gegen das Konto „admin" von zwanzig verschiedenen IPs sind trotzdem ein Muster.

Limits pro Benutzername haben allerdings eine eigene Tücke. Bei einer harten Sperre kann jeder Ihren echten Administrator aussperren, indem er absichtlich falsche Passwörter eingibt. Wachsende Verzögerungen oder eine Challenge sind hier die verträglichere Wahl.

Zwei Punkte entscheiden darüber, ob die Drosselung hilft oder schadet:

• Die Client-IP. Hinter einem CDN oder Reverse Proxy kommen unter Umständen alle Anfragen scheinbar von der Adresse des Proxys. Ein Plugin, das nur diese Adresse sieht, drosselt dann alle Besucher gleichzeitig. Der umgekehrte Fehler ist genauso schlimm: Vertraut das Plugin dem Header X-Forwarded-For von jedem Absender, können Angreifer bei jeder Anfrage eine neue IP vortäuschen und werden nie gesperrt. Konfigurieren Sie das Plugin oder das Real-IP-Modul des Webservers so, dass weitergeleitete Header nur aus den IP-Bereichen Ihres Proxys akzeptiert werden.
• Ihr eigener Weg zurück. Setzen Sie Ihre Büro-IP auf die Allowlist, sofern sie statisch ist, und kennen Sie Ihren Notfallzugang, bevor Sie ihn brauchen.

Was die Drosselung nicht leistet: Sie macht ein schwaches oder mehrfach verwendetes Passwort nicht sicher. Ein Passwort aus einer geleakten Liste kann schon beim ersten Versuch passen. Die eigentliche Lösung ist ein zweiter Faktor für jedes Konto mit erweiterten Rechten – eingerichtet wie in Zwei-Faktor-Authentifizierung für WordPress-Admins beschrieben.

XML-RPC: Warum system.multicall aus einer Anfrage viele Rateversuche macht

xmlrpc.php ist in WordPress standardmäßig aktiv. Es handelt sich um eine alte Schnittstelle für das Veröffentlichen aus der Ferne. Eine ihrer Methoden, system.multicall, führt viele Methodenaufrufe innerhalb einer einzigen HTTP-Anfrage aus. Ein Angreifer kann also eine lange Liste von Benutzername-Passwort-Kombinationen in einen einzigen POST packen.

Damit umgeht er jeden Login-Schutz, der nur die wp-login.php beobachtet oder Anfragen zählt. Eine Zeile in Ihrem Log kann Hunderte Rateversuche bedeuten. Stellen Sie sicher, dass Ihre Drosselung auch fehlgeschlagene XML-RPC-Anmeldungen zählt – oder schaffen Sie die Angriffsfläche ganz ab.

Über XML-RPC-Pingbacks lässt sich Ihre Website außerdem missbrauchen, um Anfragen an Dritte zu senden. Ein Grund mehr, sie abzuschalten, wenn nichts darauf angewiesen ist.

Bevor Sie XML-RPC abschalten: Prüfen Sie, was es noch nutzt

Manche legitimen Werkzeuge sprechen noch mit xmlrpc.php. Infrage kommen ältere Desktop-Blogging- und Remote-Publishing-Tools, ältere Setups mobiler Apps, einige Connector-Plugins und Integrationen, die vor Jahren gebaut wurden. Die Verbindung von Jetpack hat in der Vergangenheit auf XML-RPC gesetzt; wenn Sie Jetpack nutzen, prüfen Sie die aktuelle Dokumentation.

Schauen Sie zuerst in Ihre Access-Logs. Auf einem typischen Apache- oder nginx-Server mit dem Log-Format „combined":

# Welche IPs senden POST-Anfragen an xmlrpc.php?
grep "POST /xmlrpc.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Welche User-Agents?
awk -F'"' '/POST \/xmlrpc.php/ {print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Passen Sie den Pfad an Ihren Server an (zum Beispiel /var/log/apache2/access.log) und beziehen Sie rotierte Logs mit ein. Tausende Zugriffe von wechselnden IPs mit generischen User-Agents sind Angriffe. Eine Handvoll Anfragen von einer bekannten Dienst-IP gehört dagegen vermutlich zu einer Integration – fragen Sie Ihre Agentur oder den Anbieter, bevor Sie sie kappen.

Sie haben zwei Möglichkeiten:

1. **Der Filter xmlrpc_enabled.** Er deaktiviert XML-RPC-Methoden, die eine Anmeldung erfordern, und unterbindet damit das Passwortraten über XML-RPC. Methoden ohne Anmeldung wie Pingbacks funktionieren weiterhin. Siehe die WordPress-Entwicklerreferenz.
2. Die Datei auf Serverebene sperren. Das stoppt alles, und PHP wird für diese Anfragen gar nicht erst ausgeführt.

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

location = /xmlrpc.php {
    deny all;
}

Testen Sie nach der Änderung das Veröffentlichen, Ihre App und alle angebundenen Dienste. Dokumentieren Sie, was Sie geändert haben und warum – damit die nächste Person es nicht wieder „repariert".

REST-API: Benutzer-Enumeration und Rate Limiting für anonyme Anfragen

/wp-json/wp/v2/users listet Benutzer auf, die Inhalte veröffentlicht haben, samt ihrer Slugs. /?author=1 leitet auf ein Autorenarchiv weiter, dessen URL den Slug verrät. Slugs entsprechen oft dem Login-Namen – damit hat ein Angreifer schon die halben Zugangsdaten.

Den Users-Endpunkt für anonyme Besucher einzuschränken und Autoren-Scans zu blockieren, reduziert das Rauschen der Aufklärungsphase. Benutzernamen sind allerdings keine Geheimnisse. Sie zu verstecken, ist für sich genommen keine Schutzmaßnahme.

Rate Limiting für anonyme REST-Anfragen hilft gegen Scraping und automatisiertes Abtasten. Wenden Sie es nur auf anonymen Traffic an und testen Sie danach. Der Block-Editor nutzt die REST-API für angemeldete Benutzer, und Integrationen authentifizieren sich mit Anwendungspasswörtern (seit WordPress 5.6 im Core). Ein Limit, das diese trifft, legt das Bearbeiten oder einen Sync-Job lahm – auf eine Weise, die schwer nachzuvollziehen ist.

Was es nicht leistet: Rate Limiting behebt keinen verwundbaren REST-Endpunkt in einem Plugin. Es verlangsamt nur die Versuche, ihn auszunutzen.

Warum ein Plugin keinen DDoS-Angriff stoppen kann

Ein Plugin ist PHP-Code. Er läuft erst, nachdem eine Anfrage das Netzwerk durchquert hat, vom Webserver angenommen und an einen PHP-Worker übergeben wurde. Eine volumetrische Flut sättigt Ihre Bandbreite, Ihre Verbindungslimits oder Ihren Pool an PHP-Workern lange vorher. Selbst wenn das Plugin jede Anfrage in einer Millisekunde abweist, belegt jede Abweisung trotzdem einen Worker – und davon hat ein Server nur eine begrenzte Zahl.

Anders sieht es bei Fluten auf Anwendungsebene aus. Das sind viele aufwendige, aber legitim wirkende Anfragen, etwa Suchanfragen oder nicht gecachte Seiten. Hier hilft Rate Limiting nahe an der Anwendung durchaus etwas, aber nur bis zur Kapazitätsgrenze des Servers.

Eine Warnung bei Traffic-Spitzen ist nützlich, weil sie Ihnen zeigt, dass etwas passiert. Abfangen kann sie nichts. Wer ein WordPress-Plugin als „DDoS-Schutz" verkauft, verspricht zu viel.

Was ein CDN oder eine Edge-Firewall stattdessen leistet – und was der Webserver beiträgt

Ein CDN oder eine Edge-Firewall sitzt vor Ihrem Hoster, in einem Netz, das weit größer ist als Ihres. Dort lassen sich Fluten abfangen und filtern, Rate Limits und Bot-Regeln greifen, bevor der Traffic Sie erreicht, gecachte Seiten werden ausgeliefert, wenn Ihr Server in die Knie geht, und Anfragen an wp-login.php und xmlrpc.php können eine Challenge bekommen. Sobald das steht, sperren Sie den Ursprungsserver ab: Lassen Sie an Ihrer Server-Firewall nur die IP-Bereiche des CDN zu. Sonst umgehen Angreifer das CDN und gehen direkt auf die echte Adresse Ihres Servers.

Auf dem Webserver kann das nginx-Modul [limit_req](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html) Login-Versuche begrenzen, bevor PHP überhaupt startet. Hinter einem CDN oder Reverse Proxy richten Sie zuerst das Real-IP-Modul ein (und vertrauen nur den Bereichen Ihres Proxys). Andernfalls ist $binary_remote_addr die Adresse des Proxys, und alle Besucher teilen sich ein einziges Limit:

# http-Kontext
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;

# server-Kontext
location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    # Ihre bestehenden fastcgi_pass-/include-Zeilen hier beibehalten
}

fail2ban verfolgt einen anderen Ansatz. Es liest Ihre Logs und sperrt Wiederholungstäter an der Firewall – das ist günstiger, als ihnen in PHP zu antworten. Hinter einem CDN funktioniert das nicht ohne Weiteres: Die Server-Firewall sieht nur die Adressen des CDN, also müssen Sperren beim CDN selbst (oder über dessen API) erfolgen. Bei Managed Hosting fragen Sie Ihren Hoster, welchen Netzwerkschutz er bereits bietet.

Auch hier gibt es Grenzen. Eine Edge-Firewall behebt weder schwache Passwörter noch verwundbare Plugins. Und sie hilft nicht gegen das, was ein Angreifer nach einem erfolgreichen Login anstellen kann – darum geht es in WordPress-Dateieditor deaktivieren.

Eine sinnvolle Reihenfolge für kleine Unternehmen in der EU

1. Starke, einzigartige Passwörter und 2FA für jeden Administrator und Redakteur.
2. Login-Drosselung mit Limits pro IP und pro Benutzername, korrekter Erkennung der Client-IP und einem getesteten Notfallzugang.
3. Die Entscheidung zu XML-RPC: Logs prüfen, dann Filter oder Serversperre.
4. Einschränkungen gegen Benutzer-Enumeration und Limits für anonyme REST-Anfragen.
5. Ein CDN oder eine Edge-Firewall mit abgesichertem Ursprungsserver für Websites, bei denen Ausfallzeit Geld kostet.

Das hat auch eine Compliance-Seite. Art. 32 Abs. 1 lit. b DSGVO verlangt, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme auf Dauer sicherzustellen (DSGVO auf EUR-Lex). Für wichtige und besonders wichtige Einrichtungen im Anwendungsbereich von NIS2 nennt Art. 21 Abs. 2 lit. j die Multi-Faktor-Authentifizierung unter den Mindestmaßnahmen (NIS2 auf EUR-Lex). Die Einzelheiten regelt das nationale Umsetzungsgesetz – prüfen Sie es für Ihr Unternehmen.

Das Plugin Security Audit & Compliance von secaudit.eu bietet Login-Drosselung, das Abschalten von XML-RPC, Rate Limiting für anonyme REST-Anfragen und Warnungen bei Traffic-Spitzen. Es ist kein DDoS-Schutz; dafür brauchen Sie ein CDN oder eine Edge-Firewall. → secaudit.eu

Nächster Schritt: Arbeiten Sie den Rest der WordPress-Sicherheitscheckliste durch. Zeigen Ihre Logs bereits erfolgreiche Logins, die Sie nicht zuordnen können, lesen Sie stattdessen Anzeichen für eine gehackte Website.

FAQ

Funktionieren Jetpack oder meine App noch, wenn ich XML-RPC abschalte?

Möglicherweise nicht. Suchen Sie in Ihren Logs nach legitimen XML-RPC-Clients und prüfen Sie die aktuelle Dokumentation des Anbieters. Der Filter xmlrpc_enabled ist die sanftere Variante, eine Sperre auf Serverebene die strengere. Testen Sie nach jeder der beiden Änderungen.

Stoppt das Umbenennen der wp-login.php Brute-Force-Angriffe?

Es reduziert das Rauschen durch einfache Bots, ist aber keine Schutzmaßnahme. Angreifer finden die Login-Seite trotzdem oder weichen auf XML-RPC aus. Setzen Sie zusätzlich auf Drosselung und 2FA.

Reicht mein Sicherheits-Plugin bei einem DDoS-Angriff?

Nein. Wenden Sie sich an Ihren Hoster oder CDN-Anbieter. Filterung am Netzwerkrand und Caching halten die Website erreichbar.

Sperrt mich die Drosselung aus?

Das kann passieren, wenn die Client-IP falsch erkannt wird oder Sie sich mehrfach vertippen. Setzen Sie Ihre IP auf die Allowlist und halten Sie WP-CLI- oder SFTP-Zugang bereit, um das Plugin zu deaktivieren.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.