WordPress-Firewall (WAF): wie Hive Angriffe abwehrt
Die WordPress-Firewall in ReportedIP Hive prüft jede Anfrage auf Injection, Cross-Site-Scripting und Path Traversal, bevor ein Plugin oder Theme darauf reagieren kann. Diese Anleitung erklärt, was sie prüft, woher die Regeln kommen, wie Sie einen Fehlalarm ohne Code-Eingriff beheben und wann sich der optionale Erweiterte Schutz vor WordPress lohnt.
Was leistet eine Web Application Firewall für WordPress?
Eine Web Application Firewall (WAF) liest den Inhalt einer Anfrage, nicht nur ihre Herkunft. Wo eine IP-Sperre fragt „wer klopft an?“, fragt die WAF „was wird geschickt?“. Eine Anfrage mit UNION SELECT in einem Parameter oder ../../wp-config.php in einem Dateinamen wird abgewiesen, auch wenn die Adresse noch niemand gemeldet hat.
Das schließt die Lücke zwischen einer neuen Schwachstelle in einem Plugin und ihrem Update. Die meisten Angriffe auf WordPress zielen auf bekannte Fehler in Plugins und nutzen dieselben wenigen Techniken, die die OWASP Top 10 seit Jahren aufführen. Eine Firewall, die diese Techniken erkennt, schützt eine Website auch dann, wenn ein Update noch aussteht.
Was die Hive-Firewall bei jeder Anfrage prüft
Die Firewall ist einer der 16 Sensoren von ReportedIP Hive und läuft sehr früh beim Laden von WordPress. Bereits gesperrte Adressen werden vorher abgewiesen, sie prüft also nur, was übrig bleibt. Geprüft werden die Anfrage-Adresse mit Query-String, der Request-Body einschließlich JSON und der User-Agent.
Die kostenlose Baseline, die mit dem Plugin ausgeliefert wird, deckt sieben Angriffskategorien ab:
- SQL-Injection
- Cross-Site-Scripting, einschließlich HTML-Injection
- Path Traversal
- Command Injection
- Zugriffsversuche auf sensible Dateien wie Konfigurations-Backups
- Bekannte Scanner-User-Agents
- Missbrauch des Batch-Endpunkts der REST-API
Mit Priority-Sync ab dem Tarif Professional kommen über den Regel-Feed weitere Kategorien hinzu, darunter Server-Side Request Forgery, Log4Shell, PHP Object Injection, XML External Entities, Web-Shell-Uploads, CRLF- und Template-Injection.
Angemeldete Benutzer, die Beiträge bearbeiten dürfen, vom Mitarbeiter bis zum Administrator, werden nicht geprüft, denn Page-Builder und Editoren senden berechtigterweise Markup und Code. Auch der Admin-Bereich ist ausgenommen, mit einer Ausnahme: Anonyme Anfragen an die AJAX- und Formular-Endpunkte werden trotzdem geprüft. IPs auf der Whitelist, Cron-Jobs und WP-CLI passieren ohne Prüfung.
Was passiert, wenn eine Anfrage auf eine Regel trifft
Ein Treffer beendet die Anfrage mit der Hive-Sperrseite und einem Referenzcode wie WAF_SQLI-3F9A2B71. Die Seite ist cache-sicher, ein Caching-Plugin kann dem Angreifer also keine gespeicherte Kopie einer normalen Seite ausliefern. Der Code wird zusätzlich als Header X-RIP-Ref gesendet. Er entsteht aus IP, Grund und Stunde als Einweg-Hash und enthält keine personenbezogenen Daten.
Wiederholte Treffer derselben Adresse führen über die stufenweise Sperrleiter zu einer IP-Sperre. Eindeutige Angriffe wie Path Traversal, Command Injection oder ein Web-Shell-Upload sperren die Adresse schon beim ersten Treffer. SQL-Injection und Cross-Site-Scripting brauchen mehrere Treffer, weil sie die meisten Fehlalarme erzeugen. Im Modus Community Network wird die Sperre mit der Community geteilt.
Jeder Treffer landet im Ereignisprotokoll unter ReportedIP Hive > Aktivität, mit Regel, Regelgruppe, getroffenem Text, Methode und User-Agent. Wollen Sie erst beobachten und dann sperren, schalten Sie in der Karte Firewall & Bots Firewall nur melden ein: Treffer erscheinen dann als „WAF-Treffer (nur melden)“, und die Anfrage geht durch.
Woher die Firewall-Regeln kommen
Die Baseline-Regeln sind Teil des Plugins, die Firewall arbeitet also im Modus Local Shield vollständig offline und ohne Konto. Im Modus Community Network mit Schlüssel kann Hive zusätzlich Regelsätze von der Rule API von reportedip.com holen. Es sind fünf: WAF-Signaturen, Kennungen verifizierter Bots, Wegwerf-Mail-Domains, Scanner-Pfade und Tor-Exit-Nodes. Sie sehen sie mit Version, Regelanzahl und Quelle unter ReportedIP Hive > Werkzeuge, Tab Regeln.
Jeder Regelsatz ist signiert. Hive prüft die Signatur mit einem im Plugin hinterlegten Schlüssel, bevor es eine einzige Regel anwendet. Ein manipulierter oder beschädigter Feed wird verworfen, der zuletzt geprüfte Regelsatz bleibt aktiv, und gibt es keinen, übernimmt die Baseline. Die Firewall hängt nie von einer Live-Verbindung ab.
Die Tiefe der Regeln folgt dem Paranoia-Level-Modell des OWASP Core Rule Set:
| Stufe | Charakter | Tarif |
|---|---|---|
| 1 | Baseline mit wenigen Fehlalarmen | Jeder Tarif, auch Free |
| 2 | Strenger, mehr Kategorien | Ab Professional |
| 3 | Seltene und verschleierte Angriffe, Opt-in | Ab Professional |
Die Stufen 2 und 3 brauchen Priority-Sync, das die vollständigen Regelsätze täglich liefert. Die Stufe stellen Sie mit Paranoia-Stufe der Firewall in der Karte Firewall & Bots auf der Seite Schutz ein.
Wie eine fehlerhafte Regel die Website nicht lahmlegt
Regeln aus einem Feed sind ein eigenes Risiko: Ein schlecht geschriebener regulärer Ausdruck kann die CPU eines Servers pro Anfrage sekundenlang belegen. Hive sichert sich dagegen mehrfach ab. Jede Regel läuft mit einem festen Zeitbudget. Eine Regel, die scheitert, lässt die Anfrage durch, statt sie zu sperren, und das Plugin protokolliert eine Warnung. Große Request-Bodies werden nur bis zu einer Obergrenze gelesen. Und auf der Serverseite wird jede neue Regel automatisch auf gefährliche Muster geprüft, bevor sie signiert und ausgeliefert wird.
Einen Fehlalarm ohne Code beheben
Jede Signatur-Firewall meldet gelegentlich eine legitime Anfrage, etwa ein Suchformular, das Code-Schnipsel annimmt, oder Ihre eigene API, die Angriffsbeispiele empfängt. Hive löst das mit WAF-Ausnahmen, in jedem Tarif.
Schritt 1: das Ereignis finden
Fragen Sie den Besucher nach Referenzcode und Uhrzeit. Öffnen Sie ReportedIP Hive > Aktivität, Ereignisprotokoll, filtern Sie nach dem Ereignistyp WAF-Block und suchen Sie den Eintrag über IP, Zeit und Regel. Der Referenzcode selbst wird im Protokoll nicht gespeichert.
Schritt 2: die Regel erlauben
Klicken Sie in der Zeile auf die Schild-Schaltfläche, beim Überfahren beschriftet mit „Diese Regel auf diesem Pfad erlauben (WAF-Ausnahme)“. Hive legt eine Ausnahme für genau diese Regel an. Der Pfad kommt nur mit hinein, wenn das Protokoll ihn aufgezeichnet hat, und das ist bei aktiver Minimaler Protokollierung, der Voreinstellung, nicht der Fall. Ohne Pfad gilt die Ausnahme für die ganze Website, grenzen Sie sie also im nächsten Schritt ein.
Schritt 3: die Ausnahme prüfen
Alle Ausnahmen stehen in der Karte WAF-Ausnahmen unter Werkzeuge > Regeln. Dort können Sie auch von Hand eine anlegen. Der Geltungsbereich bestimmt, wie weit sie reicht: eine einzelne Regel, eine Regelgruppe oder die gesamte Engine. Eine Ausnahme für die gesamte Engine muss ein Pfad-Präfix oder einen IP-Bereich tragen, damit die Firewall nicht versehentlich für die ganze Website abgeschaltet wird. Das Menü Werkzeuge erscheint im Expertenmodus; ohne ihn führt die Schaltfläche Regeln und Ausnahmen verwalten in der Karte Firewall & Bots dorthin.
Erweiterter Schutz: sperren, bevor WordPress lädt
Die normale Firewall läuft innerhalb von WordPress. Der Erweiterte Schutz ergänzt einen kleinen Wächter, den PHP vor WordPress und vor jedem Plugin-Code ausführt. Er weist passende Anfragen und gesperrte IPs früher und mit weniger Serverlast ab. Er ist standardmäßig aus und in jedem Tarif kostenlos.
Sie schalten ihn unter ReportedIP Hive > Werkzeuge, Tab Server, mit Erweiterten Schutz aktivieren ein. Auf Apache und auf PHP-FPM, also auch bei den meisten nginx-Installationen, schreibt Hive die nötige Servereinstellung selbst. Wo das nicht geht, zeigt das Server-Setup eine Zeile für die php.ini oder die nginx-Konfiguration zum Einfügen. Der Status zeigt Läuft, sobald der Wächter für eine Anfrage gelaufen ist, Sie müssen also nicht raten, ob die Einrichtung geklappt hat.
Drei Dinge unterscheiden sich von der normalen Firewall. Der Wächter sieht keine WordPress-Rollen, nur ob jemand angemeldet ist; mit Den Request-Body angemeldeter Nutzer nicht prüfen, standardmäßig an, überspringt er den Body angemeldeter Benutzer, damit ein Redakteur beim Speichern eines Beitrags nicht abgewiesen wird. Der Wächter wendet dieselben Ausnahmen und dieselbe Paranoia-Stufe an wie die normale Firewall. Und ein Besucher, den er abweist, sieht eine schlichte Seite mit dem Wort „Forbidden“, ohne gestaltete Sperrseite, Referenzcode und Kontakt-Schaltfläche. Der Treffer erscheint trotzdem im Ereignisprotokoll mit Regel, Zeit und IP.
Beim Deaktivieren des Plugins entfernt Hive die Einstellungen, die es selbst geschrieben hat, und hinterlässt eine harmlose Platzhalter-Datei, sodass eine von Hand ergänzte Servereinstellung die Website nicht lahmlegen kann. Entfernen Sie eine solche Zeile nach der Deinstallation selbst.
Fragen zur WordPress-Firewall
Ist die Web Application Firewall von Hive kostenlos?
Die Firewall-Engine, die Baseline-Regeln für sieben Angriffskategorien, WAF-Ausnahmen und der Erweiterte Schutz sind in jedem Tarif kostenlos und funktionieren im Modus Local Shield offline. Der Tarif Professional ergänzt Priority-Sync mit täglich vollständigen Regelsätzen, strengeren Paranoia-Stufen und weiteren Kategorien wie SSRF, Log4Shell und XXE.
Sperrt die Firewall Redakteure bei der Arbeit in WordPress?
Angemeldete Benutzer, die Beiträge bearbeiten dürfen, prüft die normale Firewall nicht, und der Admin-Bereich ist ausgenommen. Beim Erweiterten Schutz bleibt der Body angemeldeter Benutzer standardmäßig ungeprüft. Löst ein Formular im Frontend oder Ihr eigener Endpunkt eine Regel aus, behebt eine WAF-Ausnahme für diese Regel und diesen Pfad das ohne Code.
Funktioniert die Firewall mit nginx?
Die normale Firewall funktioniert auf jedem Server, weil sie innerhalb von WordPress läuft. Für den Erweiterten Schutz unter nginx mit PHP-FPM schreibt Hive die Servereinstellung automatisch. Erlaubt Ihr Hoster das nicht, zeigt das Server-Setup eine Zeile für die php.ini oder die nginx-Konfiguration, die Sie von Hand ergänzen.
Was passiert, wenn der Regel-Server nicht erreichbar ist?
Nichts hört auf zu funktionieren. Hive behält den zuletzt geprüften Regelsatz und greift auf die Baseline-Regeln im Plugin zurück, falls es keinen gibt. Die nächste Synchronisierung versucht es erneut. Weil jeder Regelsatz vor der Nutzung signiert und geprüft wird, kann auch ein manipulierter Feed die Regeln nicht verändern.
Weiterlesen
Die Hive-Dokumentation beschreibt die Firewall und die Regelauslieferung sowie die WAF-Ausnahmen im Detail. Alle weiteren Funktionen erklären die Anleitungen zu ReportedIP Hive.