Anleitungen zu Plugins

WordPress absichern: Hardening-Checkliste mit 12 Schritten nach echten Angriffsdaten

2. Oktober 2026 · Patrick Schlesinger

Diese Checkliste zum Absichern von WordPress hat zwölf Schritte, und ihre Reihenfolge kommt aus dem, was WordPress-Websites im ReportedIP-Netzwerk zwischen dem 4. Juli und dem 1. Oktober 2026 tatsächlich getroffen hat: 36.548 Angriffsereignisse von 18.378 Adressen. Scanner auf der Suche nach Konfigurationsdateien, Plugins und Versionsnummern machten mehr als die Hälfte aus, das Raten von Passwörtern kam an zweiter Stelle, und die Exploits, über die alle schreiben, waren ein paar hundert Ereignisse am Ende der Liste.

Jeder Schritt benennt, was er schließt, was er kaputtmachen kann und wo der Schalter in ReportedIP Hive sitzt. Der Erkennungs- und Abriegelungskern des Plugins ist kostenlos; die Schritte, die den Professional-Tarif brauchen, sagen das. Die deutschen Bezeichnungen stammen aus der deutschen Oberfläche des Plugins. Für das meiste davon müssen Sie kein Entwickler sein: Acht der zwölf Schritte sind Schalter in einem kostenlosen Plugin, und das Plugin zeigt Ihnen, welche noch aus sind.

Wenn Sie nur zehn Minuten haben: die Kurzfassung

Die Kurzfassung dauert etwa zehn Minuten und deckt die Schritte ab, die den Großteil des Verkehrs aus der Tabelle unten stoppen.

1. Laden Sie ReportedIP Hive herunter und installieren Sie es wie jedes andere Plugin: Plugins, Installieren, Plugin hochladen, die ZIP-Datei wählen, Aktivieren.
2. Starten Sie den Schnellstart, den das Plugin nach der Aktivierung öffnet. Modus wählen, Key einfügen, falls Sie einen haben, Schutz einschalten. Sensoren, Firewall und progressive Sperre sind für Ihren Tarif voreingestellt.
3. Öffnen Sie das Dashboard und gehen Sie den Härtungs-Score durch. Jeder Punkt, bei dem noch Aktivieren steht, verlinkt auf seinen Schalter. Der zweite Faktor für Ihr eigenes Konto ist der erste, den Sie setzen sollten.

Was WordPress-Websites in den letzten 90 Tagen angegriffen hat

Die Zahlen unten sind die Angriffsereignisse, die WordPress-Websites und Server dem ReportedIP-Netzwerk in diesen 90 Tagen über seine API gemeldet haben, gezählt je Kategorie. Honeypot-Verkehr bleibt außen vor, und ein Ereignis mit mehreren Kategorien zählt in jeder davon einmal. Der Schritt der Checkliste, der den jeweiligen Vektor schließt, steht in der letzten Spalte.

Angriffsart	Ereignisse	Adressen	Geschlossen durch Schritt
Suche nach Konfigurationsdateien und Backups	16.548	7.549	2 und 3
Plugin-Scans	16.308	7.515	1 und 3
Versions-Scans	16.184	7.480	3
Brute Force auf den Login	11.235	8.010	4, 5 und 8
Benutzer-Enumeration	6.130	3.026	6
Gefälschte Suchmaschinen-Bots	1.978	382	11
Brute Force über XML-RPC	681	237	7
Versuche, Plugins auszunutzen	574	149	1 und 11
Missbrauch der REST-API	357	128	7

Aus der Tabelle folgen zwei Dinge. Der Großteil des Verkehrs ist Aufklärung, eine Website, die nichts preisgibt, bekommt also weniger Folgeangriffe. Und die kleine Zahl der Exploit-Versuche ist die eine Zeile, die in einer Kompromittierung endet, weshalb die Updates ganz oben bleiben, obwohl die Scanner-Zeilen fast dreißigmal größer sind.

Die Checkliste auf einen Blick

