ReportedIP Hive 2.0.15 – Mail Relay für mehrere Empfänger und erweiterter Hardening Mode
ReportedIP Hive 2.0.15 ist verfügbar. Diese Version behebt eine Reihe von Fehlern, die zu stillen Ausfällen im Zusammenhang mit der Zustellung von Warnmeldungen, der Deduplizierung von Angriffsmustern und der Quotenverwaltung in Unlimited-Stufen führten. Falls Ihre Website auf einer öffentlichen WordPress-Installation läuft oder hinter einer reputationsbasierten WAF liegt, sollten Sie ein Upgrade durchführen.
Aktualisierungsverfahren: Der im Plugin integrierte Updater (Plugin Update Checker, Version 5.6) fragt alle 12 Stunden die GitHub Releases ab. Um die Überprüfung manuell auszulösen, rufen Sie auf Ihrer Website „Dashboard → Updates“ auf oder laden Sie die neueste ZIP-Datei von der offiziellen Release-Seite herunter.
Was hat sich in Version 2.0.15 geändert?
Administratorbenachrichtigungen an mehrere Empfänger werden nicht mehr ausgelassen
Der verwaltete Mail Relay-Dienst (POST /reportedip/v2/relay-mail im Rahmen des reportedIP-Dienstes) überprüft pro Anfrage eine einzelne Adresse mithilfe von sanitize_email + is_email. Hive erstellte das Empfängerfeld früher wie folgt implode(', ', $recipients), war der Relay-Dienst daraufhin mit einem HTTP-422-Fehler zurückwies – und die gesamte Benachrichtigung ging verloren. Die Website protokollierte mail_failed, der Administrator sah die Benachrichtigung nie, und es gab keinen offensichtlichen Hinweis darauf, warum.
ReportedIP_Hive_Mailer::send() erkennt nun ein durch Kommas getrenntes to Feld, teilt es auf split_recipients()und versendet eine E-Mail pro Adresse über denselben Provider-Stack mittels dispatch_one(). Das lokale wp_mail() Fallback bleibt davon unberührt – er akzeptiert Kommalisten von Haus aus, und der Aufteilungspfad bleibt über alle Anbieter hinweg konsistent.
Die 14-tägige Abklingzeit pro Ereignis gilt weiterhin für den ersten Empfänger – sobald die Abklingzeit eintritt, profitieren alle verbleibenden Empfänger desselben Aufrufs von demselben set_transient() Zeitfenster. Dies entspricht dem bisherigen Verhalten und vermeidet eine N-fache Abwicklung der Wartezeit pro Zustellung.
The Hardening Mode is not activated again every hour based on the same attack pattern.
Security_Monitor::check_coordinated_attacks() wird anhand eines gleitenden 2-Stunden-Rückblicks in wp_reportedip_hive_attempts. Ein einzelnes Angriffsmuster (beispielsweise 10 IP-Adressen, die innerhalb einer Minute 20 fehlgeschlagene Logins auslösten) löste früher bei jedem stündlichen Cron-Durchlauf eine vollständige Reaktivierung des Hardening Mode aus, bis der Eintrag veraltet war. Das Aktivitätsprotokoll füllte sich mit doppelten hardening_mode_activated Einträge, und die eigentliche Auslöse-Payload wurde immer wieder durch schwächere Folgeangriffe überschrieben.
Hardening_Mode::activate() in class-hardening-mode.php schreibt nun bei der Aktivierung einen Unterdrückungsmarker pro Zeitfenster (reportedip_hive_hardening_seen_) bei der Aktivierung. Spätere Aufrufe, die dasselbe Zeitfenster betreffen, werden umgangen, es sei denn, der in Frage kommende Grund ist deutlich schwerwiegender. Die TTL des Markers entspricht der konfigurierten „Hardening“-Dauer zuzüglich 24 Stunden.
Verlängerungen bei niedrigem TTL-Wert erfolgen nun über einen separaten Codepfad. Wenn die verbleibende TTL weniger als 50 % der konfigurierten Dauer beträgt und kein stärkerer Grund vorliegt, wird die Aktivierung TRANSIENT_UNTIL und gibt hardening_mode_extended mit der Schwere low. Der ursprüngliche, schwerwiegendere Grund verbleibt in TRANSIENT_REASON und auf der Benutzeroberfläche erhalten.
Der Quotenstatus führt bei Unlimited-Stufen nicht mehr zu einer Blockierung der Berichtswarteschlange
Die Stufen „Enterprise“ und „Honeypot“ lösten früher einen no_quota , wenn der Upstream-Stempel remaining_reports = 0 einem Konto, das eigentlich unbegrenzt war – ein vorübergehender serverseitiger Fehler bei der Aktualisierung der Kontingente konnte die API-Berichtswarteschlange für den Rest des Tages unbemerkt blockieren.
get_quota_status() in class-api-client.php erkennt nun unbegrenzte Stufen über daily_report_limit < 0 || === null und erzwingt remaining = -1, entsprechend dem >= 0 Bedingung in process_report_queue().
Die Backoff-Zeiten von Relay 429 werden nun auf Client-Seite berücksichtigt
Eine 429-Antwort von POST /reportedip/v2/relay-mail (serverseitiges progressives Backoff pro Empfänger) löste bisher nur den Fallback pro Aufruf aus wp_mail() ausgelöst. Die nächste Sicherheitswarnung versuchte sofort einen weiteren HTTP-Aufruf, sodass derselbe Empfänger in den Protokollen Dutzende von 429-Fehlermeldungen pro Tag sehen konnte.
relay_request() in class-api-client.php speichert nun time() + retry_after in einem temporären Speicher pro (Endpoint, Empfänger), unterbricht nachfolgende Aufrufe innerhalb der Abklingzeit bei einem client_backoff Soft-Failure ab und hebt die Abkühlphase bei der ersten erfolgreichen Antwort auf. Die E-Mail- und SMS-Anbieter greifen weiterhin transparent auf Ausweichlösungen zurück – der Unterschied besteht darin, dass der Client nun aufhört, das Relay zu überlasten, bis das Backoff-Fenster abgelaufen ist.
Die Anzahl der Decoy Paths wurde von 16 auf 40 erweitert
Zu einem früheren Zeitpunkt in der 2.0-Reihe haben wir die Liste der Köderpfade erweitert. Die „Decoy Surface“-Funktion von Hive liefert nun 404-Trap-Antworten für: die gesamte wp-config.php.* Backup-Familie (.bak, .old, .save, .orig, .swp, .txt, nachgestellte ~); weitere .env* Backups; configuration.php.bak; gängige SQL-Dumps im Webroot (dump.sql, database.sql, backup.sql, db.sql); Apache .htpasswd sowie .htaccess.bak; Cloud-Zugangsdaten (.aws/credentials, .aws/config); SSH-Schlüssel (.ssh/id_rsa, .ssh/authorized_keys); sowie Dateien mit privaten Schlüsseln im Web-Stammverzeichnis (id_rsa, private.key, server.key).
Jede Anfrage nach einem dieser Pfade gilt nun als hochwahrscheinliches Anzeichen für einen Angreifer und wird in die Reputationsdatenbank der Community aufgenommen, wenn Sie Hive im Community Network-Modus ausführen.
Upgrade
- Automatische Aktualisierung innerhalb des Plugins. Der „Plugin Update Checker“ fragt alle 12 Stunden die GitHub Releases ab. Wenn Sie nicht warten möchten, können Sie eine Überprüfung über „Dashboard“ → „Updates“ erzwingen.
- Manueller Download. Laden Sie die aktuellste ZIP-Datei von github.com/ReportedIP/ReportedIP-Hive/releases herunter.
- WP-CLI.
wp plugin update reportedip-hiveFalls Sie WordPress über die CLI verwalten.
Vollständiger Changelog
Die vollständige Versionshistorie einschließlich 2.0.14, 2.0.13 und früherer Versionen finden Sie im Changelog für API und Plugins.