Zum Hauptinhalt springen

Brute-Force-Angriffe auf wp-login.php gehören zum täglichen Grundrauschen jeder WordPress-Site. Jede öffentlich erreichbare WordPress-Site erhält täglich automatisierte Login-Versuche. Brute Force probiert Passwörter durch, Credential Stuffing nutzt E-Mail/Passwort-Paare aus Datenlecks und ist deutlich erfolgreicher.

Die Angriffsflächen

  • /wp-login.php (und /wp-admin, das dorthin weiterleitet)
  • /xmlrpc.php: Mit system.multicall lassen sich hunderte Passwörter in einem einzigen Request testen.
  • REST-API mit Application Passwords oder Login-Endpunkte von Plugins (WooCommerce „Mein Konto“, Membership-Plugins).

Ebene 1: Accounts

  • Einzigartige, lange Passwörter aus dem Passwortmanager.
  • 2FA oder Passkeys für alle privilegierten Rollen (siehe eigener Artikel).
  • Keine vorhersehbaren Benutzernamen; Benutzer-Enumeration erschweren (Autoren-Archive /?author=1, REST /wp-json/wp/v2/users).

Ebene 2: XML-RPC abschalten

Wird XML-RPC nicht benötigt (Jetpack und einige Apps nutzen es), am besten auf Webserver-Ebene sperren. In WordPress selbst:

add_filter( 'xmlrpc_enabled', '__return_false' );

Der Filter deaktiviert nur authentifizierte Methoden; der Endpunkt antwortet weiterhin. Die Webserver-Sperre (403) ist wirksamer und spart PHP-Ressourcen.

Ebene 3: Rate Limiting und WAF

  • Webserver: limit_req in Nginx (siehe Webserver-Konfiguration).
  • Fail2ban: Fehlgeschlagene Logins ins Log schreiben (z. B. mit einem Plugin wie WP fail2ban) und IPs auf Server-Firewall-Ebene sperren.
  • Cloudflare/Edge-WAF: Rate-Limiting-Regel für /wp-login.php und /xmlrpc.php, ggf. Managed Challenge für Länder, aus denen sich nie jemand einloggt.
  • Plugin-Ebene: Limit Login Attempts, Wordfence o. ä. Funktioniert, kostet aber PHP-Ressourcen bei jedem Versuch.

Ebene 4: Login-Zugang einschränken

  • IP-Whitelist für /wp-admin und /wp-login.php, wenn die Redaktion feste IPs oder ein VPN hat. Achtung: admin-ajax.php muss für das Frontend erreichbar bleiben.
  • Zusätzliche HTTP-Basic-Auth vor wp-login.php stoppt Bots vor PHP.
  • Login-URL ändern reduziert Rauschen in den Logs, ist aber Security by Obscurity und kein Ersatz für die anderen Massnahmen.

Credential Stuffing erkennen

Anzeichen: viele verschiedene Benutzernamen von vielen IPs mit jeweils wenigen Versuchen. Klassische „5 Versuche pro IP“-Regeln greifen hier kaum. Wirksam sind 2FA, Breached-Password-Checks beim Setzen von Passwörtern (gegen die Have-I-Been-Pwned-API mit k-Anonymität) sowie Bot-Erkennung an der Edge.

Monitoring

Erfolgreiche Logins von Administratoren protokollieren und bei neuen IPs oder Ländern benachrichtigen (Activity-Log-Plugins wie WP Activity Log oder Simple History).

Weiterführende Artikel

Quellen und Dokumentation