ReportedIP Hive 2.0.15 — Mail Relay multi-destinataires et Hardening Mode amélioré
ReportedIP Hive 2.0.15 est disponible. Cette version corrige une série de bogues entraînant des échecs silencieux liés à la transmission des alertes, à la déduplication des modèles d’attaque et à la gestion des quotas sur les niveaux Unlimited. Si votre site utilise une installation WordPress publique ou est protégé par un WAF basé sur la réputation, nous vous recommandons de procéder à la mise à jour.
Procédure de mise à jour : le programme de mise à jour intégré au plugin (Plugin Update Checker, v5.6) interroge GitHub Releases toutes les 12 heures. Pour forcer la vérification, rendez-vous dans Dashboard → Mises à jour sur votre site, ou téléchargez le dernier fichier ZIP depuis la page officielle des versions.
Nouveautés de la version 2.0.15
Les notifications d’administration destinées à plusieurs destinataires ne sont plus ignorées
Le Mail Relay géré (POST /reportedip/v2/relay-mail sur le service ReportedIP) valide une seule adresse par requête via sanitize_email + is_email. Hive a utilisé cette adresse pour remplir le champ « destinataire » implode(', ', $recipients), ce que le relais rejetait alors avec un code HTTP 422 — et l’alerte était alors entièrement ignorée. Le site enregistrait mail_failed, l’administrateur n’a jamais vu la notification, et rien ne permettait d’expliquer clairement pourquoi.
ReportedIP_Hive_Mailer::send() détecte désormais un champ séparé par des virgules to , le divise à l’aide de split_recipients(), puis envoie un e-mail par adresse via la même pile de fournisseurs via dispatch_one(). La wp_mail() n’est pas affectée : elle accepte nativement les listes séparées par des virgules, et le chemin de fractionnement reste cohérent d’un fournisseur à l’autre.
Le délai de recharge de 14 jours par événement s’applique toujours au premier destinataire : une fois ce délai déclenché, les destinataires restants de la même appel bénéficient tous du même set_transient() créneau. Cela correspond au comportement historique et évite de devoir gérer N× délais de recharge par envoi.
The Hardening Mode does not re-activate every hour against the same attack pattern.
Security_Monitor::check_coordinated_attacks() s’exécute sur une fenêtre glissante de 2 heures en wp_reportedip_hive_attempts. Un seul schéma d’attaque (par exemple, 10 adresses IP effectuant 20 tentatives de Login infructueuses en une minute) déclenchait auparavant une réactivation complète du Hardening Mode à chaque balayage cron horaire jusqu’à ce que l’entrée soit supprimée. Le journal d’activité se remplissait d’entrées en double hardening_mode_activated , et la Payload réelle ayant déclenché l’alerte était sans cesse écrasée par des tentatives de suivi moins intenses.
Hardening_Mode::activate() dans class-hardening-mode.php écrit désormais un marqueur de suppression par fenêtre temporelle (reportedip_hive_hardening_seen_) lors de son activation. Les appels ultérieurs présentant la même fenêtre sont ignorés, à moins que la cause candidate ne soit strictement plus grave. La durée de vie (TTL) du marqueur correspond à la durée de renforcement configurée, majorée de 24 heures.
Les prolongations en cas de TTL faible constituent désormais un chemin de traitement distinct. Lorsque le TTL restant est inférieur à 50 % de la durée configurée et qu’aucune autre raison n’est plus pertinente, l’activation est prolongée TRANSIENT_UNTIL uniquement et émet hardening_mode_extended à la gravité low. Le motif initial, plus important, reste présent TRANSIENT_REASON et sur l’interface utilisateur.
Le statut du quota ne bloque plus la file d’attente des rapports sur les niveaux Unlimited
Les niveaux « Enterprise » et « Honeypot » provoquaient auparavant un no_quota lorsque le tampon en amont remaining_reports = 0 sur ce qui était en réalité un compte Unlimited — un bug temporaire côté serveur lors de l’actualisation du quota pouvait bloquer silencieusement la file d’attente des rapports API pour le reste de la journée.
get_quota_status() dans class-api-client.php détecte désormais un nombre Unlimited de niveaux via daily_report_limit < 0 || === null et force remaining = -1, en respectant la >= 0 condition de garde dans process_report_queue().
Les délais d'attente du relais 429 sont désormais respectés côté client
Une réponse 429 provenant de POST /reportedip/v2/relay-mail (délai de réessai progressif côté serveur par destinataire) ne déclenchait auparavant que la wp_mail() . L’alerte de sécurité suivante tentait immédiatement un autre appel HTTP, de sorte que le même destinataire pouvait voir des dizaines de codes 429 par jour dans les journaux.
relay_request() dans class-api-client.php stocke désormais time() + retry_after dans un objet transitoire (Endpoint, destinataire), court-circuite les appels suivants pendant la période de temporisation en les traitant comme un client_backoff échec souple, et réinitialise la période de refroidissement dès la première réponse réussie. Les fournisseurs de messagerie et de SMS continuent de prendre le relais de manière transparente — la différence est que le client cesse désormais de saturer le relais jusqu’à l’expiration de la fenêtre de recul.
Le nombre de parcours d'appâts leurres est passé de 16 à 40
Dans une version antérieure de la branche 2.0, nous avions élargi la liste des chemins d'appât leurres. La fonctionnalité « Decoy Surface » de Hive renvoie désormais des réponses 404-trap pour : l'ensemble de la wp-config.php.* famille de sauvegarde (.bak, .old, .save, .orig, .swp, .txt, en fin de ~) ; d’autres .env* sauvegardes ; les configuration.php.bak; les sauvegardes SQL courantes dans le répertoire racine (dump.sql, database.sql, backup.sql, db.sql); Apache .htpasswd et .htaccess.bak; identifiants de connexion au cloud (.aws/credentials, .aws/config) ; clés SSH (.ssh/id_rsa, .ssh/authorized_keys) ; et les fichiers de clés privées dans le répertoire racine du site web (id_rsa, private.key, server.key).
Toute requête concernant l'un de ces chemins est désormais considérée comme un signal d'attaquant hautement fiable et alimente la base de données de réputation de la communauté lorsque vous exécutez Hive en mode « Community Network ».
Mise à jour
- Mise à jour automatique intégrée au plugin. L'outil de vérification des mises à jour du plugin interroge GitHub Releases toutes les 12 heures. Si vous ne souhaitez pas attendre, vous pouvez forcer une vérification via Dashboard → Mises à jour.
- Téléchargement manuel. Téléchargez le dernier fichier ZIP depuis github.com/reportedip/reportedip-Hive/releases.
- WP-CLI.
wp plugin update reportedip-hivesi vous gérez WordPress via la CLI.
Changelog complet
Pour consulter l'historique complet des versions, y compris les versions 2.0.14, 2.0.13 et antérieures, consultez le Changelog de l'API et des plugins.