So verhindern Sie Brute-Force-Angriffe in WordPress (9 Schutzschichten)
John Turner
John Turner
Wenn Ihre WordPress-Website live ist, wird sie wahrscheinlich gerade angegriffen.
Automatisierte Bots scannen das Internet kontinuierlich und testen /wp-login.php auf jeder gefundenen WordPress-Website. Sie versuchen zuerst „admin“-Logins, dann eine Liste der gängigsten Passwörter.
Eine Website ohne Schutz wird täglich Hunderte dieser Versuche ausgesetzt, lautlos und ohne sichtbares Zeichen.
Was noch schlimmer ist: Fehlgeschlagene Angriffe sind nicht kostenlos. Jeder Login-Versuch startet einen PHP-Prozess auf Ihrem Server.
Genug gleichzeitige Versuche und Ihr Hosting-Plan stößt an seine Grenzen.
Echte Besucher erleben langsame Ladezeiten oder Fehlerseiten. Einige Hoster drosseln Ihr Konto automatisch. Dies geschieht auch dann, wenn keine Angreifer eindringen.
Ein erfolgreicher Angriff ist ein anderes Problem. Voller Admin-Zugriff bedeutet Inhaltsänderungen, Malware, die in Ihre Theme-Dateien injiziert wird, erstellte Backdoor-Konten, SEO-Spam, der in Ihre Beiträge eingebettet ist, oder offengelegte Kundendaten.
Die Wiederherstellung nach einem erfolgreichen Einbruch dauert bestenfalls Stunden; Tage, wenn Sie kein sauberes Backup haben.
In diesem Beitrag zeige ich Ihnen die besten Möglichkeiten, Ihre Website vor Brute-Force-Angriffen zu schützen.
Hier sind die wichtigsten Erkenntnisse:
- Selbst fehlgeschlagene Brute-Force-Angriffe schaden Ihrer Website. Sie erschöpfen PHP-Worker, verlangsamen die Ladezeiten und können das Drosseln des Hostings auslösen, bevor ein einziges Passwort richtig erraten wurde.
- Credential Stuffing ist nicht dasselbe wie Brute Force. Angreifer verwenden echte, geleakte Passwörter aus anderen Datenlecks, was bedeutet, dass ein starkes Passwort allein nicht ausreicht, wenn Ihre Benutzer Anmeldedaten wiederverwenden.
- WordPress hat keinen integrierten Schutz vor Brute-Force-Angriffen. Login-Drosselung, 2FA und WAF-Funktionalität erfordern alle ein Plugin oder eine Serverkonfiguration.
- Zwei-Faktor-Authentifizierung ist der Schritt mit dem höchsten Ertrag auf dieser Liste. Sie stoppt sowohl Brute-Force- als auch Credential-Stuffing-Angriffe, selbst wenn ein Passwort korrekt ist.
- Die system.multicall-Methode von XML-RPC umgeht die meisten Schutzmaßnahmen der Login-Seite. Das Deaktivieren schließt eine separate Angriffsfläche, die von Rate-Limiting-Plugins nicht abgedeckt wird.
- Das Ändern Ihrer Login-URL reduziert das Angriffsvolumen, ist aber keine primäre Verteidigung. Betrachten Sie es als Reibung, nicht als Schutz.
- Ein Backup, das Sie noch nie wiederhergestellt haben, ist ein Backup, das Sie eigentlich nicht haben. Testen Sie Ihren Wiederherstellungsprozess vierteljährlich, bevor Sie ihn unter Druck benötigen.
- Mehr Sicherheit-Plugins bedeuten nicht mehr Sicherheit. Ein gut konfiguriertes Plugin schlägt vier teilweise konfigurierte, die Konflikte und Overhead verursachen können.
Inhaltsverzeichnis
- Was ist ein Brute-Force-Angriff?
- Wie man Brute-Force-Angriffe in WordPress verhindert
- Ebene 1: Beginnen Sie mit Ihren Anmeldedaten
- Ebene 2: Begrenzen Sie Login-Versuche
- Ebene 3: Ändern Sie die Standard-Login-URL
- Ebene 4: Fügen Sie dem Login-Formular ein CAPTCHA hinzu
- Ebene 5: Deaktivieren oder beschränken Sie XML-RPC
- Ebene 6: Verwenden Sie eine Web Application Firewall
- Ebene 7: Härtung auf Server-Ebene
- Ebene 8: Halten Sie WordPress, Plugins und Themes aktuell
- Ebene 9: Sichern Sie Ihre Website und wissen Sie, wie Sie sie wiederherstellen
- Ebene 1: Beginnen Sie mit Ihren Anmeldedaten
- Wie man Brute-Force-Aktivitäten überwacht
- Was nicht funktioniert (und warum Leute es immer noch empfehlen)
- Häufig gestellte Fragen (FAQs)
- Stellen Sie vor dem nächsten Angriff sicher, dass Sie sich davon erholen können.
Was ist ein Brute-Force-Angriff?
Die meisten Leute stellen sich einen Brute-Force-Angriff als einen Bot vor, der zufällige Passwörter durchprobiert, bis eines funktioniert. Das passiert, aber es ist nicht die einzige Version dieses Angriffs, und es ist nicht einmal mehr die häufigste.
Klassische Brute-Force-Angriffe vs. Credential Stuffing
Klassische Brute-Force-Angriffe finden statt, wenn eine automatisierte Software jede mögliche Zeichenkombination ausprobiert, bis sie ein funktionierendes Passwort findet.
Gegen ein langes, zufälliges Passwort ist dies unpraktisch. Ein 16-stelliges zufälliges Passwort würde länger dauern, um es per Brute-Force zu knacken, als die Sonne noch brennen wird.
Credential Stuffing ist anders und gefährlicher.
Angreifer kaufen oder laden kompromittierte Datenbanken von anderen Datenlecks herunter: E-Mail-Adressen, gepaart mit Passwörtern von kompromittierten Diensten. Dann testen sie diese Paare auf WordPress-Websites.
Wenn einer Ihrer Benutzer sich mit derselben E-Mail-Adresse und demselben Passwort angemeldet hat, das er überall sonst verwendet, könnte Credential Stuffing Zugriff auf sie erhalten und sich beim ersten Versuch anmelden.
Deshalb schützt „Ich habe ein starkes Passwort“ Ihre Benutzer nicht vollständig. Ihr Passwort mag stark sein. Das ihrer Benutzer möglicherweise nicht.
Wörterbuchangriffe liegen dazwischen. Anstatt jeder möglichen Kombination testen sie eine kuratierte Liste gängiger Passwörter, bekannter Muster und Variationen von echten Wörtern. Schneller als echter Brute-Force, gezielter als zufälliges Raten.
Der XML-RPC-Multiplikator
WordPress enthält eine Datei namens xmlrpc.php, die ursprünglich für die Fernveröffentlichung und API-Integrationen entwickelt wurde. Sie akzeptiert eine Methode namens system.multicall, die es einer einzigen HTTP-Anfrage ermöglicht, Tausende von Benutzername/Passwort-Kombinationen in einem einzigen Aufruf zu testen.
Das ist wichtig, weil die meisten Plugins zur Anmeldebeschränkung /wp-login.php überwachen. Ein Bot, der xmlrpc.php verwendet, umgeht diesen Schutz vollständig. Die Begrenzung der Anmeldeseite, während XML-RPC offen bleibt, ist wie das Abschließen Ihrer Haustür und das Offenlassen des Fensters.
Wenn Sie XML-RPC nicht verwenden, ist das Schließen einer der Schritte mit dem höchsten Ertrag auf dieser Liste. Ebene 5 behandelt genau, wie.
Was Sie selbst ein fehlgeschlagener Angriff kostet
Ein Brute-Force-Angriff, der nie ein einziges korrektes Passwort errät, kostet Sie trotzdem etwas Reales.
Jeder Anmeldeversuch ist eine HTTP-Anfrage. Jede Anfrage startet einen PHP-Prozess. Auf Shared Hosting kommt Ihr Plan mit einer begrenzten Anzahl gleichzeitiger PHP-Worker.
Ein Angriff mit hohem Volumen füllt diese Worker mit Anmeldeversuchen anstelle der Bedienung Ihrer tatsächlichen Besucher. Das Ergebnis sind langsame Ladezeiten, Timeouts und in schweren Fällen eine vorübergehende Hosting-Sperre, die Sie nicht kommen sahen.
Es begräbt auch legitime Sicherheitsereignisse in Log-Rauschen. Wenn ein Angreifer es schließlich schafft, sind die fehlgeschlagenen Anmeldeversuche, die ungewöhnliche Aktivitäten gemeldet hätten, bereits mit Tausenden von Einträgen gefüllt. Sie suchen eine Nadel im Heuhaufen.
Schutz auf Plugin-Ebene reduziert den Schaden. Schutz auf Server- und Edge-Ebene eliminiert ihn. Das ist der Hauptgrund, warum dieser Leitfaden als Ebenen und nicht als Liste strukturiert ist.
Wie man Brute-Force-Angriffe in WordPress verhindert
Es gibt keine einzelne Einstellung, die Ihre Website immun macht. Was funktioniert, sind Schichten: Jede fängt auf, was die vorherige verpasst.
Ihre Anmeldedaten stoppen die meisten automatisierten Bots. Ratenbegrenzung stoppt diejenigen, die durchkommen. Eine WAF stoppt das Volumen, bevor es Ihren Server erreicht. Backups decken das Szenario ab, in dem alles andere fehlschlägt.
Die folgenden Schichten sind nach Auswirkung und Implementierungsaufwand geordnet. Beginnen Sie oben. Gehen Sie so weit, wie es Ihr Hosting-Setup zulässt. Selbst die ersten drei Schichten reduzieren Ihre Angriffsfläche dramatisch.
Hier ist, was zu tun ist:
- Schicht 1: Anmeldedaten: Ändern Sie den Standard-Admin-Benutzernamen, verwenden Sie eindeutige Passwörter für jedes Konto und aktivieren Sie die Zwei-Faktor-Authentifizierung für alle Administratoren.
- Schicht 2: Anmeldeversuche begrenzen: Drosseln Sie fehlgeschlagene Anmeldeversuche über ein Plugin oder, für stärkeren Schutz, über Cloudflare oder eine Ratenbegrenzung auf Serverebene.
- Schicht 3: Standard-Anmelde-URL ändern: Verschiebt die Adresse, die die meisten Bots anvisieren, und reduziert das Volumen automatisierter Angriffe auf Ihr Anmeldeformular.
- Schicht 4: CAPTCHA hinzufügen: Filtert automatisierte Bot-Übermittlungen im Anmeldeformular; am effektivsten in Kombination mit Ratenbegrenzung, nicht allein verwendet.
- Schicht 5: XML-RPC deaktivieren oder einschränken: Schließt eine separate Angriffsfläche, die es Angreifern ermöglicht, Tausende von Passwörtern in einer einzigen HTTP-Anfrage zu testen und so die Abwehrmaßnahmen der Anmeldeseite zu umgehen.
- Schicht 6: Web Application Firewall: Blockiert bösartigen Datenverkehr und bekannte schlechte IPs, bevor sie Ihre Anmeldeseite erreichen; Edge-WAFs wie Cloudflare verhindern Ressourcenerschöpfung bei Angriffen mit hohem Volumen.
- Schicht 7: Härtung auf Serverebene: Beschränken Sie wp-login.php nach IP, implementieren Sie Fail2ban und verwenden Sie SFTP mit SSH-Schlüsselauthentifizierung; für Besitzer von VPS und dedizierten Servern.
- Schicht 8: Alles aktuell halten: Patches die Schwachstellen, die Angreifer ausnutzen, um Fuß zu fassen, bevor sie sich mit Brute-Force tiefer hineinarbeiten.
- Schicht 9: Sichern Sie Ihre Website: Die letzte Verteidigungsschicht; ein getestetes Offsite-Backup mit einem funktionierenden Wiederherstellungspfad ist die einzige Garantie dafür, dass ein erfolgreicher Angriff Ihre Website nicht beendet.
Ebene 1: Beginnen Sie mit Ihren Anmeldedaten
Jedes automatisierte Brute-Force-Tool beginnt mit dem Benutzernamen „admin“ und den gängigsten Passwörtern. Das Entfernen beider von Ihrer Website dauert vielleicht fünf Minuten und eliminiert sofort die Mehrheit der automatisierten Angriffsversuche.
Es ist keine vollständige Verteidigung, aber es ist die schnellste Rendite für Ihre Zeit, die Sie in diesem Leitfaden finden werden.
Verwenden Sie einen nicht standardmäßigen Admin-Benutzernamen
Als WordPress zum ersten Mal auf Ihrer Website installiert wurde, wurde „admin“ als Standardbenutzername vorgeschlagen. Viele Websites ändern ihn nie. Angreifer wissen das, und jedes Brute-Force-Tool beginnt dort.
Die Verwendung eines anderen Benutzernamens zwingt einen Angreifer, zwei Unbekannte statt einer zu erraten. Das ist keine dramatische Verbesserung gegenüber einem ausgeklügelten gezielten Angriff, aber es eliminiert die überwiegende Mehrheit der automatisierten Bots, die nie über die „admin“-Vermutung hinauskommen.
Um Ihren aktuellen Benutzernamen zu überprüfen, gehen Sie in wp-admin zu Benutzer » Profil. Das Feld Benutzername befindet sich in den Namen-Einstellungen.