Schritt	Aufwand	Kann brechen	In ReportedIP Hive
1. Aktualisieren und Plugins entfernen	Wiederkehrend	Theme oder Plugin nach einem großen Update	Keine Aufgabe des Plugins
2. Dateien absichern	Einmalig	Plugins, die in ihren eigenen Ordner schreiben	PHP-Ausführung im Upload-Verzeichnis sperren
3. Versions-Fingerabdrücke verbergen	Einmalig	Nichts	Software-Fingerabdrücke verbergen
4. Login härten	Einmalig	Gemeinsam genutzte Büro-Adressen	Progressive Sperre, Passwortregeln
5. Zweiten Faktor erzwingen	Einmalig je Rolle	Nutzer ohne Telefon	Zwei-Faktor-Authentifizierung
6. Benutzer-Enumeration stoppen	Einmalig	Öffentliche Autorenseiten	User-Enumeration-Sperre
7. XML-RPC und REST schließen	Einmalig	Jetpack, die Mobil-App, Headless-Aufbauten	Zugänge abriegeln
8. Login-Seite verstecken	Einmalig	Die Lesezeichen Ihrer Redakteure	Anmeldung verbergen
9. Security-Header senden	Einmalig	Einbettungen und eine strenge CSP	Security-Header
10. HTTPS, PHP und Proxys	Einmalig	Alte Plugins auf neuem PHP	Vertrauenswürdige Proxy-Quellen
11. Eine Firewall davorsetzen	Einmalig	Formulare, die Code senden	Web Application Firewall
12. Backups und Überwachung	Wiederkehrend	Nichts	Systemstatus

1. Core, Plugins und Themes aktualisieren, und löschen, was Sie nicht nutzen

Plugin-Scans waren aus einem Grund die zweitgrößte Zeile der Tabelle: Ein Scanner, der weiß, welche Plugins und Versionen eine Website betreibt, kann sie mit veröffentlichten Schwachstellen abgleichen und mit dem einen Exploit zurückkommen, der passt. Die 574 Exploit-Versuche sind das Ende dieser Kette. Eine Installation mit aktuellen Plugins bietet nichts, worin die Kette enden könnte.

• Schalten Sie automatische Updates für den WordPress-Core ein, mindestens für Minor-Releases, denn die tragen die Sicherheitskorrekturen.
• Aktualisieren Sie Plugins und Themes nach einem Zeitplan, wöchentlich für die meisten Websites, noch am selben Tag bei einem Plugin mit veröffentlichter Schwachstelle.
• Löschen Sie inaktive Plugins und Themes. Ein inaktives Plugin hat weiterhin Dateien auf der Platte, und ein Scanner liest Dateien, nicht den Aktivierungsstatus.
• Testen Sie große Updates auf einer Staging-Kopie, bevor sie die Live-Website erreichen, vor allem WooCommerce und Page-Builder.

Wenn im Unternehmen niemand diesen Zeitplan verantwortet, geben Sie ihn an jemanden, der das jede Woche macht. Die WordPress-Wartung von CMS ADMINS, dem Münchner Team hinter ReportedIP, spielt Updates in festem Rhythmus ein, in den größeren Paketen mit Staging-Umgebung, macht tägliche Backups, überwacht die Website rund um die Uhr und hostet auf deutschen Servern für Kunden, die Wartung und Hosting aus einer Hand wollen.

2. wp-config.php, Dateirechte und den Datei-Editor absichern

Die größte Zeile der Tabelle, 16.548 Ereignisse, sind Scanner, die nach Sicherungskopien und Konfigurationsdateien fragen, die von außen nie lesbar sein dürften. Drei Einstellungen schließen den größten Teil dieser Fläche.

Fügen Sie diese zwei Zeilen in die wp-config.php ein, oberhalb der Zeile, die sagt, dass die Bearbeitung dort endet. Die erste entfernt den Theme- und Plugin-Editor aus wp-admin, sodass eine gestohlene Administrator-Sitzung kein PHP in Ihr Theme einfügen kann. Die zweite stoppt den Plugin- und Theme-Installer, den Sie nur auf einer Website wollen, auf der ohnehin jede Änderung über ein Deployment läuft.

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // nur, wenn Sie Plugins selbst deployen

Setzen Sie die Dateirechte, die der WordPress-Hardening-Leitfaden empfiehlt: Verzeichnisse 755, Dateien 644 und wp-config.php 600, damit nur der Webserver-Benutzer sie lesen kann. Lassen Sie nie eine Kopie namens wp-config.php.bak oder wp-config.old daneben liegen; ein Webserver liefert sie als Klartext aus, und genau danach haben die 16.548 Anfragen gefragt.

find /pfad/zur/website -type d -exec chmod 755 {} \;
find /pfad/zur/website -type f -exec chmod 644 {} \;
chmod 600 /pfad/zur/website/wp-config.php

