Releases

ReportedIP Hive 2.1.72: Gruppensperren und eine Schutz-Seite in fünf Tabs

9. Oktober 2026 · Patrick Schlesinger

Mit ReportedIP Hive 2.1.72 teilen mehrere WordPress-Websites ihre IP-Sperren als Gruppe, die Schutz-Seite ist neu in fünf Tabs aufgebaut, und eine Website meldet den Server, auf dem sie läuft, nicht mehr. Die Version schließt sechs Releases ab, die zwischen dem 28. September und dem 9. Oktober 2026 erschienen sind, mit zwei Regeln gegen SQL-Injection, die jetzt in der Offline-Basis der Firewall liegen, und über zwanzig Korrekturen für Multisite-Netzwerke, Formulare und den versteckten Login.

Aktualisieren Sie direkt im WordPress-Backend oder laden Sie das aktuelle ZIP von der Hive-Produktseite. Der vorige Release-Beitrag behandelte Hive 2.1.66 und den Formularschutz; dieser Beitrag hält fest, was sich seitdem geändert hat.

Was hat sich zwischen Hive 2.1.66 und 2.1.72 geändert?

Version	Datum	Wichtigste Änderung
2.1.67	28. September 2026	Gruppensperren, eigener Host wird nicht mehr gemeldet, Kommentarformular weist Bots ab
2.1.68	29. September 2026	Zwei SQL-Injection-Regeln in der Basis, Priority Sync ab Contributor
2.1.69	30. September 2026	Schutz-Seite in fünf Tabs, User-Agents in Anführungszeichen gelten als Bot
2.1.70	2. Oktober 2026	Ruhigere Flotten-Fingerabdrücke, Formulare im Netzwerk-Admin repariert
2.1.71	5. Oktober 2026	Multisite mit mehreren Domains sperrt den Admin nicht mehr aus
2.1.72	9. Oktober 2026	Wegwerf-Adressen bei Kommentaren und Formularen abgewiesen

Wie funktionieren Gruppensperren in Hive 2.1.67?

Ein Community Access Key kann in Ihrem reportedip.com-Konto einer Gruppe beitreten. Jede Adresse, die ein Mitglied meldet, ist dann bei allen anderen Mitgliedern für das Sperrfenster der Gruppe gesperrt. Hive spiegelt die Gruppenliste als Sperren eines eigenen Typs group: Ein Eintrag bleibt bis zu dem Ablauf gesperrt, den der Dienst nennt, und wird aufgehoben, sobald er die Liste verlässt.

• Die Whitelist gewinnt. Ihre eigene Whitelist schlägt weiterhin jeden Gruppeneintrag, und eine Sperre, die Sie von Hand gesetzt haben, bleibt unberührt.
• Die Gruppen-Whitelist erreicht jedes Mitglied. Adressen und Bereiche auf der Whitelist der Gruppe landen in der Whitelist jeder Website mit der Herkunft Gruppe, für IPv4 und IPv6.
• Nichts Veraltetes bleibt zurück. Verlässt der Key die Gruppe, deckt der Tarif keine Gruppen mehr ab oder wechselt die Website zu Local Shield, wird alles aufgehoben, was die Gruppe gesetzt hat.
• Sichtbar, wo Sie arbeiten. Das Dashboard zeigt eine Gruppenkarte, und unter Aktivität > IP-Listen gibt es einen Tab Gruppe mit jeder gelisteten Adresse, dem meldenden Mitglied und dem, was diese Website daraus gemacht hat.

Gruppen gibt es ab dem Professional-Tarif. Mitglieder können WordPress-Websites mit Hive und Linux-Server mit dem Agent sein, gemischt in einer Gruppe. Einrichtung und Screenshots stehen in der Anleitung IP-Sperren über WordPress-Websites teilen; Grenzen je Tarif und Webhooks finden Sie auf der Doku-Seite zu Gruppen.

Warum meldet eine Website ihren eigenen Server nicht mehr?

wp-cron, REST-Anfragen an sich selbst und das Vorladen von Caches kommen von der öffentlichen Adresse des Hosts selbst, und das sieht aus wie ein Besucher von außen. Fünf Sensoren melden direkt und haben die Prüfung dieser Adresse übersprungen, deshalb haben Websites die öffentliche IPv6 ihres eigenen Servers gemeldet. Das hat das Meldekontingent des Kontos verbraucht und den Server auf die Community-Liste gesetzt, die andere Websites lesen.

Seit 2.1.67 sitzt diese Grenze an den zwei Stellen, die jede Entscheidung passiert: in der Melde-Warteschlange und beim Sperraufruf, neben den Prüfungen auf private Adressen und die Whitelist. Ein Host merkt sich außerdem seine Adresse in beiden Familien, IPv4 und IPv6, sobald er zum ersten Mal darüber antwortet. Eine Sperre, die Sie von Hand setzen, funktioniert weiterhin.

