WordPress-Plugin: ReportedIP Hive (Full Edition)

ReportedIP Hive ist ein von der Community getriebenes WordPress-Sicherheits-Plugin. Es verwandelt jede geschützte Website in einen Sensor: Wenn eine Website angegriffen wird, lernt der Hive daraus, und jede andere Website kann den Angreifer abwehren, noch bevor die erste Anfrage eintrifft. Echtzeit-Threat Intelligence, sechzehn Attack Sensors einschließlich einer Web Application Firewall, 2FA mit vier Methoden, Progressive Block Escalation und vom Server bereitgestellte, signierte Firewall-Regelsätze. Open Source, veröffentlicht unter GPLv2+ auf GitHub.

Installation

Schnellstart

Der Schnellstart hat in 2.1.54 den zehnstufigen Setup Wizard abgelöst. Er stellt zwei Fragen, Modus und Key, liest Ihren Tarif aus der Key-Prüfung und schaltet eine Empfehlung für diesen Tarif ein. Community Network ist vorausgewählt und braucht einen geprüften Key; Local Shield ist die Alternative und wird nie blockiert. Der Experten-Button wendet dieselbe Empfehlung an und öffnet die Einstellungen; alternativ lässt sich ein vorhandener JSON-Export importieren. Die alte Adresse page=reportedip-hive-wizard leitet auf den Schnellstart weiter.

Ein späteres Tarif-Upgrade schaltet ein, was der neue Tarif empfiehlt, und zwar für jede Einstellung, die Sie nicht selbst geändert haben; das Banner nach dem Upgrade listet auf, was sich geändert hat. Ein erneuter Schnellstart wendet die empfohlenen Werte für Ihren Tarif und die drei Schalter erneut an; alle anderen Einstellungen bleiben unverändert.

Betriebsmodi

Zwei Modi, zwischen denen Sie jederzeit wechseln können, ohne lokale Daten zu verlieren.

Was Sie in den einzelnen Tarifen erhalten

Das Hive-Plugin selbst ist im Free-Tarif voll funktionsfähig: lokaler Schutz, alle sechzehn Sensoren, alle vier 2FA-Methoden. Die kostenpflichtigen Stufen umfassen eine verwaltete Zustellungsinfrastruktur (E-Mail und SMS) sowie höhere Kontingente im Community Network. Auf der Seite „Preise“ finden Sie einen vollständigen Vergleich und Informationen zum Upgrade.

Das „Business“-Paket ist mehrfach buchbar. Alle oben genannten „Business“-Angaben gelten pro Lizenz. Buchen Sie „Business“ x2, x5, x10 oder x20 am Bezahlvorgang (oder ändern Sie dies später im Stripe-Kundenportal), und die Anzahl der täglichen Überprüfungen/Reports, das monatliche 2FA-Kontingent für E-Mail/SMS sowie die Anzahl der Domains skalieren entsprechend Ihrer Lizenzanzahl, z. B. x5 = 75 Domains und 500.000 Überprüfungen pro Tag. Ab der 2-fachen Lizenzanzahl gilt automatisch ein Mengenrabatt. „PRO“ bleibt eine Einzellizenz; die Werte für „Enterprise“ sind unbegrenzt (im Rahmen der angemessenen Nutzung) und werden niemals multipliziert.

Reihenfolge der Bundle-Verwendung (PRO und Business): Zunächst wird das monatlich inbegriffene Kontingent (25 SMS / 500 E-Mails bei PRO, 75 / 2.500 bei Business) verbraucht, anschließend das Guthaben des Prepaid-Bundles. Sobald beides aufgebraucht ist, gibt die API den HTTP-Status 429 zurück, und Hive weicht bei E-Mails auf lokale wp_mail() für E-Mails (oder SMS mit festen Obergrenzen) zurück; andere 2FA-Methoden bleiben funktionsfähig. Paketguthaben verfallen nie. Stripe verwendet tax_behavior = inclusive für die Pakete mit Bruttopreisen (PAngV-konform); Reverse Charge / OSS wird automatisch von Stripe Tax abgewickelt.

6-schichtige Verteidigung

Hive führt seine Prüfungen der Reihe nach durch; jede Ebene kann die Anfrage unterbrechen, bevor sie die nächste erreicht. Angehängt an init Priorität 1 eingebunden, sodass andere Plugins bei einer blockierten IP-Adresse nicht ausgeführt werden.

1. Whitelist, vertrauenswürdige IP-Adressen und CIDR-Bereiche sind stets zugelassen (Ihr Büro, Überwachungsdienste, .).
2. Lokale Sperrliste: IP-Adressen, die Sie manuell gesperrt haben oder die lokale Schwellenwerte überschritten haben. Gespeichert in der wp_reportedip_hive_blocked.
3. Web Application Firewall gespeichert; der aktive WAF-Regelsatz wird mit der URI, der Abfrage, dem Body und dem User-Agent abgeglichen; bei einem Treffer erfolgt die Blockierung über den gemeinsamen, referenzcodierten 403-Pfad. Whitelist- und autorenorientiert, um False Positives zu vermeiden. Ein optionaler Drop-in vor WordPress kann diese Ebene ausführen, noch bevor WordPress überhaupt geladen wird.
4. Zähler für Versuche, Login, Kommentare, XMLRPC, REST-Bursts und 404-Scans lösen eine automatische Sperrung aus, sobald der Schwellenwert erreicht ist.
5. Im Community Network werden IP-Adressen mit einer Konfidenz von ≥ Schwellenwert am Rand blockiert.
6. 2FA-Abfrage: Geschützte Konten müssen einen zweiten Authentifizierungsfaktor angeben, um sich anzumelden.

Die sechzehn Attack Sensors

Jeder Sensor kann unter „Schutz → Erkennung & Schwellenwerte“ unabhängig aktiviert und angepasst werden. Die Tabelle führt zusätzlich drei begleitende Mechanismen, die dieselbe Pipeline nutzen, ohne selbst als Sensor zu zählen: Die Köderpfade melden an die Community, statt lokal zu sperren, und gehören zur Honeypot-Schicht, die versteckte Login-Adresse ist ein Zugriffsschalter und kein Detektor, und die Block Escalation ist die Reaktionsleiter, in die jeder Sensor einfließt. Das Plugin selbst zählt sechzehn Sensoren, und sein Readme ebenso.

Progressive Block Escalation

Wiederholungstäter werden härter bestraft. Die Standard-Staffelung lautet: 5 Min. → 15 Min. → 30 Min. → 24 Std. → 48 Std. → 7 Tage. Nach 30 Tagen ohne Vorfälle wird der Zähler auf Stufe 1 zurückgesetzt. Legitime Besucher, die zum ersten Mal die Sperre auslösen (CGNAT, Admins mit Tippfehlern, Datenverkehr über Mobilfunknetze), werden innerhalb von Minuten wieder freigeschaltet; hartnäckige Angreifer erreichen die 7-Tage-Stufe.

Die Stufenfolge, das Rücksetzfenster und der Hauptschalter befinden sich unter „Schutz“ → „Blockierung & Eskalation“ → „Progressive Blockierung“. Die Empfehlung des Schnellstarts lässt die Stufenleiter eingeschaltet, sodass Neuinstallationen bereits ab dem ersten Speichern eskalieren. Die feste block_duration Einstellung gilt auch dann, wenn die Stufenleiter deaktiviert ist. Eine Granularität im Sub-Stunden-Bereich wird durch die ReportedIP_Hive_Database::block_ip_for_minutes().

Web Application Firewall und Regelauslieferung

Seit Version 2.1.2 verfügt Hive über eine Web Application Firewall mit Request-Prüfung. Sofern init diese mit dem aktiven waf Regelsatz mit der URI, dem Abfrage-String, dem Anfragetext und dem User-Agent ab und blockiert Treffer über den gemeinsam genutzten, cachesicheren und referenzcodierten 403-Pfad. Sie ist gegen ReDoS-Angriffe gehärtet (begrenztes PCRE-Backtracking, „Fail-Open“-Verhalten bei fehlerhaften Regeln), berücksichtigt Whitelists und den Urheber des Inhalts, um False Positives zu vermeiden, und verursacht bei Vorhandensein eines persistenten Objekt-Caches eine zusätzliche CPU-Belastung von etwa 4 µs pro Anfrage ohne zusätzliche Datenbankabfragen.

Die Regeln sind nicht fest im Plugin hinterlegt. Sie werden über die reportedip.com-Rule API bereitgestellt, servergestützt, versioniert, mit Ed25519 signiert und gestaffelt über fünf Regelsätze (waf, bot_signatures, disposable_domains, scan_paths, tor_exits). Das Plugin überprüft jeden Regelsatz vor der Anwendung anhand eines mitgelieferten öffentlichen Schlüssels und greift stets auf eine mitgelieferte Basis zurück, sodass ein manipulierter, übergroßer oder nicht erreichbarer Feed Ihre Regeln niemals beeinträchtigen kann. Neue Angriffssignaturen erreichen alle Installationen innerhalb weniger Stunden, ohne dass eine Plugin-Veröffentlichung erforderlich ist.

• In jedem Tarif kostenlos enthalten sind die WAF-Engine und der OWASP-Top-10-Baseline-Regelsatz des Paranoia-Level 1, der im „Local Shield“-Modus auf Basis der mitgelieferten Baseline vollständig offline nutzbar ist.
• Priority Sync (ab Professional): Die umfassenderen, häufig aktualisierten und signierten Regelwerke des Paranoia-Levels 2/3 (Abdeckung von Verschleierung und Umgehungsversuchen) sowie die Live-Feeds für Bot-IP-Bereiche und Wegwerf-Domains. Die mitgelieferte Basis wird kostenlos synchronisiert; bei „Contributor“ wöchentlich; bei „Professional“ und höher täglich.
• „Extended Protection“ Drop-in (optional): Ein vor WordPress auto_prepend_file Schutz, der die WAF ausführt, bevor WordPress geladen wird. Apache (.htaccess) und PHP-FPM-Stacks, einschließlich nginx + PHP-FPM, werden automatisch über einen Document-Root .user.ini, der jeden PHP-Endpoint unabhängig von den nginx-Blöcken abdeckt location (seit Version 2.1.17); Stacks ohne FastCGI-PHP-SAPI erhalten eine Eintragung in der `php.ini` oder im Hosting-Panel auto_prepend_file Zeile oder ein nginx- fastcgi_param aus dem Reiter „Server-Einrichtung“. Der Guard überspringt standardmäßig die Überprüfung des Request-Bodys bei authentifizierten Anfragen, sodass angemeldete Redakteure beim Speichern von Inhalten den Guard niemals auslösen; URL- und User-Agent-Regeln werden weiterhin ausgeführt, und die WordPress-eigene Engine bleibt die auf Berechtigungen basierende Sicherheitsbarriere. Standardmäßig deaktiviert; beim Entfernen werden die von Hive kontrollierten Anweisungen entfernt und der Guard in einen inaktiven Platzhalter umgewandelt, anstatt ihn zu löschen (seit Version 2.1.8), sodass eine übrig gebliebene Anweisung in einer manuell bearbeiteten `php.ini`- oder Nginx-Konfiguration niemals auf eine fehlende Datei verweisen und einen 500-Fehler auf der Website auslösen kann. Das Deaktivieren der WAF-Engine oder das Umschalten auf den reinen Modus für Reports neutralisiert den Schutz ebenfalls automatisch.
• Referenzcodes: Jeder Block (WAF oder Sensor) trägt einen zuordenbaren Code wie WAF_SQLI-3F9A2B71, der auf der Blockseite angezeigt und als X-RIP-Ref Header ausgegeben. Ein fälschlicherweise blockierter Besucher gibt eine kurze Zeichenfolge an, die ein Administrator in den Protokollen abgleichen kann; das Token ist ein Einweg-Hash aus IP-Adresse, Grund und Uhrzeit, sodass keine personenbezogenen Daten offengelegt werden.

Die Konfiguration finden Sie auf der Seite „Schutz“ in der Karte „Firewall & Bots“ (Engine, Modus, Auswahl des Paranoia-Levels, Bot-Überprüfung, Spam-Abwehr). Rule Sync, WAF-Ausnahmen, der „Extended Protection“-Schutz und alle Webserver-Snippets liegen auf der Seite „Werkzeuge“ (Registerkarten „Regeln“ und „Server“; im Menü im Expertenmodus, per URL immer erreichbar). Das Firewall-Protokoll steht auf der Seite „Aktivität“.

WAF Exceptions: Umgang mit False Positives

Seit Version 2.1.9 kann ein False Positive vom Administrator behoben werden, ohne den Code zu ändern, ähnlich wie bei ModSecurity-Ausschlüssen und der Wordfence-Allowlist. Ein First-Party-Endpoint, der legitimerweise angreifähnliche Payloads empfängt (ein Formular, das HTML akzeptiert, eine Sicherheits-API, die gemeldete Angriffsdaten aufnimmt, ein Page-Builder, der Rohmarkup übermittelt), löst gelegentlich eine Injektionssignatur aus; eine Ausnahme lässt diesen einen Fall durch, während die Engine alles andere weiterhin schützt.

• Wo: Werkzeuge → Regeln → WAF-Ausnahmen, sowie eine Ein-Klick-Aktion „Zulassen“ für jede WAF-Protokollzeile, die eine eng gefasste Ausnahme für genau diese Regel auf diesem Pfad vorab ausfüllt, Sie müssen die Regel-ID nicht auswendig kennen.
• Geltungsbereiche. Eine Ausnahme bezieht sich auf eine einzelne Regel (anhand der Regel-ID aus dem WAF-Blockprotokoll), eine Regelgruppe (aus den bekannten Kategorien der Engine) oder, bei einem First-Party-Endpoint, die gesamte Engine auf einem Pfad, optional eingegrenzt auf einen IP- oder CIDR-Bereich. Eine Ausnahmeregel für die gesamte Engine muss stets eine Pfad- oder IP-Einschränkung enthalten, damit die Firewall niemals versehentlich global deaktiviert werden kann.
• Grenzen Sie den Geltungsbereich so eng wie möglich ein. Bevorzugen Sie eine einzelne Regel auf einem Pfad gegenüber einer Regelgruppe und eine Regelgruppe gegenüber einer Ausnahmeregel für die gesamte Engine. Das Blockprotokoll zeichnet den abgeglichenen Wert, das überprüfte Ziel, die Anfragemethode, die URI und den User-Agent (ab Version 2.1.11) auf, sodass Sie genau sehen können, welche Regel ausgelöst wurde und warum, bevor Sie den Zugriff zulassen.
• „Extended Protection“ berücksichtigt dieselbe Liste. Aktive Ausnahmen werden in den „Pre-WordPress“-Drop-in-Schutz integriert und bei jeder Änderung der Allowlist neu integriert; die „Pre-WordPress“-Ebene und die „In-WordPress“-Engine sind stets aufeinander abgestimmt.
• Multisite & Tarife. Ausnahmen sind netzwerkweite Daten, die in jedem Tarif verfügbar sind; die Schutz-Engine selbst bleibt kostenlos.
• Ausweichmöglichkeit für Entwickler. apply_filters('reportedip_hive_waf_bypass_routes', []) Schließt REST-Routen auf Codeebene aus. Der Abgleich erfolgt als verankerter Präfix-Test gegenüber der aufgelösten WP-REST-Route, niemals als unverankerter Teilstrang der rohen URI; somit kann ein in einen nicht zusammenhängenden Abfrageparameter eingeschleustes Umgehungstoken die WAF nicht deaktivieren.

Verified Bot Detection, Disposable-Email Blocking & Comment Spam

• Verified Bot Detection (kostenlos). Stellt sicher, dass eine Anfrage, die vorgibt, von Googlebot, Bingbot oder einem anderen Crawler zu stammen, tatsächlich von diesen stammt, zunächst durch einen DNS-freien Abgleich mit den offiziellen IP-Bereichen des Crawlers (Priority Sync), anschließend durch einen vorwärtsbestätigten Reverse DNS-Fallback, der sowohl A- als auch AAAA-Einträge auflöst. Spoofer werden markiert (Standard) oder blockiert; ein echter Crawler wird niemals blockiert. facebookexternalhit Die Überprüfung erfolgt anhand der von Meta veröffentlichten IP-Bereiche.
• Disposable-Email Blocking (kostenlos). Überprüft die bei der Registrierung (WordPress und WooCommerce) angegebene Adresse anhand der Liste für Wegwerf-E-Mail-Adressen. Drei Modi: Aus / Überwachen / Blockieren. Datenschutz-Relays (Apple „Hide My Email“, Firefox Relay, .) bilden eine eigene Kategorie, die standardmäßig durchgelassen wird. Die Live-Liste basiert auf Priority Sync.
• Comment Honeypot (kostenlos). Ein unsichtbares, von Screenreadern ignoriertes Köderfeld im Kommentarformular; Spam-Bots, die jedes Feld ausfüllen, werden abgelehnt, ohne dass echte Besucher durch ein CAPTCHA behindert werden. Seit 2.1.52 zählt ein Bot, der in die Falle tappt, auch gegen den Kommentarzähler seiner Adresse, sodass ein Wiederholungstäter die Sperrschwelle erreicht.
• Kommentar-Spamfilter (kostenlos, seit 2.1.52). Bewertet jeden eingehenden Kommentar nach Linkzahl, Linkdichte, Zahl unterschiedlicher Domains, Wegwerf-Mail-Domains, verräterischen Top-Level-Domains, einer Domain im Autorennamen und einem Text ohne eigene Aussage hinter einem Link. Mehrere Signale müssen zusammenkommen, bevor ein Kommentar zählt. Standardmäßig wird er zur Prüfung als Spam abgelegt, die direkte Abweisung ist zuschaltbar, und der Filter lässt sich unter Schutz → Registrierung & Spam abschalten.
• Formular-Ausführungsnachweis (kostenlos, seit 2.1.53). Kommentar-, Registrierungs- und Passwort-zurücksetzen-Formular tragen ein verstecktes Ankerfeld, und ein kleines Skript hängt ein zweites Feld an, dessen Name pro Installation zufällig ist. Eine Übermittlung ohne beide Felder hat das Formular nie gerendert, und genau so sieht ein Skript aus, das direkt an die Adresse postet. Nichts davon ist anfragespezifisch, Seiten-Caches bleiben also unberührt. Bei Kommentaren ist das Ergebnis nur ein Bewertungssignal: Ein Besucher ohne JavaScript bekommt seinen Kommentar zur Prüfung abgelegt statt abgewiesen, und dieser Grund allein zählt nie gegen eine Sperre. Registrierung und Passwort-Zurücksetzen weisen dagegen ab und nennen den Grund. REPORTEDIP_HIVE_DISABLE_FORM_PROOF in der wp-config.php schaltet die gesamte Ebene ab.

Blockierung von Tor-Exit-Knoten (Professional)

Seit Version 2.1.41 kann Hive Verbindungen von bekannten Tor-Ausgangsknoten ablehnen. Die Funktion ist streng opt-in, der Schalter befindet sich unter „Schutz“ → „Blockierung & Eskalation“ und ist standardmäßig deaktiviert; außerdem ist ein Professional-Tarif erforderlich: Die Liste der Ausgangsknoten wird als signierter tor_exits Regelsatz über die reguläre Rule Sync und wird zweimal täglich serverseitig aktualisiert, sodass sie angesichts der Rotation der Exit-Knoten stets auf dem neuesten Stand bleibt. Das isTor Reputationsflag der Community deckt Adressen ab, die von der Liste noch nicht erfasst wurden.

Tor-Sperren sind bewusst moderat gestaltet. Sie sind vorübergehend: standardmäßig 24 Stunden, einstellbar über den reportedip_hive_tor_block_hours Filters anpassbar; sie werden der Community niemals gemeldet, da der Betrieb eines Tor-Ausgangsknotens kein Hinweis auf Missbrauch ist. IP-Adressen auf der Whitelist werden niemals durch Tor blockiert. Sobald eine Sperre abläuft, wird bei der nächsten Anfrage die aktuelle Liste der Ausgangsknoten neu ausgewertet.

Registrierungsregeln

Seit Version 2.1.51 durchläuft jede Anmeldeseite einen Regelsatz: das WordPress-Registrierungsformular, die WooCommerce-Kundenregistrierung, Multisite-Anmeldungen und die programmatische Benutzererstellung. Die Regeln befinden sich unter „Schutz → Registrierung & Spam“ und werden in einer festgelegten Reihenfolge ausgewertet, wobei der erste Treffer maßgeblich ist: Allowlist, Rate Limit, verbotene Benutzernamen, E-Mail-Regeln, Überprüfung auf Wegwerf-E-Mail-Adressen.

• Verbotene Benutzernamen. Ein Eintrag pro Zeile zusätzlich zu einer integrierten Basisliste (admin, administrator, root, sysadmin, superadmin, webmaster, hostmaster, postmaster, support, moderator), die deaktiviert werden kann und niemals auf das kostenlose Kontingent angerechnet wird.
• E-Mail-Regeln. Eine Liste mit drei Modi: „Aus“, „Die aufgeführten Adressen blockieren“ oder „Nur die aufgeführten Adressen zulassen“. Ein bloßer Hostname bedeutet *@host. Ein Treffer im Zulassungsmodus hat Vorrang vor der Überprüfung auf Wegwerf-E-Mail-Adressen; eine leere Liste im Zulassungsmodus verhält sich wie die Option „Aus“, sodass sich niemand selbst aussperrt.
• Rate Limit für die Registrierungsrate. Pro IP-Adresse standardmäßig drei Anmeldungen pro 60 Minuten; kostenlos und konfigurierbar (Zeitfenster 1 bis 60 Minuten). Es wird lediglich die Registrierung abgelehnt: keine IP-Sperre, keine Meldung an die Community, sodass ein Büro mit NAT-Anbindung niemals für seine Nachbarn bestraft wird.
• Registrierung ausschließlich über die Allowlist (Professional). Sind IP-Bereiche in der Allowlist aufgeführt, dürfen nur diese Bereiche ein Konto erstellen.
• Sperre bei unbekanntem Benutzernamen (Opt-in, standardmäßig deaktiviert). Ein Anmeldeversuch mit einem nicht existierenden Benutzernamen sperrt die IP-Adresse sofort. Beachten Sie den Kompromiss: Die daraus resultierende Sperre fungiert als Orakel für die Existenz von Benutzernamen, weshalb die Option standardmäßig deaktiviert ist und das Ereignis niemals an die Community gemeldet wird.

Eingaberegeln. Ein einfacher Eintrag entspricht exakt (Groß-/Kleinschreibung wird nicht berücksichtigt), ein Eintrag, der * , ist ein verankerter Platzhalter, und ein in Schrägstriche eingeschlossener Eintrag (/^shop[0-9]+$/) ist ein regulärer Ausdruck. Free-Tarife erhalten zehn einfache Einträge pro Liste, einschließlich Platzhalter; der Professional-Tarif hebt die Begrenzung auf und ermöglicht reguläre Ausdrücke sowie die Registrierung ausschließlich über die Allowlist. Eine Speicherung, die das kostenlose Limit überschreitet, wird mit einem Hinweis zum Tarif abgelehnt, anstatt stillschweigend gekürzt zu werden.

Ablehnungen werden als prohibited_username, registration_denied und registration_limit und können auf der Seite „Aktivität“ unter „Registrierung“ gefiltert werden.

Einstellungen zur Zugriffssperre

Ebenfalls seit Version 2.1.51 und in jedem Tarif kostenlos verfügbar: Schalter unter „Schutz → Sicherheits-Header“, mit denen Teile von WordPress deaktiviert werden können, die eine Website nicht nutzt. Alle sind standardmäßig deaktiviert und können auf demselben Bildschirm wieder aktiviert werden.

• REST API-Zugriff. Drei Modi: offen, nur für angemeldete Besucher oder beschränkt auf ausgewählte Rollen. Die Namespaces auf der Allowlist bleiben in jedem Modus öffentlich und enthalten die Endpoints, die andernfalls nicht funktionieren (oembed/1.0, wp-site-health/v1, die gängigen Cookie-Banner- und Formular-Namespaces sowie die WooCommerce-Store-API); reportedip-hive/v1 ist stets zulässig, damit die 2FA-Routen weiterhin funktionieren. Gäste erhalten einen 401-Fehler, angemeldete Benutzer außerhalb der Rollenliste erhalten einen 403-Fehler. Durch das Sperren der API für Gäste werden auch die REST-Discovery-Links entfernt.
• XML-RPC. Verweigert xmlrpc.php, deaktiviert Pingbacks, entfernt den X-Pingback Header an der Quelle und entfernt die RSD- und WLW-Manifest-Links. Anwendungskennwörter über REST sind davon nicht betroffen; dies ist der moderne Ersatz für XML-RPC-Clients.
• Feeds. RSS-, Atom- und Kommentar-Feeds geben einen 404-Fehler zurück, und die Feed-Links verschwinden aus dem Seitenkopf.
• Admin-Bereich für nicht angemeldete Besucher. Der Zugriff wird /wp-admin/ für Besucher, die nicht angemeldet sind, und damit auch die /admin sowie /dashboard Aliase, die WordPress dorthin umleitet. Der /login Alias führt weiterhin zum Anmeldeformular, sofern „Hide Login“ nicht aktiviert ist: Nur „Hide Login“ entfernt die Kern-Weiterleitung, die dorthin führt wp-login.php. „Hide Login“ sperrt „wp-admin“ auch für Besucher; der Schalter macht diesen Bereich separat zugänglich. admin-ajax.php und admin-post.php bleiben erreichbar, da nicht authentifizierte Callbacks dort rechtmäßig Daten übermitteln.
• PHP-Ausführung in „uploads“. Schreibt einen Marker-Block in das Verzeichnis „uploads“ .htaccess , der Anfragen an PHP-ähnliche Dateinamen, einschließlich der klassischen doppelten Dateiendung, ablehnt shell.php.jpg. Nur Apache; auf Nginx und unbekannten Servern zeigt die Seite stattdessen den Codeausschnitt an, der in die Serverkonfiguration eingefügt werden muss. Durch Deaktivieren wird die Sperre vollständig entfernt.
• Software-Fingerabdrücke. Entfernt das WordPress-Generator-Tag und deaktiviert die Anzeige von PHP-Fehlern, es sei denn, WP_DEBUG und WP_DEBUG_DISPLAY aktiviert sind. Dies ist eine kosmetische Absicherung: Versionsnummern lassen sich weiterhin aus den URLs der Assets ableiten.

Die Benutzer-Sitemap (wp-sitemap-users-1.xml) ist kein eigenständiger Schalter. Sie verschwindet, solange „User Enumeration blockieren“ aktiviert ist, was die Standardeinstellung ist, da sie genau die Liste veröffentlicht, die die Sicherheitsmaßnahme verbirgt.

Zugriffsverweigerungen werden einmal pro IP-Adresse und Ereignis mit einer fünfsekündigen Drosselung protokolliert (rest_denied, xmlrpc_denied, feed_denied, admin_guest_denied). Sie lösen niemals die Sperrstufe aus und werden niemals an die Community gemeldet: Hierbei handelt es sich um Zugriffskontrolle, nicht um Angriffserkennung.

Systembereitschaft

Achtzehn Detektoren überwachen die Teile einer Installation, die unbemerkt ausfallen: zwölf melden einen Fehler, sechs schlagen eine Verbesserung vor und erscheinen als Nächste-Schritte-Karte auf dem Dashboard statt als Problem. Offene Probleme werden unter „Systemstatus“ mit ihrem Schweregrad, dem Zeitpunkt ihres ersten Auftretens, einem Link zur zuständigen Einstellung und einem Link zu dieser Seite angezeigt. Kritische Probleme und Warnungen lösen zusätzlich eine zusammenfassende Meldung auf den Plugin-Seiten aus; das Dashboard-Widget zeigt die Anzahl an, und wp reportedip status meldet sie im issues Feld. Warnungen und Hinweise können siteweit für sieben Tage zurückgesetzt werden; kritische Probleme können nicht zurückgesetzt werden. Ein Problem, das verschwindet, wird vergessen und beginnt von Neuem, sollte es erneut auftreten.

• Guard-Warteschlange nicht beschreibbar (kritisch). Extended Protection ist aktiviert, aber der Pre-WordPress-Guard kann seine Trefferwarteschlange nicht schreiben, sodass seine Blockierungen niemals importiert werden und es nie zu einer Eskalation kommt. Korrigieren Sie die Berechtigungen für das in der Meldung genannte Verzeichnis oder deaktivieren Sie Extended Protection.
• Geplante Aufgaben ins Stocken geraten (kritisch). Jeder Hive-Cron-Hook ist um mehr als 24 Stunden überfällig, sodass die Warteschlangenverarbeitung, die Reputationssynchronisierung und die Bereinigung vollständig eingefroren sind. In der Regel liegt ein fehlerhafter WP-Cron-Loopback vor; konfigurieren Sie einen echten System-Cron und setzen Sie DISABLE_WP_CRON.
• WP-Cron deaktiviert, ohne dass ein Ersatz vorhanden ist (Warnung). DISABLE_WP_CRON ist eingestellt, ALTERNATE_WP_CRON ist nicht gesetzt, und seit über einer Stunde wurde kein externer Trigger ausgeführt.
• Header „Vertrauenswürdige IP“ ohne Proxy-Bereiche (Warnung). Ein Client-IP-Header wird für jeden Peer berücksichtigt, sodass jeder, der den Ursprungsserver direkt erreicht, eine Adresse fälschen, einen Block abwerfen oder sich als IP-Adresse auf der Whitelist ausgeben kann. Legen Sie Ihre Proxy-Bereiche unter „Community“ fest.
• Veraltetes Datenbankschema (kritisch). Die gespeicherte Schemaversion liegt hinter der des Plugins zurück. In der Regel handelt es sich um eine abgebrochene Migration; durch das Neuladen einer Plugin-Seite wird der Vorgang erneut versucht.
• Community-Ebene beeinträchtigt (Warnung). Das Fenster für die letzten Anfragen zeigt eine niedrige Erfolgsquote an. Überprüfen Sie den ausgehenden HTTPS-Verkehr zu ReportedIP.com sowie den Community Access Key.
• Obergrenze für Mail Relay erreicht (Warnung). Das monatliche Kontingent für verwaltete E-Mails ist aufgebraucht, und 2FA-E-Mails fallen auf wp_mail() zurück. Buchen Sie ein Aufladepaket oder warten Sie auf die Zurücksetzung.
• SMS Relay-Limit erreicht (Warnung). Das monatliche SMS-Kontingent ist aufgebraucht. Benutzer, bei denen SMS die einzige Methode ist, sollten eine zweite Methode hinzufügen.
• E-Mail-Zustellung fehlgeschlagen (Warnung). WordPress hat wiederholte wp_mail_failed Fehler gemeldet, sodass 2FA-Codes und Benachrichtigungen nicht ankommen. Überprüfen Sie die SMTP-Konfiguration. Empfängeradressen werden aus der gespeicherten Nachricht entfernt.
• Kein Verschlüsselungs-Backend (kritisch). Weder libsodium noch OpenSSL sind verfügbar, sodass TOTP-Secrets und Telefonnummern im Ruhezustand nicht verschlüsselt gespeichert werden können. Bitten Sie Ihren Host, eine der beiden Erweiterungen zu aktivieren.
• Die Berichtswarteschlange enthält fehlgeschlagene Einträge (Warnung). Die Wiederholungsversuche für die Reports sind erschöpft. Überprüfen Sie diese und versuchen Sie es erneut auf der Registerkarte „API-Warteschlange“.
• Rückstand in der Berichtswarteschlange (Warnung). Ausstehende Reports stapeln sich, was in der Regel auf ein Cron- oder Verbindungsproblem hindeutet.
• Login-Adresse weiterhin öffentlich (Hinweis). Hide Login ist aus, jeder Bot kennt also die Adresse des Anmeldeformulars. Die Nächste-Schritte-Karte nimmt einen Slug entgegen und schaltet die Funktion in einem Schritt ein.
• Storefront-2FA im Tarif enthalten, aber aus (Hinweis). Die Website betreibt WooCommerce, und der Tarif enthält die im Theme gerenderte Kunden-Abfrage, die nicht eingeschaltet ist. Ein Klick aktiviert sie.
• Footer-Badge aus (Hinweis). Das Badge „Protected by ReportedIP“ wird nicht angezeigt. Es ist freiwillig, und ein Klick schaltet es ein.
• Erweiterter Schutz möglich, aber nicht aktiv (Hinweis). Der Server unterstützt den Guard vor WordPress, und er läuft nicht. Jede geblockte Anfrage startet deshalb weiterhin erst WordPress.
• Local Shield statt Community-Netzwerk (Hinweis). Die Website schützt sich selbst, fragt das Netzwerk aber weder, noch trägt sie zu ihm bei.
• Ihr eigener zweiter Faktor fehlt (Hinweis). Die Zwei-Faktor-Authentifizierung ist für die Website aktiv, und das Konto, das die Seite gerade ansieht, hat keine Methode eingerichtet. Wird pro Person gemeldet, nie siteweit.

Vertrauenswürdige Proxy-Quellen (Cloudflare, Reverse-Proxys, Load-Balancer)

Wenn Ihre Website hinter Cloudflare, einem Reverse-Proxy oder einem Load-Balancer betrieben wird, ist der verbindende Peer der Proxy; die tatsächliche Besucheradresse wird in einem HTTP-Header wie CF-Connecting-IP oder X-Forwarded-For. Wählen Sie diesen Header unter „Community“ → „Vertrauenswürdige IP-Header“ aus und geben Sie ab Version 2.1.41 die Adressen des Proxys in der Liste „Vertrauenswürdige Proxy-Quellen“ direkt darunter an, eine IP-Adresse oder ein CIDR-Bereich pro Zeile, z. B. die veröffentlichten Cloudflare-Bereiche.

Sobald die Liste eingerichtet ist, wird der Header nur noch für Anfragen berücksichtigt, die tatsächlich von einer deklarierten Proxy-Adresse ausgehen. Wer den Ursprungsserver direkt erreicht, kann den Header nicht fälschen, um sich als eine auf der Whitelist stehende Adresse auszugeben oder eine aktive Sperre zu umgehen. Eine leere Liste behält das bisherige Verhalten bei (Header von jedem Peer akzeptiert), sodass bestehende Konfigurationen weiterhin funktionieren; wenn Sie jedoch einem Header vertrauen, geben Sie Ihre Proxys an. Die gleiche Überprüfung wird im „Extended Protection“-Guard vor WordPress durchgesetzt.

Security Headers

Absicherung der Antwort-Header bei jeder Frontend-Anfrage. Header, die bereits von Ihrem Server oder einem anderen Plugin gesendet wurden, werden erkannt und unverändert belassen.

• Basis-Paket (kostenlos), X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Erweitert (Professional): HSTS, Permissions-Policy, eine Content-Security-Policy (standardmäßig nur zur Erstellung von Reports, mit einem Generator) sowie das Trio zur domänenübergreifenden Isolierung (COOP / CORP / COEP).

Über die Registerkarte „Server-Einrichtung“ können die konfigurierten Header zusätzlich als nginx-Konfiguration auf Serverebene add_header / Apache Header -Direktiven auf Serverebene exportieren.

Protection & Hardening Score

Zwei Dashboard-Anzeigen (0–100 sowie eine Benotung von A+ bis F im Stil des Mozilla-Observatoriums) bewerten Ihre Erfassungsreichweite und Ihren Absicherungsstatus, mit Deep-Links zu den einzelnen Elementen, über die Sie einen Sensor aktivieren können. Gesperrte (kostenpflichtige) Funktionen fließen in das sichtbare Potenzial ein, wirken sich jedoch nicht negativ auf Ihre Bewertung aus, sodass auch der Free-Tarif eine Bestnote erreichen kann.

Sicherheits-Dashboard & Analysen

Seit 2.1.57 beantwortet das Dashboard die Frage „fertig, und jetzt?“: Ein Statusbanner nennt den Tarif, für den die Empfehlung angewendet wurde, das Einrichtungsdatum und die Zahl der davon abweichenden Einstellungen; Karten mit nächsten Schritten (Hide Login aus, Shop-2FA im Tarif enthalten, aber aus, Badge aus, erweiterter Schutz möglich, aber nicht aktiv, Local Shield statt Community Network, eigener zweiter Faktor fehlt) tragen eine Inline-Aktion oder einen Link und lassen sich sieben Tage zurückstellen; eine Zeile je Schutzbereich zeigt den Kurzstatus und springt zur Karte; höchstens eine Tarifkarte erscheint pro Besuch. Der Expertenmodus ist ein Schalter im Seitenkopf.

Das Haupt-Dashboard öffnet sich mit einer Schlagzeilenleiste, die die in den letzten 30 Tagen abgewehrten Angriffe, die heute abgewehrten Angriffe, die derzeit gesperrten IP-Adressen sowie die Anzahl der aktivierten Schutzebenen anzeigt (zum Beispiel 17 / 20). Darunter werden die Analysedaten aus allen Sensoren angezeigt, nicht nur die klassischen Zähler für Login und Spam.

• Zeitleiste der Sicherheitsereignisse. Ein gestapeltes Flächendiagramm, das alle Aktivitäten in sieben Kategorien gruppiert: Login & Anmeldedaten, Firewall (WAF), Scanner & Sonden, gefälschte Bots, Aufklärung & Enumeration, Spam & Flooding sowie Anomalien, über einen wählbaren Zeitraum von 7, 30 oder 90 Tagen.
• Verteilung der Bedrohungen. Eine Aufschlüsselung, welche Angriffsfamilie den Zeitraum dominierte, sodass Sie auf einen Blick erkennen können, ob Sie mit Brute-Force-Angriffen, Exploit-Versuchen auf Firewall-Ebene, Scannern oder Spam konfrontiert sind.
• Firewall: Häufigste Angriffstypen. Die von der WAF blockierten Angriffe sortiert nach Regelgruppen (SQL Injection, Cross-Site-Scripting, Path-Traversal, Log4Shell, User-Agents von Scannern, .).
• Aufschlüsselung nach Schweregrad. Anzahl der Ereignisse der Stufen „Kritisch“, „Hoch“, „Mittel“ und „Niedrig“, damit das Ausmaß schwerwiegender Vorfälle niemals in einer einzigen Gesamtsumme verborgen bleibt.
• Top-Angreifer (30 Tage). Die aktivsten Quell-IPs mit ihrer Trefferanzahl, dem Zeitpunkt ihrer letzten Erfassung und der Angabe, ob sie derzeit blockiert oder nur überwacht werden.
• Aktuelle Aktivitäten. Der Live-Ereignisstrom, wobei jeder Eintrag mit seinem Schweregrad und der Bedrohungsfamilie sowie den relevanten Details (abgeglichene WAF-Regel, abgefragter Pfad, gefälschter Bot-Name) versehen ist.

Alle Zahlen sind in jedem Tarif in Echtzeit verfügbar; das Dashboard spiegelt wider, was Ihre Website tatsächlich blockiert hat. Die Tarife „Professional“ und „Business-Tarif“ bieten darüber hinaus detailliertere Analysen (längere Verlaufs- und Protokollaufbewahrung, geografische Verteilung der Angreifer sowie den unten beschriebenen, Compliance-konformen Prüfpfad).

Seit Version 2.1.41 werden die wichtigsten Zahlen auch als Sicherheits-Widget direkt im WordPress-Dashboard angezeigt: In den letzten 30 Tagen blockierte Angriffe, heutige Blockierungen, aktive IP-Sperren, Schutzebenen und der Erkennungswert erscheinen direkt auf der Startseite von wp-admin, mit Deep-Links zum Plugin. In Multisite-Umgebungen wird das Widget auf dem Netzwerk-Dashboard sowie, für Super-Admins, auf den Dashboards der Unter-Websites mit netzwerkweiten Zahlen angezeigt. Seit Version 2.1.51 enthält es zudem die Anzahl der offenen Bereitschaftsprobleme; siehe „Systembereitschaft“.

Neben dem Dashboard gibt es sieben Seiten mit Listentabellen: „Blockierte IPs“, „Whitelist“, „Sicherheitsprotokolle“, „API-Warteschlange“, der Audit Event Trail (Business), der Sitzungsmanager unter „Benutzer → Sitzungen“ (Business) und die 2FA-Admin-Übersicht. Eine separate Seite „Systemstatus“ listet alle offenen Bereitschaftsprobleme mit ihrem Schweregrad, dem Zeitpunkt ihres ersten Auftretens und einem Link zur entsprechenden Einstellung auf. Seit 2.1.62 ist der Ereignisfilter des Sicherheitsprotokolls durchsuchbar und wählt ganze Gruppen, und jeder Ereignistyp, den das Plugin schreibt, steht in einer Registry.

Audit Event Trail (Business)

Seit 2.1.62 zeichnet der Trail auf, wer was auf der Website geändert hat, nicht nur, was mit Konten passiert ist. Acht Auslöser-Gruppen, 48 Ereignistypen, jede Gruppe ein Schalter auf der Schutz-Seite (Karte „Datenschutz und Protokolle"):

• An- und Abmeldungen (standardmäßig aus: die lautesten Zeilen, und Fehlversuche stehen ohnehin im Sicherheitsprotokoll).
• Benutzerkonten: Registrierung, Löschung, Profil-, E-Mail- und Passwortänderungen, Rollenänderungen mit handelndem Benutzer, Passwort-Zurücksetzungen, Kontosperren, beendete Sitzungen, bearbeitete Rollenrechte.
• Seiten und Beiträge: veröffentlicht, zurückgezogen, in den Papierkorb verschoben, wiederhergestellt, gelöscht, URL-Slug geändert. Automatische Speicherungen, Revisionen und Auto-Drafts werden ignoriert.
• Plugins, Themes und Core: installiert, aktualisiert, aktiviert, deaktiviert, gelöscht, Theme gewechselt, Core aktualisiert, jeweils mit Version vorher und nachher. Automatische Updates sind ebenfalls Zeilen, als Cron markiert.
• Website-Einstellungen: 26 Core-Optionen (Website-Adresse, Permalinks, Lesen, Diskussion, Registrierung, automatische Updates) und jede Hive-Einstellung, jeweils mit altem und neuem Wert; eine Liste wird als „hinzugekommen" und „entfernt" abgelegt.
• Menüs und Widgets: angelegte, geänderte und gelöschte Menüs, Menüpositionen, einer Seitenleiste hinzugefügte oder daraus entfernte Widgets.
• Theme- und Plugin-Datei-Editor: eine über den eingebauten Editor gespeicherte Datei, nur wenn sich die Datei tatsächlich geändert hat.
• Netzwerk (nur Multisite): angelegte, geänderte, archivierte oder gelöschte Websites, zu einer Website hinzugefügte oder daraus entfernte Benutzer, erteilte oder entzogene Super-Admin-Rechte.

Jede Zeile nennt den handelnden Benutzer, den Weg der Anfrage (Browser, WP-CLI, Cron, REST, AJAX) und das betroffene Objekt, verlinkt, solange es existiert. Geheimnisse werden nie geschrieben: Ein Datenschlüssel oder Optionsname, der ein Passwort, Token, einen Key oder Code bezeichnet, hält seine Werte draußen. Die Aufbewahrung beträgt standardmäßig 90 Tage, einstellbar von 1 bis 365, und die nächtliche Bereinigung läuft wie beim Sicherheitsprotokoll in Blöcken von 5.000 Zeilen. Gespeichert in der eigenen Tabelle audit_log; DSGVO-Export und -Löschung decken sie ab.

Der Reiter unter „Aktivität" filtert nach Ereignis oder Auslöser-Gruppe, Benutzer, Adresse, Objekt und Datumsbereich, und die CSV- und JSON-Exporte übernehmen den aktiven Filter. In einem Netzwerk grenzt der Netzwerk-Admin die Liste auf eine Website oder auf die Netzwerk-Zeilen ein, und jeder Website-Administrator hat im Website-Menü eine Audit-Trail-Seite mit den Zeilen seiner Website. Unterhalb von Business zeigt der Reiter fünf Beispielzeilen und was er beantworten würde; dort wird nichts aufgezeichnet, und das 30-Tage-Sicherheitsprotokoll bleibt in jedem Tarif.

Benutzerkontenverwaltung und Sitzungen (Business)

Seit Version 2.1.51 kann ein Konto gesperrt werden, ohne es zu löschen: über die Profilseite des Benutzers, über die Benutzerliste (Spalte „Gesperrt“, Ansicht und Massenaktionen) oder mithilfe wp reportedip user block. Die Sperrung beinhaltet eine optionale Meldung, die bei der Anmeldung angezeigt wird, sowie einen internen Vermerk, der dem Benutzer niemals angezeigt wird.

Ein gesperrtes Konto behält seinen gesamten Inhalt bei, kann sich jedoch nicht anmelden, kein Anwendungskennwort authentifizieren und keine Kennwortzurücksetzung durchführen. Durch die Sperrung werden alle Sitzungen und alle vertrauenswürdigen 2FA-Geräte sofort beendet, sodass ein bereits angemeldeter Benutzer bei der nächsten Anfrage abgemeldet wird. Die Sperrung Ihrer eigenen Konten oder der eines Super-Administrators wird abgelehnt; bei einer Installation mit nur einer Instanz gilt dies ebenfalls für die Sperrung des letzten verbleibenden Administrators. Eine Sperre bleibt auch nach Ablauf des Abonnements bestehen, und die Aufhebung einer Sperre unterliegt keinerlei Einschränkungen.

Unter „Benutzer → Sitzungen“ werden die aktiven Sitzungen aller angemeldeten Benutzer mit Anmeldezeitpunkt, Ablaufzeit, IP-Adresse und Gerät aufgelistet; hier können Sie eine einzelne Sitzung oder alle Sitzungen eines Benutzers beenden. Ihre eigene aktuelle Sitzung kann niemals über diese Liste beendet werden. Sperrungen und Beendigungen werden im Audit Event Trail aufgezeichnet. Bei Multisite befindet sich die Seite im Netzwerk-Admin-Bereich, und eine Sperre gilt netzwerkweit, da WordPress-Benutzer und -Sitzungen netzwerkweit gelten.

MainWP Integration

Hive lässt sich über ein MainWP-Dashboard fernverwalten, ohne dass ein zusätzliches Child-Plugin oder eine MainWP-Erweiterung erworben werden muss. Es bindet sich in den MainWP-Child-Filter ein mainwp_child_extra_execution , sodass jeder Auftrag über den bestehenden MainWP-Child-Kanal authentifiziert wird, ohne zusätzliche Anmeldedaten und ohne neue Angriffsfläche. Die Einrichtung ist ganz einfach: Installieren Sie MainWP Child und Hive auf der verwalteten Website, verbinden Sie die Website wie gewohnt mit Ihrem MainWP-Dashboard, fertig.

Es werden zwei Auftragstypen unterstützt:

• Synchronisierung von Sicherheitsmetriken, ausschließlich aggregierte Werte: aktive Blockierungen, Größe der Whitelist, fehlgeschlagene Logins, Kommentar-Spam, Reputationsblockierungen, Größe der Warteschlange, aktuelle kritische Ereignisse, 2FA-aktivierte Benutzer. Seit Version 2.1.6 meldet die Synchronisierung zudem den Firewall-Status (waf_enabled, waf_report_only, waf_dropin_enabled, waf_dropin_running, waf_server sowie ein daraus abgeleitetes waf_needs_setup Flag), so kann ein Dashboard Websites kennzeichnen, bei denen der Extended Protection aktiviert, aber noch nicht aktiv ist, typischerweise ein Nginx-Host, der noch auf sein Server-Snippet wartet.
• Bereitstellung (reportedip_hive_provision): Übermitteln Sie einen API Key vom vertrauenswürdigen Dashboard an eine verwaltete Website und schalten Sie diese seit Version 2.1.12 optional im selben Job in den Community Network-Modus um (community Flag). Der Synchronisierungsauftrag Reports den aktuellen Status jeder untergeordneten Website operation_mode.

IP-Adressen, Benutzernamen, Secrets oder der API Key verlassen niemals die verwaltete Website; die SynchronisierungsPayload besteht ausschließlich aus Zählwerten und Statusflags.

Seit Version 2.1.47 kann die MainWP-Erweiterung zusätzlich Hive-Einstellungen zentral verwalten: Sie liest ein versioniertes Einstellungsschema von jeder Website aus, wendet eine globale Richtlinie mit site-spezifischen Feldüberschreibungen an und erkennt Abweichungen anhand eines Einstellungs-Fingerabdrucks, der bei jeder Synchronisierung Reports liefert. Die Validierung erfolgt stets auf der verwalteten Website selbst, pro Schlüssel, wobei planabhängige Werte übersprungen werden.

Cloud-Flottenmanagement (Business)

Im Business-Tarif können dieselben Einstellungsrichtlinien auch ohne MainWP verwaltet werden, direkt über Ihr ReportedIP-Dashboard unter „Domains“: Definieren Sie eine globale Richtlinie, überschreiben Sie einzelne Felder pro Website, übernehmen Sie die Änderungen mit einem Klick und erkennen Sie sofort, wenn eine Website von der Richtlinie abweicht, einschließlich eines Live-Vergleichs zwischen Soll- und Ist-Werten pro Website.

• Strikt auf Opt-in-Basis. Jede Website entscheidet selbst: Der Schalter „Cloud-Flottenmanagement“ auf der Registerkarte „Allgemeine Einstellungen“ von Hive ist standardmäßig deaktiviert. Ohne diese Aktivierung lehnt die Website jede Verwaltungsanfrage ab.
• Nur signierte Anfragen. Jeder Push wird vom ReportedIP-Flottendienst mit Ed25519 signiert und auf Ihrer Website anhand eines im Plugin enthaltenen öffentlichen Schlüssels verifiziert, ergänzt durch ein fünfminütiges Gültigkeitsfenster, einmalig verwendbare Anfrage-IDs, eine Bindung an die eigene Adresse Ihrer Website sowie einen Nachweis Ihres Community Access Key. Es müssen keine Passwörter, Token oder zusätzliche Anmeldedaten verwaltet werden.
• Es gelten dieselben Regeln wie bei MainWP. Beide Dashboards verwenden das identische Einstellungsprotokoll; jeder Wert wird auf Ihrer Website validiert, bevor er geschrieben wird, und planabhängige Einstellungen werden übersprungen und niemals erzwungen.
• Erfordert Hive 2.1.48 oder neuer, den Community Network-Modus und einen Business- (oder Enterprise-)Tarif.

Multisite-Netzwerke

Die Full Edition ist ausschließlich für Netzwerke vorgesehen (Network: true, seit Version 2.0.0): Die Aktivierung auf Einzelseitenebene wird von WordPress verborgen, sodass die Sicherheitskonfiguration im gesamten Netzwerk einheitlich bleibt. Alle neun Tabellen befinden sich unter $wpdb->base_prefix, wodurch jede Sicherheitsentscheidung netzwerkweit gilt, standortübergreifende Brute-Force-Versuche in einem zentralen Zähler zusammengefasst werden und eine einzige Sperre die IP-Adresse sofort von allen Unterseiten ausschließt.

• Netzwerkadministratoren erhalten den vollständigen Einstellungsumfang, eine Protokollansicht für alle Websites und den Audit-Trail mit Website-Filter.
• Website-Administratoren einer Unterseite erhalten eine schreibgeschützte Oberfläche für Status und Protokolle, den Audit-Trail ihrer eigenen Website (Business) sowie genau zwei bearbeitbare, websitespezifische Einstellungen: den Frontend-2FA-Slug und zusätzliche Rollen mit 2FA-Pflicht (eine Unterseite kann 2FA für mehr Rollen erzwingen, nie für weniger).
• Cron-Aufträge werden ausschließlich auf der Hauptseite ausgeführt; es finden keine doppelten Synchronisierungen oder Bereinigungsvorgänge pro Unterseite statt.
• WAF Exceptions sind netzwerkweite Daten, die vom Netzwerkadministrator verwaltet werden.

Zwei-Faktor-Authentifizierung (2FA)

Es werden vier Methoden unterstützt, die pro Benutzer kombiniert werden können. Recovery Codes werden bei der Ersteinrichtung generiert. Secrets werden im Ruhezustand verschlüsselt gespeichert (libsodium mit OpenSSL-Fallback).

• TOTP: RFC 6238 (6 Ziffern, 30-Sekunden-Fenster). Funktioniert mit Google Authenticator, Authy, 1Password, Bitwarden, .
• E-Mail: Sechsstelliges OTP über den konfigurierten E-Mail-Anbieter; mit Rate Limiting (3 Codes pro 15 Minuten, 5 Verifizierungsversuche pro Code, 60 Sekunden Wartezeit bis zum erneuten Versand).
• SMS: Sechsstelliges OTP über den verwalteten ReportedIP-SMS Relay (ab Professional-Tarif; siehe unten). Die Telefonnummer wird verschlüsselt gespeichert.
• WebAuthn, Passkeys, Sicherheitsschlüssel (YubiKey), plattformbasierte Authentifikatoren (Touch ID, Face ID, Windows Hello). Interner CBOR-Parser, keine Abhängigkeit von externen Komponenten.
• Trusted Devices, opt-in-basierte „Dieses Gerät merken“-Token mit konfigurierbarer Gültigkeitsdauer (standardmäßig 30 Tage). Gespeichert als wp_reportedip_hive_trusted_devices als SHA-256-Hashes.
• Recovery Codes: 10 Einmalcodes xxxx-xxxx Codes; Warnung bei niedrigem Stand bei ≤ 3 verbleibenden Codes.

Hardware Security Key (YubiKey)

Seit der Versionsreihe 2.1.33–2.1.36 werden FIDO2-Hardware-Schlüssel voll unterstützt: Die YubiKey-5-Serie (USB-A, USB-C, Lightning sowie die NFC-Modelle, die an ein Smartphone gehalten werden), die „Security Key by Yubico“-Reihe und alle anderen CTAP2-Authentifikatoren funktionieren auf allen drei Challenge-Oberflächen: dem wp-login-Interstitial, der WooCommerce-Storefront-Abfrage und dem Passwort-Reset-Fenster. Ältere, ausschließlich U2F-fähige Schlüssel (CTAP1) werden offiziell nicht unterstützt.

• Zur Einrichtung öffnen Sie Ihre Profilseite (Benutzer → Profil → Zwei-Faktor-Authentifizierung), wählen Sie „Sicherheitsschlüssel hinzufügen“ → „Sicherheitsschlüssel (USB / NFC)“, geben Sie dem Schlüssel einen Namen, stecken Sie ihn ein und berühren Sie den goldenen Kontakt, sobald der Browser Sie dazu auffordert. Auf einem Smartphone halten Sie den Schlüssel flach an die Rückseite im oberen Bereich (NFC). Für die Registrierung ist keine FIDO2-PIN erforderlich.
• Ein Schlüssel pro Konto ist kostenlos. Der Business-Tarif bietet erweiterte Sicherheitsschlüssel: mehrere Schlüssel pro Konto, die Registrierung eines zweiten YubiKeys, den Sie als Backup-Schlüssel an einem sicheren Ort aufbewahren sollten, sowie eine automatische Modellerkennung („YubiKey 5-Serie mit NFC“ wird neben dem Schlüssel angezeigt) und E-Mail-Benachrichtigungen, sobald ein Schlüssel hinzugefügt oder entfernt wird.
• Haben Sie Ihren Schlüssel verloren? Melden Sie sich mit einem Ihrer Recovery Codes (oder Ihrem Backup-Schlüssel im Business-Tarif) an und entfernen Sie anschließend den verlorenen Schlüssel auf Ihrer Profilseite. Durch das Entfernen des letzten Schlüssels wird die Methode vollständig deaktiviert.
• Klonerkennung: Bei jeder Anmeldung wird der Signaturzähler des Schlüssels erhöht. Eine Authentifizierung, bei der sich der Zähler nicht erhöht, wird abgelehnt, protokolliert und dem Kontoinhaber in jedem Tarif per E-Mail gemeldet.
• Algorithmen: ES256 für jeden Schlüssel; Ed25519 wird bei YubiKey-Firmware 5.2.3+ automatisch ausgehandelt, wenn der Server über libsodium verfügt.

2FA-Brute-Force-Schutz

Die 2FA-Verifizierungsleiter verläuft wie folgt: 3 → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Erreicht der Zähler die oberste Stufe, wird die IP-Adresse in den zentralen auto_block_ip() Pfad (Ereignis 2fa_brute_force), was wie bei jedem anderen Sensor eine schrittweise Eskalation und eine Berichterstattung im Community-Modus auslöst.

Headless 2FA REST

Für App-Integrationen stellt das Plugin drei Routen unter dem Namensraum reportedip-hive/v1:

• POST /2fa/challenge Benutzername + Passwort → Challenge-Token + aktivierte Methoden (20 Anfragen / 5 Min. pro IP-Adresse).
• POST /2fa/verify Token + Methode + Code → setzt das Authentifizierungs-Cookie (30 Anfragen / 5 Minuten pro IP).
• GET /2fa/methods Aktive Methoden für den aktuellen Benutzer anzeigen.

Adaptive Step-Up-Auslöser (Professional)

Die Durchsetzung der 2FA für eine Rolle erfordert bei jeder Anmeldung die Eingabe des zweiten Faktors. Adaptive Auslöser, die in Version 2.1.51 hinzugefügt wurden, stellen einen Mittelweg für alle anderen dar: Benutzer, die eine Methode eingerichtet haben, werden nur dann erneut dazu aufgefordert, wenn sich etwas an der Anmeldung geändert hat. Die Matrix befindet sich unter „Schutz“ → „Zwei-Faktor-Authentifizierung“ → „Durchsetzung“, mit einer Spalte pro Auslöser und einer Zeile pro Rolle.

• Neues Land, neue IP-Adresse, neues Netzwerk (/24 oder IPv6 /64) oder neues Gerät, jeweils im Vergleich zum eigenen Verlauf des Benutzers. Für die Ländererkennung ist der Community Network-Modus erforderlich; im „Local Shield“-Modus bleibt dieser Auslöser inaktiv.
• Alle N Tage seit der letzten bestandenen Überprüfung und alle N Anmeldungen, wobei N neben der Matrix konfigurierbar ist.
• Mehr als N gleichzeitige Sitzungen für diesen Benutzer.

Eine ausgelöste Herausforderung ignoriert das Cookie für Trusted Devices, was genau der Sinn der Sache ist: Das Gerät ist vertrauenswürdig, die Umstände jedoch nicht. Die 2FA-IP-Allowlist und der reportedip_2fa_bypass Filter werden weiterhin umgangen. Benutzer, für die keine Authentifizierungsmethode konfiguriert ist, werden niemals ausgesperrt; das Überspringen wird protokolliert (2fa_stepup_skipped_no_method) und sie werden daran erinnert, eine Methode einzurichten. Der Verlauf wird benutzerspezifisch geführt, sodass bei der ersten Anmeldung nach Aktivierung eines Auslösers keine Herausforderung erfolgt und die Administratorrolle erst dann aktiviert werden kann, wenn ein Administrator eine Herausforderung auf der Website bestanden hat.

WooCommerce-Frontend-Login

Die Frontend-2FA von Hive bleibt innerhalb Ihrer aktiven Storefront-Theme; Kunden, die sich über [woocommerce_my_account], über den klassischen Checkout oder die WooCommerce-Blöcke „Warenkorb“ und „Checkout“ anmelden, schließen ihren zweiten Authentifizierungsschritt auf einer themenbezogenen Seite ab. Der Status von Warenkorb und Checkout bleibt während der Weiterleitung erhalten; das Cookie für Trusted Devices wird mit dem wp-login-Ablauf geteilt.

• Konfigurationspfad, 2FA → Frontend-Login für WooCommerce.
• Konfigurierbare Slugs, Herausforderungs-Slug (Standard reportedip-hive-2fa) sowie Einrichtungs-Slug (Standard reportedip-hive-2fa-setup); beide sind editierbar, werden auf Konflikte geprüft, und die Rewrite-Regeln werden bei Änderungen automatisch aktualisiert.
• Herabstufung des Tarifs, weiche Deaktivierung bei den Tarifen „Free“ und „Contributor“; Einstellungen, Slug-Auswahlen und der Onboarding-Status bleiben erhalten, es entsteht kein Datenverlust beim erneuten Upgrade.
• Konflikterkennung: Hive zeigt eine Administrator-Meldung an, wenn Solid Security, das WP Two-Factor-Plugin oder Wordfence 2FA die Kontrolle über das Anmeldeformular haben, und deaktiviert die Frontend-Challenge, um doppelte Abfragen zu vermeiden.
• Verfügbarkeit der Tarife: „Professional“ und höher. Die kostenlosen WooCommerce-Sensoren für fehlgeschlagene Login-Versuche (woocommerce_login_failed, woocommerce_checkout_login_form_failed_login) sind in jedem Tarif weiterhin verfügbar und speisen den Brute-Force-Zähler.

E-Mail- und SMS-Zustellung

Die E-Mail-Ebene läuft über einen pluggbaren Anbietervertrag (ReportedIP_Hive_Mailer). Der Standardanbieter ist WordPress wp_mail(); Integratoren können einen eigenen Anbieter einbinden, ohne den Rest des Plugins zu verändern. Ab dem „Professional“-Tarif können Transaktions-E-Mails (2FA-Codes, Sicherheitsbenachrichtigungen) stattdessen über den verwalteten Mail Relay von ReportedIP versendet werden: eine SPF-, DKIM- und DMARC-konforme Absenderinfrastruktur, sodass OTP-E-Mails nicht im Spam-Ordner landen, wie es bei nicht authentifizierten wp_mail() E-Mails von Shared-Hosting-Anbietern oft der Fall ist.

• SMS-2FA ist eine Funktion der Professional-Stufe, die ausschließlich über den verwalteten ReportedIP-Relay bereitgestellt wird; ein eigenes SMS-Konto, Twilio-Anmeldedaten oder ein Mobilfunkvertrag sind nicht erforderlich. Die Funktion wird bei Abschluss eines kostenpflichtigen Tarifs automatisch konfiguriert; aktivieren Sie sie unter „Schutz“ → „Zwei-Faktor-Authentifizierung“ → „SMS“. Die Wartezeit für erneute Sendeversuche pro Empfänger steigt schrittweise an (0 s → 30 s → 1 m → 2 m → 5 m → 15 m), sodass eine verzögerte oder nicht zugestellte SMS ohne Nachteile erneut angefordert werden kann, während ein echter Versandanstieg weiterhin gedrosselt wird.
• Monatliche Kontingente und Prepaid-Pakete. PRO umfasst 25 SMS / 500 E-Mails pro Monat, Business 75 / 2.500 (pro Lizenz). Prepaid-Pakete ergänzen diese Kontingente; die Preise entnehmen Sie bitte der obigen Tarifübersicht und im Abschnitt zur Reihenfolge der Paketverbrauchsregelung erfahren Sie genau, was geschieht, wenn ein Kontingent aufgebraucht ist (Spoiler: E-Mails werden dann auf den lokalen wp_mail(), keine 2FA-Methode wird jemals deaktiviert).
• E-Mail-Vorlagen mit eigenem Branding (ab Business). Business ermöglicht White-label-Transaktions-E-Mails: Ihr Logo, Ihre Farben und Ihre Absenderidentität werden in 2FA- und Benachrichtigungs-E-Mails anstelle des „ReportedIP“-Brandings angezeigt, passend zum White-label-Schnellstart und den 2FA-Seiten.

Konfigurationsübersicht

Alle Einstellungen liegen auf einer Seite, ReportedIP Hive → Schutz: vierzehn Karten, eine je Bereich, jede mit Kurzstatus, ein Suchfeld, das die passende Karte öffnet, und zwei Tiefen. „Einfach“ zeigt die sechzehn Einstellungen, die im Alltag zählen; der Expertenschalter im Seitenkopf zeigt jedes Feld. Was keine Einstellung ist (Drop-in des erweiterten Schutzes, Server-Snippets, Regel-Sync, Ausnahmen, Import/Export, Test-Mail), liegt unter Werkzeuge, im Menü im Expertenmodus und per Adresse immer erreichbar. Jede Option steht in einer einzigen kanonischen Registrierung, trägt eine einzeilige Beschreibung und wird an einer Stelle bereinigt, sodass die Schutz-Seite, das MainWP-Formular und die Cloud-Flotte dasselbe Feld mit demselben Text anzeigen und der Schnellstart über dieselbe Registrierung schreibt. Jede Option der Registrierung lässt sich aus der Ferne verwalten. Nur wenige bleiben bewusst lokal: die Verbindungsidentität (Betriebsmodus, API-Schlüssel, Endpunkt), die Freigabe der Fernverwaltung selbst, der Schalter zum Löschen der Daten bei der Deinstallation, der Hauptschalter des Hardening Mode (sein Zustand „kein gespeicherter Wert“ aktiviert das Hardening ab dem Professional-Tarif automatisch) und der Schalter für den erweiterten Schutz, der eine Server-Direktive neben sich braucht.

Die wichtigsten Standardeinstellungen:

Datenbanktabellen

Neun Tabellen, die bei der Aktivierung erstellt und mit einem Präfix versehen werden wp_reportedip_hive_. Schema-Version 17, mit idempotenter schrittweiser Migration bei jedem Plugin-Update; Löschung nur auf Wunsch bei Deinstallation. Die Migration v16 wurde mit Version 2.1.50 ausgeliefert und hebt die Schwellenwerte für Reputationssperren auf, die unterhalb der 25-%-Untergrenze gespeichert waren, sodass der Einstellungsbildschirm nun anzeigt, was tatsächlich angewendet wird. In Multisite-Umgebungen befinden sich alle Tabellen unter $wpdb->base_prefix , sodass Entscheidungen bezüglich Bedrohungen netzwerkweit gelten. Migration v17 kam mit 2.1.62 und ergänzt die Objekt-Spalten des Audit-Trails.

• logs Sicherheitsereignisse, JSON-Details, Schweregrad, Markierung „gemeldet“; die Quelle für die Dashboard-Analysen (7- / 30- / 90-Tage-Trends, Aufschlüsselungen nach Familie und Schweregrad, Top-Angreifer).
• whitelist Vertrauenswürdige IPs und CIDR-Bereiche; Ablaufdatum optional.
• blocked Aktive Sperren (manuell / automatisch / Reputation), mit blocked_until.
• attempts IP-spezifischen Zählern pro Versuchstyp, mit Zeitstempeln für ersten und letzten Versuch; race-safe atomares „Upsert“ auf einem eindeutigen Schlüssel (IP, Versuchstyp) seit Schema v15.
• api_queue Ausstehende und fehlgeschlagene Reports an die Community-API; Wiederholungslogik.
• stats Tägliche Aggregate (fehlgeschlagene Logins, Sperren, Spam, XML-RPC, Reputation) für Trendübersichten und Reports.
• trusted_devices 2FA-Gerätetoken (SHA-256-Hashes), IP-Adresse und Gerätename, Ablaufdatum.
• audit_log nur anhängender Audit-Trail darüber, wer was geändert hat (Business); hinzugefügt in Schema v9, Objekt-Spalten seit Schema v17.
• waf_exceptions Die vom Backend verwaltete WAF-Allowlist (Gültigkeitsbereich: Regel / Gruppe / Pfad, optional IP/CIDR); hinzugefügt in Schema v10, netzwerkweit.

Frontend-Shortcodes & automatische Fußzeile

Betten Sie ein kleines „Protected by Hive“-Abzeichen an beliebiger Stelle auf der Website ein. Alle Shortcodes rendern eine einzige <rip-hive-banner> Webkomponente und beziehen Live-Zahlen aus einem 6-stündigen temporären Cache (kein API-Aufruf pro Seitenaufruf).

• [reportedip_badge] kleines Abzeichen (Standard-Schutzfarbton).
• [reportedip_stat] Einzelne Statistik (Standard: „Trust“-Farbton).
• [reportedip_banner] Breites Banner (Standard: Community-Farbton).
• [reportedip_shield] Schild-Symbol (Standard: „Contributor“-Farbton).

Gemeinsame Attribute: stat (z. B. attacks_30d, reports_total), tone (protect / trust / community / contributor), color, background, label, intro. Die automatische Fußzeile, die der Schnellstart einschaltet, verwendet dieselbe Komponente mit einer konfigurierbaren Variante und Ausrichtung.

Seit 2.1.57 hat die Community-Seite einen Tab „Badges“: oben das Footer-Badge mit Live-Vorschau, darunter ein Banner-Generator. Eine von sechs Vorlagen wählen (Footer-Badge, Schild, Bedrohungszähler, Community-Banner, Contributor, Login-Schild), Variante, Zahl, Wortlaut, Design und Ausrichtung anpassen und den erzeugten Shortcode kopieren. Farben, Text-Überschreibungen und die vollständige Attributliste liegen hinter einem Aufklappbereich.

WP-CLI-Referenz

Die 2FA-Tools, der Hardening Mode und (seit Version 2.1.41) die Community-IP-Abfrage sind vollständig skriptfähig:

wp reportedip 2fa status [--user=<id>]
wp reportedip 2fa enable <user_id> --method=<totp|email|sms|webauthn> [--secret=<base32>]
wp reportedip 2fa disable <user_id> [--method=<m>]
wp reportedip 2fa reset <user_id>
wp reportedip 2fa enforce --role=<role> [--remove]
wp reportedip 2fa audit [--user=<id>] [--since=<date>]
wp reportedip 2fa cleanup
wp reportedip hardening <status|activate|deactivate>
wp reportedip lookup <ip> [--format=<table|json|csv|yaml>]
wp reportedip status [--format=<table|json|csv|yaml>]
wp reportedip user block <user> [--message=<text>] [--note=<text>]
wp reportedip user unblock <user>
wp reportedip user list [--format=<table|json|csv|yaml>]

wp reportedip status gibt den Betriebsmodus, den Tarif und seit Version 2.1.51 ein issues Feld, in dem die offenen Bereitschaftsprobleme aufgeführt sind, als key (severity)auflistet, wodurch es als Überwachungssonde genutzt werden kann. Die user Befehle erfordern einen Business-Tarif für die Sperrung; die Entsperrung funktioniert stets.

Kompatibilität mit Cache-Plugins

Seit Version 1.5.2 definiert die Antwort auf eine gesperrte Seite DONOTCACHEPAGE, DONOTCACHEDB und DONOTCACHEOBJECT (wird von WP Rocket, W3 Total Cache, WP Super Cache und LiteSpeed Cache berücksichtigt) und gibt explizite Cache-Control: no-store, no-cache, must-revalidate, max-age=0, Pragma: no-cache sowie den WordPress-Kern- nocache_headers() . Ein einzelner blockierter Angreifer kann den Seitencache nicht mehr mit einem 403-Fehler verunreinigen, den legitime Besucher andernfalls bis zum Ablauf des Caches erhalten würden.

Filter und Aktions-Hooks

• apply_filters('reportedip_hive_external_url', $url, $context) ersetzen beliebige externe URLs (Datenschutzerklärung, Registrierung, FAQ, .).
• apply_filters('reportedip_hive_rest_bypass_routes', $routes) Erweitern Sie die Liste der REST-Routenpräfixe, die den Burst-Monitor umgehen (Cookie-Banner-Integrationen).
• apply_filters('reportedip_hive_scan_paths', $paths) Erweitern Sie die Honeypot-Pfadliste für den Scan-Detektor.
• apply_filters('reportedip_hive_decoy_paths', $paths) Erweitern Sie die Liste der Köderpfade für Decoy Paths.
• apply_filters('reportedip_hive_waf_bypass_routes', $routes) Schließen Sie REST-Routen auf Code-Ebene vom WAF aus (verankerte Präfixübereinstimmung mit der aufgelösten Route; standardmäßig leer). Bevorzugen Sie die vom Backend verwalteten WAF Exceptions für einmalige False Positives.
• apply_filters('reportedip_hive_mail_provider', $provider) Ihren eigenen E-Mail-Anbieter einbinden (implementieren interface-mail-provider.php).
• apply_filters('reportedip_hive_blocked_page_strings', $strings, $context) die für Besucher sichtbaren Texte auf der 403-Blockierungsseite überschreiben (White-label; Schlüssel doc_title, title, message, reason). Seit Version 2.1.41.
• apply_filters('reportedip_hive_reputation_block_hours', 24) / apply_filters('reportedip_hive_tor_block_hours', 24) Dauer der vorübergehenden Reputations- und Tor-Exit-Knoten-Sperren.
• do_action('reportedip_hive_threshold_exceeded', $ip, $event_type, $details) Wird bei jeder bestätigten Sensorerkennung ausgelöst, unabhängig von den Einstellungen für automatische Sperrung und Berichterstellung. Seit Version 2.1.41.
• do_action('reportedip_hive_ip_blocked', $ip, $reason, $blocked_until) Wird ausgelöst, wenn eine IP-Adresse gesperrt wird; $blocked_until ist ein Datums- und Zeitangabe im UTC-Format oder null bei dauerhaften Sperren.
• do_action('reportedip_hive_ip_unblocked', $ip) Wird ausgelöst, wenn eine Sperre aufgehoben wird.
• do_action('reportedip_hive_report_queued', $ip, $category_ids, $report_type) Wird einmal pro Report ausgelöst, der in die API-Warteschlange gelangt (durch Kommas getrennte Kategorie-IDs; negative oder positive).
• do_action('reportedip_hive_access_denied', $ip, $context) wird unmittelbar vor dem Rendern der 403-Sperrseite ausgelöst. Seit Version 2.1.41.
• do_action('reportedip_hive_2fa_verified', $user_id, $method) Wird nach einer bestandenen Zwei-Faktor-Überprüfung ausgelöst, sowohl im Formular für den Login als auch am REST-Verifizierungs-Endpoint. Seit Version 2.1.51 wird die Kern- wp_login Aktion wird dort ebenfalls ausgelöst: Bis dahin wurde sie nur bei Logins ausgelöst, bei denen keine Überprüfung stattfand, wodurch der Sensor für geografische Anomalien, die E-Mail bei neuen Geräten, der Prüfpfad und die 2FA-Erinnerung bei jedem Login mit Überprüfung keine Informationen erhielten.
• apply_filters('reportedip_hive_reputation_threshold_floor', 25) Erhöhen Sie den Schwellenwert von 25 % unterhalb der Blockierungsschwelle für das Community-Vertrauen. Eine Senkung ist nicht möglich.
• apply_filters('reportedip_hive_2fa_bypass', false, $user) Überspringen Sie den zweiten Faktor für einen Benutzer; dies wird auch von den adaptiven Step-up-Auslösern berücksichtigt.

Häufig gestellte Fragen

Die Fragen, die uns am häufigsten gestellt werden. Jede Antwort verweist gegebenenfalls auf den entsprechenden Abschnitt weiter oben.

Allgemeines

Installation und Einrichtung

Modi & Sensoren

2FA

Leistung und Kompatibilität

Datenschutz & DSGVO

Anpassung & Erweiterung

add_filter('reportedip_hive_rest_bypass_routes', function ($routes) {
    $routes[] = '/my-consent-plugin/v1';
    return $routes;
});

add_filter('reportedip_hive_scan_paths', function ($paths) {
    $paths[] = '/.aws/credentials';
    return $paths;
});

Kontingente, Tarife & Konto

Fehlerbehebung

Das Plugin blockiert keine IP-Adressen

Überprüfen Sie, ob der Report-Only Mode aktiviert ist; dieser protokolliert Bedrohungen, ohne sie zu blockieren. Vergewissern Sie sich außerdem, dass der Blockierungsschwellenwert nicht zu hoch eingestellt ist (Standard: 75 %) und dass die automatische Blockierung aktiviert ist (die Dauerstrategie ist deaktiviert, solange die automatische Blockierung ausgeschaltet ist).

Die Benutzer-Sitemap ist nach dem Update verschwunden

Ein Plugin, eine App oder ein Feed funktioniert nach dem Aktivieren des Lockdown-Schalters nicht mehr

Öffnen Sie „Schutz → Sicherheits-Header“ und schalten Sie den verdächtigen Schalter wieder aus; die Änderung tritt sofort in Kraft. Typische Fälle: eine mobile App oder ein Jetpack-ähnlicher Dienst, der weiterhin XML-RPC nutzt, ein Headless-Frontend oder ein Block-Editor-Plugin, das die REST API aufruft, ohne angemeldet zu sein (fügen Sie dessen Namespace zur Allowlist hinzu, anstatt die API erneut zu öffnen), ein Podcast- oder Newsletter-Dienst, der den RSS-Feed ausliest, sowie ein Zahlungsanbieter, der Daten an /wp-admin/ sendet. Auf der Seite „Aktivität“ werden alle abgelehnten Zugriffe mit ihrem Pfad unter „Firewall“ aufgelistet, sodass Sie den Aufrufer identifizieren können, bevor Sie Änderungen vornehmen. Eine unerwartet abgelehnte Registrierung wird unter „Registrierung“ zusammen mit der Regel protokolliert, die auf sie zutraf.

API-Verbindungsfehler im Community Network-Modus

Stellen Sie sicher, dass Ihr Server ausgehende HTTPS-Anfragen an reportedip.com senden kann. Einige Hosts blockieren ausgehende Verbindungen standardmäßig. Überprüfen Sie den API Key im Dashboard.

Besucher mit Cookie-Banner werden blockiert

Seit Version 1.5.0 werden die vier gängigen Einwilligungs-Namespaces (real-cookie-banner, complianz, borlabs-cookie, cookie-law-info) standardmäßig umgangen. Falls Ihr Stack einen anderen Namensraum verwendet, erweitern Sie die Umgehungsliste über den reportedip_hive_rest_bypass_routes Filter.

Legitime Nutzer werden blockiert

Fügen Sie deren IP-Adressen oder CIDR-Bereiche zur lokalen Whitelist hinzu. IP-Adressen auf der Whitelist werden niemals blockiert, unabhängig von ihrer Reputation.

Haben Sie sich ausgesperrt? (Eigene IP gesperrt, wp-admin nicht erreichbar)

Falls Ihre eigene IP-Adresse auf der Sperrliste gelandet ist und wp-admin nicht erreichbar ist, können Sie den Zugriff direkt in der Datenbank über phpMyAdmin oder die Datenbankkonsole Ihres Hosts wiederherstellen. Nutzen Sie vorzugsweise die Admin-Benutzeroberfläche (das Whitelist-Formular verfügt seit Version 2.1.41 über die Funktion „Meine IP hinzufügen“), sofern diese erreichbar ist; der direkte Datenbankzugriff ist der Notausgang und kein Werkzeug für den täglichen Gebrauch, da er die Validierung des Plugins umgeht.

Fügen Sie Ihre aktuelle öffentliche IP-Adresse zur Whitelist-Tabelle hinzu; Adressen auf der Whitelist haben Vorrang vor jeder Sperre:

INSERT INTO wp_reportedip_hive_whitelist (ip_address, ip_type, reason, added_by, is_active)
VALUES ('203.0.113.42', 'ipv4', 'Self-rescue: restore admin access', 1, 1);

Verwenden Sie 'ipv6' oder 'cidr' als ip_type für eine IPv6-Adresse oder einen Adressbereich; für rotierende private IPv6-Präfixe tragen Sie Ihr /64-Netzwerk als Whitelist-Netzwerk ein 'cidr'. added_by ist Ihre WordPress-Benutzer-ID (1 für das erste Admin-Konto). Alternativ können Sie Ihre Zeile aus der Blocktabelle löschen:

DELETE FROM wp_reportedip_hive_blocked WHERE ip_address = '203.0.113.42';

Ersetzen Sie das wp_ Präfix durch Ihr tatsächliches Tabellenpräfix aus wp-config.php falls dieses abweicht (in Multisite-Umgebungen verwenden die Plugin-Tabellen das Basispräfix). Die Änderung wird bei der nächsten Anfrage wirksam. Falls Extended Protection (der Pre-WordPress-Guard) aktiv ist und die Sperrung weiterhin besteht, löschen Sie bitte auch die zwischengespeicherte Blockliste wp-content/uploads/reportedip-hive/blocked-*.list, der Schutz arbeitet nach dem „Fail-Open“-Prinzip, und die Datei wird bei der nächsten Synchronisierung automatisch neu erstellt.

Die Firewall blockiert eine legitime Anfrage (WAF-False Positive)

Öffnen Sie „Aktivität“, suchen Sie die Sperre im Protokoll (der X-RIP-Ref Referenzcode auf der Blockierungsseite mit einer Protokollzeile übereinstimmt) und klicken Sie auf „Zulassen“; dadurch wird eine eng gefasste Ausnahme genau für diese Regel auf diesem Pfad erstellt. Siehe „WAF Exceptions“ für Hinweise zum Geltungsbereich. Ausnahmen gelten auch für den „Extended Protection“-Schutz vor WordPress.

„Extended Protection“ ist aktiviert, wird jedoch als „nicht ausgeführt“ angezeigt

Typisch für nginx-Hosts, bei denen die automatisch generierte .user.ini Direktive nicht übernommen wird (z. B. user_ini.filename deaktiviert ist oder der Dokumentstamm nicht dem Scan-Pfad entspricht). Auf der Registerkarte „Werkzeuge → Server“ werden die manuellen Optionen angezeigt: die Zeile „PHP-FPM-Pool / php.ini“ auto_prepend_file oder das nginx fastcgi_param -Snippet. Der Status ist überprüfbar; er gibt an, ob der Schutzmechanismus bei der aktuellen Anfrage tatsächlich ausgeführt wurde. Die in WordPress integrierte Engine schützt die Website in jedem Fall; das Plugin verschiebt lediglich die gleichen Prüfungen auf einen früheren Zeitpunkt.

Hohe API-Auslastung / Aufbrauchen der Prüfungen

Antworten werden standardmäßig 24 Stunden lang lokal (mit ETag) zwischengespeichert. Sollten Ihnen dennoch die Prüfungen ausgehen, erhöhen Sie cache_duration Ihren Tarif oder wählen Sie ein höheres Paket. Überwachen Sie die Warteschlange und das Kontingent im Dashboard.

Durch 2FA ausgesperrt

Verwenden Sie einen der bei der 2FA-Einrichtung gespeicherten Recovery Codes. Sollten diese verloren gegangen sein, kann ein Administrator die 2FA für jeden Benutzer unter „Benutzer → Zwei-Faktor-Authentifizierung“ zurücksetzen. Als letztes Mittel: wp reportedip 2fa reset <user_id>.

Seit Version 2.1.22 wird ein Benutzer der 2FA nie eingerichtet hat, standardmäßig nicht mehr gesperrt: Sobald die Karenzzeit und die Überspringmöglichkeiten ausgeschöpft sind, wird er angemeldet und direkt in die erzwungene Registrierung weitergeleitet (ohne Überspringoption). Administratoren und Multisite-Superadministratoren können niemals vollständig ausgesperrt werden, selbst wenn Sie die Richtlinie wieder auf „Anmeldung blockieren“ zurücksetzen.

Der Block-Editor (Gutenberg) wird immer wieder gedrosselt

Der Block-Editor löst innerhalb weniger Sekunden über 50 REST-Aufrufe aus. Seit Version 1.2.2 umgehen angemeldete Benutzer den globalen REST-Burst-Monitor; es zählen nur anonyme Bursts. Stellen Sie sicher, dass Sie Version 1.2.2 oder neuer verwenden.

DSGVO & Datenschutz

Das Plugin wurde unter Berücksichtigung des Datenschutzes entwickelt und ist vollständig GDPR Compliant.

• „Local Shield“-Modus: Es verlassen keine Daten Ihren Server. Die gesamte Erkennung und Blockierung erfolgt lokal.
• Community Network-Modus: Die IP-Adresse des Angreifers, die Threat Category und der Zeitstempel werden weitergegeben, und jede Anfrage identifiziert die Installation selbst (Website-Adresse, Plugin-/WordPress-Version; dies dient der Zählung der Lizenzdomänen und dem Support). Keine Benutzernamen, keine Passwörter, keine Kommentarinhalte, keine Endbenutzerdaten.
• User-Agents werden vor der Speicherung auf 50 Zeichen gekürzt.
• Automatische Bereinigung: Sicherheitsprotokolle werden nach Ablauf der konfigurierten Aufbewahrungsfrist (standardmäßig 30 Tage) gelöscht. Die automatische Anonymisierung setzt bereits früher ein (standardmäßig 7 Tage).
• Verschlüsselung im Ruhezustand: TOTP-Geheimnisse, WebAuthn-Anmeldedaten und SMS-Telefonnummern werden mit libsodium (OpenSSL-Fallback) verschlüsselt gespeichert.
• Kein Besucher-Tracking: Keine Cookies, keine Tracking-Pixel. Die einzige Telemetrie ist die Installationsidentität (Website-Adresse, Plugin-/WordPress-Version), die mit API-Anfragen im Community-Modus gesendet wird, Daten über Ihre Installation, niemals über Ihre Besucher.
• Integration in die Datenschutz-Tools von WordPress: Hive registriert einen Exporteur und Löscher für personenbezogene Daten im WordPress-Kern, sodass Anfragen unter „Tools → Personenbezogene Daten exportieren / löschen“ automatisch die Datensätze von Hive für das angeforderte Thema enthalten (Protokolleinträge, Trusted Devices, Audit-Trail-Einträge). Außerdem liefert es einen vorgeschlagenen Absatz für den WordPress-Leitfaden zur Datenschutzerklärung (Schutz → Datenschutz & Protokolle → Leitfaden zur Datenschutzerklärung), den Sie in Ihre eigene Datenschutzerklärung kopieren können.
• Open Source: Der vollständige Quellcode ist auf GitHub veröffentlicht, jede Zeile ist überprüfbar.

Highlights des Changelogs

• 2.1.62: Der Audit-Trail zeichnet auf, wer was geändert hat: acht Auslöser-Gruppen (Konten, Seiten und Beiträge, Plugins und Themes, Einstellungen mit altem und neuem Wert, Menüs und Widgets, der Datei-Editor, das Netzwerk) mit handelndem Benutzer, Anfrageweg und betroffenem Objekt, Schalter je Gruppe, 90 Tage Aufbewahrung als Standard mit blockweiser Bereinigung, ein Website-Filter für Netzwerke und eine Audit-Trail-Seite für jeden Website-Administrator. Jeder Ereignistyp lebt in einer Registry; der Filter des Ereignisprotokolls ist durchsuchbar und wählt ganze Gruppen, und Formular-Spam ist zurück in den Diagrammen.
• 2.1.58–2.1.61: Der Formular-Ausführungsnachweis kann eine Rechenaufgabe verlangen (Professional), ein Captcha-Ersatz, den eigene Formulare über eine kleine Schnittstelle nutzen; Contact Form 7 und Ultimate Member sind ab Professional abgedeckt, Formidable Forms und Elementor Forms ab Business; der Kommentar-Spamfilter liest acht weitere Signale; die Formular-Einstellungen bekamen eine eigene Karte, und jede Einstellung nennt den Tarif, zu dem sie gehört.
• 2.1.57: Die Aktivitätsseite öffnet auf dem Ereignisprotokoll hinter einer Filterleiste, die sich als Lesezeichen ablegen lässt, die Community-Seite teilt sich in Einstellungen, Community und Badges (Ein-Klick-Footer-Badge plus Banner-Generator), das Dashboard trägt eine Statuszeile und zugeklappte Schutzbereiche, und die Hinweise zur Berichtswarteschlange schweigen, solange nichts senden kann. Ein abgelehnter Zugangsschlüssel zählt nicht mehr als Fehlversuch im API-Gesundheitsfenster.
• 2.1.56: Die Seiten Einstellungen und Firewall wurden durch eine Schutz-Seite ersetzt (eine Karte je Registerbereich, Suche, Einfach- und Expertentiefe, ein gemeinsamer Speicherdienst mit MainWP, Flotte und Import) und durch eine Werkzeug-Seite für Drop-in, Regel-Sync, WAF-Ausnahmen, Import, Export, Reset und Test-Mail. Das Dashboard bekam ein Statusbanner, Nächste-Schritte-Karten aus sechs Hinweis-Detektoren und eine Zeile je Schutzbereich. Alte Einstellungs- und Firewall-Adressen leiten weiter.
• 2.1.54–2.1.55: Aus dem Einrichtungsassistenten wurde ein einseitiger Schnellstart, der den Tarif aus der Schlüsselprüfung liest und eine passende Empfehlung über das Einstellungsregister einschaltet; ein späterer Tarifwechsel aktiviert für unveränderte Werte, was der neue Tarif empfiehlt. Jede gespeicherte Einstellung folgt jetzt einem Standard, und das Dashboard zeigt die neuesten Meldungen von reportedip.com in der Sprache des Administrators.
• 2.1.52–2.1.53: Abwehr für Kommentare und Formulare. Ein bewertender Kommentar-Spamfilter mit rund zwanzig Signalen (ein Kommentar, der auf Freigabe wartet, ist kein Spam-Urteil mehr), ein cache-fester Ausführungsnachweis auf Kommentar-, Registrierungs- und Passwort-Formularen und die Community-Reputationsprüfung, die von der Anmeldeseite auf genau diese drei Formulare ausgeweitet wurde. In jedem Tarif kostenlos.
• 2.1.51: Fünf neue Schutzmaßnahmen. Registrierungsschutz (verbotene Benutzernamen, E-Mail-Regeln, eine Begrenzung der Anmelderate pro IP-Adresse, eine Opt-in-Sperre für Anmeldungen mit nicht existierenden Benutzernamen), Zugriffssperrschalter für REST, XML-RPC, Feeds, wp-admin, PHP bei Uploads sowie Versions-Fingerabdrücke und ein Systembereitschaftsregister mit zwölf Detektoren, alles kostenlos in jedem Tarif. Kontosperrung sowie der Sitzungsmanager unter „Benutzer → Sitzungen“ im Business-Tarif, adaptive Auslöser für die zweistufige Zwei-Faktor-Authentifizierung je nach Rolle im Professional-Tarif. Siebzig Optionen wurden in das Einstellungsregister verschoben (insgesamt 169, alle beschrieben, 71 fernverwaltbar); der Import von Einstellungen kann den Sanitizer nicht mehr umgehen, und der Hardening Mode begrenzt nun auch die Schwellenwerte für die Login-Oberflächen von WooCommerce und für den Login mit Anwendungskennwörtern.
• 2.1.48–2.1.50: Cloud-Flottenmanagement (Business) über drei mit Ed25519 signierte REST-Routen mit einem Aktualisierungsfenster, einmalig verwendbaren Anfrage-IDs und Zielgruppenbindung; standardmäßig deaktiviert, kann aktivieren. Eine Untergrenze von 25 % unterhalb des Schwellenwerts für den „Community-Confidence“-Block, wobei die Migration v16 gespeicherte Werte unterhalb dieser Untergrenze aufhebt, sowie vollständige IP-Verwaltung über WP-CLI (whitelist, block, unblock, blocked list, attempts reset) sowie wp reportedip status.
• 2.1.42–2.1.47: Die Sicherheits- und Korrektheitsprüfung: admin-ajax.php innerhalb des Block-Gates und der Firewall durchgeführt, einmalig verwendbare TOTP-Codes, eine WAF-Exception, die die dahinterliegenden Regeln nicht mehr verschleiert, prozentkodierte Prüfungen, die von drei weiteren Sensoren erfasst werden, sowie zweiundvierzig AJAX-Handler auf einem gemeinsamen Permissions Guard. Zudem eine Installationsidentität im wp.org-Stil bei jeder API-Anfrage, eine Karte mit lizenzierten Domains auf dem Dashboard, das kanonische Einstellungsregister mit seinem versionierten Remote-Protokoll sowie wieder für MainWP und ManageWP sichtbare Plugin-Updates.
• 2.1.37–2.1.41: Opt-in-Sperrung von Tor-Exit-Knoten (Professional, signierter tor_exits Regelsatz), vertrauenswürdige Proxy-Quellbereiche zum Schutz vor „Forwarded-Header“-Spoofing, ein Sicherheits-Widget auf dem wp-admin-Dashboard, ein „Never-Block“-Veto für von der Community verifizierte Infrastruktur, eine erweiterte IP-Abfrage mit wp reportedip lookup, stabile Integrator-Hooks (reportedip_hive_threshold_exceeded), race-sichere Versuchszähler (Schema v15) sowie eine strengere Firewall: Ausnahmen für Crawler erfordern ein überprüfbares Signal, Payload-Regelgruppen blockieren bereits beim ersten Treffer, Release-Builds enthalten wieder die gebündelten Regelsätze, und vier Regeln schließen die CVE-2026-64638 (XSS2Shell)-Kette beim Login. Die Domain wurde auf reportedip.com verlegt.
• 2.1.33–2.1.36: Offizielle Unterstützung für YubiKey und Hardware Security Key: vollständige WebAuthn-Prozesse auf allen drei Challenge-Oberflächen, ein Multi-Key-Manager mit attestationbasierter Modellerkennung (Business), Erkennung geklonter Schlüssel über Regression des Signaturzählers mit E-Mail-Benachrichtigungen in allen Tarifen, Ed25519, sofern libsodium verfügbar ist, sowie ein überarbeiteter, leicht verständlicher Abschnitt zur 2FA mit einer vom Benutzer wählbaren Standardmethode.
• 2.1.26–2.1.32: Kreuzprüfung durch verifizierte Crawler (ein gefälschter Googlebot-User-Agent tätigt keine Käufe), eine zentrale Schutzfunktion, die verifizierte Bots niemals blockiert, Community-Reputationssperren, die alle Bereiche abdecken, Verhinderung von Selbstsperrungen für die eigenen Adressen des Servers, volumengewichtete Block Escalation sowie die Leistungsoptimierung: 36 → 11 Abfragen pro Anfrage, ein 8-KB-Header für die Blocklist sowie eine TTFB im Dashboard von 920 → 278 ms (Schema v13).
• 2.1.25: Die WAF blockiert die REST-Batch-Route-Confusion-Angriffsklasse des WordPress-Kerns in jedem Tarif (strukturelle Regeln, kein Token-Abgleich), überprüft eine dekodierte Kopie des Request-Bodies (wodurch eine Umgehung über kodierte Payloads verhindert wird) und Paranoia-Level-2/3-Blockierungen renderen ihre spezifische Referenzkategorie.
• 2.1.22–2.1.24: Die erzwungene 2FA-Standardkonfiguration sieht nun eine obligatorische Registrierung anstelle einer Sperrung vor (Administratoren und Super-Administratoren können niemals dauerhaft gesperrt werden); eine doppelte Übermittlung der 2FA-Herausforderung führt nicht mehr dazu, dass Benutzer bei „Sitzung abgelaufen“ hängen bleiben; die PHPUnit eval-stdin.php RCE-Prüfung (CVE-2017-9841) wird in jedem Tarif blockiert.
• 2.1.14–2.1.20: Korrektheit des Produktions-Hostings: UTC-konforme Datums- und Zeitangaben (die automatische Sperrung schlug auf Nicht-UTC-Datenbankservern stillschweigend fehl), der Hide Login funktioniert hinter Seiten-Caches und auf Websites mit „Trailing Slash“ sowie auf Nginx-Seiten, „Extended Protection“ konfiguriert sich automatisch unter Nginx + PHP-FPM und überspringt die Body-Prüfung für angemeldete Redakteure, die API-Zustandsprüfung nutzt ein rollierendes Fenster, und das Abfragen der Relay-Quota für Hot-Paths wurde entfernt.
• 2.1.9–2.1.13: Vom Backend verwaltete WAF Exceptions mit einer Ein-Klick-Aktion „Zulassen“ (Schema v10), selbsterklärende Blockprotokollierung (abgeglichener Wert, Ziel, Methode, URI, User-Agent), MainWP-Provisioning kann Websites in den Community-Modus versetzen, und das Sicherheits-Dashboard wurde zu einer umfassenden Analyseansicht (sieben Bedrohungsfamilien, Diagramm der WAF-Regelgruppen, Top-Angreifer).
• 2.1.0–2.1.8: Die Firewall-Version: ein serverseitig bereitgestelltes, mit Ed25519 signiertes „Rule Delivery Framework“, das eine Anfragen prüfende Web Application Firewall speist (kostenlose Engine + „Paranoia-Level-1“-Baseline, PRO-Level 2/3 über „Priority Sync“, Verified Bot Detection, Disposable-Email Blocking, Comment Honeypot, Security Headers (grundlegend kostenlos, erweitert in PRO), Protection & Hardening Score für Dashboard-Schutz und Absicherung, Referenzcodes für Sperrseiten (X-RIP-Ref), den Audit Event Trail (Schema v9), die MainWP Integration sowie einen Firewall-Verwaltungsbereich, gefolgt von Korrekturen für False Positives bei legitimen Crawlern und der ausfallsicheren Drop-in-Entfernung.
• 2.0.x: Netzwerkweite Multisite-Aktivierung (Network: true), Verwaltung der Zugriffsebenen pro Blog, Banner für Ebenen-Upgrades, verstärkte Überwachung von App-Passwörtern und geografischen Anomalien, 2FA im WooCommerce-Frontend ab PRO+, Hardening Mode für koordinierte Angriffe, Erkennung und Meldung von Decoy Paths.
• 1.5.2: Kompatibilität mit Cache-Plugins auf der 403-Seite; die 2FA-Drosselung wird zu einer echten Eskalationssperre ausgebaut; init Priorität 1.
• 1.5.1: Übersichtlichkeit im Blockierungs-Reiter (Reports > Automatische Blockierung > Dauer-Strategie); Editoren für feste Länge und Stufenleiter werden inline ausgetauscht.
• 1.5.0: Progressive Block Escalation (5 m → 7 d Leiter); Cookie-Banner-Endpoints werden standardmäßig umgangen; Standardwerte für 404/Kommentar-Spam wurden gelockert.
• 1.2.4: Die Schaltfläche „Erneut versuchen“ in der API-Warteschlange löst nun tatsächlich den API-Aufruf aus.
• 1.2.0: Sieben neue Sensoren: App-Passwort-Monitor, REST-Burst-Monitor, Blockierung von User Enumeration, 404/Scan-Detektor, Geo-Anomalie, Passwortstärke, Hide Login.
• 1.1.0: Zentraler Mailer mit Markenvorlage.
• 1.0.0: Erste öffentliche Veröffentlichung: IP-Sperrung, 4-Methoden-2FA, Setup Wizard, Listentabellen.

Vollständige Historie: Changelog.md auf GitHub.

Suchen Sie die kleinere Version?

Zuletzt aktualisiert: 20. September 2026 · Betreut vom ReportedIP-Team