Der Upload-Ordner ist der eine Ort, an dem ein Besucher eine Datei auf Ihrem Server ablegen kann. Hive ergänzt eine Regel, die die Ausführung von PHP darin verweigert, sodass ein Skript, das über ein kaputtes Upload-Formular hereinkommt, nicht gestartet werden kann. Auf Apache schreibt das Plugin die Regel selbst in die .htaccess der Uploads; auf nginx zeigt es einen Schnipsel zum Einfügen. Der Schalter heißt PHP-Ausführung im Upload-Verzeichnis sperren unter Schutz, Firewall & Bots, Zugänge abriegeln.

Wenn Dateien auf dem Server bearbeiten nicht Ihr Ding ist, nehmen Sie nur den letzten Schalter und bitten Sie Ihren Hoster um die zwei Zeilen und die Dateirechte. Für einen Hoster ist das eine Sache von fünf Minuten.

3. Scannern keine Versionsnummern mehr liefern

WordPress schreibt seine Version in den Seitenquelltext, in die Feeds und in die URLs von Skripten und Stylesheets, und 16.184 Ereignisse in 90 Tagen waren Scanner, die genau das gelesen haben. Die Fingerabdrücke zu entfernen behebt für sich genommen nichts. Es hört auf, dem Scanner die Liste dessen zu liefern, was er als Nächstes probieren soll, und deshalb kommt der Schritt für den geringen Aufwand so früh.

In Hive heißt der Schalter Software-Fingerabdrücke verbergen, im selben Bereich Zugänge abriegeln. Zwei weitere Dinge fangen Scanner schon am Eingang ab: Der Scan-Detektor zählt verfehlte Pfade je Adresse und sperrt nach einer Salve, und die Köderpfade beantworten die Anfrage nach einer Datei, die es auf keiner echten Website gibt, mit einer Sperre und einer Meldung ans Netzwerk. Beides ist kostenlos und standardmäßig an; die Anleitung zu Köderpfaden erklärt, was sie tun und was nicht.

4. Den Login teuer machen: eindeutige Namen, starke Passwörter, progressive Sperren

Brute Force auf den Login waren 11.235 Ereignisse von 8.010 Adressen, die breiteste Streuung aller Zeilen: Die meisten dieser Adressen haben es ein paarmal versucht und sind weitergezogen. Dieses Muster entscheidet über die Verteidigung. Allein nach Adresse zu sperren skaliert nicht gegen 8.010 davon, also muss das Passwort unerratbar sein, und die Versuche müssen den Angreifer etwas kosten.

• Kein Konto namens admin. Legen Sie einen neuen Administrator mit einem Namen an, den niemand erraten kann, melden Sie sich damit an, löschen Sie den alten und ordnen Sie dessen Inhalte dem neuen Konto zu.
• Starke, eindeutige Passwörter mit Leak-Prüfung. Die Passwortregeln von Hive legen eine Mindestlänge und Zeichenklassen fest und können ein neues Passwort gegen bekannte Datenlecks prüfen, ohne das Passwort irgendwohin zu senden.
• Progressive Sperre statt pauschalem Bann. Hive zählt fehlgeschlagene Logins je Adresse und sperrt beim ersten Verstoß für Minuten und bei Wiederholung für Tage, sodass ein Kollege mit Tippfehler nicht einen Tag lang ausgesperrt ist. Die Anleitung zur Brute-Force-Sperre geht die Leiter durch.
• Teilen Sie, was Sie lernen. Im Modus Community-Netzwerk wird eine Adresse, die andere Websites bereits gemeldet haben, abgewiesen, bevor das Passwort geprüft wird, und Ihre eigenen Sperren helfen der nächsten Website.

5. Zwei-Faktor-Authentifizierung für jede Rolle erzwingen, die bearbeiten darf

Ein zweiter Faktor ist der eine Schritt, der ein gestohlenes oder erratenes Passwort wertlos macht, und genau deshalb ist er der größte Einzelposten im Härtungs-Score. Hive bringt vier Methoden mit: eine Authenticator-App, Passkeys und Hardware-Schlüssel, einen Code per E-Mail und SMS im Professional-Tarif über das verwaltete Relay. Die ersten drei sind in jedem Tarif kostenlos, auch im komplett offline laufenden Modus Local Shield.

