WordPress-Login härten: 2FA, CAPTCHA und Versuchslimit gegen 30 Millionen Bot-Logins

Der WordPress-Login ist das meistangegriffene Element einer Website - nicht weil Angreifer besonders kreativ sind, sondern weil er bei fast allen Installationen unter derselben Adresse erreichbar ist und Millionen Bots rund um die Uhr automatisiert Passwörter ausprobieren. Das Plugin Limit Login Attempts Reloaded dokumentierte in einem Zeitraum von zwölf Monaten über 50 Milliarden blockierte Login-Angriffe auf seinen Nutzern. Hochgerechnet auf eine einzelne Seite bedeutet das: mehrere Millionen Versuche pro Monat sind keine Ausnahme, sondern Normalzustand.

Die gute Nachricht ist, dass sich dieser Angriffsvektor mit konkreten Maßnahmen weitgehend schließen lässt - ohne tiefes Serverwissen, ohne Programmieraufwand und ohne dass sich legitime Nutzer dabei im Weg stehen. In diesem Artikel zeige ich, was ich bei meinen Kunden standardmäßig einrichte und warum die Kombination aus mehreren Schutzschichten entscheidend ist.

Warum der Login so attraktiv für Angreifer ist

WordPress hält weltweit rund 43 Prozent aller Websites am Laufen. Diese Marktdominanz macht es zum bevorzugten Ziel von Botnetzwerken, die keine Schwachstelle in einem bestimmten Plugin suchen, sondern einfach Credentials ausprobieren - tausende pro Stunde, gegen tausende Seiten gleichzeitig. Nach Angaben von Wordfence werden bis zu 190.000 WordPress-Seiten pro Stunde angegriffen.

Das Angriffsmuster ist simpel: Benutzername admin (oder eine Variante davon), dazu eine Liste geleakter Passwörter aus dem Darknet. Credential-Stuffing nennt sich das - und es funktioniert erschreckend oft, weil viele Betreiber das Standard-Passwort beim Setup nicht ernst genug nehmen oder denselben Zugangsdaten auf mehreren Diensten nutzen.

Schritt 1: Den Benutzernamen "admin" abschaffen

Das klingt trivial, ist aber der effektivste Einzelschritt überhaupt. Bots beginnen fast immer mit admin, administrator oder dem Domainnamen als Benutzernamen. Wer einen unvorhersehbaren Benutzernamen verwendet, macht Brute-Force-Angriffe statistisch um Größenordnungen schwieriger.

In einer bestehenden WordPress-Installation legt man einfach einen neuen Administrator-Account mit einem anderen Namen an, überträgt alle Inhalte, und löscht den alten admin-Nutzer. Per WP-CLI geht das in unter einer Minute. Alternativ lässt sich der Anzeigename vom Benutzernamen trennen - der Anzeigename erscheint öffentlich, der Login-Name bleibt verborgen.

Ein Kunde aus Hamburg betrieb seinen WooCommerce-Shop jahrelang mit dem Benutzernamen admin und einem acht Zeichen langen Passwort. Nachdem ich das Wordfence-Log aktiviert hatte, sahen wir innerhalb von 24 Stunden über 4.000 fehlgeschlagene Versuche - ausschließlich gegen diesen Nutzernamen.

Schritt 2: Zwei-Faktor-Authentifizierung für alle privilegierten Konten

Selbst ein starkes Passwort kann geleakt werden - durch einen Datenbreach bei einem anderen Dienst, durch Phishing oder durch Keylogger auf einem kompromittierten Gerät. 2FA macht ein gestohlenes Passwort alleine nutzlos, weil ein zweiter Faktor benötigt wird.

Für WordPress empfehle ich 2FA via TOTP-App (Google Authenticator, Aegis, Authy) über Plugins wie Wordfence (in der kostenlosen Version enthalten) oder WP 2FA von Melapress. SMS-basierte 2FA ist bequemer, aber anfälliger für SIM-Swapping-Angriffe - für kritische Produktionsseiten würde ich immer TOTP bevorzugen.

