Ultimativer WordPress-Login-Sicherheitsleitfaden (2026): Brute-Force-Angriffe stoppen

Die meisten “WordPress gehackt”-Vorfälle, zu denen ich gerufen werde, sind keine Zero-Days. Es ist Credential Stuffing gegen admin mit einem Passwort aus einem 2019er Forendump, das von einem rotierenden Pool aus Residential-Proxies auf /wp-login.php einschlägt. Der Seitenbetreiber gibt WordPress die Schuld; die tatsächliche Ursache ist, dass Login-Sicherheit als ein einziger Schalter (“starkes Passwort”) behandelt wurde statt als vier oder fünf gestaffelte Kontrollen. Heise.de und das BSI dokumentieren denselben Befund quartalsweise in ihren Lageberichten.

Dieser Leitfaden geht durch die Schichten, die ich auf Kundenseiten tatsächlich konfiguriere: Benutzernamen-Hygiene, 2FA mit funktionierendem WP-CLI-Notausgang, Rate-Limiting an Cloudflare und Server, sowie der Recovery-Pfad für den Tag, an dem jemand sein Telefon verliert oder ein Application Password in ein öffentliches Repo committet. Für Seiten unter DSGVO-Pflicht macht Art. 33 mit der 72-Stunden-Meldefrist jede dieser Kontrollen zu einer dokumentierten Pflicht, nicht einer Empfehlung. Die BSI-Mindeststandards für Webanwendungen verlangen mehrstufige Authentifizierung explizit für administrative Zugänge.

#Wie WordPress-Logins tatsächlich angegriffen werden

Drei Muster decken fast alles ab, was ich in Access-Logs sehe:

• Brute-Force auf /wp-login.php: Bots POSTen an wp-login.php mit log=admin&pwd=.... Verteilt auf hunderte IPs, oft aus Residential-Proxy-Netzen wie 911.re-Nachfolgern. Per-IP-Rate-Limits stoppen sie nicht.
• Credential Stuffing: derselbe Endpunkt, aber Credentials kommen aus öffentlichen Breach-Dumps (“Collection #1” bis #5, RockYou2024). Benutzername ist die geleakte E-Mail oder der Login. Mit einem haveibeenpwned-Check beim Passwort-Setzen lasst sich das vorab abfangen.
• XML-RPC system.multicall-Verstärkung: ein POST an /xmlrpc.php mit einem system.multicall-Body lasst Hunderte Passwörter in einer einzigen HTTP-Request testen, was Per-Request-Rate-Limits umgeht. Wer die WP-Mobile-App oder Jetpack nicht nutzt, sollte xmlrpc.php am Server blockieren.
• REST-API-Benutzerenumeration: ?rest_route=/wp/v2/users und /wp-json/wp/v2/users geben echte slug-Werte für jeden veröffentlichten Autor zurück. Dieser Slug ist der Login-Name. Kombiniert mit den obigen Dumps hat der Angreifer die halbe Credential-Hälfte.

Mittwald und Raidboxes liefern ModSecurity-Profile mit aktivierten Anti-Brute-Force-Regeln per Default aus, aber keiner deckt alle vier Vektoren ohne zusätzliche Konfiguration ab.

#Teil 1: die “admin”-Schwachstelle (Benutzerenumeration)

Warum lieben Hacker den Benutzernamen “admin”? Weil er ihre Arbeit halbiert.

In einem Brute-Force-Angriff muss der Angreifer zwei Dinge erraten: den Benutzernamen und das Passwort. Wenn Sie “admin” verwenden, haben Sie ihnen 50% der Anmeldedaten kostenlos gegeben.

#Das “ID 1”-Problem

Standardmäßig hat der erste in WordPress erstellte Benutzer die ID 1. Hacker scannen oft ihre-seite.com/?author=1. Wenn Ihre Seite zu ihre-seite.com/author/admin/ weiterleitet, haben Sie jedem Angreifer Ihren Benutzernamen verraten.

#Die Lösung: chirurgische Entfernung

Sie können einen WordPress-Benutzernamen nicht einfach “umbenennen”. Sie müssen einen Transplantationsprozess durchführen, der alle Inhalte erhält und das anfällige Konto eliminiert.

1. Neuen Commander erstellen:

   • Gehen Sie zu Benutzer -> Neu hinzufügen.
   • Benutzername: Etwas Unklares (z.B. Obsidian_Eagle_88). Vermeiden Sie Ihren echten Namen oder alles, was von Ihrer Domain erraten werden kann.
   • E-Mail: Ihre sichere E-Mail-Adresse.
   • Rolle: Administrator.

2. Als neuer Commander einloggen: Verwenden Sie ein privates Browser-Fenster.

3. Den alten Benutzer löschen:

   • Gehen Sie zu Benutzer.
   • Hover über “admin” und klicken Sie auf Löschen.
   • KRITISCHER SCHRITT: WordPress fragt: “Was soll mit Inhalten dieses Benutzers geschehen?”
   • Wählen Sie: “Alle Inhalte zuweisen an:” -> [Wählen Sie Ihren neuen Benutzer].

Benutzerenumeration über REST API blockieren:

// Benutzerenumeration über REST API blockieren
add_filter('rest_endpoints', function($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    return $endpoints;
});

#Teil 2: 2FA und das Lockout-Problem

Ein Passwort allein ist ein Single Point of Failure. Mit 2FA braucht ein Angreifer Passwort plus zweiten Faktor; mit Passkeys (weiter unten) gibt es überhaupt kein geteiltes Geheimnis mehr, das geleakt werden kann.

Was die meisten Anleitungen auslassen, ist der Failure-Mode: Was passiert, wenn der Admin sein Telefon verliert, das Unternehmen verlasst, oder das TOTP-Geheimnis auf einem Gerät eingerichtet wurde, das gewiped wurde. Sie brauchen einen dokumentierten WP-CLI-Notausgang bevor Sie 2FA erzwingen, nicht danach.

# Notfall: 2FA für ausgesperrten Benutzer deaktivieren (Two-Factor / WP 2FA)
wp user meta delete <user_id> _two_factor_enabled_providers
wp user meta delete <user_id> _two_factor_provider
wp user meta delete <user_id> _two_factor_options

# Oder auflisten, was gesetzt ist, um zu wissen, was zu entfernen ist
wp user meta list <user_id> --keys=_two_factor_enabled_providers,_two_factor_provider

Ausführen per SSH am Server. Hat der Admin auch keinen SSH mehr, ist der Recovery-Pfad das Hosting-Panel-Terminal oder eine SQL-Query gegen wp_usermeta. Dokumentieren Sie das, bevor Sie es brauchen. Bei DSGVO-pflichtigen Seiten frisst eine verlorene Stunde Suche ein Drittel der 72-Stunden-Meldefrist.

#Die 2FA-Ebenen

1. SMS-Codes (Veraltet - Nicht verwenden) SMS-basierte 2FA gilt als unsicher. SIM-Swapping-Angriffe ermöglichen es Hackern, Telefonnummern zu kapern.

2. TOTP-Apps (Standard-Sicherheit) Time-based One-Time Password (TOTP)-Apps wie Google Authenticator, Authy oder Ente Auth generieren Codes, die sich alle 30 Sekunden ändern. Diese sind deutlich sicherer, da:

• Codes werden lokal auf Ihrem Gerät generiert
• Keine Netzwerkübertragung des Secrets
• Funktioniert offline

3. Hardware-Sicherheitsschlüssel (Der eiserne Standard) Physische Sicherheitsschlüssel wie YubiKey verwenden Public-Key-Kryptographie für unphishbare Authentifizierung.

#Application Passwords prüfen

WordPress-Core bringt Application Passwords mit (24-Zeichen-Tokens für REST-API- und XML-RPC-Clients). Sie umgehen 2FA per Design. Ich habe diese Tokens in .env-Dateien gefunden, die in öffentliche GitHub-Repos committet wurden, und in Mobile-App-Crashreports in Support-Foren. Quartalsweise prüfen:

wp user application-password list <user_id>
wp user application-password delete <user_id> <uuid>

Wenn Sie die REST-API nicht für authentifizierte Schreibzugriffe nutzen, deaktivieren Sie Application Passwords komplett mit add_filter( 'wp_is_application_passwords_available', '__return_false' ); in einem Mu-Plugin.

#Teil 3: passwortloses Login mit Passkeys

Im Jahr 2026 bewegen wir uns völlig weg von Passwörtern. Passkeys repräsentieren die Zukunft der Authentifizierung und nutzen die Biometrik auf Ihrem Gerät (TouchID, FaceID, Windows Hello).

#Wie Passkeys funktionieren

Passkeys verwenden den WebAuthn-Standard, um kryptographische Schlüsselpaare zu erstellen:

1. Registrierung: Ihr Gerät erstellt einen privaten Schlüssel (sicher gespeichert) und einen öffentlichen Schlüssel (an den Server gesendet)
2. Authentifizierung: Der Server sendet eine Herausforderung; Ihr Gerät signiert sie mit dem privaten Schlüssel
3. Verifizierung: Der Server verifiziert die Signatur mit dem gespeicherten öffentlichen Schlüssel

#Teil 4: Rate-Limiting für wp-login.php und xmlrpc.php

Selbst wenn 2FA die eigentliche Übernahme blockiert, frisst ein nicht rate-limitierter Brute-Force-Angriff PHP-FPM-Worker und MySQL-Verbindungen. Auf Shared Hosting (verbreitet bei kleineren deutschen Mittelständlern) kann das die Seite umlegen, ohne je ein Passwort zu knacken. Sie wollen Rate-Limits in drei Schichten, in dieser Wirksamkeitsreihenfolge: Edge (Cloudflare), Server (Nginx oder fail2ban), Anwendung (Plugin).

#Ebene 0: Cloudflare-Rate-Limiting-Regel

Wenn die Seite hinter Cloudflare lauft (im Free-Plan enthalten), ist das die Regel mit dem höchsten Hebel. Dashboard → Security → WAF → Rate limiting rules:

• Field: URI Path
• Operator: equals
• Value: /wp-login.php
• When: 5 Requests / 1 Minute von derselben IP
• Then: Managed Challenge (oder Block für 1 Stunde)

Eine zweite Regel für /xmlrpc.php hinzufügen, falls aktiviert. Vorteil gegenüber fail2ban: Requests werden am Edge gestoppt, bevor sie das Origin erreichen.

#Ebene 2: das CAPTCHA (Cloudflare Turnstile)

Google reCAPTCHA ist nervig und beeinträchtigt möglicherweise die Zugänglichkeit. Cloudflare Turnstile ist die moderne Alternative.

Warum Cloudflare Turnstile?

• Unsichtbar: Die meisten Benutzer sehen nie eine Herausforderung
• Datenschutzfokussiert: Keine persönlichen Daten an Dritte gesendet
• Zugänglichkeit: Funktioniert mit Screenreadern und assistiven Technologien
• Kostenlos: Großzügige kostenlose Stufe für die meisten Websites

#Ebene 3: Serverebene (Fail2Ban)

Fail2Ban scannt Ihre Server-Logs und sperrt automatisch IP-Adressen, die bösartiges Verhalten zeigen.

Installation auf Ubuntu/Debian:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

WordPress-spezifische Konfiguration:

Eine Feinheit, die die meisten Tutorials falsch machen: Ein fehlgeschlagener wp-login.php-POST liefert HTTP 200 zurück (die Seite re-rendert mit Fehler), ein erfolgreicher liefert 302 (Redirect zu wp-admin). Wer also nur auf 200 matched, fängt sowohl legitime Fehlversuche als auch erfolgreiche Logins ab und sperrt sich selbst aus, wenn er das Passwort dreimal vertippt. Das folgende Pattern kombiniert den 200 mit dem Brute-Force-Volumen über die findtime des Jails:

Erstellen Sie /etc/fail2ban/filter.d/wordpress.conf:

[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php.*" 200
            ^<HOST> .* "POST /xmlrpc\.php.*" 200
ignoreregex = ^<HOST> .* "POST /wp-login\.php.*" 302

Nginx-Konfiguration für Rate Limiting:

# Rate Limit Zone Definition (im http-Block)
limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;

# Auf wp-login.php anwenden
location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

#Teil 5: Login-Monitoring und Benachrichtigungen

Sie können nicht schützen, was Sie nicht sehen können. Verwenden Sie Server-seitige oder externe Protokollüberwachung anstelle von Sicherheits-Plugins:

• Überwachen Sie /var/log/nginx/access.log auf fehlgeschlagene Logins
• Verwenden Sie fail2ban für Benachrichtigungen bei Brute-Force-Mustern
• Rotieren und archivieren Sie Logs mindestens 90 Tage lang

#Teil 6: Incident-Response-Verfahren

Phase 1: Erkennung und Identifizierung

1. Unerwartete Admin-Aktivität erkennen
2. Umfang bewerten: Welche Konten sind kompromittiert?

Phase 2: Eindämmung

1. Alle Admin-Passwörter sofort ändern
2. Alle Benutzer abmelden (WordPress-Sitzungen löschen)
3. Verdächtige IP-Adressen auf Firewall-Ebene blockieren

Phase 3: Beseitigung

1. WordPress-Kerndateien aus offizieller Quelle wiederherstellen
2. Alle Plugins von WordPress.org neu installieren
3. Datenbank auf bösartige Injektionen scannen

Phase 4: Wiederherstellung

1. Aus sauberem Backup wiederherstellen, falls verfügbar
2. Integrität aller wiederhergestellten Dateien überprüfen
3. Website mit verbessertem Monitoring wieder aktivieren

#Teil 7: Benutzerenumeration deaktivieren

Nginx-Methode:

# Autoren-Enumeration blockieren
if ($args ~* "author=([0-9]*)") {
    return 403;
}

# Benutzerenumeration über REST API blockieren
location ~* /wp-json/wp/v2/users {
    deny all;
    return 403;
}

#Teil 8: Hardening an den Rändern

#wp-admin auf bekannte IPs beschränken

Wenn Ihr Team aus einem kleinen Set statischer IPs arbeitet (Büro, VPN), entfernt eine CIDR-Allowlist auf /wp-admin/ die öffentliche Angriffsfläche komplett. Alles außerhalb der Allowlist bekommt 403, bevor WordPress geladen wird. Der Trade-off ist real: reisende Admins, Freelancer im Hotel-WLAN und Notfallzugriff vom Handy sind blockiert. Nur einsetzen, wenn Sie ein dokumentiertes VPN mit verlasslicher Verfügbarkeit haben.

location ^~ /wp-admin/ {
    allow 203.0.113.0/24;     # Büro
    allow 198.51.100.42/32;   # VPN
    deny all;
    # ...bestehende fastcgi-Config
}
location = /wp-login.php {
    allow 203.0.113.0/24;
    allow 198.51.100.42/32;
    deny all;
}

Bei Cloudflare-fronted Seiten geht das mit einer WAF-Custom-Rule auf http.request.uri.path matches "^/wp-(admin|login)" und not ip.src in {203.0.113.0/24}.

#wp-login.php umbenennen

Die Login-URL zu verschieben ist Obscurity, keine Security. Es reduziert dummen Bot-Traffic in den Access-Logs (nützlich fürs Signal-Rauschen-Verhältnis), aber ein gezielter Angreifer scraped sie aus dem Source jeder Seite. Behandeln Sie das als Rauschfilter, niemals als Schicht.

#Dateibearbeitung im Admin deaktivieren

Zwei Konstanten in wp-config.php schließen den häufigsten Post-Compromise-Eskalationspfad: ein Angreifer mit Admin-Zugang bearbeitet Theme-/Plugin-PHP über das Dashboard.

define( 'DISALLOW_FILE_EDIT', true );  // versteckt Design > Theme-Datei-Editor
define( 'DISALLOW_FILE_MODS', true );  // blockiert auch Plugin-/Theme-Install + Updates

DISALLOW_FILE_MODS ist heftig, weil es One-Click-Updates bricht; nur einsetzen, wenn Code per CI deployed wird und Updates per WP-CLI laufen.

#Web Application Firewall

Ein WAF filtert bösartigen Traffic, bevor er die WordPress-Installation erreicht:

• Cloudflare WAF: Free-Tier enthalt Managed Rules für WordPress; Pro-Plan bringt OWASP CRS auf Paranoia Level 1
• ModSecurity + OWASP CRS: Server-Option für selbst gehostete Nginx/Apache-Setups. Mittwald und Raidboxes liefern Profile mit aktivierten Anti-Brute-Force-Regeln vor. Paranoia Level 1 ist die praktische Baseline; PL2+ erzeugt zu viele False Positives bei Gutenberg
• Sucuri: Premium-WAF mit WordPress-spezifischen Virtual Patches

#SSL/TLS für Login-Seiten

Stellen Sie sicher, dass die gesamte Seite HTTPS nutzt, besonders Login-Seiten:

1. SSL-Zertifikat installieren (Let’s Encrypt liefert kostenlose Zertifikate)
2. HTTPS-Redirects in der Webserver-Konfiguration erzwingen
3. HTTP Strict Transport Security (HSTS) aktivieren
4. Sichere Cookies für die WordPress-Authentifizierung verwenden

#Was ich auf einer Kundenseite tatsächlich konfiguriere

Keine generische Posture-Checkliste. Die spezifische Auftragsreihenfolge, die ich beim Hardening eines WordPress-Logins von Grund auf abarbeite:

1. Den Benutzer admin löschen, Inhalte neu zuweisen, nickname und display_name des überlebenden Admins so setzen, dass der Slug nicht den Login verrat.
2. /wp-json/wp/v2/users und ?rest_route=/wp/v2/users für nicht authentifizierte Requests via rest_endpoints-Filter blocken.
3. 2FA für alle Rollen administrator und editor erzwingen, TOTP als Default und ein dokumentiertes wp user meta delete-Recovery-Runbook im Team-Passwortmanager.
4. wp user application-password list für jeden Admin auditieren; alles über 90 Tage alt oder unbekannt löschen.
5. Cloudflare-Rate-Limit-Regel auf /wp-login.php hinzufügen (5/min, Managed Challenge) sowie eine zweite Regel auf /xmlrpc.php, falls nicht komplett geblockt.
6. fail2ban mit dem wp-login-Filter installieren, der 200 (Fehler) von 302 (Erfolg) unterscheidet, damit ausgesperrte Nutzer nicht falschlich gebannt werden.
7. DISALLOW_FILE_EDIT in wp-config.php setzen. DISALLOW_FILE_MODS nur ergänzen, wenn das Team per CI deployed.
8. HTTPS, HSTS mit preload, und Set-Cookie: Secure; HttpOnly; SameSite=Lax für wordpress_logged_in_* erzwingen.
9. Prüfen, dass wp-config.php eindeutige Salts hat (wp config shuffle-salts), der DB-User nur die Privilegien hat, die WordPress braucht (kein GRANT ALL), und der Datenbankzugriff auf localhost gebunden ist.

Login-Sicherheit sind vier oder fünf gestaffelte Kontrollen, nicht eine. Eine Schicht weglassen und die anderen halten noch; drei weglassen und Sie sind zurück bei der reinen Passwort-Abhängigkeit.

Application Passwords, fail2ban-Bann-Zähler und das 2FA-Recovery-Runbook quartalsweise neu auditieren. Bei den meisten Seiten, die ich von anderen Anbietern übernehme, ist eine der drei Sachen verrutscht: ein veraltetes App Password eines Ex-Mitarbeiters, ein fail2ban, das seit 6 Monaten nichts mehr gebannt hat, weil sich der Log-Pfad verschoben hat, oder ein 2FA-Setup, bei dem niemand weiß, wie man es bei toten Admin-Telefonen umgeht. Wenn die Seite unter DSGVO Art. 33 lauft, ist das Runbook nicht optional, sondern Sorgfaltsnachweis.

Erfahren Sie mehr über WordPress-Sicherheitsdienste bei WPPoland. Aktualisiert: 28. Januar 2026