Ein Blick in die ReportedIP Web Application Firewall
ReportedIP bietet eine Web Application Firewall, die jede Anfrage prüft, bevor WordPress darauf reagiert. Sie gleicht die URL, den Abfrage-String, den Anfragetext und den User-Agent mit einem signierten Regelsatz ab und blockiert so SQL-Injection, XSS, Path-Traversal, Command-Injection und ein Dutzend weiterer Angriffsarten – wobei sich die Regeln ohne die Veröffentlichung eines Plugins automatisch aktualisieren.
Die Engine und ihr Standardregelsatz sind in jedem Tarif kostenlos enthalten. In dieser Anleitung wird erläutert, wie die Firewall den Datenverkehr überprüft, woher die Regeln stammen und wie verhindert wird, dass ein fehlerhafter regulärer Ausdruck die Website lahmlegt.
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 abgeglichen und mit dem aktiven Regelsatz abgeglichen.
Die Kosten belaufen sich auf etwa 4 Mikrosekunden CPU-Zeit pro Anfrage, ohne zusätzliche Datenbankabfragen, sofern ein persistenter Objekt-Cache vorhanden ist. Zu den abgedeckten Angriffsklassen gehören SQL-Injection, Cross-Site-Scripting, Path-Traversal, Befehlsinjection und LFI-Wrapper sowie SSRF, Log4Shell/JNDI, PHP-Objektinjection, NoSQL-Injection, XXE, Webshell-Uploads, CRLF und Template-Injection – jede mit einem eigenen Blockierungsgrundcode.
Die Überprüfung ist schreibgeschützt und berücksichtigt Fehlalarme. Angemeldete Administratoren sind davon ausgenommen (Admins fügen SQL-Befehle und Code rechtmäßig in Editoren ein), /wp-admin wird nie ü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 reine Protokollierungsmodus aktiviert ist.
Warum die Firewall-Regeln 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.de Rule API und werden als versionierte, mit Ed25519 signierte und stufenweise gestaffelte Regelsätze bereitgestellt, 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. Jede Datei ist mit einer separaten Ed25519-Signatur versehen, und das Plugin überprüft diese anhand eines mitgelieferten Satzes öffentlicher Schlüssel (der aktuelle sowie der nächste für die Rotation). vorher bei der Anwendung. Wenn die Überprüfung fehlschlägt, der Feed zu groß ist oder der Server nicht erreichbar ist, greift Hive auf einen integrierten Basisregelsatz zurück. Ein manipulierter oder gekaperter Feed kann die Regeln nicht beeinträchtigen – selbst wenn ein API-Schlüssel 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 Regelsynchronisierung ist optional: Sie wird nur im Community-Modus ausgeführt, wenn ein API-Schlüssel festgelegt ist.
Kostenlose Basisversion, erweiterte Funktionen bei „Professional“
Die Staffelung der Regeln folgt dem „Paranoia Level“-Modell des OWASP Core Rule Set, dem de facto WAF-Standard, der von ModSecurity und Cloudflare verwendet wird.
| Paranoia-Stufe | Charakter | Bienenstockplan |
|---|---|---|
| PL1 | Die auf ein Minimum an Fehlalarmen abgestimmte Basiskonfiguration deckt die OWASP Top 10 ab | Kostenlos (im Basisangebot enthalten) |
| PL2 | Wachsamer, dafür ein paar mehr Fehlalarme | Mitwirkender (wöchentlich) / Profi |
| PL3 | Seltene Angriffe, Verschleierung und Umgehung von WAFs, gelegentliche Fehlalarme | Professional (Priority Sync) |
Mit der Free-Version erhalten Sie eine funktionierende Firewall mit geringer Falsch-Positiv-Rate – das ist unser Schutzversprechen. Die Professional-Version bietet zusätzlich die umfassenderen, regelmäßig aktualisierten PL2/PL3-Regelsätze über Priority Sync sowie 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 katastrophaler Backtracking-Fehler (ReDoS) hat Stack Overflow einmal für 34 Minuten offline gebracht. Hive schützt sich in mehreren Ebenen davor:
- Untere Rückverfolgungsgrenze. Vor der Inspektionsschleife legt Hive fest
pcre.backtrack_limitauf 100.000 (von der Standardwert von 1 Million) und setzt ihn anschließend wieder zurück, wodurch die Laufzeit im schlimmsten Fall pro Muster begrenzt wird. - Bei einem Regex-Fehler auf „Fail-open“ setzen. Wenn ein Muster an seine Grenze stößt,
preg_match()Ergebnissefalse, nicht0oder1— ein stiller Bypass, wenn nicht markiert. Hive behandeltfalseals „Fail-Open“ plus eine protokolliertewaf_pattern_errorEreignis. Ein Regelverstoß blockiert niemals legitimen Datenverkehr und sperrt die Website niemals ab: Verfügbarkeit geht 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.de 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 (in WordPress standardmäßig aktiviert) beschleunigt die Mustererkennung.
Erweiterter Schutz: Blockierung vor dem Laden von WordPress
Die init-Die 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 PHPs auto_prepend_file Richtlinie, derselbe Ansatz, den Wordfence als „Erweiterter Schutz“ bezeichnet. Diese Funktion ist standardmäßig deaktiviert und ergänzt die integrierte WordPress-Engine.
- Apache erhält ein
php_value auto_prepend_fileZeile, die in ein markiertes.htaccessBlock. - PHP-FPM erhält ein
auto_prepend_fileEintrag in.user.inioder eine Zeile in der php.ini bzw. im Hosting-Panel. - nginx lässt sich nicht automatisch konfigurieren (die Konfigurationsdatei befindet sich außerhalb des Web-Stammverzeichnisses und muss neu geladen werden), daher generiert Hive einen Codeausschnitt zum Kopieren und Einfügen, in dem der aktuelle absolute Pfad bereits eingetragen ist.
Das Drop-in wird bei jedem Fehler geöffnet, und beim Entfernen wird die Direktive stets entfernt, bevor die Guard-Datei gelöscht wird – somit kann ein veralteter Prepend, der auf eine fehlende Datei verweist, niemals zu einem fatalen Fehler der Website führen. Seit Version 2.1.4 ist die Konfiguration überprüfbar: Der Status gibt an, ob der Guard für die aktuelle Anfrage tatsächlich ausgeführt wurde, anstatt dies nur anzunehmen.
Referenzcodes verwandeln einen falschen Block in eine einzeilige Suche
Jeder Block enthält einen zuordenbaren Referenzcode wie beispielsweise WAF_SQLI-3F9A2B71, das auf der Blockseite angezeigt und als X-RIP-Ref Kopfzeile. Ein Besucher, der versehentlich gesperrt wurde, gibt eine kurze Zeichenfolge an, und ein Administrator findet diese in den Protokollen wieder. 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 kostenlos?
Ja. Die WAF-Engine und die OWASP-Top-10-Baseline der Stufe 1 sind in jedem Tarif enthalten, einschließlich der kostenlosen Stufe 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, und /wp-admin wird nie überprüft. Wenn ein Frontend-Formular eine Regel auslöst, schalten Sie die WAF in den reinen Berichtsmodus, suchen Sie den Fehlercode in den Protokollen und nehmen Sie von dort aus Anpassungen vor.
Was passiert, wenn der Regel-Server nicht erreichbar ist?
Es kommt zu keinen Ausfällen. Das Plugin verwendet weiterhin den zuletzt überprüften Regelsatz oder die mitgelieferte Baseline und versucht die Synchronisierung später erneut. Die Firewall benötigt für ihren Betrieb keine aktive Verbindung.