Wichtig: 2FA nur für privilegierte Rollen zu erzwingen ist ausreichend. Kunden-Accounts in einem WooCommerce-Shop brauchen keine 2FA - das würde die Conversion unnötig belasten.

Schritt 3: Login-Versuche begrenzen

Ohne Begrenzung kann ein Bot unbegrenzt viele Passwörter ausprobieren - WordPress blockiert das von Haus aus nicht. Das Plugin Limit Login Attempts Reloaded (über 2 Millionen aktive Installationen) oder die integrierte Funktion von Wordfence setzen hier eine Grenze.

Meine Standardkonfiguration: 4 erlaubte Versuche, dann 20 Minuten Sperre. Nach einer weiteren Sperre: 24 Stunden. Das reicht, um automatisierte Angriffe zu unterbrechen, ohne legitime Nutzer nachhaltig zu behindern - wer sein Passwort vergessen hat, nutzt den "Passwort vergessen"-Link.

Eine Eigenheit bei LiteSpeed- und Nginx-Hosting (wie auf LH.pl): Manche Hosts liefern dem Plugin nicht die echte IP-Adresse des Clients, sondern die des Proxys. Dann wird der Proxy gesperrt statt der angreifenden IP. Das lässt sich über die Plugin-Einstellungen mit der Option "Trusted IP Origins" korrigieren - dort auf X-Forwarded-For oder CF-Connecting-IP umstellen.

Schritt 4: reCAPTCHA v3 am Login-Formular

reCAPTCHA v3 von Google läuft unsichtbar im Hintergrund. Es beobachtet das Nutzerverhalten auf der Seite und berechnet einen Score zwischen 0 (sehr wahrscheinlich Bot) und 1 (sehr wahrscheinlich Mensch). Ab einem konfigurierbaren Schwellenwert - typisch 0,5 - wird der Login-Versuch abgelehnt.

Der Vorteil gegenüber reCAPTCHA v2 ("Ich bin kein Roboter"): Keine sichtbare Unterbrechung für echte Nutzer. Kein Klick-Test, keine Ampeln oder Fahrräder identifizieren. Das ist besonders im B2B-Umfeld relevant, wo Kunden auf eine seriöse, störungsfreie Login-Erfahrung Wert legen.

Alternativ zu Google reCAPTCHA gibt es Cloudflare Turnstile - datenschutzfreundlicher, da keine Daten an Google gehen, und mit ähnlicher Erkennungsrate. Für Seiten, bei denen Datenschutz besonders im Fokus steht, ist das eine ernstzunehmende Alternative.

Schritt 5: Den /wp-login.php-Pfad schützen

Es gibt zwei Strategien: den Pfad umbenennen oder den Zugriff auf bekannte IPs beschränken. Beide ergänzen sich.

Das Plugin WPS Hide Login ändert die Login-URL auf einen beliebigen Pfad, zum Beispiel /mein-bereich/. Anfragen an /wp-login.php werden mit einem 404-Fehler beantwortet. Das hält die große Masse automatisierter Scanner fern, die auf den Standardpfad abzielen. Kein Allheilmittel - ein entschlossener Angreifer kann die echte URL durch andere Methoden herausfinden - aber als eine Schicht im Gesamtkonzept sinnvoll.

Für Seiten mit festem IP-Bereich (Agentur-Intranet, Unternehmens-Backend) lässt sich /wp-login.php per .htaccess auf bestimmte IP-Adressen beschränken. Das schützt absolut gegen externe Angriffe, ist aber für Seiten mit wechselnden Standorten unpraktisch.

Schritt 6: Rate Limiting auf Serverebene

Wer auf einem VPS oder einem Server mit Nginx- oder LiteSpeed-Konfigurationszugang arbeitet, kann Rate Limiting direkt auf Serverebene konfigurieren. Das greift, bevor PHP oder WordPress überhaupt geladen werden - was bei sehr hohem Angriffsvolumen den Unterschied zwischen einem stabilen Server und einem Absturz ausmachen kann.