WordPress erlaubt Ihnen nicht, Ihren Benutzernamen direkt zu ändern, aber Sie können ein neues Administratorkonto mit einem anderen Benutzernamen erstellen, die Eigentümerschaft Ihrer Inhalte übertragen und das alte „admin“-Konto löschen.
WP-CLI-Benutzer können dies mit einem Befehl tun:
wp user update 1 --user_login=yourname
Verwenden Sie starke, eindeutige Passwörter für jedes Konto
Jedes Administratorkonto auf Ihrer Website benötigt sein eigenes, eindeutiges Passwort.
Credential Stuffing funktioniert, indem bekannte Benutzername/Passwort-Kombinationen aus anderen Datenlecks getestet werden. Wenn ein Benutzer sein E-Mail-Passwort seitenübergreifend wiederverwendet hat und dieses Passwort woanders durchgesickert ist, könnte Credential Stuffing beim ersten Versuch eine Anmeldung ermöglichen.
WordPress verfügt über eine integrierte Passwortstärkeanzeige, die schwache Passwörter auf dem Profilbildschirm kennzeichnet. Das verhindert die schlechtesten Entscheidungen, erzwingt aber keine Mindestlänge und verhindert keine Wiederverwendung.

Für mehr Kontrolle ermöglicht Ihnen Password Policy Manager, siteweite Passwortanforderungen festzulegen und erzwungene Zurücksetzungen für Konten durchzuführen, die diese nicht erfüllen.
Zwei-Faktor-Authentifizierung aktivieren
Wenn 2FA aktiviert ist, reicht ein korrektes Passwort nicht aus, um sich anzumelden. Der Angreifer benötigt außerdem einen zeitlich begrenzten Code von einem physischen Gerät, das er nicht hat.
Das stoppt klassische Brute-Force-, Credential-Stuffing- und Wörterbuchangriffe. Selbst wenn ein Angreifer Ihr exaktes Passwort aus einem Datenleck hat, kann er sich ohne den zweiten Faktor nicht anmelden.
WordPress Core enthält keine 2FA. Sie benötigen ein Plugin.
WP 2FA ist kostenlos, aktiv gepflegt und einfach zu konfigurieren. Es unterstützt Authentifizierungs-Apps wie Google Authenticator, Authy und 1Password.