Das Erzwingen je Rolle ist der Teil, der zählt. Wählen Sie unter Schutz, Grundschutz, Zwei-Faktor-Authentifizierung die Rollen, die einen zweiten Faktor nutzen müssen, mindestens Administratoren und Redakteure. Nutzer bekommen eine Schonfrist für die Einrichtung, Wiederherstellungscodes decken ein verlorenes Telefon ab, und auch das Zurücksetzen des Passworts verlangt den zweiten Faktor, sodass ein gestohlenes Postfach ihn nicht umgehen kann. Die Anleitung zur Zwei-Faktor-Authentifizierung vergleicht die vier Methoden.

Professional ergänzt die adaptive Nachprüfung: Eine Anmeldung aus einem neuen Land, einem neuen Netz oder von einem neuen Gerät fragt den zweiten Faktor erneut ab, auch auf einem vertrauten Gerät. Für einen Shop zeigt die Storefront-Variante die Abfrage im WooCommerce-Theme auf Mein Konto und an der Kasse.

6. Benutzer-Enumeration stoppen

Bevor ein Bot Passwörter rät, will er Benutzernamen, und WordPress gibt sie an vier Stellen heraus: über die Weiterleitung ?author=1, den Benutzer-Endpunkt der REST-API, die oEmbed-Antwort und die Login-Fehlermeldung, die verrät, ob Benutzername oder Passwort falsch war. Die 6.130 Enumerations-Ereignisse sind Bots, die Namen für die 11.235 Login-Versuche von oben sammeln.

Die User-Enumeration-Sperre von Hive schließt alle vier auf einmal und zählt die Abfragen je Adresse, sodass ein Bot, der weiterfragt, gesperrt wird. Websites, die auf ihre Autorenseiten verlinken, können diese öffentlich lassen; die anderen drei bleiben zu. Der Schalter ist unter Schutz, Grundschutz standardmäßig an.

7. XML-RPC, die REST-API und die anderen Türen schließen, die Sie nicht nutzen

Brute Force über XML-RPC und Missbrauch der REST-API waren zusammen rund tausend Ereignisse, weit weniger als die Login-Seite, und es sind die zwei Schalter, die am ehesten etwas kaputtmachen. Testen Sie also, bevor Sie sich darauf verlassen. XML-RPC brauchen die Jetpack-App, die WordPress-Mobil-App und einige Publishing-Werkzeuge; die REST-API nutzen der Block-Editor, die meisten Formular- und Shop-Plugins und jedes Headless-Frontend.

Der Bereich Zugänge abriegeln in Hive bietet die Schalter mit eingebautem Mittelweg. XML-RPC abschalten schaltet den Endpunkt und Pingbacks komplett ab; wenn Sie ihn brauchen, entfernt ein zweiter Schalter nur die Multicall-Methode, die Hunderte Passwort-Versuche in eine Anfrage packt. Zugriff auf die REST API kann offen bleiben, auf angemeldete Nutzer begrenzt oder auf gewählte Rollen eingeschränkt werden, mit einer Liste von Namensräumen, die für ein Cookie-Banner oder ein Shop-Plugin immer erreichbar bleiben. RSS- und Atom-Feeds abschalten ist für Websites, die niemand abonniert hat.

Jeder Schalter ist kostenlos, standardmäßig aus und vom selben Bildschirm aus umkehrbar. Die vollständige Liste steht in der Dokumentation zum Abriegeln.

8. Die Login-Seite verstecken und wp-admin für Besucher schließen

Die Anmeldeseite von wp-login.php wegzuverlegen hält keinen gezielten Angreifer auf, nimmt die Website aber aus jedem automatisierten Durchlauf heraus, der die Standardadresse probiert, und dort beginnt das meiste Passwortraten. Anmeldung verbergen in Hive setzt einen eigenen Slug, legt fest, was die alte Adresse antwortet, und protokolliert, wer noch danach fragt. wp-admin für Besucher schließen schickt abgemeldete Besucher vom Admin-Bereich weg, statt ihnen das Formular zu zeigen.

Sagen Sie Ihren Redakteuren die neue Adresse, bevor Sie umschalten, und behalten Sie die Whitelist des Plugins für das Büronetz im Blick: Eine Adresse darauf wird nie gesperrt, was auch immer sie tut.

9. Security-Header senden

Antwort-Header sagen dem Browser, was er verweigern muss: einen Dateityp zu erraten, Ihre Seiten auf einer fremden Website einzurahmen, die vollständige Adresse preiszugeben, wenn ein Besucher einem Link folgt, oder auf HTTP zurückzufallen. Die drei Basis-Header X-Content-Type-Options, X-Frame-Options und Referrer-Policy sind in Hive kostenlos und auf fast jeder Website unbedenklich. HSTS, Permissions-Policy, eine Content-Security-Policy, die im Nur-Melden-Modus startet, und das Cross-Origin-Trio kommen mit Professional.

