16 Attack Sensors, die WordPress-Angriffe in Echtzeit erkennen
Die Erkennung von Angriffen auf WordPress ist nur so gut wie die Signale, die sie überwacht. ReportedIP Hive betreibt 16 unabhängige Sensoren für die Bereiche Login, Kommentare, REST, XMLRPC und 404-Fehler – jeder davon mit einem einstellbaren Schwellenwert und einer sinnvollen Standardeinstellung.
In diesem Leitfaden sind alle 16 Sensoren, die werkseitig voreingestellten Schwellenwerte sowie die jeweiligen Angriffe, die sie abwehren, aufgeführt.
Was ist ReportedIP Hive?
ReportedIP Hive ist ein umfassendes WordPress-Sicherheits-Plugin, das Brute-Force-Schutz, eine vollständige 2FA-Suite und auf freiwilliger Basis zugängliche Threat Intelligence aus der Community vereint. Die hier beschriebene Erkennungsfunktion ist in jedem Modus kostenlos verfügbar, einschließlich des vollständig offline arbeitenden „Local Shield“. Der vollständige Funktionsumfang von ReportedIP Hive finden Sie auf der Produktseite.
Die 16 Erkennungssensoren und ihre Standardeinstellungen
Jeder Sensor zählt Ereignisse pro IP-Adresse innerhalb eines gleitenden Zeitfensters. Wird der Schwellenwert überschritten, wird die IP-Adresse in die Sperrliste aufgenommen. Die Standardwerte sind bewusst konservativ gewählt – Sie können jeden einzelnen Wert unter „Einstellungen → Schutz“ verschärfen oder lockern.
- Fehlgeschlagene Logins – 5 Fehlversuche / 15 Min.
- Passwort-Spray – eindeutige Benutzernamen von einer IP-Adresse, 5/10 Min. Die Zähler werden gehasht, sodass keine Benutzernamen im Klartext gespeichert werden.
- Kommentarspam – 5 / 60 Min., wird vor der Ausführung des Kommentarfilters ausgewertet.
- XMLRPC-Missbrauch – 10 / 60 Min., wobei
system.multicallseparat überwacht. - Missbrauch von Anwendungspasswörtern – REST/XMLRPC-Basic-Auth-Versuche, die darauf abzielen, die 2FA zu umgehen, 5 bzw. 15 Minuten.
- REST API Rate Limit – global 240 pro 5 Minuten, sensible Routen 20 pro 5 Minuten.
- Schutz vor User Enumeration – blockiert
?author=N,/wp-json/wp/v2/userssowie oEmbed-Abfragen und maskiert Login-Fehler. - 404 / Scanner-Erkennung — 12 / 2 Min., zuzüglich einer sofortigen Sperrung bei bekanntermaßen schädlichen Pfaden wie
.env,wp-config.bakund/.git/. - Web Application Firewall – überprüft die URI, den Abfrage-String, den Body und den User-Agent anhand eines signierten, vom Server bereitgestellten Regelsatzes (SQLi, XSS, Path Traversal, Befehlsinjektion, SSRF, Log4Shell und mehr). Die Engine und die OWASP-Top-10-Basisregeln sind in jedem Tarif Free enthalten; die umfassenderen Regelwerke der Paranoia Level 2 und 3 werden im Professional-Tarif über Priority Sync bereitgestellt.
- Verified Bot Detection – zunächst werden Googlebot, Bingbot und andere Crawler anhand ihrer offiziellen IP-Bereiche überprüft, anschließend erfolgt ein auf Forward-DNS-Bestätigung basierender Reverse DNS-Fallback. Spoofer werden markiert oder blockiert; echte Crawler werden niemals blockiert.
- Disposable-Email Blocking – überprüft die bei der Registrierung (WordPress und WooCommerce) angegebene Adresse anhand der Liste der Wegwerf-E-Mail-Adressen und bietet dabei die Modi „Aus“, „Überwachen“ und „Blockieren“. Datenschutz-Relays wie „Apple Hide My Email“ werden standardmäßig durchgelassen.
- Comment Honeypot – ein unsichtbares, von Bildschirmleseprogrammen nicht erfasstes Scheinfeld im Kommentarformular; Spam-Bots, die jedes Feld ausfüllen, werden abgewiesen, ohne dass echte Besucher durch ein CAPTCHA behindert werden.
- Geografische Anomalie – ein Login aus einem Land, das für diesen Nutzer bisher noch nicht verzeichnet wurde; dabei können optional die Cookies für Trusted Devices widerrufen werden.
- Passwortrichtlinie – Mindestlänge, Zeichenklassen und eine optionale „Have-I-Been-Pwned“-Prüfung auf k-Anonymität.
- WooCommerce-Login-Hooks – Die Formulare für den Bestellvorgang und „Mein Konto“ werden getrennt von
wp-login.php. - Endpoints für die Einwilligung über Cookie-Banner – „Real Cookie Banner“, „Complianz“, „Borlabs“ und „CookieYes“ sind standardmäßig von den REST-Rate Limits ausgenommen.
Warum Suchmaschinen und KI-Crawler sie nicht erkennen
Seit Version 2.0.5 werden Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot und andere verifizierte Crawler von den 404- und REST-Burst-Auslösern ausgeschlossen, sodass ein legitimer Crawl über veraltete URLs niemals dazu führt, dass ein Bot in die Sperrkette gerät. Diese Ausnahme ist beabsichtigt: Eine Anfrage an einen Honeypot-Pfad wie /.env löst weiterhin sofort einen Trigger aus, selbst wenn sie von einem selbsternannten „Googlebot“ stammt – diese Anfrage ist der Indikator für einen Angriff.
Wie das Zählen zu einem Hindernis wird
Die Sensoren im Brute-Force-Stil verwenden alle dieselbe Fehlerzähler-Skala: 3 Fehler → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Nach dem 15. Fehler wird die IP-Adresse in einen regulären Eintrag in der blocked Tabelle über die kanonische handle_threshold_exceeded() Pipeline in einen echten Eintrag in der Tabelle umgewandelt, was dann die progressive Eskalationsleiter auslöst und im Community-Modus einen anonymisierten Bericht in die Warteschlange stellt.
Verwandte Anleitungen
- Stufenweise IP-Sperrung: von einer 5-minütigen Sperre bis zu einer 7-tägigen Sperre
- Hardening Mode: Automatische Verschärfung der Schwellenwerte bei koordinierten Angriffen
- Honeypot-Decoy Paths, die Scanner bereits bei der ersten Abfrage sperren
In der Dokumentation zum WordPress-Plugin werden die Einstellungen der einzelnen Sensoren ausführlich beschrieben. Sehen Sie sich die vollständigen Anleitungen zum ReportedIP Hive-Plugin an oder lesen Sie den Quellcode auf GitHub.