ReportedIP 2.0.15 – E-Mail-Relay für mehrere Empfänger und verbesserter Sicherheitsmodus
ReportedIP 2.0.15 ist verfügbar. Diese Version behebt eine Reihe von Fehlern, die zu stillen Ausfällen bei der Benachrichtigungszustellung, der Deduplizierung von Angriffsmustern und der Quotenverwaltung in unbegrenzten Tarifen führten. Wenn Ihre Website auf einer öffentlichen WordPress-Installation läuft oder hinter einer reputationsbasierten WAF steht, sollten Sie ein Upgrade durchführen.
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.