Zwei Warnungen aus dem Einstellungsbildschirm selbst: Schalten Sie HSTS nie ein, bevor HTTPS überall funktioniert, denn Browser merken sich die Anweisung für die Dauer, die Sie setzen, und lassen Sie eine Content-Security-Policy immer zuerst im Nur-Melden-Modus laufen, denn eine zu strenge durchgesetzte Richtlinie lässt eine Seite kaputt aussehen. Header, die Ihr Server schon sendet, werden erkannt und in Ruhe gelassen. Prüfen Sie das Ergebnis von außen mit dem Security-Header-Check.

Wenn Ihnen das alles nichts sagt: Schalten Sie die drei Basis-Header ein und lassen Sie den Rest aus. Das allein ist mehr, als die meisten Websites senden.

10. HTTPS, eine aktuelle PHP-Version und die echte Client-Adresse

Drei Dinge gehören zur Hosting-Ebene, und kein Plugin kann sie für Sie erledigen. HTTPS mit gültigem Zertifikat auf jeder Subdomain, weil jeder Schritt oben voraussetzt, dass das Sitzungs-Cookie verschlüsselt reist. Eine PHP-Version, die noch Sicherheitskorrekturen bekommt, weil ein nicht mehr gepflegtes PHP eine Schwachstelle ist, für die kein Patch mehr kommt. Und hinter Cloudflare oder jedem Reverse-Proxy der Header, der die echte Besucheradresse transportiert.

Der letzte Punkt entscheidet, ob jeder andere Schritt funktioniert. Sieht das Plugin die Adresse des Proxys statt die des Besuchers, sperrt es den Proxy und lässt den Angreifer durch. Die Proxy-Einstellung von Hive nimmt den Header und die Proxy-Bereiche entgegen; die Seite Systemstatus warnt, wenn ein Header ohne Bereiche gesetzt ist. Wer die Hosting-Ebene lieber gar nicht selbst verantworten will: Die Wartungspakete von CMS ADMINS enthalten Hosting auf deutschen Servern mit aktuell gehaltener PHP-Version.

11. Eine Firewall vor PHP setzen und sie unter Angriff nachziehen lassen

Die 574 Exploit-Versuche und die 1.978 gefälschten Suchmaschinen-Bots sind das, wofür eine Web Application Firewall da ist. Die Firewall von Hive prüft jede Anfrage auf SQL-Injection, Cross-Site-Scripting, Path Traversal, Command Injection und Scanner-Werkzeuge, und die Engine mit ihrem OWASP-Basisregelsatz ist in jedem Tarif kostenlos. Ein optionales Drop-in sperrt, bevor WordPress überhaupt lädt, mit fertig erzeugter Apache- und nginx-Konfiguration. Die Prüfung verifizierter Bots bestätigt Googlebot und Bingbot über ihre offiziellen Adressbereiche und markiert oder sperrt die Nachahmer.

Professional ergänzt zwei Dinge. Die tieferen Regelsätze kommen signiert über Priority Sync, sobald sie veröffentlicht sind, und der Härtungsmodus reagiert auf einen koordinierten Angriff: Treffen viele Adressen in kurzer Zeit den Login, zieht das Plugin seine Schwellen website-weit für eine Stunde an und lässt sie danach wieder los. Verteilte Brute Force aus einem Botnetz bricht mitten im Lauf ab, statt unter der Grenze je Adresse durchzuschlüpfen. Die Anleitung zur Firewall und die Anleitung zum Härtungsmodus behandeln beides im Detail.

12. Backups, die Sie wiederhergestellt haben, Überwachung und eine Bereitschaftsprüfung

Ein Backup zählt erst, wenn Sie es einmal wiederhergestellt haben. Bewahren Sie tägliche Kopien außerhalb des Webservers auf, lange genug, um vor eine spät bemerkte Kompromittierung zurückzukommen, und spielen Sie mindestens einmal im Quartal eine davon auf einer Staging-Website ein, damit das Vorgehen bekannt ist, bevor es gebraucht wird.

