Brute-Force-Angriff

Ungewöhnliche Last ohne erkennbaren Grund?

Oft steckt ein Dauerbeschuss der Anmeldeseite dahinter. Wir sehen in die Protokolle und wehren dort ab, wo es die Leistung nicht kostet.

Ein Brute-Force-Angriff ist der Versuch, Zugangsdaten durch systematisches Ausprobieren zu erraten — automatisiert, mit hoher Geschwindigkeit und meist gegen viele Ziele gleichzeitig. Bei WordPress trifft er in aller Regel die Anmeldeseite. Der überwiegende Teil dieser Angriffe ist nicht auf eine bestimmte Website gerichtet, sondern durchsucht das Netz nach Zielen mit schwachen Zugängen.

Kurz zusammengefasst:

• Automatisiert und ungezielt — es trifft jede erreichbare WordPress-Installation.
• Die verbreitete Variante ist der Credential-Stuffing-Angriff mit Daten aus Lecks.
• Wirksamste Gegenmittel: 2FA und einzigartige Passwörter.
• Auch erfolglose Angriffe kosten Serverleistung.
• Benutzernamen sind bei WordPress oft öffentlich ermittelbar.

Die Varianten

Die dritte Zeile ist der eigentliche Grund, warum Passwortwiederverwendung so gefährlich ist. Wenn dieselbe Kombination bei einem beliebigen anderen Dienst abgeflossen ist, wird sie kurz darauf gegen tausende WordPress-Anmeldeseiten getestet — auch gegen deine.

Das Benutzernamen-Problem

Ein Angriff braucht zwei Teile. Den Benutzernamen liefert WordPress erschreckend oft selbst mit: über Autorenarchive unter /author/name/, über die Anzeige des Autors unter Beiträgen, über die REST-Schnittstelle und über ?author=1, das auf die Autorenseite weiterleitet.

Damit bleibt nur noch das Passwort zu erraten. Sinnvolle Gegenmaßnahmen:

• Kein Konto namens „admin“ und kein Konto, das dem Anzeigenamen entspricht.
• Anzeigename vom Anmeldenamen trennen — WordPress erlaubt das.
• Autorenarchive abschalten, wenn sie nicht gebraucht werden.
• Benutzerauflistung über die Schnittstelle einschränken, sofern sie nicht benötigt wird.

Was tatsächlich hilft

1. Zwei-Faktor-Authentifizierung. Das wirksamste Einzelmittel — ein erratenes Passwort allein nützt nichts mehr.
2. Einzigartige, lange Passwörter aus einem Passwortmanager. Länge schlägt Komplexität.
3. Versuche begrenzen. Nach wenigen Fehlversuchen sperren oder verzögern.
4. XML-RPC abschalten, wenn nichts darauf angewiesen ist — dort lassen sich viele Versuche in einer einzigen Anfrage bündeln.
5. Serverseitig abwehren, damit die Anfragen gar nicht erst PHP erreichen. Das schont die Leistung deutlich mehr als eine Abwehr im Plugin.
6. Anmeldeseite absichern — etwa durch eine zusätzliche Zugriffsbeschränkung, wenn nur wenige Personen dort hinmüssen.

Was wenig bringt: die Anmeldeseite bloß umzubenennen. Das hält einfache Suchskripte auf und ist als Ergänzung in Ordnung, aber es ist kein Schutz — nur eine Unbequemlichkeit für Angreifer.

Die Nebenwirkung: Last

Selbst erfolglose Angriffe sind spürbar. Jeder Versuch startet PHP, fragt die Datenbank ab und prüft ein Passwort — absichtlich rechenintensiv. Ein paar tausend Versuche pro Stunde reichen auf kleineren Paketen aus, um die Website spürbar zu verlangsamen.

Deshalb lohnt die Abwehr auf Serverebene doppelt: Sie schützt und sie hält die Ladezeiten stabil. Wer unerklärliche Lastspitzen sieht, sollte zuerst in die Zugriffsprotokolle sehen.

Häufige Fragen

Warum wird meine kleine Website überhaupt angegriffen?

Weil niemand sie ausgesucht hat. Die Angriffe laufen automatisiert gegen alles, was erreichbar ist. Eine gekaperte Website ist als Spamschleuder oder Weiterleitungsziel nützlich — unabhängig davon, wie bekannt sie ist.

Hilft es, die Anmeldeseite umzubenennen?

Ein wenig, gegen einfache Skripte. Es ist aber kein Schutz: Wer gezielt sucht, findet sie. Als Ergänzung sinnvoll, als alleinige Maßnahme nicht.

Wie lang sollte ein Passwort sein?

Länge wirkt stärker als Sonderzeichen. Mindestens 16 Zeichen, für jeden Dienst ein anderes, erzeugt und verwahrt in einem Passwortmanager. Regelmäßiges Wechseln bringt wenig, wenn das Passwort einzigartig und lang ist.

Was ist Credential Stuffing?

Das Ausprobieren echter Zugangsdaten aus fremden Datenlecks. Es ist die erfolgreichste Angriffsvariante — und der Grund, warum dasselbe Passwort bei mehreren Diensten so riskant ist.

Merke ich einen laufenden Angriff?

Meist nur an den Symptomen: langsamere Seite, ungewöhnliche Serverlast, viele fehlgeschlagene Anmeldungen in den Protokollen, gelegentlich Benachrichtigungen eines Sicherheits-Plugins.

Reicht ein Sicherheits-Plugin zur Abwehr?

Es hilft, greift aber erst, wenn die Anfrage WordPress schon erreicht hat — die Last entsteht trotzdem. Wirksamer ist eine Abwehr auf Serverebene, kombiniert mit Zwei-Faktor-Authentifizierung.