miniOrange 2FA und das Two Factor Plugin sind weitere weit verbreitete Optionen mit zusätzlicher Konfigurationsflexibilität.
Passkeys sind die neuere Alternative. Sie verwenden den WebAuthn-Standard und sind von Natur aus phishing-resistent: Es gibt keinen abzufangenden Code, kein SMS-SIM-Swapping und keine zu kompromittierende Authentifizierungs-App. Die Plugin-Unterstützung reift noch, aber wenn Ihr Setup es unterstützt, sind Passkeys eine Überlegung wert.
Wenden Sie 2FA auf jedes Administratorkonto auf der Website an. Nicht nur auf Ihres. Ein ungeschütztes Admin-Konto ist alles, was ein Angreifer braucht.
Ebene 2: Begrenzen Sie Login-Versuche
Standardmäßig erlaubt WordPress unbegrenzte Anmeldeversuche. Ein Bot kann zehntausend Passwörter ausprobieren, während Sie Kaffee kochen.
Rate-Limiting unterbindet dies nach einer Handvoll Versuchen und sperrt die betreffende IP, bevor sie auch nur in die Nähe einer korrekten Anmeldeinformation gelangt.
Plugin-basiertes Login-Throttling
Login-Throttling-Plugins funktionieren, indem sie fehlgeschlagene Versuche pro IP-Adresse verfolgen. Nach einer bestimmten Anzahl von Fehlern blockiert das Plugin diese IP für einen definierten Zeitraum. Der Bot des Angreifers zieht weiter.
Limit Login Attempts Reloaded ist die am weitesten verbreitete kostenlose Option mit einer einfachen Konfigurationsseite und ohne Bloat.

Wordfence beinhaltet Throttling als Teil seines breiteren Funktionsumfangs, was es zu einer Überlegung macht, wenn Sie ein einzelnes Plugin wünschen, das mehrere Sicherheitsebenen abdeckt.
Für die meisten Websites sind 5-10 fehlgeschlagene Versuche vor einer temporären Sperrung ein vernünftiger Ausgangspunkt.
Niedrigere Schwellenwerte erhöhen die Sicherheit, können aber zu Problemen im Support führen. Unternehmensbüros, Universitäten und Mobilfunknetze teilen sich oft eine einzige IP-Adresse für Hunderte von Benutzern. Wenn eine Person ihr Passwort dreimal falsch eingibt, werden alle anderen ausgesperrt.
Testen Sie Ihre Schwellenwerte anhand der tatsächlichen Anmeldungen Ihrer Benutzer.
Eine Einschränkung, die es wert ist, zu kennen: Plugins auf Anwendungsebene rufen bei jeder von ihnen verarbeiteten Anfrage immer noch PHP auf. Bei einem wirklich hochvolumigen Angriff empfängt Ihr Server immer noch den gesamten Datenverkehr.
Das Plugin hindert den Angreifer am Erfolg, aber es stoppt nicht den Ressourcenverbrauch. Darum geht es im nächsten Abschnitt.
Wann Sie den Schutz nach oben im Stack verschieben sollten
Cloudflares kostenloser Tarif ermöglicht es Ihnen, benutzerdefinierte Ratenbegrenzungsregeln zu erstellen, die speziell auf /wp-login.php und /xmlrpc.php abzielen.
Der Datenverkehr wird am Edge von Cloudflare gefiltert, bevor er Ihren Server erreicht. Ihre PHP-Worker bleiben für tatsächliche Besucher frei.
Dies ist das am einfachsten zugängliche Upgrade vom Schutz auf Plugin-Ebene und es kostet nichts.
Ebene 3: Ändern Sie die Standard-Login-URL
Die meisten automatisierten Bots zielen auf /wp-login.php ab, da WordPress dort standardmäßig das Anmeldeformular platziert. Wenn Sie es zu einer benutzerdefinierten URL verschieben, finden die meisten Bots es nie. Sie stoßen auf eine 404, markieren Ihre Website als Sackgasse und ziehen weiter.
Dies ist eine Reibungsschicht, keine primäre Verteidigung. Ein entschlossener Angreifer, der speziell Ihre Website ins Visier nimmt, kann eine benutzerdefinierte Anmelde-URL auf andere Weise finden.
Aber die Reduzierung des automatisierten Angriffsaufkommens hat einen echten Wert:
- Weniger fehlgeschlagene Anmeldeversuche
- Weniger Rauschen im Aktivitätsprotokoll
- Weniger PHP-Prozess-Overhead durch Drosselungs-Plugins, die tote Anfragen verarbeiten
Das Hauptrisiko besteht darin, die URL zu verlieren. Wenn Sie Ihren benutzerdefinierten Anmelde-Pfad vergessen und Ihr Hoster keinen Notfall-Zugriff auf wp-admin bietet, sind Sie von Ihrer eigenen Website ausgesperrt.
Bevor Sie diese Änderung vornehmen, speichern Sie die benutzerdefinierte URL in Ihrem Passwort-Manager und bestätigen Sie die Notfallzugriffsmethode Ihres Hosters. Einige Hoster bieten phpMyAdmin-Zugriff oder eine vom Support unterstützte Zurücksetzung der Anmeldung.
WPS Hide Login erledigt dies mit minimaler Konfiguration: Installieren Sie es, legen Sie Ihren benutzerdefinierten Pfad fest und speichern Sie.

