ReportedIP 2.0.15 — Retransmisión de correo a múltiples destinatarios y modo de refuerzo de seguridad mejorado
Ya está disponible ReportedIP 2.0.15. 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 planes ilimitados. 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) comprueba las versiones de GitHub cada 12 horas. Para forzar la comprobación, ve a Panel de control → Actualizaciones en tu sitio web, o descarga el archivo ZIP más reciente desde la página oficial de versiones.
Novedades de la versión 2.0.15
Las notificaciones administrativas con varios destinatarios ya no se pierden
El servidor de retransmisión de correo gestionado (POST /reportedip/v2/relay-mail (en el ReportedIP ) comprueba una sola dirección por solicitud a través de sanitize_email + is_email. Hive solía crear el campo «recipient» como implode(', ', $recipients), que el relé rechazó con un código HTTP 422, y toda la alerta se descartó. 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 una lista separada por comas to campo, 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(). Local wp_mail() La opción de reserva no se ve afectada: admite 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 lo mismo set_transient() ranura. Esto se ajusta al comportamiento anterior y evita tener que llevar un recuento de tiempos de espera N× por cada entrega.
El modo de refuerzo ya no se reactiva cada hora ante el mismo patrón de ataque
Security_Monitor::check_coordinated_attacks() se ejecuta sobre un intervalo móvil de 2 horas en wp_reportedip_hive_attempts. Un único patrón de ataque (por ejemplo, 10 direcciones IP intentando 20 inicios de sesión fallidos en un minuto) solía activar la reactivación completa del modo de refuerzo en cada barrido cron horario hasta que el registro caducaba. El registro de actividad se llenaba de entradas duplicadas hardening_mode_activated las entradas, y la carga útil real del disparador se veía constantemente sobrescrita por otras posteriores de menor potencia.
Hardening_Mode::activate() en class-hardening-mode.php ahora escribe un marcador de supresión por ventana de tiempo (reportedip_hive_hardening_seen_<md5>) en el momento de la activación. Las llamadas posteriores que presenten el mismo margen de tiempo se ignoran, a menos que el motivo propuesto sea claramente más grave. El marcador TTL registra la duración del endurecimiento configurada más 24 horas.
Las extensiones de TTL bajo ahora siguen una ruta de código independiente. Cuando el TTL restante es inferior al 50 % de la duración configurada y si la razón candidata no es más sólida, la activación se extiende TRANSIENT_UNTIL y emite hardening_mode_extended en función de la gravedad low. La razón original, más convincente, sigue siendo TRANSIENT_REASON y en la interfaz de usuario.
El estado de la cuota ya no bloquea la cola de informes en los planes ilimitados
Los niveles «Enterprise» y «Honeypot» solían llegar a la cola no_quota cortocircuito cuando el sello de la fase anterior remaining_reports = 0 en lo que, en realidad, era una cuenta ilimitada: un fallo técnico pasajero en la actualización de la cuota por parte del servidor 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 fuerzas remaining = -1, a juego con el >= 0 guardia en process_report_queue().
Ahora se respetan los retrasos de Relay 429 en el lado del cliente
Una respuesta 429 de POST /reportedip/v2/relay-mail (retroceso progresivo del lado del servidor por destinatario) antes solo se activaba por llamada wp_mail() solución alternativa. El siguiente La alerta de seguridad intentaba inmediatamente otra llamada HTTP, por lo que el mismo destinatario podía ver decenas de códigos 429 al día en los registros.
relay_request() en class-api-client.php ahora en tiendas time() + retry_after en un transitorio por (punto final, destinatario), se omiten las llamadas posteriores dentro del periodo de espera y se pasa directamente a un client_backoff error no crítico, y borra el tiempo de espera tras la primera respuesta satisfactoria. Los proveedores de correo electrónico y SMS siguen recurriendo a la alternativa de forma transparente; la diferencia es que el cliente deja de enviar mensajes repetidos al servidor de retransmisión hasta que expire el periodo de espera.
Las rutas de los cebos 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 de error 404 para: la lista completa wp-config.php.* familia de respaldo (.bak, .old, .save, .orig, .swp, .txt, a la zaga ~); más .env* copias de seguridad; Joomla configuration.php.bak; archivos de volcado SQL habituales en el directorio raíz de la 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 los archivos de clave privada 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».
Actualizar
- Actualización automática desde el propio plugin. El Plugin Update Checker consulta GitHub Releases cada 12 horas. Si no quieres esperar, puedes forzar una comprobación desde el Panel de control → Actualizaciones.
- Descarga manual. Descarga el último archivo ZIP desde github.reportedip.
- WP-CLI.
wp plugin update reportedip-hivesi gestionas WordPress a través de la CLI.
Lista completa de cambios
Para consultar el historial completo de versiones, incluidas las versiones 2.0.14, 2.0.13 y anteriores, consulta el registro de cambios de la API y los complementos.