WordPress-Login absichern: Schutz vor Brute-Force

Es ist kurz nach sieben, du öffnest den Laptop, und im Postfach liegt eine Mail deines Monitorings: Über Nacht wurden auf der Seite eines Kunden mehr als vierhundert fehlgeschlagene Anmeldeversuche registriert, verteilt auf Dutzende IP-Adressen aus aller Welt. Niemand hat versucht, sich als Mensch einzuloggen. Das war ein Bot, der stur Benutzernamen und Passwörter durchprobiert hat – und er kommt heute Nacht wieder. Die eigentliche Frage ist nicht, ob solche Angriffe passieren, sondern ob die Seite darauf vorbereitet ist.

Für Agenturen, die viele WordPress-Seiten betreuen, ist das keine Ausnahme, sondern der Normalzustand. Der Login ist die am häufigsten angegriffene Tür einer jeden Website, und sie steht bei einer WordPress-Standardinstallation an einer bekannten Stelle. Wer diese Tür nicht absichert, verlässt sich allein auf die Passwortdisziplin seiner Kunden – und die ist erfahrungsgemäß dünn.

WordPress-Login absichern: Wo die Angriffe ansetzen

Um zu verstehen, warum der Login so exponiert ist, hilft ein Blick auf die Zahlen. Der Sicherheitsdienstleister Wordfence blockierte laut seinem 2024 Annual WordPress Security Report im Jahr 2024 über 55 Milliarden Passwort-Angriffe, die von rund 136 Millionen verschiedenen IP-Adressen ausgingen. Das ist keine gezielte Verschwörung gegen einen bestimmten Kunden, sondern industrielles Ausprobieren im großen Maßstab: Bots scannen das halbe Netz nach WordPress-Installationen und werfen bekannte Zugangsdaten dagegen.

Warum lohnt sich das für die Angreifer? Weil gestohlene und schwache Zugangsdaten der mit Abstand erfolgreichste Weg ins System sind. Der Verizon Data Breach Investigations Report 2025 nennt kompromittierte Anmeldedaten den häufigsten ersten Einstiegspunkt für Sicherheitsverletzungen überhaupt; bei einfachen Webanwendungen waren 88 Prozent der Angriffe mit gestohlenen Zugangsdaten verbunden. Ein Angreifer muss selten eine ausgefeilte Lücke finden – oft genügt es, sich einzuloggen.

Zwei Angriffsmuster musst du dabei auseinanderhalten. Beim klassischen Brute-Force-Angriff probiert der Bot massenhaft Kombinationen durch, bevorzugt gegen den Standardnutzer und schwache Passwörter. Beim Credential Stuffing verwendet er dagegen echte Zugangsdaten, die bei anderen Diensten geleakt wurden, und setzt darauf, dass dein Kunde dasselbe Passwort mehrfach nutzt. Gegen das erste Muster hilft, das Ausprobieren zu bremsen. Gegen das zweite hilft nur, dass ein geknacktes Passwort allein nicht mehr genügt.

Die zwei Standardadressen, die jeder Bot kennt

WordPress liefert den Login-Bereich immer an denselben Pfaden aus: /wp-login.php und /wp-admin. Jeder Bot kennt sie. Das ist der Grund, warum eine frische Installation binnen Stunden die ersten Anmeldeversuche sieht, auch wenn die Domain noch nirgends verlinkt ist. Diese Vorhersagbarkeit ist Teil des Problems – und ein Ansatzpunkt für die Verteidigung.

Die wirksamsten Hebel, der Reihe nach

Sicherheit am Login ist kein einzelner Schalter, sondern eine Kette. Fang mit dem an, was am meisten bringt.

Der stärkste Hebel ist die Zwei-Faktor-Authentifizierung für alle Konten mit Schreibrechten, also Administratoren und Redakteure. Sie sorgt dafür, dass ein erratenes oder geleaktes Passwort ins Leere läuft, weil der zweite Faktor fehlt – meist ein zeitbasierter Code aus einer App. Das entwertet sowohl Brute-Force als auch Credential Stuffing auf einen Schlag. Für Kundenprojekte ist das die Maßnahme mit dem besten Verhältnis von Aufwand und Wirkung, und sie sollte nicht optional sein. Der nächste Schritt in dieselbe Richtung sind Passkeys, die das Passwort ganz ersetzen; warum die passwortlose Anmeldung langsam zum Standard wird, haben wir gesondert beleuchtet.

In der Praxis stößt du bei der Einführung der Zwei-Faktor-Authentifizierung manchmal auf Widerstand: Kunden empfinden den zweiten Schritt als lästig. Dem begegnest du am besten, indem du die Einrichtung selbst übernimmst, Wiederherstellungscodes sicher hinterlegst und erklärst, dass genau diese kleine Hürde den Unterschied macht, wenn ein Passwort einmal irgendwo geleakt ist. Ein Faktor mehr beim eigenen Login wiegt leicht gegen einen kompromittierten Kundenauftritt, für den am Ende die Agentur geradestehen soll.

