ReportedIP 2.0.15 — Relais de messagerie multi-destinataires et mode de renforcement de la sécurité amélioré
ReportedIP 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 illimités. Si votre site utilise une installation WordPress publique ou est protégé par un pare-feu 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 Tableau de bord → Mises à jour sur votre site, ou téléchargez le dernier fichier ZIP depuis la page officielle des versions.
Quelles sont les nouveautés de la version 2.0.15 ?
Les notifications d'administration destinées à plusieurs destinataires ne sont plus ignorées
Le relais de messagerie géré (POST /reportedip/v2/relay-mail (sur le ReportedIP ) vérifie qu'une seule adresse est fournie par requête via sanitize_email + is_email. Hive a utilisé pour construire le champ destinataire comme implode(', ', $recipients), que le relais a ensuite rejeté avec un code HTTP 422 — et l'alerte a été complètement ignorée. Le site a enregistré 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 une liste séparée par des virgules to champ, le divise via split_recipients(), et envoie un e-mail par adresse via la même pile de fournisseurs via dispatch_one(). Local wp_mail() La solution de secours n'est pas affectée : elle prend en charge 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 d'attente de 14 jours par événement s'applique toujours au premier destinataire : une fois ce délai écoulé, les autres destinataires de la même communication bénéficient tous du même set_transient() slot. Cela correspond au comportement historique et évite de devoir gérer N× temps de recharge par livraison.
Le mode de renforcement ne se réactive plus toutes les heures face au même schéma d'attaque
Security_Monitor::check_coordinated_attacks() est calculé sur une période glissante de 2 heures wp_reportedip_hive_attempts. Un seul schéma d'attaque (par exemple, 10 adresses IP effectuant 20 tentatives de connexion infructueuses en l'espace d'une minute) déclenchait une réactivation complète du mode de renforcement à chaque cycle horaire du cron, jusqu'à ce que l'entrée soit supprimée. Le journal d'activité s'est alors rempli d'entrées en double hardening_mode_activated les entrées, et la charge utile réelle du déclencheur était sans cesse écrasée par des versions ultérieures moins performantes.
Hardening_Mode::activate() dans class-hardening-mode.php écrit désormais un marqueur de suppression par fenêtre temporelle (reportedip_hive_hardening_seen_<md5>) lors de l'activation. Les appels ultérieurs présentant la même fenêtre sont ignorés, sauf si la raison candidate est strictement plus grave. Le marqueur TTL suit la durée de durcissement configurée, majorée de 24 heures.
Les prolongations TTL-low constituent désormais un chemin de traitement distinct. Lorsque la durée de vie restante (TTL) est inférieure à 50 % de la durée configurée et si la raison candidate n'est pas plus forte, l'activation se prolonge TRANSIENT_UNTIL uniquement et émet hardening_mode_extended en fonction de la gravité low. La raison initiale, plus convaincante, demeure TRANSIENT_REASON et dans l'interface utilisateur.
Le statut du quota ne bloque plus la file d'attente des rapports sur les niveaux illimités
Les niveaux « Enterprise » et « Honeypot » avaient l'habitude d'atteindre la file d'attente no_quota court-circuit lorsque le tampon en amont remaining_reports = 0 sur ce qui était en réalité un compte illimité — 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 illimité de niveaux via daily_report_limit < 0 || === null et les forces remaining = -1, correspondant à >= 0 garde à process_report_queue().
Les délais d'attente de Relay 429 sont désormais pris en compte côté client
Une réponse 429 provenant de POST /reportedip/v2/relay-mail (délai d'attente progressif côté serveur par destinataire) ne déclenchait auparavant que le délai par appel wp_mail() solution de secours. Le suivant L'alerte de sécurité a immédiatement tenté 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 maintenant en magasin time() + retry_after dans un événement transitoire de type (point de terminaison, destinataire), court-circuite les appels suivants pendant la période de refroidissement vers un client_backoff erreur non fatale, et réinitialise le délai d'attente dès la première réponse réussie. Les fournisseurs de messagerie et de SMS continuent de se rabattre sur une solution de secours de manière transparente — la différence est que le client cesse désormais d'inonder le relais de requêtes jusqu'à l'expiration de la fenêtre de repli.
Le nombre de parcours d'appâts-appâts a été porté de 16 à 40
Dans une version antérieure de la série 2.0, nous avons élargi la liste des chemins d'appât pour les leurres. La fonctionnalité « Decoy Surface » de Hive renvoie désormais des réponses 404 pour : l'intégralité wp-config.php.* famille de sauvegarde (.bak, .old, .save, .orig, .swp, .txt, en queue de peloton ~) ; plus .env* sauvegardes ; Joomla configuration.php.bak; les fichiers de sauvegarde SQL courants se trouvent dans le répertoire racine du site web (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 situés à la 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 indiquant la présence d'un attaquant avec un niveau de fiabilité élevé 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. Le Plugin Update Checker interroge GitHub Releases toutes les 12 heures. Si vous ne souhaitez pas attendre, lancez une vérification manuelle via Tableau de bord → Mises à jour.
- Téléchargement manuel. Téléchargez le dernier fichier ZIP sur github.reportedip.
- WP-CLI.
wp plugin update reportedip-hivesi vous gérez WordPress via l'interface de ligne de commande.
Journal complet des modifications
Pour consulter l'historique complet des versions, y compris les versions 2.0.14, 2.0.13 et antérieures, consultez le journal des modifications de l'API et des plugins.