Eine Ergänzung, die diesen Schritt effektiver macht: Erstellen Sie eine Cloudflare-Regel, die auf dem ursprünglichen /wp-login.php-Pfad eine 403 zurückgibt, nachdem Sie ihn verschoben haben.
Ohne diese Regel existiert die alte URL weiterhin und antwortet, was bedeutet, dass ein persistenter Scanner sie immer noch finden kann, indem er gängige Pfade abfragt. Das Blockieren der alten URL am Edge schließt diese Lücke.
Ebene 4: Fügen Sie dem Login-Formular ein CAPTCHA hinzu
CAPTCHA stoppt automatisierte Bots daran, Anmeldeformulare abzusenden, indem es den Nachweis menschlicher Interaktion erfordert. Ein Skript, das Ihre Anmeldeseite Tausende Male pro Stunde aufruft, kann eine visuelle oder verhaltensbezogene Herausforderung nicht so lösen wie ein Mensch.
Für die meisten Websites reduziert das Hinzufügen von CAPTCHA zum Anmeldeformular das Volumen automatisierter Einreichungen erheblich.
Beachten Sie, dass es nicht unschlagbar ist. Es gibt CAPTCHA-Lösungsdienste: echte Menschen, die Bruchteile eines Cents dafür bezahlt bekommen, Herausforderungen im großen Stil zu lösen, oder maschinelle Lernmodelle, die darauf trainiert sind, ältere CAPTCHA-Formate zu knacken.
Gegen einen gezielten, gut ausgestatteten Angreifer ist CAPTCHA ein Geschwindigkeitshemmnis. Gegen die automatisierten Bots, die für die überwiegende Mehrheit des Brute-Force-Traffics verantwortlich sind, ist es effektiv.
Die drei in Betracht zu ziehenden Optionen verfolgen jeweils einen anderen Ansatz.
- Google reCAPTCHA v3 läuft unsichtbar im Hintergrund, bewertet das Nutzerverhalten und kennzeichnet verdächtige Anfragen, ohne dass die Nutzer etwas tun müssen.
- hCaptcha verfolgt eine datenschutzorientierte Haltung und ist eine direkte Drop-in-Alternative.
- Cloudflare Turnstile ist kostenlos, für die meisten Benutzer reibungslos und sendet keine Verhaltensdaten an Google.
Von den dreien ist Turnstile meine aktuelle Empfehlung für neue Setups. Die Datenschutzkompromisse sind besser und die Benutzererfahrung ist sauberer.
Wordfence enthält CAPTCHA-Optionen. Wenn Sie es bereits verwenden, prüfen Sie, ob das integrierte CAPTCHA Ihr Anmeldeformular abdeckt, bevor Sie ein separates Plugin hinzufügen.
Ebene 5: Deaktivieren oder beschränken Sie XML-RPC
XML-RPC war die ursprüngliche Remote-Publishing-API von WordPress, die für eine Zeit entwickelt wurde, bevor die REST-API existierte. Die meisten Websites verwenden sie nicht mehr. Wenn sie aktiviert bleibt, gibt sie Angreifern eine separate Angriffsfläche, die die meisten der bisher eingerichteten Anmeldeseiten-Abwehrmaßnahmen umgeht.
Xmlrpc.php akzeptiert eine Methode namens system.multicall, die Tausende von Anmeldeversuchen in einer einzigen HTTP-Anfrage bündelt.
Ein Ratenbegrenzungs-Plugin, das /wp-login.php überwacht, wird dies nicht sehen. Ihr CAPTCHA wird nicht ausgelöst. Der Angriff landet unter Ihren Abwehrmaßnahmen, da er auf eine andere Tür abzielt.
Bevor Sie es deaktivieren, prüfen Sie, ob Sie es tatsächlich verwenden. Jetpack verbindet sich über XML-RPC mit WordPress.com. Einige ältere mobile Publishing-Workflows hängen davon ab.
Wenn Sie Jetpack nicht verwenden oder von einer mobilen App aus veröffentlichen, benötigen Sie es wahrscheinlich nicht.
Sicherheits-Plugins wie Wordfence haben einen Ein-Klick-Schalter im Abschnitt Anmeldeeinstellungen.

Das Disable XML-RPC-API Plugin ist eine leichtgewichtige Alternative, wenn Sie lieber keine vollständige Sicherheitssuite installieren möchten.
Auf Nginx oder Apache können Sie xmlrpc.php auf Serverebene blockieren, sodass die Anfrage PHP gar nicht erst erreicht.
Wenn Sie XML-RPC für Jetpack oder eine andere Integration benötigen, ist die gezielte Lösung, system.multicall speziell zu blockieren und nicht den gesamten Endpunkt. Eine Cloudflare WAF-Regel kann dies tun, ohne die legitime XML-RPC-Funktionalität zu beeinträchtigen.
Die Beschränkung des Zugriffs auf xmlrpc.php auf bestimmte IP-Adressen ist eine weitere Option für Integrationen mit bekannten, stabilen Quellen.
Die REST-API ist der moderne Ersatz für neue Integrationen. Wenn Sie etwas entwickeln, das XML-RPC verwendet hätte, entwickeln Sie es stattdessen gegen die REST-API.
Ebene 6: Verwenden Sie eine Web Application Firewall
Eine Web Application Firewall (WAF) sitzt zwischen dem eingehenden Datenverkehr und Ihrer WordPress-Website, inspiziert Anfragen und blockiert bösartige, bevor sie Ihre Anmeldeseite erreichen.
Je näher sie am Netzwerkrand arbeitet, desto weniger Arbeit hat Ihr Server unter Angriff. Eine Plugin-basierte WAF stoppt Angriffe, nachdem sie Ihren Server erreicht haben. Eine Edge-Level-WAF stoppt sie, bevor sie überhaupt dort ankommen.
Plugin-basierte WAFs
Plugin-WAFs wie Wordfence und MalCare filtern Anfragen auf Anwendungsebene. Sie pflegen Datenbanken mit bekannten bösartigen IP-Adressen, Bot-Signaturen und Angriffsmustern und blockieren übereinstimmende Anfragen, bevor WordPress sie verarbeitet.