Die Überwachung ist die andere Hälfte. Die Seite Systemstatus in Hive listet, was üblicherweise still versagt: einen stehen gebliebenen Cron, einen Proxy-Header ohne Bereiche, einen fehlschlagenden Mailversand, einen Administrator ohne eigenen zweiten Faktor. Jeder Befund trägt eine Schwere, den Zeitpunkt des ersten Auftretens und einen Link zur verantwortlichen Einstellung. Im Business-Tarif hält das Audit-Protokoll fest, wer welche Einstellung, welches Plugin, welche Datei oder welches Konto geändert hat, mit altem und neuem Wert, und genau das brauchen Sie am Morgen nach einem Vorfall.

Das Ergebnis messen: der Härtungs-Score

Jeder Schritt dieser Checkliste, den das Plugin sehen kann, wird im Dashboard von Hive bewertet. Der Härtungs-Score gewichtet dreizehn Punkte, vom erzwungenen zweiten Faktor bis zu den verborgenen Fingerabdrücken, vergibt eine Note von A+ bis F und verlinkt jeden Punkt mit seiner Einstellung. Eine frische Installation mit den Voreinstellungen startet absichtlich niedrig: Der Score misst, was Sie eingeschaltet haben, nicht, was das Plugin könnte.

Die zwei Schaltflächen unter den Anzeigen öffnen Mozilla Observatory und securityheaders.com, damit Sie den Header-Teil des Scores mit einem Werkzeug bestätigen können, das nicht von uns ist. Wie der Score aufgebaut ist, steht in der Dokumentation zum Score.

Welche Schritte Hive Professional brauchen

Das meiste dieser Checkliste läuft mit dem kostenlosen Plugin. Professional, 14,90 Euro im Monat inkl. MwSt. für drei Domains, ergänzt die Teile, die verwaltete Infrastruktur oder einen Regel-Feed brauchen.

Punkt der Checkliste	Free	Professional
Sechzehn Sensoren und progressive Sperre	Ja	Ja
Schalter zum Abriegeln und Anmeldung verbergen	Ja	Ja
Zweiter Faktor per App, Passkey und E-Mail	Ja	Ja
Zweiter Faktor per SMS	Nein	Ja
Adaptive Nachprüfung je Rolle	Nein	Ja
Basis-Security-Header	Ja	Ja
HSTS, Permissions-Policy, CSP, Cross-Origin-Header	Nein	Ja
Firewall-Engine und OWASP-Basis	Ja	Ja
Tiefere Regelsätze über Priority Sync	Nein	Ja
Härtungsmodus bei koordinierten Angriffen	Nein	Ja
Härtungs-Score und Systemstatus	Ja	Ja

Fragen zum Absichern von WordPress

Reicht ein Security-Plugin, um WordPress abzusichern?

Ein Security-Plugin deckt acht der zwölf Schritte dieser Liste ab: den Login, den zweiten Faktor, die Enumeration, die Abriegelungs-Schalter, die versteckte Login-Seite, die Header, die Firewall und den Score. Updates, Dateirechte, HTTPS und Backups liegen außerhalb des Plugins, auf dem Server und in einer Routine, und kein Plugin kann sie übernehmen.

Bricht das Abschalten von XML-RPC Jetpack oder die WordPress-App?

Ja, beide nutzen XML-RPC und funktionieren nicht mehr, wenn der Endpunkt abgeschaltet ist. Der zweite Schalter von Hive lässt XML-RPC laufen und entfernt nur die Multicall-Methode, die Hunderte Passwort-Versuche in eine Anfrage packt, also den Teil, den Angreifer nutzen.

Wie oft sollte ich die Checkliste erneut durchgehen?

Schritt 1 läuft wöchentlich und Schritt 12 vierteljährlich. Die anderen zehn werden einmal gesetzt und bleiben gesetzt; der Härtungs-Score im Dashboard zeigt auf einen Blick, wenn einer davon wieder abgeschaltet wurde, etwa nach einem Plugin-Konflikt.

Brauche ich hinter Cloudflare noch ein Firewall-Plugin?

Cloudflare filtert am Rand und sieht nie einen fehlgeschlagenen WordPress-Login, einen Kommentar oder ein abgeschicktes Formular, und genau dort passieren die meisten Ereignisse aus der Tabelle oben. Die beiden Ebenen ergänzen sich, sofern dem Plugin gesagt wird, dass es dem Cloudflare-Header für die Besucheradresse vertrauen soll.

Weiterlesen

• Schnellstart-Anleitung für Hive
• Register der Systembereitschaft
• Schutz vor Formular-Spam
• ReportedIP Hive holen