Ein Blick in die ReportedIP Hive Web Application Firewall
ReportedIP Hive bietet eine Web Application Firewall, die jede Anfrage auswertet, bevor WordPress darauf reagiert. Dabei werden die URL, die Abfragezeichenfolge, der Anfragetext und der User-Agent mit einem signierten Regelsatz abgeglichen, wodurch SQL Injection, XSS, Path-Traversal, Command-Injection und ein Dutzend weiterer Angriffsarten blockiert werden – und die Regeln aktualisieren sich automatisch, ohne dass eine Plugin-Version veröffentlicht werden muss.
Die Engine und ihr Standard-Regelsatz sind in jedem Tarif kostenlos enthalten. In diesem Leitfaden wird erläutert, wie die Firewall den Datenverkehr überprüft, woher die Regeln stammen, wie verhindert wird, dass ein fehlerhafter regulärer Ausdruck die Website lahmlegt, wie Sie ein False Positive über den Admin-Bereich beseitigen können und wie der optionale „Pre-WordPress-Guard“ funktioniert. Die Informationen beziehen sich auf Hive in der Version 2.1.21, nach der Sicherheitsoptimierung in den Versionen 2.1.5 bis 2.1.21.
Was die WordPress-Firewall bei jeder Anfrage überprüft
Die WAF läuft auf dem init Hook mit Priorität 1, unmittelbar nach der IP-Block-Prüfung von Hive. Eine Anfrage von einer bereits gesperrten IP-Adresse erreicht die Firewall gar nicht erst, sodass kein unnötiger Aufwand entsteht. Alles andere wird überprüft: Die Anfrage-URI, der Abfrage-String, der Anfrage-Body und der User-Agent werden abgeflacht und mit dem aktiven Regelsatz abgeglichen.
Die Kosten belaufen sich auf etwa 4 Mikrosekunden CPU-Zeit pro Anfrage, wobei keine zusätzlichen Datenbankabfragen erforderlich sind, wenn ein persistenter Objekt-Cache vorhanden ist. Zu den erfassten Angriffsklassen gehören SQL Injection, Cross-Site-Scripting, Path-Traversal, Befehlsinjection und LFI-Wrapper sowie SSRF, Log4Shell/JNDI, PHP-Objektinjection, NoSQL-Injection, XXE, Web-Shell-Uploads, CRLF und Template-Injection – jeweils mit einem eigenen Blockierungsgrundcode.
Die Überprüfung erfolgt im schreibgeschützten Modus und berücksichtigt False Positives. Angemeldete Administratoren sind davon ausgenommen (Administratoren fügen SQL-Anweisungen und Code rechtmäßig in Editoren ein), /wp-admin wird niemals überprüft, und IP-Adressen auf der Whitelist werden übersprungen. Ein Treffer wird über denselben cache-sicheren, referenzcodierten 403-Pfad blockiert, den auch die anderen Sensoren verwenden, oder lediglich protokolliert, wenn der Report-Only Mode aktiviert ist.
Warum die Firewall Rules auf einem Server und nicht im Plugin gespeichert sind
Die meisten WordPress-Firewalls verwenden fest programmierte Signaturen, sodass für jede Regelaktualisierung eine neue Plugin-Version veröffentlicht werden muss. Hive geht den umgekehrten Weg: Die Signaturen stammen aus der „reportedip.com Rule API“ in Form von versionierten, mit Ed25519 signierten und nach Stufen gestaffelten Regelsätzen, die alle sechs Stunden synchronisiert werden. Neue Angriffssignaturen erreichen jede Installation innerhalb weniger Stunden.
Es gibt vier Regelwerke — waf, bot_signatures, disposable_domains und scan_paths. Jeder ist mit einer separaten Ed25519-Signatur signiert, und das Plugin überprüft diese anhand eines mitgelieferten Satzes öffentlicher Schlüssel (aktueller sowie nächster Schlüssel für die Rotation), bevor es sie anwendet. Wenn die Überprüfung fehlschlägt, der Feed zu groß ist oder der Server nicht erreichbar ist, greift Hive auf einen mitgelieferten Basis-Regelsatz zurück. Ein manipulierter oder gekaperter Feed kann die Regeln nicht verfälschen – selbst wenn ein API Key offengelegt wird oder TLS kompromittiert ist.
Die Basisversion ist im Plugin enthalten, sodass die Firewall im „Local Shield“-Modus vollständig offline funktioniert – ohne Konto und ohne ausgehende Verbindungen. Die Rule Sync-Synchronisierung erfolgt auf freiwilliger Basis: Sie wird nur im „Community“-Modus ausgeführt, wenn ein API Key festgelegt ist.
Free Basisversion, erweiterte Funktionen in der Professional-Version
Die Staffelung der Regeln orientiert sich am „Paranoia Level“-Modell des OWASP Core Rule Set, dem de-facto-Standard für WAFs, der von ModSecurity und Cloudflare verwendet wird.
| Paranoia Level | Charakter | Hive plan |
|---|---|---|
| PL1 | Die auf ein Minimum an False Positives optimierte Basiskonfiguration deckt die OWASP Top 10 ab | Free (im Lieferumfang enthalten) |
| PL2 | Wachsamer, dafür einige wenige False Positives mehr | Contributor (wöchentlich) / Professional |
| PL3 | Seltene Angriffe, Verschleierungstaktiken und Abdeckung von WAF-Umgehungen, gelegentliche False Positives | Professional (Priority Sync) |
Mit der Free-Version erhalten Sie eine funktionsfähige Firewall mit geringer Rate an False Positives – das ist unser Schutzversprechen. Die Professional-Version bietet zusätzlich die umfassenderen, regelmäßig aktualisierten PL2/PL3-Regelsätze über Priority Sync sowie die Live-Feeds zu Bot-IP-Bereichen und Wegwerf-Domains.
Wie Hive verhindert, dass eine fehlerhafte Regel Ihre Website lahmlegt
Da die Muster aus einem Feed stammen, stellt ein fehlerhafter regulärer Ausdruck ein erhebliches Risiko dar: Ein katastrophales Backtracking (ReDoS) führte einst dazu, dass Stack Overflow 34 Minuten lang nicht erreichbar war. Hive schützt sich in mehreren Ebenen davor:
- Untergrenze für den Rücklauf. Vor der Prüfschleife setzt Hive
pcre.backtrack_limitauf 100.000 (abgesenkt vom Standardwert von 1 Million) und stellt diesen Wert anschließend wieder her, wodurch die Laufzeit im ungünstigsten Fall pro Muster begrenzt wird. - Bei einem Regex-Fehler wird der „Fail-Open“-Modus aktiviert. Wenn ein Muster die Grenze erreicht,
preg_match()wirdfalse, nicht0oder1– eine stille Umgehung, wenn die Option nicht aktiviert ist. Hive behandeltfalsedies als „Fail-Open“ plus ein protokollierteswaf_pattern_errorEreignis. Eine fehlerhafte Regel blockiert niemals legitimen Datenverkehr und sperrt die Website niemals ab: Verfügbarkeit hat Vorrang vor Strenge. - 8 KB Textkörper. Bei Textkörpern, die größer als 8 KB sind, werden die Textkörpergruppen übersprungen, sodass die Basis für das Zurückverfolgen begrenzt ist.
- Serverseitiger Linter. Auf reportedip.com wird jedes Muster vor der Signierung auf katastrophales Backtracking überprüft – ein gefährliches Muster wird gar nicht erst ausgeliefert.
Kuratierte Muster bevorzugen zudem atomare Gruppen und besitzbezogene Quantoren, die ohne Backtracking auskommen, und das JIT von PCRE (das in WordPress standardmäßig aktiviert ist) beschleunigt den Abgleich.
Beseitigen Sie ein False Positive im Admin-Bereich, ohne den Code zu ändern
Jede signaturbasierte Firewall meldet gelegentlich eine legitime First-Party-Anfrage – beispielsweise einen Page-Builder, der Rich-HTML-Inhalte übermittelt, oder ein Sicherheits-Plugin, das legitimerweise angreiferähnliche Payloads verarbeitet. Seit Version 2.1.9 handhabt Hive dies auf die gleiche Weise wie die ModSecurity-Ausnahmen und die Wordfence-Allowlist: über eine vom Backend verwaltete Ausnahmeliste, ohne dass Code oder eine Umleitung zum reinen Melden erforderlich sind.
- Ein Klick pro Protokollzeile. Jede WAF-Sperre im Protokoll enthält eine „Allow“-Aktion, die eine eng gefasste Ausnahme genau für diese Regel auf diesem Pfad erstellt. Das Sperrprotokoll erfasst den abgeglichenen Wert, das überprüfte Ziel, die Anfragemethode, die URI, den User-Agent und den Paranoia Level, sodass eine Entscheidung auch ohne Reproduktion der Anfrage nachvollziehbar ist.
- Auf einen bestimmten Bereich beschränkt, niemals global. Eine Ausnahme bezieht sich auf eine einzelne Regel, eine Regelgruppe oder – bei einem First-Party-Endpoint – auf die gesamte Engine auf einem Pfad, der optional auf eine IP-Adresse oder einen CIDR-Bereich eingegrenzt werden kann. Eine Ausnahme für die gesamte Engine muss einen Pfad oder eine IP-Adresse enthalten, sodass die Firewall niemals versehentlich standortweit deaktiviert werden kann.
- Netzwerkweit und kostenlos. Ausnahmen werden als netzwerkweite Daten gespeichert (Option
reportedip_hive_waf_exceptions, Schemadb_version10) und stehen in jedem Tarif zur Verfügung – die Schutz-Engine selbst bleibt kostenlos. - Dies gilt auch für den „Pre-WordPress“-Schutz. „Extended Protection“ integriert dieselben Ausnahmen und aktualisiert sie bei jeder Änderung der Allowlist, sodass ein Client, den Sie im Admin-Bereich zugelassen haben, bereits berücksichtigt wird, noch bevor WordPress überhaupt geladen wird.
Das Ausnahmeformular ist selbsterklärend: Der Bereichsauswähler zeigt nur das relevante Feld an, und das mehrdeutige Eingabefeld „Regel-ID oder Gruppe“ wird in ein Feld für die Regel-ID und ein Gruppen-Dropdown-Menü aufgeteilt, das mit den der Engine bekannten Kategorien gefüllt ist. Entwickler erhalten zudem eine Ausweichmöglichkeit auf Code-Ebene – den reportedip_hive_waf_bypass_routes Filter, der durch einen verankerten str_starts_with Test gegen die aufgelöste REST-Route abgeglichen wird, sodass ein Bypass-Token in einem nicht damit in Zusammenhang stehenden Abfrageparameter die WAF nicht deaktivieren kann.
Extended Protection: Blockierung, bevor WordPress geladen wird
Die init-Hook-Firewall wird nach dem Start von WordPress ausgeführt. Um Schutz zu bieten, bevor Plugin-Code ausgeführt wird, bietet Hive ein optionales Drop-in an, das die WAF über die PHP-Direktive auto_prepend_file — denselben Ansatz, den Wordfence als „Extended Protection“ bezeichnet. Diese Funktion ist standardmäßig deaktiviert und ergänzt die in WordPress integrierte Engine; sie überprüft Request-Inhalte genau wie die Haupt-Engine (ein Hoisting-Fehler, der dazu führte, dass die Überprüfung der Request-Inhalte stillschweigend ohne Wirkung blieb, wurde in Version 2.1.10 behoben).
- Apache erhält eine
php_value auto_prepend_fileZeile in einen markierten.htaccessBlock geschrieben. - PHP-FPM – einschließlich nginx. Hive erkennt die PHP-FPM-SAPI vor der nginx-Serverzeichenfolge und schreibt ein Dokument-Root
.user.ini, den PHP-FPM bei jeder Anfrage unabhängig von den nginx-Blöcken berücksichtigtlocation. Seit Version 2.1.17 wird nginx automatisch unterstützt, ohne dass ein manueller Schritt erforderlich ist – frühere Versionen konnten lediglich ein manuell eingefügteslocationCode-Schnipsel, der nur den einen Block schützte, in dem er platziert wurde. - Fallback-Snippet. Auf Systemen ohne FastCGI-PHP-SAPI generiert Hive weiterhin eine zum Kopieren und Einfügen bestimmte Zeile für die `php.ini` bzw. den PHP-FPM-Pool sowie einen Nginx-Block
fastcgi_param PHP_VALUEBlock; die Registerkarte „Server-Einrichtung“ zeigt diese an, sobald die automatisch generierten.user.ininoch nicht wirksam ist.
Drei Sicherheitsmaßnahmen machen den Schutzmechanismus vorhersehbar. Er überspringt die Körperkontrolle bei angemeldeten Benutzern – er erkennt das wordpress_logged_in Cookie, sodass ein Redakteur, der einen Beitrag über admin-ajax.php oder die REST API speichert, wird niemals durch eine XSS-/SQLi-Signatur ausgelöst (URL- und User-Agent-Regeln werden weiterhin ausgeführt, und die WordPress-eigene Engine bleibt die auf Berechtigungen basierende Sicherheitsbarriere). Es führt beim Umschalten eine Selbstheilung durch: Das Deaktivieren der WAF oder das Umschalten in den reinen Modus für Reports neutralisiert auch den Pre-WordPress-Schutz, sodass die Firewall nach dem Ausschalten niemals weiter durchgreifen kann. Und die Entfernung ist ausfallsicher: Durch die Deaktivierung des Plugins werden die von Hive gesteuerten Anweisungen entfernt und anstelle des Löschens der Schutzdatei ein inaktiver Platzhalter hinterlassen, sodass eine übrig gebliebene auto_prepend_file Zeile in einer nginx- oder php.ini-Konfiguration, die Hive nicht bearbeiten kann, niemals auf eine fehlende Datei verweisen und einen 500-Fehler auf der Website auslösen.
Die Einrichtung ist überprüfbar: Die Reports geben an, ob die Schutzfunktion für die aktuelle Anfrage tatsächlich ausgeführt wurde – „Einrichtung abgeschlossen“, sobald sie funktioniert –, anstatt nur zu vermuten. Der Setup Wizard führt Sie bei Neuinstallationen mit sicheren Standardeinstellungen durch den Vorgang.
Referenzcodes verwandeln einen fehlerhaften Block in eine einzeilige Suche
Jeder Block enthält einen zuordenbaren Referenzcode, wie beispielsweise WAF_SQLI-3F9A2B71, der auf der Blockseite angezeigt und als X-RIP-Ref Header gesendet wird. Ein Besucher, der versehentlich gesperrt wurde, gibt eine kurze Zeichenfolge an, und ein Administrator gleicht diese in den Protokollen ab – anschließend hebt er die Sperre mit der Ein-Klick-Aktion „Zulassen“ auf, falls es sich um ein False Positive handelte. Das Token ist ein Einweg-Hash aus der IP-Adresse, dem Grund und der Uhrzeit, sodass keine personenbezogenen Daten preisgegeben werden.
Häufig gestellte Fragen
Ist die Web Application Firewall Free?
Ja. Die WAF-Engine und die OWASP-Top-10-Baseline der Stufe 1 sind in jedem Tarif enthalten, einschließlich des Free tier und des vollständig offline arbeitenden „Local Shield“-Modus. Der „Professional“-Tarif bietet zusätzlich die umfassenderen Regelsätze der Stufen 2 und 3 sowie Live-Feeds über „Priority Sync“.
Wird die Firewall meine eigenen Administratoraufgaben blockieren?
Nein. Angemeldete Administratoren sind davon ausgenommen, /wp-admin wird niemals überprüft, und die Pre-WordPress-Sicherheitsüberprüfung überspringt die Body-Prüfung für alle angemeldeten Benutzer. Sollte ein Frontend-Formular oder ein First-Party-Endpoint eine Regel auslösen, öffnen Sie das WAF-Protokoll, klicken Sie in der entsprechenden Zeile auf „Zulassen“, um eine eng gefasste Ausnahme zu erstellen, und schon sind Sie fertig – ganz ohne Programmieraufwand und ohne Umweg über reine Berichtsfunktionen.
Läuft die Firewall auf Nginx?
Ja, und seit Version 2.1.17 konfiguriert sich der Pre-WordPress-Guard automatisch in Nginx, indem er einen Document-Root .user.ini , die PHP-FPM bei jeder Anfrage berücksichtigt. Falls Ihr Stack INI-Dateien auf Verzeichnisebene deaktiviert hat, wird auf der Registerkarte „Server-Einrichtung“ stattdessen eine Zeile für die php.ini oder nginx fastcgi_param Zeile an, die Sie stattdessen einfügen können.
Was geschieht, wenn der Regel-Server nicht erreichbar ist?
Es tritt kein Fehler auf. Das Plugin verwendet weiterhin den zuletzt überprüften Regelsatz oder die mitgelieferte Basiskonfiguration und versucht die Synchronisierung zu einem späteren Zeitpunkt erneut. Die Firewall ist für ihren Betrieb zu keinem Zeitpunkt auf eine aktive Verbindung angewiesen.