Für Websites auf Shared Hosting, bei denen die Serverkonfiguration nicht zugänglich ist, ist eine Plugin-WAF der richtige Ausgangspunkt.
Die Einschränkung besteht darin, dass Ihr Server immer noch jede Anfrage erhält, die die WAF auswertet. Bei einem groß angelegten Angriff wird PHP immer noch gestartet, das Plugin läuft immer noch und Ihre Hosting-Ressourcen werden immer noch beansprucht. Der Angreifer kommt nicht hinein, aber die Kosten für die Ressourcen sind real.
Edge-Level-WAFs
Cloudflares kostenlose Stufe filtert den Datenverkehr in ihrem globalen Netzwerk, bevor er Ihren Server erreicht. Bot-Management, Ratenbegrenzung und Turnstile CAPTCHA-Herausforderungen laufen alle am Edge.
Ihr Server sieht nur den Datenverkehr, den Cloudflare bereits überprüft hat. Während eines Angriffs mit hohem Volumen bleibt Ihre Website für echte Besucher schnell, da der Angriffsverkehr nie ankommt.
Sucuri bietet eine verwaltete WAF mit WordPress-spezifischen Regelsätzen und einer integrierten CDN-Schicht. Es ist ein kostenpflichtiger Dienst, aber die verwaltete Regelwartung ist für Websites, die keinen Entwickler zur aktiven Überwachung von Sicherheitskonfigurationen haben, in Betracht zu ziehen.
Verwaltete WordPress-Hosts, einschließlich WP Engine und Kinsta, beinhalten Infrastruktur-WAFs als Teil ihres Hosting-Stacks. Wenn Sie auf einer dieser Plattformen sind, haben Sie wahrscheinlich bereits Edge-Schutz. Bestätigen Sie mit Ihrem Host, was deren WAF speziell abdeckt und ob benutzerdefinierte Regeln verfügbar sind.
Eine Cloudflare-Konfiguration, die es wert ist, implementiert zu werden: eine benutzerdefinierte Firewall-Regel, die den gesamten Datenverkehr zu /wp-admin blockiert, außer von Ihrer IP-Adresse oder dem IP-Bereich Ihres Teams.
Für Websites, die von einem kleinen Team von vorhersehbaren IPs oder einer gemeinsamen VPN verwaltet werden, ist dies einer der effektivsten Einzelschritte. Automatisierte Bots können den Admin-Bereich überhaupt nicht erreichen.
Stellen Sie einfach sicher, dass Ihre Website keine /wp-admin-URLs für kundenorientierte Funktionen (wie WooCommerce Mein Konto-Seiten oder Mitgliederportal-Logins) verwendet, bevor Sie diese Regel aktivieren.
Ebene 7: Härtung auf Server-Ebene
Wenn Sie Ihren eigenen Server oder VPS verwalten, können Sie den Schutz vor WordPress schieben und Angriffe blockieren, bevor sie PHP oder irgendeinen WordPress-Code berühren.
Dieser Abschnitt ist für Entwickler und Besitzer von VPS- oder dedizierten Servern. Wenn Sie sich auf Shared Hosting ohne Zugriff auf die Serverkonfiguration befinden, springen Sie zu Layer 8.
wp-login.php nach IP einschränken
Wenn Sie und Ihr Team sich immer von vorhersehbaren IP-Adressen aus anmelden, z. B. von einem Büronetzwerk oder einer gemeinsamen VPN, können Sie /wp-login.php auf dem Server auf diese IPs beschränken. Jede Anfrage von einer anderen IP erhält ein 403, bevor WordPress geladen wird.
Auf Nginx sieht das in Ihrem Serverblock so aus:
location = /wp-login.php {
allow 203.0.113.10;
deny all;
}
Ersetzen Sie die IP durch Ihre eigene. Fügen Sie mehrere allow-Zeilen für mehrere IPs hinzu. Die Anfrage von einer nicht aufgeführten Adresse erreicht niemals PHP.
Dies funktioniert nicht für WooCommerce-Websites, Mitgliederplattformen oder Setups, bei denen sich Kunden über WordPress anmelden. Es eignet sich am besten für Geschäfts- oder Portfolioseiten mit einem kleinen, stabilen Administrator-Team.
Implementiere Fail2ban
Fail2ban liest Ihre Server-Logs und sperrt automatisch IP-Adressen, die mit von Ihnen definierten Mustern übereinstimmen. Für WordPress bedeutet dies, dass eine IP, die wiederholte fehlgeschlagene Anmeldeversuche im Log generiert, Ihrer Firewall-Blockierliste hinzugefügt wird, normalerweise über iptables oder nftables, bevor sie genügend Versuche ansammelt, um relevant zu sein.
Es erfordert ein WordPress-Integrations-Plugin, um zu funktionieren: Fail2ban muss fehlgeschlagene Anmeldeversuche in einem parsebaren Format lesen, und WordPress schreibt diese standardmäßig nicht in die Server-Logs.
WP fail2ban kümmert sich darum und schreibt Authentifizierungsereignisse in einem Format, das Fail2ban direkt parsen kann.
Das Ergebnis ist ein Schutz, der auf der Netzwerkebene operiert: blockierte IPs erreichen niemals Ihren Webserver, geschweige denn WordPress. In Kombination mit der Ratenbegrenzung von Nginx am Anmelde-Endpunkt ist dies das engste nicht-unternehmensweite Setup, das verfügbar ist.
Verwenden Sie SFTP und SSH-Schlüssel, nicht FTP
Brute-Force-Angriffe zielen nicht nur auf Ihre Anmeldeseite ab. FTP läuft über Port 21 und überträgt Anmeldeinformationen im Klartext. Angreifer scannen nach offenen FTP-Ports und führen den gleichen Ansatz des Raten von Anmeldeinformationen durch, den sie für wp-login.php verwenden.
SFTP verschlüsselt die Verbindung. Wenn Ihr Hoster es unterstützt, wechseln Sie zu SFTP und deaktivieren Sie FTP vollständig. Die meisten modernen Hoster unterstützen dies; einige deaktivieren FTP standardmäßig.
Verwenden Sie für den SSH-Zugriff auf Ihren Server schlüsselbasierte Authentifizierung anstelle von Passwort-Authentifizierung. Ein SSH-Schlüsselpaar eliminiert den Vektor des Passwort-Ratens auf der Server-Ebene: Es gibt kein Passwort, das per Brute-Force geknackt werden könnte.
Generieren Sie lokal ein Schlüsselpaar, fügen Sie den öffentlichen Schlüssel zu ~/.ssh/authorized_keys Ihres Servers hinzu und deaktivieren Sie die passwortbasierte SSH-Anmeldung in Ihrer sshd_config.
Wenn Sie einen VPS verwalten und dies noch nicht getan haben, ist dies das Erste, was sich einzurichten lohnt.
Ebene 8: Halten Sie WordPress, Plugins und Themes aktuell
Brute Force ist oft der zweite Angriff, nicht der erste. Angreifer nutzen häufig eine Schwachstelle in einem veralteten Plugin aus, um einen Fußabdruck zu hinterlassen, ein Hintertür-Konto zu erstellen oder Berechtigungen zu eskalieren.
Brute Force kommt danach und zielt auf bereits existierende Konten ab. Aktualisierungen schließen die Einstiegspunkte, die Brute Force überhaupt erst lohnenswert machen.
WordPress Core behandelt kleinere Versionsupdates standardmäßig automatisch. Hauptversionen erfordern manuelle Maßnahmen oder eine explizite Auto-Update-Einstellung in Ihrem Hosting-Dashboard.
Automatische Updates pro Plugin sind direkt in wp-admin verfügbar. Gehen Sie zu Plugins » Installierte Plugins, und Sie sehen in der rechten Spalte für jedes Plugin einen Schalter Auto-Updates aktivieren.