Bei Nginx lässt sich mit der limit_req-Direktive definieren, wie viele Anfragen pro Zeiteinheit an /wp-login.php weitergeleitet werden. Eine einfache Konfiguration erlaubt zum Beispiel 5 Anfragen pro Minute und blockt alles darüber mit einem HTTP-429-Status. Das ist kein Ersatz für Plugin-Schutz, aber eine robuste erste Verteidigungslinie.

Besonders relevant wird das, wenn eine Seite unter aktivem Angriff steht: Ohne serverseitiges Rate Limiting werden tausende PHP-Prozesse gestartet, die Datenbank belastet und der Arbeitsspeicher des Servers erschöpft. Das Ergebnis ist eine Seite, die für echte Besucher nicht mehr erreichbar ist - nicht wegen eines erfolgreichen Einbruchs, sondern wegen schlichter Überlastung. Das erlebe ich bei Kunden ohne Schutzmaßnahmen regelmäßig als ersten spürbaren Effekt eines Brute-Force-Angriffs.

Für verwaltete WordPress-Hosting-Umgebungen (Kinsta, Raidboxes, Strato Managed WordPress) ist diese Konfiguration oft bereits serverseitig aktiv oder kann über das Hosting-Dashboard aktiviert werden. Bei Shared-Hosting ohne eigene Server-Konfiguration bleibt das Plugin-basierte Limiting die einzige Option - umso wichtiger, es konsequent zu aktivieren.

Passwort-Richtlinien nicht vergessen

Alle technischen Schutzmaßnahmen helfen wenig, wenn ein Mitarbeiter das Passwort sommer2024 verwendet. Starke Passwörter sind die Grundlage, auf der jede Härtungsmaßnahme aufbaut. WordPress erzwingt keine Passwort-Komplexität von Haus aus - das lässt sich über Plugins oder Coding lösen.

Das Plugin WP Password Policy Manager oder die entsprechende Funktion von Wordfence erlaubt es, Mindestlänge, Sonderzeichen und Ablaufdatum für Passwörter zu erzwingen. Für WooCommerce-Shops mit externen Mitarbeitern (Lagerverwaltung, Kundenservice) ist das kein Luxus, sondern Pflicht. Passwortwechsel alle 90 Tage für privilegierte Konten, kombiniert mit 2FA, schließt die meisten praxisrelevanten Angriffsvektoren.

Was in den Wartungsvertrag gehört

Eine einmalige Härtung ist nicht ausreichend. Angriffsmuster ändern sich, neue IPs kommen hinzu, Plugins erhalten Updates. Wer seine WordPress-Seite dauerhaft sicher betreiben möchte, braucht eine regelmäßige Überprüfung.

In meinen WordPress-Wartungspaketen ist die Login-Sicherheit fester Bestandteil der monatlichen Routine: Wordfence-Logs auf verdächtige IPs prüfen, gesperrte IPs auswerten, Plugins auf aktuelle Sicherheitsupdates prüfen und den 2FA-Status aller privilegierten Konten bestätigen. Dazu kommt das Monitoring auf bekannte Plugin-Schwachstellen per CVE-Feed, weil viele Angriffe nicht über den Login, sondern über anfällige Plugin-Versionen laufen.

Wenn Sie nicht sicher sind, ob Ihre Website bereits Ziel aktiver Angriffe ist: Aktivieren Sie die Login-Log-Funktion von Wordfence und schauen Sie sich nach 24 Stunden die blockierten Versuche an. Bei den meisten meiner Kunden ist das Ergebnis ernüchternd - und überzeugend genug, um sofort mit der Härtung anzufangen.

Im Ernstfall - wenn der Login bereits kompromittiert wurde - hilft dieser Leitfaden weiter: Was tun, wenn WordPress gehackt wurde. Und wenn Sie die Login-Härtung nicht selbst übernehmen möchten, finden Sie auf meiner Seite für WordPress-Dienstleistungen das passende Paket dafür.