WordPress Brute Force: den Login wirkungsvoll absichern

Von Manuel Hack, ihp media · Aktualisiert am 20. Juni 2026

Wer eine WordPress-Website betreibt, bekommt Besuch, den er nicht eingeladen hat. Bots durchsuchen das Netz systematisch nach wp-login.php und probieren dort vollautomatisch Zugangsdaten durch. Das ist kein seltenes Ereignis, das nur bekannte Seiten trifft: Wordfence zufolge blockierte das Netzwerk im Jahr 2024 über 55 Milliarden Passwortangriffe auf WordPress-Installationen weltweit. Diese Zahl illustriert den Dauerzustand, nicht eine außergewöhnliche Angriffswelle.

Dieser Artikel konzentriert sich auf den Brute-Force-Angriff selbst: wie er technisch funktioniert, warum XML-RPC ihn dramatisch beschleunigt, und welche Schutzmaßnahmen tatsächlich greifen. Passwörter, Zwei-Faktor-Authentifizierung und Benutzerrollen behandelt der Ratgeber zur Login-Grundabsicherung, wer dort noch nicht war, sollte dort anfangen.

Was ein Brute-Force-Angriff ist und wie er abläuft

Der Begriff stammt aus der Kryptographie: Brute Force bedeutet, alle möglichen Kombinationen durchzuprobieren, bis die richtige gefunden ist. Auf den WordPress-Login übertragen heißt das: Ein automatisiertes Programm schickt POST-Requests an wp-login.php, jedes Mal mit einer anderen Benutzername-Passwort-Kombination. Bei einfachen Wörterbuch-Angriffen kommt eine Liste häufiger Passwörter zum Einsatz. Bei komplexeren Varianten werden alle Zeichenkombinationen bis zu einer bestimmten Länge durchgespielt.

Der Angriff funktioniert vollautomatisch. Der Angreifer muss nicht aktiv dabei sein, er startet das Skript und wartet. Das erklärt, warum auch kleine Unternehmenswebsites betroffen sind: Die Angriffe richten sich nicht gegen eine Person, sondern scannen das gesamte Netz nach erreichbaren WordPress-Installationen. Eine Seite mit wenig Traffic ist genauso ein Ziel wie eine mit tausenden Besuchern täglich.

WordPress-Installations sind leicht erkennbar: der Pfad /wp-content/ in Quelltexten, das Generator-Meta-Tag oder charakteristische HTTP-Responses verraten das CMS. Das BSI hat in seiner Cybersicherheitswarnung zu Brute-Force-Angriffen auf exponierte Systeme (2024) dokumentiert, wie Angreifer nach erfolgreichen Login-Versuchen systematisch Backdoors einschleusen, sich lateral bewegen und Ransomware vorbereiten. Der eigentliche Einbruch ist oft nur der erste Schritt.

Credential Stuffing: der gefährlichere Bruder

Credential Stuffing ist technisch eine Variante des Brute-Force-Angriffs, aber mit einem entscheidenden Unterschied: Statt Passwörter zu erraten, werden echte Zugangsdaten aus Datenlecks anderer Dienste eingesetzt. OWASP beschreibt Credential Stuffing als die automatisierte Injektion gestohlener Benutzername-Passwort-Paare in Login-Formulare.

Die Trefferquote liegt weit über der eines klassischen Wörterbuch-Angriffs, weil die Daten real sind. Eine 2011 durchgeführte Analyse zeigte, dass zwei Drittel der Nutzer, deren Zugangsdaten sowohl im Sony- als auch im Gawker-Datenleck auftauchten, auf beiden Plattformen dasselbe Passwort verwendet hatten. Dieses Muster hat sich seitdem kaum verändert.

Für WordPress bedeutet das: Ein Nutzer, der dasselbe Passwort für seine WP-Installation und für einen anderen Dienst verwendet, der gehackt wurde, ist angreifbar, selbst wenn sein WP-Passwort für sich genommen als stark gilt. Credential Stuffing umgeht damit den Passwortschutz auf einer anderen Ebene. Deshalb reicht es nicht, auf starke Passwörter zu verweisen und es dabei zu belassen. Die Schutzmaßnahmen auf Systemebene, also Login-Limits, WAF und 2FA, greifen unabhängig davon, wie das Passwort kompromittiert wurde.

XML-RPC: die unterschätzte Hintertür