Für die meisten Websites ist die Aktivierung von Auto-Updates für alle aktiven Plugins die richtige Entscheidung. Das Risiko eines fehlerhaften Updates ist real, aber weitaus geringer als das Risiko, ein Plugin mit einer bekannten Schwachstelle über Wochen nach der Veröffentlichung eines Patches auszuführen.
Themes folgen der gleichen Logik. Ein inaktives Theme, das auf Ihrem Server liegt und eine ungepatchte Schwachstelle aufweist, ist immer noch ausnutzbar, auch wenn es nicht das aktive Theme ist.
Löschen Sie alles, was Sie nicht verwenden. Deaktiviert bedeutet nicht sicher.
Dasselbe gilt für Plugins. Die Dateien eines deaktivierten Plugins befinden sich immer noch auf dem Server und sind weiterhin zugänglich. Wenn diese Dateien eine Schwachstelle aufweisen, kann diese ausgenutzt werden, unabhängig davon, ob das Plugin in WordPress aktiv ist.
Wenn Sie ein Plugin nicht verwenden, löschen Sie es vollständig, anstatt es deaktiviert zu lassen.
Für Teams, die mehrere Websites verwalten, ermöglichen Tools wie ManageWP, MainWP und Jetpack Manage die Überwachung und Anwendung von Updates auf allen Websites von einem einzigen Dashboard aus. Das Aktualisieren von zwanzig Installationen nacheinander ist die Art von Reibung, die zu verpassten Patches führt.
Ebene 9: Sichern Sie Ihre Website und wissen Sie, wie Sie sie wiederherstellen
Der Leitfaden zur Härtung gegen Brute-Force-Angriffe von WordPress.org fasst es klar zusammen: Führen Sie getestete, offline-fähige Backups durch und üben Sie Ihre Wiederherstellungsverfahren.
Jede Schicht davor reduziert das Risiko. Diese Schicht eliminiert das schlimmste Ergebnis.
Wenn ein Angreifer jede andere Schicht durchdringt, ist ein aktuelles Backup der Unterschied zwischen einer einstündigen Wiederherstellung und einem vollständigen Neuaufbau. Das Backup verhindert nicht den Einbruch. Es bestimmt, wie schlimm der Einbruch tatsächlich ist.
„Getestet“ ist das Wort, das in diesem Satz am wichtigsten ist. Testen bedeutet, eine Wiederherstellung in einer Staging-Umgebung durchzuführen, zu bestätigen, dass die Website korrekt hochfährt, und genau zu wissen, welche Schritte der Prozess beinhaltet, bevor Sie ihn unter Druck durchführen müssen.
Planen Sie vierteljährlich einen Wiederherstellungstest. Er dauert weniger als eine Stunde und beseitigt alle Unsicherheiten im schlimmsten Moment.
Automatisieren Sie Backups und Wiederherstellungen mit Duplicator
Was ein Backup speziell in einem Brute-Force-Einbruchsszenario nützlich macht: Es muss extern, unabhängig vom kompromittierten Server und mit einem Wiederherstellungspfad sein, der auch dann funktioniert, wenn WordPress vollständig gesperrt ist.
Duplicator Pro erfüllt all diese Anforderungen.

Automatische geplante Backups werden stündlich, täglich, wöchentlich oder monatlich ohne manuelles Eingreifen ausgeführt. Sie legen den Zeitplan einmal fest und haben immer einen aktuellen Wiederherstellungspunkt.

Zur Speicherung verbindet sich Duplicator Pro mit Amazon S3, Google Drive, Dropbox, OneDrive und anderen Cloud-Diensten von Drittanbietern.

Duplicator Cloud ist der eigene Speicher von Duplicator: Kein separates Konto erforderlich, kein Dienst eines Drittanbieters zu konfigurieren. Im Gegensatz zu anderen Optionen wurde er speziell für die Speicherung von WordPress-Backups entwickelt.

Wenn etwas schiefgeht, können Sie direkt aus dem Cloud-Speicher wiederherstellen, ohne zuerst Dateien auf den Server hochladen zu müssen. Wenn Ihr Server kompromittiert ist und Sie dem, was darauf ist, nicht vertrauen, ziehen Sie die Wiederherstellung direkt aus der Cloud-Kopie.

Disaster-Recovery-URLs sind das Teil, von dem die meisten Leute nichts wissen, bis sie es brauchen. Nach einem erfolgreichen Brute-Force-Angriff ändern Angreifer als Erstes das Admin-Passwort oder erstellen neue Konten und sperren den ursprünglichen Besitzer aus.
Eine Disaster-Recovery-URL umgeht wp-admin vollständig und ermöglicht Ihnen, eine Wiederherstellung einzuleiten, auch wenn Sie sich nicht anmelden können. Ich habe dies einmal in einem echten Vorfall verwendet. Es ist die Funktion, die den Unterschied zwischen einer einstündigen Wiederherstellung und einem Tag am Telefon mit dem Hosting-Support ausmacht.

