Zum Hauptinhalt springenZur Fußzeile springen
Anleitungen zu Plugins

Ein Blick in die ReportedIP Web Application Firewall

Patrick Schlesinger
Titelseite des ReportedIP -Plugin-Handbuchs – Web Application Firewall, kostenlos und unter GPL-2.0

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.

The engine and its baseline ruleset are free on every plan. This guide covers how the firewall inspects traffic, where the rules come from, how a bad regex is stopped from taking the site down, how to clear a false positive from the admin, and how the optional pre-WordPress guard works. It reflects Hive as of version 2.1.21, after the 2.1.5–2.1.21 hardening run.

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-StufeCharakterBienenstockplan
PL1Die auf ein Minimum an Fehlalarmen abgestimmte Basiskonfiguration deckt die OWASP Top 10 abKostenlos (im Basisangebot enthalten)
PL2Wachsamer, dafür ein paar mehr FehlalarmeMitwirkender (wöchentlich) / Profi
PL3Seltene Angriffe, Verschleierung und Umgehung von WAFs, gelegentliche FehlalarmeProfessional (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_limit auf 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() Ergebnisse false, nicht 0 oder 1 — ein stiller Bypass, wenn nicht markiert. Hive behandelt false als „Fail-Open“ plus eine protokollierte waf_pattern_error Ereignis. 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.

Clear a false positive from the admin, without touching code

Any signature firewall will occasionally flag a legitimate first-party request — a page builder posting rich HTML, or a security plugin that legitimately ingests attack-like payloads. Since version 2.1.9, Hive handles this the way ModSecurity exclusions and the Wordfence allowlist do: a backend-managed exception list, no code and no report-only detour required.

  • One click per log row. Every WAF block in the log carries an Allow action that creates a narrow exception for exactly that rule on that path. The block log records the matched value, the inspected target, the request method, URI, user-agent and paranoia level, so a decision is diagnosable without reproducing the request.
  • Scoped, never global. An exception targets a single rule, a rule group, or — for a first-party endpoint — the whole engine on a path, optionally narrowed to an IP or CIDR. A whole-engine exception must carry a path or IP, so the firewall can never be switched off site-wide by accident.
  • Network-wide and free. Exceptions are stored as network-wide data (option reportedip_hive_waf_exceptions, schema db_version 10) and available on every plan — the protection engine itself stays free.
  • Applies to the pre-WordPress guard too. Extended Protection bakes the same exceptions in and rebakes them whenever the allowlist changes, so a client you allowed in the admin is honoured before WordPress even loads.

The exception form is self-explanatory: the scope selector reveals only the relevant field, and the ambiguous “Rule ID or group” input is split into a Rule ID field and a group dropdown populated from the engine’s known categories. Developers get a code-level escape hatch as well — the reportedip_hive_waf_bypass_routes filter, matched by an anchored str_starts_with test against the resolved REST route, so a bypass token in an unrelated query parameter cannot disable the WAF.

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 directive — the same approach Wordfence calls Extended Protection. It is off by default and additive to the in-WordPress engine, and it inspects request bodies just like the main engine (a hoisting bug that made body inspection a silent no-op was fixed in 2.1.10).

  • Apache erhält ein php_value auto_prepend_file Zeile, die in ein markiertes .htaccess Block.
  • PHP-FPM — including nginx. Hive detects the PHP-FPM SAPI ahead of the nginx server string and writes a document-root .user.ini, which PHP-FPM honours for every request regardless of nginx location blocks. Since 2.1.17 this covers nginx automatically, with no manual step — earlier versions could only offer a hand-pasted location snippet that protected just the one block it landed in.
  • Fallback snippet. On stacks without a FastCGI PHP SAPI, Hive still generates a copy-paste php.ini / PHP-FPM-pool line and an nginx fastcgi_param PHP_VALUE block; the Server Setup tab surfaces these whenever the auto-written .user.ini is not yet taking effect.

Three safety behaviours make the guard predictable. It skips body inspection for signed-in users — it detects the wordpress_logged_in cookie, so an editor saving a post through admin-ajax.php or the REST API is never tripped by an XSS/SQLi signature (URL and user-agent rules still run, and the in-WordPress engine stays the capability-aware backstop). It self-heals on toggle: disabling the WAF or switching it to report-only neutralises the pre-WordPress guard as well, so the firewall can never keep enforcing after it was switched off. And removal is fail-safe: deactivating the plugin strips the directives Hive controls and leaves an inert placeholder instead of deleting the guard file, so a leftover auto_prepend_file line in an nginx or php.ini config Hive cannot edit can never point at a missing file and 500 the site.

The setup is verifiable: the status reports whether the guard actually executed for the current request — “Setup complete” the moment it works — instead of guessing. The setup wizard walks new installs through it with safe defaults.

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 header. A visitor who is blocked by mistake quotes one short string, and an admin matches it in the logs — then clears it with the one-click Allow action if it was a false positive. The token is a one-way hash of the IP, the reason and the hour, so it exposes no personal data.

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?

No. Logged-in administrators are exempt, /wp-admin is never inspected, and the pre-WordPress guard skips body inspection for any signed-in user. If a front-end form or a first-party endpoint does trip a rule, open the WAF log, click Allow on that row to create a narrow exception, and you are done — no code and no report-only detour needed.

Does the firewall run on nginx?

Yes, and since 2.1.17 the pre-WordPress guard configures itself on nginx automatically by writing a document-root .user.ini that PHP-FPM honours for every request. If your stack disables per-directory INI files, the Server Setup tab shows a php.ini or nginx fastcgi_param line to paste instead.

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.

Los geht’s

Eine Antwort hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit * gekennzeichnet

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren