ReportedIP Hive 2.0.15 — Mail Relay a múltiples destinatarios y Hardening Mode mejorado
Ya está disponible la versión 2.0.15 de ReportedIP Hive. Esta versión corrige una serie de errores que provocaban fallos silenciosos relacionados con el envío de alertas, la deduplicación de patrones de ataque y la gestión de cuotas en los niveles Unlimited. Si tu sitio web utiliza una instalación pública de WordPress o está protegido por un WAF basado en reputación, te recomendamos que actualices.
Procedimiento de actualización: el actualizador integrado en el complemento (Plugin Update Checker, v5.6) consulta GitHub Releases cada 12 horas. Para forzar la comprobación, ve a Dashboard → Actualizaciones en tu sitio web, o descarga el archivo ZIP más reciente desde la página oficial de lanzamientos.
Novedades de la versión 2.0.15
Las notificaciones administrativas dirigidas a varios destinatarios ya no se pierden
El servicio de Mail Relay gestionado (POST /reportedip/v2/relay-mail en el servicio ReportedIP) valida una única dirección por solicitud a través de sanitize_email + is_email. Hive solía generar el campo del destinatario como implode(', ', $recipients), lo que provocaba que el relé lo rechazara con un código HTTP 422, y toda la alerta se descartaba. El sitio registró mail_failed, el administrador nunca vio la notificación y no había ninguna pista clara de por qué.
ReportedIP_Hive_Mailer::send() Ahora detecta un campo separado por comas to , lo divide mediante split_recipients(), y envía un correo por cada dirección a través de la misma pila de proveedores mediante dispatch_one(). La wp_mail() no se ve afectado: acepta listas separadas por comas de forma nativa, y la ruta de división se mantiene coherente en todos los proveedores.
El tiempo de espera de 14 días por evento sigue aplicándose al primer destinatario: una vez que se activa el tiempo de espera, el resto de destinatarios de la misma llamada se benefician todos de la misma set_transient() franja horaria. Esto se ajusta al comportamiento anterior y evita tener que llevar un control de N× tiempos de espera por cada entrega.
Hardening Mode ya no se reactiva cada hora ante el mismo patrón de ataque.
Security_Monitor::check_coordinated_attacks() se ejecuta sobre un historial móvil de 2 horas en wp_reportedip_hive_attempts. Un único patrón de ataque (por ejemplo, 10 direcciones IP que intentaban 20 Logins fallidos en un minuto) solía activar una reactivación completa del «Hardening Mode» en cada barrido cron horario hasta que la entrada caducaba. El registro de actividad se llenaba de entradas duplicadas hardening_mode_activated , y la Payload real que había activado el modo seguía siendo sobrescrita por otras posteriores de menor intensidad.
Hardening_Mode::activate() en class-hardening-mode.php ahora escribe un marcador de supresión por ventana de tiempo (reportedip_hive_hardening_seen_) en el momento de la activación. Las llamadas posteriores que presenten la misma ventana se descartan, a menos que la causa candidata sea claramente más grave. El TTL del marcador registra la duración del endurecimiento configurada más 24 horas.
Las extensiones de TTL bajo constituyen ahora una ruta de código independiente. Cuando el TTL restante es inferior al 50 % de la duración configurada y no existe un motivo candidato más relevante, la activación se prolonga TRANSIENT_UNTIL y emite hardening_mode_extended con una gravedad low. El motivo original, más importante, permanece en TRANSIENT_REASON y en la interfaz de usuario.
El estado de la cuota ya no bloquea la cola de informes en los niveles Unlimited
Los niveles «Enterprise» y «Honeypot» solían provocar un no_quota cuando el servidor de origen marcaba remaining_reports = 0 lo que en realidad era una cuenta Unlimited: un fallo pasajero del lado del servidor en la actualización de la cuota podía bloquear silenciosamente la cola de informes de la API durante el resto del día.
get_quota_status() en class-api-client.php ahora detecta niveles ilimitados a través de daily_report_limit < 0 || === null y obliga a remaining = -1, ajustándose a la >= 0 guardia en process_report_queue().
Ahora se respetan los retrasos de Relay 429 en el lado del cliente
Una respuesta 429 procedente de POST /reportedip/v2/relay-mail (retroceso progresivo del lado del servidor por destinatario) antes solo activaba el wp_mail() . La siguiente alerta de seguridad intentaba inmediatamente otra llamada HTTP, por lo que el mismo destinatario podía ver docenas de códigos 429 al día en los registros.
relay_request() en class-api-client.php ahora almacena time() + retry_after en un transitorio por (Endpoint, destinatario), acorta las llamadas posteriores dentro del periodo de espera a un client_backoff error leve, y borra el periodo de espera tras la primera respuesta satisfactoria. Los proveedores de correo electrónico y SMS siguen actuando de forma transparente; la diferencia es que el cliente ahora deja de saturar el relé hasta que expire el periodo de espera.
Las rutas de cebo señuelo se han ampliado de 16 a 40
En versiones anteriores de la línea 2.0 ampliamos la lista de rutas de señuelo. La función «Decoy Surface» de Hive ahora devuelve respuestas 404 de trampa para: toda la wp-config.php.* familia de copias de seguridad (.bak, .old, .save, .orig, .swp, .txt, «trailing» ~); más .env* copias de seguridad; configuration.php.bak; volcados SQL habituales en el directorio raíz web (dump.sql, database.sql, backup.sql, db.sql); Apache .htpasswd y .htaccess.bak; credenciales de la nube (.aws/credentials, .aws/config); claves SSH (.ssh/id_rsa, .ssh/authorized_keys); y archivos de claves privadas en el directorio raíz web (id_rsa, private.key, server.key).
Cualquier solicitud de una de estas rutas se considera ahora una señal de atacante de alta fiabilidad y se incorpora a la base de datos de reputación de la comunidad cuando se ejecuta Hive en modo «Community Network».
Actualización
- Actualización automática desde el propio complemento. El «Plugin Update Checker» consulta GitHub Releases cada 12 horas. Si no quieres esperar, puedes forzar una comprobación desde el Dashboard → Actualizaciones.
- Descarga manual. Descarga el archivo ZIP más reciente desde github.com/reportedip/reportedip-hive/releases.
- WP-CLI.
wp plugin update reportedip-hivesi gestionas WordPress a través de la CLI.
Changelog completo
Para consultar el historial completo de versiones, incluidas las versiones 2.0.14, 2.0.13 y anteriores, consulta el Changelog de la API y los complementos.