Der zweite Hebel ist, die Zahl der Anmeldeversuche zu begrenzen. Nach einigen Fehlversuchen wird die betreffende IP-Adresse für eine Weile gesperrt, und du wirst bei auffälligem Verhalten benachrichtigt. Das macht das stumpfe Durchprobieren unwirtschaftlich, weil der Bot pro IP nur noch eine Handvoll Versuche hat. Kombiniert mit einer Sperre auf Serverebene – etwa über fail2ban – bremst das automatisierte Kampagnen erheblich aus.

Der dritte Hebel betrifft die Zugangsdaten selbst. Der Benutzername „admin" gehört abgeschafft, weil er dem Bot die Hälfte der Arbeit erspart. Passwörter müssen lang, einzigartig und pro Seite verschieden sein – und genau hier liegt für Agenturen ein eigenes Risiko, weil sie Dutzende Kundenzugänge verwalten. Wie du diese sauber und ohne Excel-Chaos organisierst, steht im Beitrag über den Passwort-Manager für Agenturen.

XML-RPC: die vergessene Hintertür

Ein Punkt, der bei der Login-Absicherung gern übersehen wird, ist die Schnittstelle XML-RPC unter xmlrpc.php. Sie wird von manchen älteren Apps, von bestimmten Jetpack-Funktionen und von externen Diensten genutzt – ist aber zugleich ein beliebtes Ziel, weil sich über sie Anmeldeversuche bündeln und Sperren am normalen Login umgehen lassen. Braucht die Seite XML-RPC nicht, solltest du den Zugriff einschränken oder ganz abschalten. Prüfe das aber vorher, denn manche Anbindungen hängen daran; eine blinde Deaktivierung kann eine funktionierende Integration lahmlegen. Im Zweifel schränkst du den Zugriff auf die benötigten Methoden ein, statt die Schnittstelle komplett zu schließen.

Ergänzend lässt sich der Admin-Bereich auf Serverebene zusätzlich abschotten – über IP-Beschränkungen, wenn der Kunde nur aus festen Netzen arbeitet, oder über einen vorgeschalteten Passwortschutz per HTTP-Authentifizierung. Das ist nicht für jede Seite nötig, aber für sensible Projekte eine wirksame zweite Mauer vor der eigentlichen Anmeldung. In dieselbe Kategorie der stillen, kostenlosen Verstärkung gehören die HTTP-Security-Header, die eine Seite an anderer Stelle härter machen.

Warum der Login nur der Anfang ist

So wichtig die Anmeldung ist – sie ist nicht der einzige Weg hinein. Wordfence weist darauf hin, dass in der eigenen Praxis kompromittierte Zugangsdaten des Hosting-Kontos häufig der eigentliche Einstieg sind, nicht der WordPress-Login selbst. Das heißt: Auch der Zugang zu Server, FTP und Hosting-Panel gehört mit derselben Sorgfalt gesichert wie das wp-admin. Ein perfekt abgesicherter WordPress-Login nützt wenig, wenn das FTP-Passwort seit Jahren dasselbe ist.

Und selbst die stärkste Login-Absicherung ersetzt nicht die laufende Pflege. Ein großer Teil der erfolgreichen Einbrüche läuft nicht über den Login, sondern über veraltete Plugins mit bekannten Lücken – ein Thema, das wir bei der WordPress-Wartung als Agentur-Standbein ausführlich behandelt haben. Login-Härtung und Update-Disziplin sind zwei Seiten derselben Medaille. Und wenn es trotz allem passiert, entscheidet ein vorbereiteter Notfallplan für gehackte WordPress-Seiten darüber, wie teuer der Vorfall wird.

Ein übernommenes Konto ist dabei nicht nur ein technisches Problem. Verschafft sich ein Angreifer über den Login Zugriff auf personenbezogene Daten – Kundenkonten, Bestellungen, Formulareinträge –, kann daraus schnell eine meldepflichtige Datenpanne werden, für die enge Fristen gelten. Wie der 72-Stunden-Notfallplan bei einer Datenpanne aussieht, ist ein eigenes Kapitel; für die Login-Absicherung genügt der Merksatz, dass ein verhinderter Einbruch auch eine verhinderte Meldepflicht ist.

Aus der Absicherung wird ein Standbein

Für kleine Agenturen liegt hier derselbe Hebel wie bei so vielen Wartungsthemen: aus einer technischen Notwendigkeit ein planbares Angebot zu formen. Geh deinen betreuten Bestand einmal systematisch durch und dokumentiere pro Seite, ob 2FA aktiv ist, ob Login-Versuche begrenzt werden, ob der Admin-Nutzer noch „admin" heißt und ob XML-RPC gebraucht wird. Aus dieser Bestandsaufnahme wird ein „Login-Härtungs-Check", den du einmal einrichtest und danach im Rahmen der Wartung überwachst.

Das Schöne daran ist, dass die Wirkung für den Kunden greifbar bleibt, ohne dass etwas Sichtbares passiert – im Idealfall merkt niemand je etwas, weil der nächtliche Bot einfach abprallt. Genau das ist der Wert: nicht das Aufräumen nach dem Einbruch, sondern der Einbruch, der nie stattfindet. Die Zahlen zeigen unmissverständlich, dass die Angriffe kommen. Ob sie ins Leere laufen, entscheidest du, bevor die erste Mail des Monitorings im Postfach liegt.