Skip to main contentSkip to footer
Anleitungen zu Plugins

16 Attack Sensors, die WordPress-Angriffe in Echtzeit erkennen

Aktualisiert Patrick Schlesinger
ReportedIP Hive plugin guide cover: 16 WordPress attack detection sensors

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, wobei jeder Sensor über einen einstellbaren Schwellenwert und eine sinnvolle Standardeinstellung verfügt.

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, 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 pro IP-Adresse, 5 bzw. 10 Minuten. 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.multicall separat überwacht.
  • Missbrauch von Anwendungspasswörtern: REST/XMLRPC-Basic-Auth-Versuche, die darauf abzielen, die 2FA zu umgehen, 5 / 15 Min.
  • 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/users sowie oEmbed-Abfragen und maskiert Login-Fehler.
  • 404 / Scanner-Erkennung: 12 / 2 Min., zusätzlich eine sofortige Sperrung bei bekanntermaßen fehlerhaften Pfaden wie .env, wp-config.bak und /.git/.
  • Die 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 kostenlos enthalten; die umfassenderen Regelsätze der Paranoia-Level 2 und 3 werden im Professional-Tarif über Priority Sync bereitgestellt.
  • Die Verified Bot Detection überprüft zunächst Googlebot, Bingbot und andere Crawler anhand ihrer offiziellen IP-Bereiche und greift anschließend auf einen Forward-confirmed reverse DNS-Fallback zurück. Spoofer werden markiert oder blockiert; echte Crawler werden niemals blockiert.
  • Registrierungsschutz, ein einheitlicher Regelkatalog für alle Registrierungsplattformen: Wegwerf-E-Mail-Domains mit den Modi „Deaktivieren“, „Überwachen“ und „Blockieren“ (Datenschutz-Relays wie „Apple Hide My Email“ werden standardmäßig durchgelassen), verbotene Benutzernamen, Regeln zum Zulassen und Blockieren von E-Mail-Adressen sowie ein Rate Limit für die Registrierungsrate pro IP-Adresse.
  • Nachweis der Formularausführung: ein verstecktes Ankerfeld sowie ein per Skript hinzugefügtes Duplikat, das je nach Installation unterschiedlich benannt ist, bei Kommentaren, Anmeldungen und Passwortzurücksetzungen; eine Übermittlung, die keines dieser Felder enthielt, führte nie zur Darstellung des Formulars. Vierfach-Bewertung, in jedem Tarif kostenlos.
  • Die Überprüfung auf Community-Risiken bei Formularen, Kommentaren, Registrierungen und Passwortzurücksetzungen erfolgt anhand des Community Network mit denselben Schwellenwerten, die auch auf der Seite für den Login gelten; eine Adresse, von der aus die Website einen Login ablehnen würde, kann stattdessen auch keinen Kommentar veröffentlichen.
  • Geografische Anomalie: Ein Login aus einem Land, das für diesen Benutzer 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, Checkout- und „Mein Konto“-Formulare werden getrennt von wp-login.php.

Zwei Elemente auf demselben Bildschirm, die keine Sensoren sind. Der Comment Honeypot ist ein unsichtbares, von Screenreadern ignoriertes Scheinfeld im Kommentarformular: Bots, die jedes Feld ausfüllen, werden abgewiesen, und ein echter Besucher sieht niemals ein CAPTCHA. Er gehört zur Honeypot-Ebene und nicht zu den Zählsensoren. Und die Einwilligungs-Endpoints von Real Cookie Banner, Complianz, Borlabs und CookieYes sind standardmäßig von den REST-Rate Limits ausgenommen, da sie auf einer konformen Website bei jedem einzelnen Seitenaufruf wie ein Burst erscheinen. Keiner von ihnen zählt für eine Sperre, weshalb keiner als Sensor gewertet wird.

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 gilt als Anzeichen 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

In der Dokumentation des WordPress-Plugins 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.

Entdecken Sie den ReportedIP Hive →

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Fill out this field
Fill out this field
Bitte geben Sie eine gültige E-Mail-Adresse ein.
You need to agree with the terms to proceed