XML-RPC ist eine Legacy-Schnittstelle, die ursprünglich für die Fernverwaltung von WordPress-Installationen und externe Clients gedacht war. Sie liegt standardmäßig unter /xmlrpc.php und ist in den meisten Installationen aktiv, auch wenn niemand sie bewusst nutzt.

Das Problem: XML-RPC unterstützt die Methode system.multicall, die mehrere API-Aufrufe in einem einzigen Request bündelt. Sucuri hat 2015 die Amplification-Technik dokumentiert, die seither in unveränderter Form in Angriffs-Tools weiterlebt: Ein einziger POST-Request an xmlrpc.php kann Hunderte Login-Versuche enthalten. Weil jeder dieser Versuche kein eigenständiger Login-Request an wp-login.php ist, greifen Plugin-basierte Ratenlimiter an der normalen Login-Seite schlicht nicht.

Wer kein Jetpack, keine ältere mobilen App und kein externes Publishing-Tool einsetzt, braucht XML-RPC nicht. Das Deaktivieren ist dann die sauberste Lösung:

// In functions.php oder einem mu-plugin:
add_filter( 'xmlrpc_enabled', '__return_false' );

Alternativ lässt sich /xmlrpc.php auf Server-Ebene sperren, was noch früher im Request-Ablauf greift:

# Nginx:
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

# Apache (.htaccess):
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Login-Versuche begrenzen

Die einfachste und wirksamste einzelne Maßnahme gegen klassische Brute-Force-Angriffe an wp-login.php ist ein Ratenlimit: Nach einer festgelegten Zahl fehlgeschlagener Versuche wird die IP-Adresse vorübergehend gesperrt. WordPress selbst hat diese Funktion nicht von Haus aus.

Auf Plugin-Ebene leisten das Limit Login Attempts Reloaded zuverlässig. Sinnvolle Ausgangswerte: Sperre nach 3 bis 5 Fehlversuchen innerhalb von 10 Minuten, Sperrdauer 30 bis 60 Minuten. Bei wiederholten Sperren derselben IP lässt sich die Dauer automatisch verlängern. OWASP empfiehlt zusätzlich einen progressiven Backoff: Die Wartezeit zwischen erlaubten Versuchen wächst mit jedem weiteren Fehlversuch.

Ein Hinweis zur Fehlerkonfiguration: Wer die Sperre zu aggressiv setzt, riskiert, legitime Nutzer auszusperren. Bei Websites mit vielen Redakteuren, die über mobile Netze arbeiten, teilen sich manchmal viele Nutzer eine IP-Adresse. Eine Whitelist für bekannte Büro-IPs ist dann sinnvoll.

Wer Managed-WordPress-Hosting nutzt (Raidboxes, Kinsta, WP Engine), hat einen Ratenlimiter oft bereits auf Infrastrukturebene aktiv. Dann ergibt eine zusätzliche Plugin-Ebene selten Mehrwert und verursacht nur doppelte Logs.

IP-Sperren und Fail2Ban

Plugin-Sperren greifen auf PHP-Ebene: WordPress startet, lädt alle Plugins, und erst dann wird die IP gesperrt. Das kostet Serverressourcen. Robuster ist eine Sperre auf Infrastrukturebene, die greift, bevor PHP überhaupt gestartet wird.

Fail2Ban ist das Standardwerkzeug dafür auf selbst verwalteten Servern. Es wertet die Nginx- oder Apache-Zugriffslogs aus und sperrt IP-Adressen über iptables oder nftables, sobald die konfigurierte Schwelle überschritten ist. Eine typische WordPress-Konfiguration sieht so aus:

# /etc/fail2ban/jail.local
[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/nginx/access.log
port     = http,https
maxretry = 5
findtime = 300
bantime  = 3600

Der passende Filter sucht in den Logs nach POST-Requests an /wp-login.php und /xmlrpc.php mit HTTP-200-Antworten (WordPress gibt auch bei fehlgeschlagenen Logins 200 zurück). Wer hinter einem Cloudflare-Proxy sitzt, muss darauf achten, dass Nginx die echte Client-IP aus dem X-Forwarded-For-Header zieht, sonst sperrt Fail2Ban die Cloudflare-IP, nicht den Angreifer.

Auf Shared-Hosting ohne Root-Zugang ist Fail2Ban nicht verfügbar. Dort ist man auf Plugin-Lösungen oder CDN-basierte Schutzmaßnahmen angewiesen.

Login-URL ändern

Die Standard-URL /wp-login.php ist jedem Scanner bekannt. Sie auf einen anderen Pfad zu legen, ist kein Sicherheitsmerkmal im eigentlichen Sinne, aber es filtert einen erheblichen Teil des automatisierten Massenscannings heraus, weil die meisten Bots keine individuelle Suche betreiben. Sie scannen die bekannten Pfade und gehen weiter, wenn sie nichts finden.

WPS Hide Login erledigt das ohne Eingriff in Core-Dateien und ohne eigene Rewrite-Regeln in der .htaccess. Der neue Pfad sollte nicht offensichtlich sein (/admin, /login oder /cms probieren Scanner ebenfalls). Wichtig: Den neuen Pfad merken oder sofort in einem Passwort-Manager hinterlegen. Wer den Pfad vergisst, ist ausgesperrt und braucht FTP-Zugang, um das Plugin zu deaktivieren.

Was die Login-URL-Änderung nicht leisten kann: Ein gezielter Angreifer, der die URL kennt oder findet, ist durch den Pfadwechsel nicht aufgehalten. Die anderen Schutzmaßnahmen bleiben notwendig.

CAPTCHA

Ein CAPTCHA fordert den Nutzer auf, eine Aufgabe zu lösen, die für Menschen einfach, für automatisierte Skripte schwierig ist. Klassisch sind die Google reCAPTCHA-Versionen, aber auch Cloudflare Turnstile und hCaptcha sind verbreitete Alternativen, die weniger Nutzerdaten an Google senden.

OWASP hält CAPTCHA für eine wirksame Maßnahme, formuliert aber die Anforderung präzise: Es muss zu nahezu 100 % von Menschen lösbar sein und zu nahezu 100 % von Computern nicht. Ältere reCAPTCHA-v1-Implementierungen haben diese Anforderung faktisch nicht mehr erfüllt, weshalb Google reCAPTCHA v2 und v3 entwickelt hat. Version 3 arbeitet unsichtbar im Hintergrund und vergibt Risiko-Scores, ohne den Nutzer zu unterbrechen.

Ein praktisches Problem: Manche CAPTCHA-Lösungen, insbesondere reCAPTCHA v3, sind ohne Cookie-Einwilligung nach DSGVO problematisch, weil Daten an Google-Server übertragen werden. Wer DSGVO-Konformität ohne Kompromisse braucht, ist mit Cloudflare Turnstile oder einem Mathematik-CAPTCHA aus einem einheimischen Plugin besser bedient.

CAPTCHA sollte nicht als alleinige Maßnahme stehen. Fortgeschrittene Bots mit CAPTCHA-Solving-Diensten lösen selbst schwierige CAPTCHAs automatisch. Die Kombination mit einem Ratenlimit ist effektiver als eines von beidem allein.

Web Application Firewall

Eine Web Application Firewall (WAF) analysiert den eingehenden HTTP-Traffic, bevor er den Webserver oder WordPress erreicht, und filtert bekannte Angriffsmuster heraus. Für WordPress gibt es WAFs auf zwei Ebenen:

Plugin-basiert: Wordfence und WP Cerber bringen eigene WAF-Funktionen mit, die auf PHP-Ebene arbeiten. Der kostenlose Wordfence-Plan enthält eine grundlegende Firewall. Der Nachteil bleibt: WordPress und PHP müssen starten, bevor die Firewall eingreift.

Vorgelagert (CDN/DNS): Cloudflare als Reverse-Proxy schaltet die WAF vor den Ursprungsserver. Schon der kostenlose Plan bringt eine Bot-Erkennung mit. Der Pro-Plan (ab 20 US-Dollar pro Monat, Stand Juni 2026) erweitert die WAF-Regelsätze erheblich und erlaubt eigene Firewall-Regeln. Requests von bekannten Angreifer-IPs werden abgeblockt, bevor sie den Server überhaupt erreichen. Das entlastet die Server-Ressourcen spürbar.

Wer Cloudflare einsetzt, kann über eine benutzerdefinierte Regel wp-login.php so konfigurieren, dass Anfragen aus Ländern blockiert werden, aus denen legitime Logins nie zu erwarten sind. Das ist kein wasserdichter Schutz, reduziert aber das Volumen automatisierter Angriffe erheblich.

Wer einen umfassenden Überblick über WordPress-Sicherheitsplugins braucht, findet dort eine detaillierte Einordnung der verschiedenen Anbieter.

Schutzmaßnahmen im Überblick

Schritt-für-Schritt: Brute-Force-Schutz einrichten

1. Aktuellen Zustand prüfen. Im Hosting-Kontrollpanel oder den Nginx-/Apache-Logs nachsehen, wie viele Requests pro Stunde auf wp-login.php und xmlrpc.php treffen. Damit lässt sich einschätzen, ob bereits ein aktiver Angriff läuft.
2. XML-RPC abschalten (sofern nicht benötigt). In functions.php oder einem mu-plugin add_filter('xmlrpc_enabled','__return_false'); einfügen. Danach prüfen, ob externe Integrationen (Jetpack, mobile App) noch funktionieren. Falls ja, ist die Schnittstelle nicht benötigt, der Filter bleibt.
3. Login-Limit einrichten. Plugin installieren (Limit Login Attempts Reloaded oder WP Cerber), Schwelle auf 3 bis 5 Fehlversuche in 10 Minuten konfigurieren, Sperrdauer auf 60 Minuten, eigene IP auf die Whitelist setzen.
4. Login-URL verlegen (optional, aber empfohlen). WPS Hide Login installieren, neuen Pfad wählen, sofort im Passwort-Manager hinterlegen. Den alten Pfad /wp-login.php zusätzlich auf Server-Ebene mit HTTP 404 beantworten, damit Scanner kein Signal bekommen.
5. WAF oder Cloudflare aktivieren. Für Shared-Hosting: Wordfence (kostenlos) oder WP Cerber. Für eigene Server oder bei höherem Schutzbedarf: Cloudflare als Proxy, WAF-Regeln für den Login-Bereich aktivieren.
6. Fail2Ban konfigurieren (nur eigene Server). Filter für wp-login.php– und xmlrpc.php-POST-Requests erstellen, Jail mit maxretry = 5, findtime = 300, bantime = 3600 aktivieren, Dienst neu starten und mit fail2ban-client status wordpress bestätigen, dass die Jail läuft.
7. Monitoring aktivieren. Wordfence oder WP Activity Log einrichten. E-Mail-Benachrichtigungen bei verdächtiger Login-Aktivität aktivieren. Einmal im Monat die Benutzerliste auf unbekannte Administrator-Konten prüfen.

<?php
/**
 * Plugin Name: IHP Brute-Force-Schutz
 * Description: Deaktiviert XML-RPC vollständig.
 */

// XML-RPC deaktivieren
add_filter( 'xmlrpc_enabled', '__return_false' );

// Optional: Login-Fehler-Meldung entschärfen (kein Hinweis auf falsches Passwort vs. Benutzername)
add_filter( 'login_errors', function() {
    return 'Zugangsdaten ungültig.';
} );

[Definition]
failregex = ^<HOST> .+ "POST /(wp-login\.php|xmlrpc\.php) HTTP.+" (200|403) .+$
ignoreregex =

sudo systemctl restart fail2ban
fail2ban-client status wordpress

Praxisbeispiel aus einem Kundenprojekt

In einem Projekt für einen mittelständischen Dienstleister stellten wir bei der Übernahme der technischen Betreuung fest, dass die Website täglich mehrere hundert fehlgeschlagene Login-Versuche verzeichnete. Der Server reagierte träge, obwohl kein Traffic-Anstieg durch Besucher zu verzeichnen war. Die Ursache: Das Hosting-Paket war auf die reguläre Last ausgelegt, nicht auf die zusätzliche Last Hunderter täglicher POST-Requests an wp-login.php.

XML-RPC war aktiv, Jetpack wurde nicht eingesetzt. Nach dem Deaktivieren per Filter sank die Zahl der Angriffs-Requests auf weniger als ein Zehntel. Ein Ratenlimiter auf Plugin-Ebene stoppte den Rest. Die Serverlast fiel messbar, ohne dass wir das Hosting-Paket upgraden mussten.

Das Muster ist typisch: Nicht der erfolgreiche Einbruch ist das erste Problem, das auffällt, sondern die Serverlast durch die Angriffe selbst. Wer wartet, bis Zugangsdaten kompromittiert werden, hat die Gegenmaßnahmen zu spät eingeleitet. Mehr dazu, was zu tun ist, wenn ein Angriff erfolgreich war, steht im Notfallplan für gehackte WordPress-Seiten.

Sofort-Checkliste

• XML-RPC deaktiviert, sofern nicht für externe Tools benötigt?
• Login-Ratenlimit aktiv (max. 5 Fehlversuche, dann 60 Minuten Sperre)?
• Login-URL auf einen nicht-öffentlichen Pfad gelegt?
• WAF aktiv (plugin-basiert oder via Cloudflare)?
• Fail2Ban konfiguriert (falls eigener Server)?
• Monitoring: E-Mail-Benachrichtigung bei Login-Anomalien eingerichtet?
• Benutzerliste: Keine unbekannten Administrator-Konten vorhanden?
• Zwei-Faktor-Authentifizierung für alle Administratoren aktiv (Details: Artikel 87)?
• SSL/HTTPS aktiv, damit Zugangsdaten verschlüsselt übertragen werden (Artikel 84)?
• WordPress-Core, Plugins und Theme aktuell gehalten?

Häufige Fragen

Was ist der Unterschied zwischen Brute Force und Credential Stuffing?

Ein klassischer Brute-Force-Angriff probiert Passwörter nach einem Schema durch: häufige Wörter, Zeichenkombinationen, Variationen. Credential Stuffing setzt dagegen echte Zugangsdaten ein, die bei früheren Datenlecks anderer Dienste erbeutet wurden. Die Trefferquote von Credential Stuffing ist deshalb deutlich höher, weil die Daten nicht geraten, sondern bekannt sind. Beide Angriffe treffen wp-login.php, Credential Stuffing ist in der aktuellen Bedrohungslage häufiger.

Reicht es, die Login-URL zu ändern?

Nein. Eine geänderte Login-URL filtert automatisiertes Massenscanning heraus, weil die meisten Bots keine individuelle URL-Suche betreiben. Sobald ein Angreifer die neue URL kennt oder gezielt nach ihr sucht, ist der Schutz aufgehoben. Ein Ratenlimit und eine WAF wirken unabhängig davon, welche URL der Angreifer verwendet.

Warum greift mein Login-Limit-Plugin nicht gegen XML-RPC?

Plugin-basierte Ratenlimiter überwachen in der Regel POST-Requests an wp-login.php. XML-RPC nutzt einen eigenen Endpunkt (xmlrpc.php) und die Methode system.multicall, die Hunderte Authentifizierungsversuche in einem einzigen Request bündelt. Das Plugin sieht nur einen Request, nicht Hunderte Login-Versuche. Die Lösung ist XML-RPC zu deaktivieren, wenn es nicht gebraucht wird, oder xmlrpc.php auf Server-Ebene zu sperren.

Kann Cloudflare allein ausreichen?

Cloudflare (kostenloser Plan) reduziert Brute-Force-Angriffe erheblich, weil bekannte Bot-IPs und verdächtige Traffic-Muster gefiltert werden, bevor sie den Server erreichen. Als einzige Maßnahme reicht das nicht: Wird eine Anfrage von Cloudflare durchgelassen, greift ohne weiteren Schutz nichts. Die sinnvolle Kombination ist Cloudflare plus ein Ratenlimit auf Plugin- oder Nginx-Ebene plus XML-RPC deaktiviert.

Was tue ich, wenn meine Website gerade unter Angriff steht?

Zunächst prüfen, ob bereits ein Konto kompromittiert wurde: Unbekannte Administrator-Konten in der Benutzerverwaltung sind ein klares Zeichen. Falls ja: Alle Passwörter sofort ändern, unbekannte Konten löschen, WordPress-Secret-Keys in wp-config.php neu generieren (damit werden alle aktiven Sitzungen ungültig). Danach sofort XML-RPC deaktivieren, ein Ratenlimit einrichten und Wordfence oder WP Cerber installieren. Der vollständige Notfallplan steht im Ratgeber für gehackte WordPress-Seiten. Wurde Malware eingeschleust, erklärt der Artikel zu Malware in WordPress finden und entfernen, wie man vorgeht.

Brauche ich ein separates Security-Plugin oder reicht Cloudflare?

Die Antwort hängt vom Hosting ab. Wer auf Shared-Hosting ohne Root-Zugang sitzt, ist auf Plugin-Lösungen angewiesen. Wer Cloudflare einsetzt, deckt damit die Netzwerkebene ab, braucht aber weiterhin einen Ratenlimiter auf WordPress-Ebene für den Fall, dass Cloudflare einen Request durchlässt. Ein guter Mittelweg ist Cloudflare (kostenlos) plus Limit Login Attempts Reloaded (kostenlos) plus XML-RPC deaktiviert.