ReportedIP 2.0.15 – E-Mail-Relay für mehrere Empfänger und verbesserter Sicherheitsmodus
ReportedIP Hive 2.0.15 is out. This release closes a class of silent-failure bugs around alert delivery, attack-pattern deduplication, and quota handling on unlimited tiers. If your site is on a public WordPress install or behind a reputation-driven WAF, you should upgrade.
Upgrade-Möglichkeiten: Der im Plugin integrierte Updater (Plugin Update Checker, v5.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?
Benachrichtigungen an mehrere Empfänger werden nicht mehr verworfen
Der verwaltete E-Mail-Relay (POST /reportedip/v2/relay-mail (im ReportedIP ) überprüft pro Anfrage eine einzelne Adresse über sanitize_email + is_email. Hive hat das Empfängerfeld wie folgt aufgebaut: implode(', ', $recipients), was das Relay daraufhin mit einem HTTP-Status 422 zurückwies – und die gesamte Benachrichtigung wurde verworfen. Die Website protokollierte mail_failedDer Administrator hat die Benachrichtigung nie gesehen, und es gab keinen offensichtlichen Grund dafür.
ReportedIP_Hive_Mailer::send() erkennt nun ein durch Kommas getrenntes to Feld, teilt es über split_recipients()und versendet über denselben Provider-Stack eine E-Mail pro Adresse über dispatch_one(). Lokal wp_mail() Die Fallback-Lösung bleibt davon unberührt – sie akzeptiert Kommalisten von Haus aus, und der Aufteilungsweg bleibt bei allen Anbietern einheitlich.
Die 14-tägige Abklingzeit pro Ereignis gilt weiterhin für den ersten Empfänger – sobald die Abklingzeit einsetzt, profitieren alle übrigen Empfänger desselben Aufrufs von derselben set_transient() Slot. Das entspricht dem bisherigen Verhalten und vermeidet die Verwaltung von N× Abklingzeiten pro Zustellung.
Der „Hardening“-Modus wird nicht mehr stündlich bei demselben Angriffsmuster erneut aktiviert
Security_Monitor::check_coordinated_attacks() wird über einen gleitenden 2-Stunden-Rückblick in wp_reportedip_hive_attempts. Ein einzelnes Angriffsmuster (zum Beispiel 10 IP-Adressen, die innerhalb einer Minute 20 fehlgeschlagene Anmeldeversuche versuchten) löste bei jedem stündlichen Cron-Durchlauf eine vollständige Reaktivierung des Hardening-Modus aus, bis der Eintrag veraltet war. Das Aktivitätsprotokoll füllte sich mit doppelten hardening_mode_activated Einträge, und die eigentliche Trigger-Nutzlast wurde immer wieder durch schwächere Folgeeinträge überschrieben.
Hardening_Mode::activate() in class-hardening-mode.php schreibt nun eine Unterdrückungsmarkierung pro Zeitfenster (reportedip_hive_hardening_seen_<md5>) bei der Aktivierung. Spätere Aufrufe, die dasselbe Fenster anzeigen, werden übersprungen, es sei denn, der vorgeschlagene Grund ist deutlich schwerwiegender. Die TTL des Markers entspricht der konfigurierten Hardening-Dauer plus 24 Stunden.
Erweiterungen bei niedrigem TTL-Wert werden nun in einem separaten Codepfad verarbeitet. Wenn die verbleibende TTL weniger als 50 % der konfigurierten Dauer beträgt und Wenn der Grund des Kandidaten nicht überzeugender ist, wird die Aktivierung ausgeweitet TRANSIENT_UNTIL und sendet hardening_mode_extended je nach Schweregrad low. Der ursprüngliche, gewichtigere Grund bleibt bestehen TRANSIENT_REASON und in der Benutzeroberfläche.
Der Quotenstatus führt in den unbegrenzten Tarifen nicht mehr zum Einfrieren der Berichtswarteschlange
Die Stufen „Enterprise“ und „Honeypot“ landeten früher in der Warteschlange no_quota Kurzschluss, wenn das vorgelagerte Stempel remaining_reports = 0 Bei einem eigentlich unbegrenzten Konto konnte eine vorübergehende serverseitige Störung bei der Aktualisierung der Kontingente dazu führen, dass die API-Berichtswarteschlange für den Rest des Tages unbemerkt blockiert wurde.
get_quota_status() in class-api-client.php erkennt nun unbegrenzte Ebenen über daily_report_limit < 0 || === null und zwingt remaining = -1, passend zu >= 0 Wache 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 (serverseitiger progressiver Backoff pro Empfänger) löste bisher nur pro Aufruf wp_mail() Ausweichlösung. Die weiter Die Sicherheitswarnung löste sofort einen weiteren HTTP-Aufruf aus, sodass derselbe Empfänger täglich Dutzende von 429-Fehlern in den Protokollen sehen konnte.
relay_request() in class-api-client.php jetzt im Handel erhältlich time() + retry_after in einem pro-(Endpunkt, Empfänger) Transienten werden nachfolgende Aufrufe innerhalb der Abklingzeit auf einen client_backoff „Soft-Failure“ und setzt die Abklingzeit bei der ersten erfolgreichen Antwort zurück. Die E-Mail- und SMS-Anbieter greifen weiterhin transparent auf das Backup zurück – der Unterschied besteht darin, dass der Client nun aufhört, das Relay zu überfluten, bis das Backoff-Fenster abgelaufen ist.
Die Anzahl der Köderwege wurde von 16 auf 40 erweitert
In einer früheren Version der 2.0-Reihe haben wir die Liste der Köderpfade erweitert. Hives „Decoy Surface“ liefert nun 404-Fehlerantworten für: die gesamte wp-config.php.* Ersatzfamilie (.bak, .old, .save, .orig, .swp, .txt, im Schlepptau ~); mehr .env* Sicherungen; Joomla configuration.php.bak; gängige SQL-Dumps im Webroot (dump.sql, database.sql, backup.sql, db.sql); Apache .htpasswd und .htaccess.bak; Cloud-Anmeldedaten (.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 für einen dieser Pfade gilt nun als hochwahrscheinliches Anzeichen für einen Angreifer und wird in die Reputationsdatenbank der Community aufgenommen, wenn Sie Hive im Community-Netzwerk-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. Lade die neueste ZIP-Datei von github.reportedip herunter.
- WP-CLI.
wp plugin update reportedip-hivefalls Sie WordPress über die Befehlszeile verwalten.
Vollständiges Änderungsprotokoll
Die vollständige Versionshistorie einschließlich 2.0.14, 2.0.13 und früherer Versionen finden Sie im Änderungsprotokoll für API und Plugins.