Die Ein-Klick-Wiederherstellung kümmert sich um Standardwiederherstellungen ohne manuelle Dateiübertragungen oder FTP-Zugriff. Wählen Sie das Backup aus, klicken Sie auf Wiederherstellen und bestätigen Sie. Das ist der Vorgang.

Wie man Brute-Force-Aktivitäten überwacht
Die meisten Besitzer von WordPress-Websites erfahren, dass sie unter Beschuss stehen, durch die Drosselungsmitteilung ihres Hosting-Providers und nicht durch ihre eigene Überwachung. Bis dahin hat der Angriff bereits Serverressourcen verbraucht, Ihre Protokolle mit Rauschen gefüllt und in einigen Fällen Erfolg gehabt.
Die Einrichtung proaktiver Sichtbarkeit dauert weniger als eine Stunde und bedeutet, dass Sie wissen, was auf Ihrer Website passiert, bevor Ihr Hoster es weiß.
Proaktive Überwachung
Aktivitätsprotokoll gibt Ihnen eine vollständige Audit-Trail aller Aktionen, die auf Ihrer Website durchgeführt wurden, wie z. B. fehlgeschlagene Anmeldeversuche, erfolgreiche Anmeldungen, Änderungen der Benutzerrolle, Aktivierungen und Deaktivierungen von Plugins, Änderungen der Einstellungen und Dateibearbeitungen.

Dieser Umfang ist nach einem Brute-Force-Einbruch wichtig. Ein Angreifer, der eindringt, meldet sich nicht nur an; er nimmt Änderungen vor.
Das Aktivitätsprotokoll zeigt diese Änderungen in einer lesbaren Zeitleiste an, sodass Sie genau sehen können, was passiert ist und in welcher Reihenfolge. Das sind die Informationen, die Sie benötigen, um den Schaden einzuschätzen und zu wissen, was bereinigt werden muss.

Lassen Sie sich vom Aktivitätsprotokoll E-Mail-Benachrichtigungen für ungewöhnliche Anmeldeaktivitäten senden. Dies hilft Ihnen, einen Brute-Force-Angriff sofort zu erkennen und zu stoppen, anstatt ihn danach zu bereinigen.

Ihr Hosting-Kontrollpanel ist eine weitere Überwachungsebene. Unerklärliche PHP-Worker-Spitzen oder CPU-Auslastung außerhalb der Geschäftszeiten sind oft das erste sichtbare Zeichen eines großvolumigen Angriffs, das auftritt, bevor Ihr Sicherheitspaket genügend Ereignisse protokolliert hat, um eine Benachrichtigung auszulösen.
Anzeichen, dass Sie bereits unter Beschuss stehen
Einige Angriffe kündigen sich an. Andere sind leiser.
Ein plötzlicher Anstieg fehlgeschlagener Anmeldebenachrichtigungen in Ihrem Aktivitätsprotokoll ist das deutlichste Signal. Wenn Sie normalerweise zwei oder drei fehlgeschlagene Versuche pro Tag sehen und plötzlich Hunderte sehen, hat sich etwas geändert.
Sperrbenachrichtigungen von Benutzern, die sich tatsächlich nicht angemeldet haben, sind ein subtileres Zeichen. IP-basierte Sperrungen betreffen jeden Benutzer, der sich diese IP teilt: Ein Firmenbüro oder ein Universitätsnetzwerk, in dem eine Person eine Sperrung auslöst, kann alle anderen mit derselben Verbindung blockieren.
Wenn Ihr Support-Posteingang mit „Ich kann mich nicht anmelden“-Nachrichten von Personen gefüllt wird, die ihre Passwörter nicht zurücksetzen wollten, überprüfen Sie Ihr Sperrprotokoll.
Langsame wp-admin-Antworten oder PHP-Worker-Erschöpfungsfehler in Ihrem Hosting-Fehlerprotokoll deuten auf Ressourcenverbrauch durch einen großvolumigen Angriff hin. Die Website funktioniert immer noch, aber sie ist langsamer als sie sein sollte, und die Protokolle erklären warum.
Gehen Sie nach einem Sicherheitsvorfall in wp-admin zu Benutzer » Alle Benutzer und filtern Sie nach der Rolle Administrator.

