ReportedIP Hive 2.1.21 – Absicherung der WordPress-Firewall
ReportedIP Hive 2.1.21 bildet den Abschluss einer Serie von 17 Releases zur Verbesserung der Sicherheit. Seit der Einführung der Firewall in den Versionen 2.1.2 bis 2.1.4 wurde in jeder Version von 2.1.5 bis 2.1.21 daran gearbeitet, diese neue WAF-Ebene produktionsreif zu machen: Der Schutz vor WordPress-Angriffen deckt nun automatisch auch nginx ab, False Positives werden aus dem Admin-Bereich entfernt, und ein schwerwiegender Fehler, der bei Datenbanken außerhalb der UTC-Zeitzone zu automatischen Sperrungen führte, wurde behoben.
Der gesamte Erkennungskern bleibt frei verfügbar und unterliegt der GPL-2.0. Führen Sie ein Update über „Plugins → Nach Updates suchen“ durch oder laden Sie die neueste ZIP-Datei von der GitHub Releases-Seite herunter. Falls Sie die Firewall selbst verpasst haben, beginnen Sie mit der Beschreibung zur Firewall-Version 2.1.4.
Was hat sich seit Hive 2.1.4 geändert?
Zwischen Version 2.1.5 (11.06.2026) und Version 2.1.21 (03.07.2026) wurden siebzehn Versionen veröffentlicht. Keine davon führte eine neue Säule ein – der Schwerpunkt lag auf der Absicherung der WAF, Extended Protection und der automatischen Blockierung, die mit den Versionen 2.1.2 bis 2.1.4 eingeführt wurden.
| Version | Änderung der Überschrift |
|---|---|
| 2.1.5 | Ein schwerwiegender ArithmeticError im CIDR-Matcher behoben; echte Crawler werden nicht mehr fälschlicherweise als User Enumeration blockiert; Loopback- und private IP-Adressen werden niemals als Angreifer gemeldet. |
| 2.1.6 | Der „Verified-Bot“-Klassifikator wurde auf drei Zustände umgestellt, sodass echte Bing-/Crawler-IP-Adressen außerhalb des Startbereichs nicht mehr fälschlicherweise als „falscher Bot“ eingestuft werden. |
| 2.1.7 | Einheitliche Abzeichen für die verschiedenen Ebenen im Admin-Bereich; gruppierter Filter für Ereignisarten in den Protokollen; Fehlerbehebung beim Export von Protokollen im JSON-/CSV-Format. |
| 2.1.8 | Das Deaktivieren der Extended Protection führt nicht mehr dazu, dass eine Website offline geschaltet wird – der Schutzmechanismus wird, ähnlich wie bei Wordfence, zu einem inaktiven Platzhalter umgewandelt. |
| 2.1.9–2.1.11 | Vom Backend verwaltete WAF Exceptions: Beseitigen Sie ein False Positive über die Admin-Oberfläche, ganz ohne Programmieraufwand; selbsterklärendes Formular für Exceptions und FAQ. |
| 2.1.12 | Mit der MainWP-Bereitstellung kann eine verwaltete Website in den Community Network-Modus versetzt werden. |
| 2.1.13 | Das Sicherheits-Dashboard wurde zu einer umfassenden Analyseansicht überarbeitet; der „Hardening Mode“ wird bei routinemäßigen Brute-Force-Angriffen im Hintergrund nicht mehr ausgelöst. |
| 2.1.14–2.1.15 | Die automatische Sperrung wurde auf Nicht-UTC-Datenbankservern UTC-kompatibel gestaltet; Zeitstempel von Administratoren werden in der Zeitzone der Website angezeigt. |
| 2.1.16 | Eine außer Kontrolle geratene /relay-quota Abfrage, die bei jeder Frontend-Anfrage ausgelöst werden könnte. |
| 2.1.17 | „Extended Protection“ deckt automatisch jeden PHP-Endpoint auf Nginx ab; der Guard überspringt die Überprüfung des Body-Inhalts für angemeldete Redakteure. |
| 2.1.18 | Der Zustand „API-Zustand verschlechtert“ normalisiert sich von selbst wieder (rollendes Fenster); das Sicherheitsprotokoll kann nicht mehr durch eine Fehler-Schleife überflutet werden. |
| 2.1.19 | Das Problem mit dem versteckten Login hinter Permalinks mit abschließendem Schrägstrich und Seiten-Caches (WP Rocket & Co.) wurde behoben. |
| 2.1.20–2.1.21 | Anweisungen zur Einrichtung des nginx-Servers werden nun angezeigt, wenn die automatische Konfiguration deaktiviert ist; der Setup Wizard und die 2FA-Funktion wurden überarbeitet. |
„Extended Protection“ ist gewachsen: Die WAF-Lösung für die Zeit vor WordPress deckt nun automatisch auch nginx ab
„Extended Protection“ leitet den Datenverkehr durch eine auto_prepend_file Prüfung, bevor WordPress geladen wird. Bei nginx bedeutete dies früher das Einfügen eines handgeschriebenen location Code-Schnipsel einzufügen – der jedoch nur den jeweiligen Block schützt, in dem er platziert wurde, sodass Anfragen, die von eigenen Blöcken verarbeitet wurden (wp-login.php, der zwischengespeicherte Front-Controller), an der Firewall vorbeischlüpften.
Version 2.1.17 erkennt die PHP-FPM-SAPI vor der nginx-Serverzeichenfolge und schreibt stattdessen ein Dokument-Root .user.ini . PHP-FPM berücksichtigt auto_prepend_file diesen dort für jede Anfrage, unabhängig von den nginx-Blöcken location , ohne dass ein manueller Schritt erforderlich ist. Der Nginx-/php.ini-Ausschnitt dient weiterhin nur als Fallback für Stacks ohne FastCGI-PHP-SAPI, und ab Version 2.1.20 werden diese manuellen Anweisungen angezeigt, sobald die automatisch generierte Direktive noch nicht wirksam ist.
Die Schutzmaßnahme blockiert angemeldete Redakteure nicht mehr und wird bei einer Entfernung nicht mehr deaktiviert.
Da der Schutzmechanismus vor WordPress ausgeführt wird, hat er zuvor jeden Anfragetext überprüft – sodass ein angemeldeter Autor, der einen Beitrag über admin-ajax.php oder die REST API speichern wollte, eine XSS-/SQLi-Signatur auslösen und einen 403-Fehler erhalten. Version 2.1.17 erkennt das wordpress_logged_in Cookie und überspringt die Überprüfung des Request-Körpers bei authentifizierten Anfragen (URL- und User-Agent-Regeln werden weiterhin ausgeführt), wobei die in WordPress integrierte Engine weiterhin als fähigkeitsorientierte Sicherheitsbarriere fungiert. Das Deaktivieren der WAF oder das Umschalten in den reinen Berichtsmodus deaktiviert nun auch den vor WordPress laufenden Schutzmechanismus.
Auch die Deinstallation ist nun sicher. Vor Version 2.1.8 führte die Deaktivierung des Plugins, während sich die auto_prepend_file Direktive in einer Datei stand, die Hive nicht bearbeiten kann (eine Nginx-Konfiguration fastcgi_param oder eine manuell bearbeitete `php.ini`), führte dazu, dass PHP auf einen gelöschten Schutzmechanismus verwies und jede Anfrage mit einem 500-Fehler zum Absturz brachte. Beim Entfernen werden nun die von Hive kontrollierten Direktiven entfernt und ein inaktiver Platzhalter zurückgelassen, sodass eine übrig gebliebene Direktive niemals auf eine fehlende Datei verweisen kann.
False Positives des WAF werden nun über die Verwaltungskonsole gelöscht, ohne dass Code erforderlich ist
Eine Signatur-Firewall stuft gelegentlich eine legitime First-Party-Anfrage als verdächtig ein – ein Sicherheits-Plugin, das angreiferähnliche Payloads erfasst, ist hierfür ein klassisches Beispiel. In den Versionen 2.1.9 bis 2.1.11 wurde ein vom Backend verwaltetes Ausnahmesystem eingeführt, das ähnlich wie die ModSecurity-Ausschlüsse und die Wordfence-Allowlist funktioniert.
- Jede Zeile im WAF-Protokoll enthält eine „Allow“-Aktion, die eine eng gefasste Ausnahme für genau diese Regel auf diesem Pfad schafft.
- Eine Ausnahme gilt für eine einzelne Regel, eine Regelgruppe oder – bei einem First-Party-Endpoint – für die gesamte Engine auf einem Pfad, der optional auf eine IP-Adresse oder einen CIDR-Block eingegrenzt werden kann. Eine Ausnahme für die gesamte Engine muss stets einen Pfad oder eine IP-Adresse enthalten, damit die Firewall niemals versehentlich global deaktiviert werden kann.
- Ausnahmen bilden netzwerkweite Daten (Option
reportedip_hive_waf_exceptions,db_version10), die in jedem Tarif verfügbar sind – die Schutz-Engine selbst bleibt kostenlos.
In Version 2.1.10 wurde ein Hoisting-Fehler behoben, bei dem die „Pre-WordPress“-Prüfung bei jedem POST-Body einen schwerwiegenden Fehler auslöste – die Überprüfung des Body in dieser Ebene war zuvor eine stille No-Op-Operation gewesen –, und es wurde sichergestellt, dass das Drop-in nun dieselben Ausnahmen berücksichtigt wie die WordPress-Engine. In Version 2.1.11 wurde das mehrdeutige Feld „Regel-ID oder Gruppe“ in ein Eingabefeld für die Regel-ID und ein Dropdown-Menü für die Gruppe aufgeteilt, das mit den bekannten Kategorien der Engine gefüllt ist, sodass nun klar ist, was eingegeben werden muss und woher der Wert stammt.
Die automatische Sperrung schlug bei Datenbanken, die nicht auf UTC basierten, stillschweigend fehl.
Die folgenreichste Korrektur in diesem Durchlauf ist 2.1.14. Zeitstempel für Ablauf und Versuche werden in UTC geschrieben, wurden jedoch mit der MySQL-Sitzungsuhr abgeglichen (NOW() / CURDATE()). Auf einem Server, dessen Datenbank-Zeitzone nicht UTC ist, führte diese Diskrepanz dazu, dass der Versuchs-Zähler pro IP-Adresse innerhalb seines Zeitfensters nie hochgezählt wurde – sodass die Schwellenwerte für fehlgeschlagene Logins und XML-RPC nie erreicht wurden und kein Angreifer jemals gesperrt wurde –, während jeder neu geschriebene Eintrag als bereits abgelaufen behandelt wurde, wodurch die Sperrliste während eines aktiven Angriffs leer blieb.
Alle Datums- und Zeit-Spalten sowie alle Vergleiche sind nun über die gesamte Datenbankebene hinweg UTC-konsistent, und zwar im Detektor für koordinierte Angriffe, beim Wiederherstellungsdurchlauf der Warteschlange, beim Ablauf der Gültigkeit der Trusted Devices sowie in den täglichen Statistiken. Mit Version 2.1.15 wurde es dem Administrator dann ermöglicht, diese Zeitstempel in der Zeitzone der Website statt im rohen UTC-Format darzustellen, und mit 2.1.18 wurden die API-Statistiken auf dieselbe UTC-Konvention umgestellt. Falls Ihre Datenbank auf einer Nicht-UTC-Uhr läuft, ist Version 2.1.14+ die Version, mit der die progressive Sperrung überhaupt funktioniert.
Weniger False Positives, weniger Protokollrauschen, aussagekräftigere Analysen
In mehreren Versionen wurde die Erkennung verschärft, sodass normaler Datenverkehr keine Blockierungen mehr auslöst. Seit Version 2.1.13 wird der „Hardening Mode“ nicht mehr durch routinemäßige Brute-Force-Angriffe im Hintergrund ausgelöst: Die Coordinated-Attack Detection-Detektoren zählen nun einzelne failed_login Ereignisse über ein Echtzeitfenster, anstatt den Lebenszeitzähler jeder IP zu summieren, wobei realistische Standardwerte gelten (verteilt: 10 verschiedene IPs und 50 Versuche in 10 Minuten; Burst: 8 IPs und 30 Versuche in einer Minute). In derselben Version wurde das Sicherheits-Dashboard zu einer umfassenden Analyseansicht überarbeitet – mit einem Schlagzeilenbereich, einer gestapelten Zeitleiste, die in sieben Bedrohungsfamilien gruppiert ist und über einen 7/30/90-Tage-Wahlschalter verfügt, einem Donut-Diagramm nach Angriffsvektoren, einem Balkendiagramm zu WAF-Regelgruppen, einer Aufschlüsselung nach Schweregrad sowie einer Tabelle der häufigsten Angreifer.
Was die Störsignale betrifft, so hat die Version 2.1.16 eine außer Kontrolle geratene /relay-quota Poll, der auf Hotpaths (Firewall, Security Headers, Bot-Überprüfung) tausende Male pro Minute ausgelöst werden konnte, und in Version 2.1.18 wurde „API-Verfügbarkeit beeinträchtigt“ von einem Lebenszeitzähler, der sich endlos festsetzte, auf ein rollierendes Fenster über die letzten 50 Aufrufe innerhalb von 7 Tagen umgestellt – und wiederholte api_call_failed Anfragen auf eine pro Minute begrenzt, sodass eine Fehlerhäufung nicht mehr Zehntausende von Protokolleinträgen erzeugen kann. In Version 2.1.19 wurde das Problem des verdeckten Logins für Websites mit Permalinks mit abschließendem Schrägstrich und hinter einem Seitencache behoben, bei denen eine zwischengespeicherte Anmeldeseite den Cookie-Handshake unbemerkt unterbrach.
So führen Sie ein Update auf Hive 2.1.21 durch
Der integrierte Update-Checker fragt GitHub alle 12 Stunden ab; neue Versionen werden wie jedes andere Update auf Ihrem Plugin-Bildschirm angezeigt. Um Version 2.1.21 sofort herunterzuladen, öffnen Sie „Plugins“ → „Nach Updates suchen“. Abgesehen von der Tabelle „WAF Exceptions“ (db_version 10), die bereits in Version 2.1.9 hinzugefügt wurde, und der Setup Wizard führt Sie bei Neuinstallationen nun mit sicheren Standardwerten durch Extended Protection.