Wie sieht die neue Schutz-Seite aus?

Seit 2.1.69 hat die Schutz-Seite fünf Tabs statt fünfzehn Karten: Grundschutz, Formulare, Firewall & Bots, Erweitert und Betrieb, jeweils mit einer Statusanzeige. Jede Einstellung ist eine Zeile: links ein verständlicher Satz, rechts der Schalter. Ein Schalter, den Ihr Tarif nicht enthält, nennt den nötigen Tarif, statt ausgegraut dazustehen.

• Die Experteneinstellungen jedes Bereichs liegen hinter Technische Details anzeigen; im Expertenmodus sind sie von Anfang an geöffnet.
• Jeder Tab hat ein Änderungen speichern und ein Standard wiederherstellen, das die Empfehlung für Ihren Tarif schreibt.
• Ein Knopf Schutz prüfen neben dem Statusbanner führt die Einrichtungsprüfung erneut aus und zählt die offenen Probleme und Hinweise.
• 2.1.72 fasst den Erweiterten Schutz in einer Karte mit einem Status und einem Knopf zusammen.

Die Einstellungsregistrierung, das Remote-Schema für MainWP und die Cloud-Flotte sowie jeder Link auf die Seite sind gleich geblieben. Die Härtungs-Checkliste geht die Schalter der Reihe nach durch.

Welche Firewall- und Spam-Regeln sind strenger geworden?

Zwei Regeln gegen SQL-Injection gehören jetzt zur Offline-Basis

Fehlerbasierte Injection liest Daten über EXTRACTVALUE() oder UPDATEXML() aus der Fehlermeldung der Datenbank, und eine Second-Order-Injection reist im Trackback-Text mit und schlägt später zu. Beide Regeln kamen bisher nur über Rule Sync. Seit 2.1.68 liegen sie in der mitgelieferten Basis, damit ist auch eine Website im Local-Shield-Modus geschützt, in der Engine innerhalb von WordPress und im Wächter vor WordPress. Die Angriffsklasse beschreibt der OWASP-Eintrag zu SQL-Injection.

Priority Sync beginnt mit dem Contributor-Tarif

Contributor erhält jetzt das WAF-Regelwerk mit Paranoia Level 2 und die IP-Bereichslisten der Bots, wöchentlich aktualisiert. Level 3 und die tägliche Aktualisierung bleiben bei Professional. Die Engine setzt die Obergrenze selbst durch, ein Downgrade fällt sofort auf die Basisstufe zurück.

Das Kommentarformular weist Bots ab wie jedes andere Formular

Ein Kommentar von einem Client, der das Seitenskript nie ausgeführt hat, bekam bisher ein paar Spam-Punkte und konnte trotzdem in der Moderation landen. Seit 2.1.67 wird er direkt abgewiesen, mit demselben Wortlaut und derselben Logzeile wie beim Registrierungsformular und den sechs Formular-Plugins. Ein Link im Kommentartext zählt jetzt wie ein Link im Website-Feld: Gemessen an 349 echten Spam-Kommentaren stieg die Trefferquote gegen Bots, die die Skriptprüfung bestehen, von 42 auf 50 Prozent.

User-Agents in Anführungszeichen und Wegwerf-Adressen

Kein Browser setzt seinen User-Agent in Anführungszeichen, ein falsch konfigurierter Headless-Client schon. Seit 2.1.69 wird eine solche Einsendung abgewiesen, sofort gesperrt und gemeldet, und die neue Basisregel waf_ua_quoted stoppt denselben Client in beiden Firewall-Schichten. Seit 2.1.72 bitten Kommentare und jedes geschützte Formular einen Absender mit Wegwerf-Mailadresse um eine dauerhafte Adresse; die Einstellung bietet Sperren, Beobachten und Aus, Standard ist Sperren.

Was ändert sich für Multisite-Netzwerke und verwaltete Flotten?

• Mehrere Domains, ein Admin. Mit eingeschaltetem Hide Login landete ein Admin, der über Meine Websites auf eine andere Domain des Netzwerks wechselte, auf der Sperrseite. Seit 2.1.71 zeigen solche Links auf den Login dieser Domain, mit der Admin-Seite als redirect_to.
• Formulare im Netzwerk-Admin funktionieren. WordPress liefert für das Netzwerk keine admin-post.php, deshalb antworteten das Ausblenden von Hinweisen, der Gruppenabgleich und 2FA-Aktionen mit 404. Repariert in 2.1.70; das Speichern der Schutz-Seite führt dort seit 2.1.69 zurück in den Netzwerk-Admin.
• Keine falsche Abweichung nach einem Update. Der Einstellungs-Fingerabdruck, den MainWP und die reportedip.com-Flotte sehen, umfasst nur noch Werte, die vom Standard abweichen. Ein Release mit einer neuen Einstellung markiert also nicht mehr jede Website als geändert.
• Checkbox-Gruppen in den Dashboards. Rollen, 2FA-Methoden und Auslösergruppen des Audit-Trails erscheinen in MainWP und der Flotte als Checkboxen statt als rohes JSON-Feld.