Ein unbefugtes Administratorkonto, das während eines Angriffsfensters erstellt wurde, ist ein Zeichen dafür, dass der Angreifer erfolgreich war und sich selbst eine Hintertür hinterlassen hat. Überprüfen Sie dies, bevor Sie einen Vorfall als abgeschlossen betrachten.
Was nicht funktioniert (und warum Leute es immer noch empfehlen)
Einige der am häufigsten wiederholten WordPress-Sicherheitsempfehlungen klingen vernünftig, bieten aber wenig echten Schutz. Wenn Sie den Unterschied kennen, ersparen Sie sich die Mühe, Dinge zu implementieren, die ein falsches Sicherheitsgefühl vermitteln.
Geoblocking nach Land
Der Reiz liegt auf der Hand: Wenn die meisten Ihrer Angriffe aus einem bestimmten Land kommen, blockieren Sie dieses Land. Das Problem ist, dass Botnetze nicht so funktionieren.
Ein Botnetz ist ein Netzwerk kompromittierter Maschinen: Heimrouter, Server, IoT-Geräte, normale Computer, die mit Malware infiziert sind. Diese Maschinen sind überall, auch in Ihrem eigenen Land.
Der Datenverkehr aus Russland oder China blockiert kein Botnetz mit Knotenpunkten in den Vereinigten Staaten, Großbritannien und Australien. Es blockiert legitime Besucher aus diesen Ländern. Für die meisten Websites lohnt sich der Kompromiss nicht.
Schutz der wp-admin-Seite mit HTTP-Authentifizierung
Das Hinzufügen einer zweiten Passwortabfrage vor dem wp-admin-Verzeichnis klingt nach einer nützlichen zusätzlichen Sicherheitsebene. In der Praxis kann es jedoch das WordPress AJAX beeinträchtigen, auf das wp-admin für Kernfunktionen angewiesen ist, einschließlich des Speicherns von Beiträgen, der Ausführung von Plugin-Einstellungen und der Verarbeitung von Medien-Uploads.
Websites, die dies korrekt mit sorgfältigen AJAX-Ausschlüssen implementieren, können es zum Laufen bringen, aber für die meisten Website-Besitzer überwiegt die Komplexität der Konfiguration den Nutzen.
Häufig gestellte Fragen (FAQs)
Was ist der effektivste Weg, um Brute-Force-Angriffe zu verhindern?
Zwei-Faktor-Authentifizierung für jedes Administratorkonto. Selbst wenn ein Angreifer ein Passwort korrekt errät oder durch eine Datenpanne erhält, blockiert 2FA die Anmeldung ohne den zweiten Faktor. Kombinieren Sie dies mit einem Ratenbegrenzungs-Plugin oder einer WAF-Regel und einem aktuellen Offsite-Backup.
Verfügt WordPress über einen integrierten Schutz vor Brute-Force-Angriffen?
Nein. Der WordPress-Kern enthält keine Begrenzung der Anmeldeversuche, keine Zwei-Faktor-Authentifizierung und keine WAF-Funktionalität. Sie benötigen ein Sicherheits-Plugin oder eine Serverkonfiguration, um diese Schutzmaßnahmen hinzuzufügen. WordPress.com (die gehostete Plattform) bietet standardmäßig einen Schutz vor Brute-Force-Angriffen. Selbst gehostete WordPress.org-Websites nicht.
Kann ein Brute-Force-Angriff meiner Website schaden, auch wenn niemand eindringt?
Ja. Ein Angriff mit hohem Volumen sendet Tausende von HTTP-Anfragen an Ihren Server, unabhängig davon, ob Anmeldeinformationen erfolgreich sind oder nicht. Dies kann PHP-Worker erschöpfen, Ihre Website für echte Besucher verlangsamen und ein Drosseln oder eine vorübergehende Sperrung durch den Hoster auslösen. Eine Ratenbegrenzung auf Server- oder Edge-Ebene verhindert dies; Plugins auf Anwendungsebene allein nicht.
Wie stoppe ich XML-RPC-Brute-Force-Angriffe?
Wenn Sie XML-RPC nicht für Jetpack, mobile Veröffentlichungen oder Integrationen von Drittanbietern verwenden, deaktivieren Sie es über ein Plugin oder eine Serverkonfiguration. Wenn Sie es benötigen, blockieren Sie die Methode system.multicall mit einer WAF-Regel oder beschränken Sie den Zugriff auf xmlrpc.php auf bestimmte IP-Adressen.
Ist die Änderung der WordPress-Anmelde-URL wirksam?
Sie reduziert das Volumen automatisierter Angriffe, da die meisten Bots die Standard-URL /wp-login.php anvisieren. Das ist ein echter Vorteil. Sie sollte jedoch nicht die einzige Verteidigung gegen gezielte Angriffe sein. Beachten Sie, dass Sie sich bei Verlust einer benutzerdefinierten Anmelde-URL ohne Wiederherstellungsplan von Ihrer eigenen Website aussperren können. Betrachten Sie es als eine Reibungsschicht, nicht als primären Schutz.
Wie oft sollte ich meine WordPress-Website sichern?
Für WooCommerce oder Mitgliedschaftsseiten mit häufigen Transaktionen: alle paar Stunden oder in Echtzeit. Sie könnten auch häufigere Datenbank-Backups in Betracht ziehen und tägliche oder wöchentliche vollständige Website-Backups planen. Das richtige Intervall ist, wie viele Daten Sie sich leisten können zu verlieren. Speichern Sie mindestens ein Backup extern, testen Sie die Wiederherstellung vierteljährlich und stellen Sie sicher, dass mindestens ein Backup sowohl die Datenbank als auch alle Website-Dateien enthält.
Was ist Credential Stuffing und wie unterscheidet es sich von Brute Force?
Brute Force versucht jede mögliche Passwortkombination. Credential Stuffing verwendet echte Benutzername/Passwort-Paare, die aus anderen Datenlecks stammen. Wenn ein Benutzer sein Passwort über mehrere Websites hinweg wiederverwendet hat, kann Credential Stuffing beim ersten Versuch eine Anmeldung durchführen. Zwei-Faktor-Authentifizierung stoppt beides. Ein eindeutiges Passwort stoppt Credential Stuffing, aber nicht Brute Force.
Was sollte ich tun, wenn meine WordPress-Website bereits kompromittiert wurde?
Stellen Sie ein sauberes Backup wieder her, das vor der Kompromittierung erstellt wurde. Wenn Sie keines haben, verwenden Sie einen Malware-Scanner wie Wordfence oder MalCare, um injizierten Code zu identifizieren und zu entfernen, setzen Sie dann alle Passwörter zurück und widerrufen Sie alle aktiven Sitzungen website-weit. Nach der Wiederherstellung arbeiten Sie jede Schicht in diesem Beitrag durch, bevor Sie die Website wieder online schalten.
Stellen Sie vor dem nächsten Angriff sicher, dass Sie sich davon erholen können.
Brute-Force-Angriffe werden immer günstiger. Cloud-basierte Botnetze, Credential-Datenbanken aus jahrelangen angesammelten Datenlecks und CAPTCHA-Lösungsdienste haben die Kosten für die Durchführung eines anhaltenden Angriffs auf eine WordPress-Website auf nahezu Null gesenkt.
Jede Schutzschicht in diesem Beitrag reduziert Ihr Risiko. Keine davon reduziert es auf Null. Die einzige Garantie, dass ein erfolgreicher Angriff Ihre Website nicht beendet, ist ein getestetes Backup, von dem Sie wiederherstellen können, auch wenn wp-admin vollständig gesperrt ist.
Über 1,5 Millionen WordPress-Profis nutzen Duplicator Pro genau dafür: automatische geplante Backups in Duplicator Cloud oder jedem großen Cloud-Speicheranbieter, Fernwiederherstellung ohne erneutes Hochladen von Dateien auf einen kompromittierten Server und Disaster-Recovery-URLs, die Ihre Website wiederherstellen, auch wenn Sie sich nicht anmelden können.
Wenn dieser Beitrag Sie zum Nachdenken über WordPress-Sicherheit und -Wiederherstellung gebracht hat, sind diese Anleitungen als nächstes lesenswert.
- So schützen Sie Ihre Website vor Hackern (Umfassender Sicherheitsleitfaden)
- Ist WordPress sicher? Die Wahrheit enthüllt
- WordPress-Sicherheitscheckliste: Schritt-für-Schritt-Anleitung zum Schutz Ihrer Website
- So stellen Sie eine gehackte WordPress-Website wieder her (9 Expertentipps)
- So bereinigen Sie eine WordPress-Website
- WordPress-Debugging meistern: Von den Grundlagen bis zu fortgeschrittenen Techniken
- 9 beste WordPress-Datenbank-Backup-Plugins (um Ihre Daten zu sichern)