Firewall und WAF

Hive prüft Anfragen an zwei Stellen, die sich gleich verhalten: in einer Engine innerhalb von WordPress und in einem optionalen Schutz, der läuft, bevor WordPress lädt. Die Regeln stehen nicht fest im Plugin, sondern kommen signiert von reportedip.com, mit einer mitgelieferten Basis, die offline immer funktioniert. Die Engine ist in jedem Tarif kostenlos.

Die Engine innerhalb von WordPress

Auf init mit Priorität 1 vergleicht die Engine den aktiven Regelsatz mit der URI, dem Query-String, dem Request-Body (auch in einer dekodierten Kopie) und dem User-Agent: SQL-Injection, Cross-Site-Scripting, Path Traversal, Command Injection, File-Inclusion-Wrapper, SSRF, Log4Shell, PHP Object Injection, XXE, Uploads von Web Shells, CRLF und Template Injection, Scanner-User-Agents. Ein Treffer endet auf der gemeinsamen Sperrseite mit 403.

• Sicher gebaut: begrenzte reguläre Ausdrücke, eine fehlerhafte Regel wird übersprungen, und ein Fehler lässt die Anfrage durch, statt die Website lahmzulegen.
• Kein Fehlalarm für Ihre Redaktion: angemeldete Benutzer mit Bearbeitungsrechten, wp-admin, Cron und WP-CLI prüft die Engine nicht; die Whitelist gewinnt immer.
• Nur melden: Die Firewall kann protokollieren, was sie sperren würde (waf_would_block), ohne zu sperren.
• Wo: Engine, Modus und Paranoia Level unter Schutz → Firewall & Bots; Regelsynchronisation und Ausnahmen unter Werkzeuge → Regeln; das Firewall-Protokoll unter Aktivität.

Signierte Regelauslieferung und Priority Sync

Regelsätze kommen versioniert und mit Ed25519 signiert von reportedip.com. Das Plugin prüft jeden Regelsatz gegen einen mitgelieferten öffentlichen Schlüssel und behält die eingebaute Basis, wenn ein Feed fehlt, zu groß ist oder die Prüfung nicht besteht, ein manipulierter Feed kann Ihre Regeln also nicht verändern. Neue Signaturen erreichen jede verbundene Website innerhalb von Stunden, ohne Plugin-Release.

Paranoia Level 3 ist streng und erkennt verschleierte Payloads, um den Preis von mehr Fehlalarmen; er ist für erfahrene Betreiber gedacht. Contributor ist ein kostenloser Tarif für Konten, die Daten beitragen, zum Beispiel über einen Honeypot oder den Linux-Agenten.

Extended Protection: der Schutz vor WordPress

Ein optionaler Schutz über auto_prepend_file wendet dieselben Regeln, Ausnahmen, Whitelist und IP-Sperren an, bevor WordPress lädt, eine gesperrte Anfrage kostet also fast nichts. Seine Treffer landen in einer Warteschlange und werden ins Protokoll und in die Eskalationsleiter übernommen; eine Sperre, die das Plugin setzt, erreicht den Schutz noch in derselben Anfrage. Der Schutz ist standardmäßig aus und wird unter Werkzeuge → Server eingerichtet:

• Apache und PHP-FPM (auch nginx mit PHP-FPM) werden über .htaccess oder eine .user.ini im Document Root automatisch eingerichtet.
• Andere Umgebungen erhalten die Zeile für php.ini oder das Hosting-Panel oder ein nginx-Snippet mit fastcgi_param.
• Angemeldete Benutzer: Der Schutz überspringt die Prüfung des Body, wenn ein Anmelde-Cookie von WordPress vorhanden ist, das Speichern von Inhalten löst ihn also nie aus; Regeln für URL und User-Agent gelten weiter.
• Ein Status, dem Sie trauen können: Der Reiter Server meldet, ob der Schutz für die aktuelle Anfrage wirklich gelaufen ist, und die Systembereitschaft warnt, wenn seine Warteschlange nicht beschreibbar ist.
• Fail-open und sicher zu entfernen: Jeder Fehler lässt die Anfrage durch. Beim Abschalten entfernt Hive die Direktiven, die es verwaltet, und lässt eine wirkungslose Platzhalterdatei zurück, eine übrig gebliebene Zeile in einer von Hand bearbeiteten Konfiguration zeigt also nie auf eine fehlende Datei. Auch der Nur-Melden-Modus schaltet den Schutz ab.

Ausnahmen für Fehlalarme

Ein Formular, das HTML annimmt, ein Page Builder, der rohes Markup sendet, oder eine API, die Angriffsmuster entgegennimmt, kann ab und zu eine Signatur auslösen. Eine Ausnahme lässt genau diesen Fall durch, während der Rest geschützt bleibt.

• Wo: Werkzeuge → Regeln → WAF-Ausnahmen, oder Erlauben an einer Firewall-Zeile im Protokoll, das eine enge Ausnahme für genau diese Regel auf diesem Pfad vorbelegt.
• Umfang: eine Regel, eine Regelgruppe oder, für einen eigenen Endpunkt, die ganze Engine auf einem Pfad, auf Wunsch eingegrenzt auf eine Adresse oder einen Bereich. Eine Ausnahme für die ganze Engine braucht immer einen Pfad oder eine Adresse, die Firewall lässt sich also nie versehentlich global abschalten.
• Eng halten: eine Regel auf einem Pfad vor einer Gruppe, eine Gruppe vor der ganzen Engine. Die Protokollzeile zeigt den getroffenen Wert, den geprüften Teil, Methode, URI und User-Agent und bei admin-ajax.php die AJAX-Aktion.
• Beide Schichten: Ausnahmen werden in den Schutz eingebaut und bei jeder Änderung der Liste neu erzeugt. In einem Netzwerk gelten sie für alle Websites. Jeder Tarif.
• Im Code: Der Filter reportedip_hive_waf_bypass_routes nimmt REST-Routen über ein verankertes Präfix der aufgelösten Route aus; er wirkt nur in der Engine.

Referenzcodes und die Sperrseite

Jede Sperre, ob Firewall oder Sensor, trägt einen Code wie WAF_SQLI-3F9A2B71 auf der Sperrseite und im Header X-RIP-Ref. Ein versehentlich gesperrter Besucher nennt den Code, und Sie finden die Zeile im Protokoll. Der Code ist ein Einweg-Hash aus Adresse, Grund und Stunde und verrät deshalb nichts. Die Texte der Sperrseite lassen sich mit dem Filter reportedip_hive_blocked_page_strings ersetzen.

Seiten-Caches

Die Sperrseite definiert DONOTCACHEPAGE, DONOTCACHEDB und DONOTCACHEOBJECT und sendet Cache-Control: no-store, no-cache, must-revalidate, max-age=0, Pragma: no-cache sowie die nocache_headers() von WordPress. WP Rocket, W3 Total Cache, WP Super Cache und LiteSpeed Cache halten sich daran, ein gesperrter Angreifer hinterlässt also nie ein zwischengespeichertes 403 für echte Besucher. Die Formularprüfung enthält nichts Anfragespezifisches, zwischengespeicherte Seiten funktionieren also weiter.

Zuletzt aktualisiert: 16. Oktober 2026 · Betreut vom ReportedIP-Team