Beide Verwaltungswege beschreiben der Abschnitt zu MainWP und der Abschnitt zu Multisite der Hive-Dokumentation.

Welche Fehler haben die sechs Releases behoben?

• Ein verifizierter Crawler wird für einen Scanner-Pfad nicht mehr gesperrt. Eine Adresse, die über den veröffentlichten Adressbereich des Crawlers oder per Forward-Confirmed Reverse DNS (FCrDNS) belegt ist, behält ihre Ausnahme. Ein User-Agent allein reicht weiterhin nicht (2.1.72).
• Ein lange offenes Formular wird angenommen. Das Seitenskript erneuert seine Antwort jetzt, bevor sie abläuft, wenn der Tab wieder sichtbar wird und im Moment des Absendens (2.1.72).
• Massenaktionen funktionieren nach einem Filter. Löschen oder erneutes Senden von Warteschlangeneinträgen, Logs, Sperren oder Whitelist-Einträgen tat nach dem Filtern nichts (2.1.72).
• Der versteckte Login zeigt wieder den echten Fehler. Eine abgelaufene Sitzung oder ein blockiertes Cookie erscheint nicht mehr als „Ungültige Anmeldedaten.“ (2.1.67).
• Eine abgelaufene Sitzung sperrt kein Büro mehr aus. Ein abgemeldeter Aufruf von wp-admin wird weiterhin abgewiesen und protokolliert, zählt aber nicht mehr für die Sperrleiter (2.1.67).
• Hide Login und sein Slug lassen sich zusammen einschalten. Werte werden jetzt auf jedem Kanal vor den Schaltern geschrieben, MainWP und die Flotte eingeschlossen (2.1.69).
• Mail-Fußzeilen nennen die Website bei ihrer Adresse. Ein Linktext, der etwas anderes nennt als sein Ziel, gilt für Microsoft 365 und Gmail als Phishing-Signal (2.1.72).
• Installationen werden auf wordpress.org wieder gezählt. Updates kommen weiterhin nur über den Release-Kanal von ReportedIP (2.1.70).

Seit 2.1.68 folgt außerdem der Audit-Trail dem Schalter User-Agents protokollieren, der standardmäßig aus ist, so wie es das Sicherheitslog schon immer tat. Der Abschnitt zu DSGVO führt auf, was Hive speichert.

Fragen zu Hive 2.1.72

Welcher Tarif enthält Gruppensperren in Hive?

Gruppensperren brauchen den Professional-Tarif oder höher. Ein Key in einem niedrigeren Tarif erhält einen Hinweis, und der Abgleich fragt weiter nach, ein Upgrade braucht auf der Website also keinen weiteren Schritt. Ein Key ohne Gruppe merkt keinerlei Änderung. Sobald der Tarif Gruppen abdeckt und der Key in keiner Gruppe ist, zeigt das Dashboard einen nächsten Schritt mit Link zum Gruppenbereich Ihres Kontos.

Ändern sich meine Schutz-Einstellungen mit der neuen Seite in fünf Tabs?

Ihre gespeicherten Einstellungen bleiben genau so, wie sie waren. Die Seite mit fünf Tabs liest und schreibt dieselbe Registrierung wie die alten Karten, und MainWP und die Cloud-Flotte nutzen dasselbe Remote-Schema. Nur Standard wiederherstellen schreibt neue Werte, und zwar nur für den Tab, in dem Sie es anklicken. Eine neue Einstellung kommt eingeschaltet: Seit 2.1.72 werden Wegwerf-Adressen bei Kommentaren und geschützten Formularen abgewiesen, einstellbar im Tab Formulare.

Was sollte ich nach dem Update auf 2.1.72 prüfen?

Öffnen Sie die Schutz-Seite und klicken Sie auf Schutz prüfen, um die offenen Punkte zu sehen. Legen Sie im Tab Formulare fest, wie Wegwerf-Mailadressen behandelt werden sollen; Sperren ist der Standard. Teilen sich mehrere Ihrer Websites dieselben Angreifer, legen Sie in Ihrem Konto eine Gruppe an und fügen Sie deren Keys hinzu.

Weiterlesen

• Gruppensperren in Hive
• Firewall und Regelauslieferung
• Bots, Wegwerf-Mails und Kommentar-Spam
• Funktionen je Tarif

Betreiben Sie neben WordPress auch Linux-Server? Das Release von Linux Agent 0.3.48 bringt dieselben Gruppen in die Kernel-Firewall. Frühere Hive-Releases: Hive 2.1.62 mit dem Audit-Trail und Hive 2.1.57 mit dem neu gebauten Admin-Bereich.