ReportedIP Hive 2.1.21 — Fortalecimiento del cortafuegos de WordPress
ReportedIP Hive 2.1.21 pone el broche final a una serie de 17 versiones dedicadas al refuerzo de la seguridad. Desde que se incorporó el cortafuegos en las versiones 2.1.2–2.1.4, cada versión, desde la 2.1.5 hasta la 2.1.21, se ha dedicado a hacer que esa nueva capa WAF sea apta para producción: la protección previa a WordPress ahora cubre automáticamente nginx, se han eliminado los False Positives del panel de administración y se ha corregido un error real de bloqueo automático en bases de datos que no utilizan el huso horario UTC.
Todo el núcleo de detección es Free y está bajo licencia GPL-2.0. Actualízalo desde «Plugins» → «Buscar actualizaciones», o descarga el archivo ZIP más reciente desde la página de GitHub Releases. Si te has perdido el cortafuegos en sí, empieza por la descripción de la versión 2.1.4 del cortafuegos.
¿Qué ha cambiado desde la versión 2.1.4 de Hive?
Se publicaron diecisiete versiones entre la 2.1.5 (11 de junio de 2026) y la 2.1.21 (3 de julio de 2026). Ninguna de ellas añadió un nuevo pilar: la línea de desarrollo se centró en reforzar el WAF, ampliar Extended Protection y el bloqueo automático que se introdujeron en las versiones 2.1.2 a 2.1.4.
| Versión | Cambio en el titular |
|---|---|
| 2.1.5 | Se ha corregido un error ArithmeticError en el comparador CIDR; ya no se bloquean los rastreadores legítimos por User Enumeration; las direcciones IP de bucle invertido y privadas nunca se notifican como atacantes. |
| 2.1.6 | El clasificador de bots verificados ahora tiene tres estados, por lo que las direcciones IP reales de Bing o de los rastreadores que se encuentren fuera del rango inicial ya no se etiquetan erróneamente como «bots falsos». |
| 2.1.7 | Insignias de nivel unificadas en todo el panel de administración; filtro de tipos de eventos agrupados en los registros; se ha corregido la exportación de registros en formato JSON/CSV. |
| 2.1.8 | Desactivar la «Extended Protection» ya no provoca que el sitio quede fuera de línea: el filtro se neutraliza y se convierte en un marcador de posición inerte, al estilo de Wordfence. |
| 2.1.9–2.1.11 | Excepciones del WAF gestionadas desde el backend: elimina un False Positive desde el panel de administración, sin necesidad de código; formulario de excepciones y FAQ que se explican por sí mismos. |
| 2.1.12 | La configuración de MainWP permite cambiar un sitio gestionado al modo «Community Network». |
| 2.1.13 | El Dashboard de seguridad se ha rediseñado para ofrecer una vista analítica completa; Hardening Mode ya no se activa ante ataques de Brute Force rutinarios en segundo plano. |
| 2.1.14–2.1.15 | El bloqueo automático ahora es compatible con UTC en servidores de bases de datos que no utilizan UTC; las marcas de tiempo de administración se muestran en la zona horaria del sitio. |
| 2.1.16 | Se ha detenido una consulta /relay-quota que se ejecutaba sin control y podía activarse con cada solicitud del front-end. |
| 2.1.17 | La «Extended Protection» cubre automáticamente todos los Endpoints PHP en nginx; el filtro omite la inspección del cuerpo de la solicitud para los editores que hayan iniciado sesión. |
| 2.1.18 | El mensaje «El estado de la API se ha deteriorado» se resuelve por sí solo (ventana móvil); el registro de seguridad ya no puede verse saturado por un bucle de fallos. |
| 2.1.19 | Se ha solucionado el problema del Hide Login tras los enlaces permanentes con barra al final y las cachés de página (WP Rocket y similares). |
| 2.1.20–2.1.21 | Se han mostrado las instrucciones de configuración del servidor nginx cuando la configuración automática está desactivada; se han mejorado el Setup Wizard y la copia de la autenticación de dos factores (2FA). |
«Extended Protection» ha evolucionado: el WAF anterior a WordPress ahora es compatible automáticamente con nginx
«Extended Protection» ejecuta el cortafuegos a través de un auto_prepend_file filtro antes de que se cargue WordPress. En nginx, esto solía implicar pegar un location — que solo protegía el bloque en el que se insertaba, por lo que las solicitudes gestionadas por sus propios bloques (wp-login.php, el controlador frontal en caché) se colaban más allá del cortafuegos.
La versión 2.1.17 detecta la SAPI de PHP-FPM antes de la cadena del servidor nginx y escribe una ruta raíz del documento .user.ini . PHP-FPM respeta auto_prepend_file allí para cada solicitud, independientemente de los location , sin necesidad de ningún paso manual. El fragmento de código de nginx / php.ini se mantiene como opción de reserva únicamente para pilas que no cuenten con una SAPI FastCGI de PHP, y la versión 2.1.20 hace que esas instrucciones manuales aparezcan siempre que la directiva generada automáticamente aún no haya entrado en vigor.
La protección ya no bloquea a los editores que han iniciado sesión ni se desactiva al eliminarla.
Dado que el filtro se ejecuta antes que WordPress, anteriormente inspeccionaba el cuerpo de cada solicitud; por lo tanto, un autor que hubiera iniciado sesión y guardara una entrada a través de admin-ajax.php o la REST API podía activar una firma de XSS/SQLi y recibir un error 403. La versión 2.1.17 detecta la wordpress_logged_in cookie y omite la inspección del cuerpo en las solicitudes autenticadas (las reglas de URL y de agente de usuario siguen aplicándose), mientras que el motor integrado en WordPress sigue actuando como mecanismo de seguridad que tiene en cuenta las capacidades del sistema. Desactivar el WAF, o configurarlo en modo de solo informe, ahora también desactiva el filtro previo a WordPress.
Ahora, la desinstalación también es segura. Antes de la versión 2.1.8, al desactivar el complemento mientras la auto_prepend_file directiva se encontraba en un archivo que Hive no puede editar (un archivo de nginx fastcgi_param o un php.ini editado manualmente) hacía que PHP apuntara a un protector eliminado y provocaba un error 500 en cada solicitud. Ahora, al desinstalarlo, se eliminan las directivas que controla Hive y se deja un marcador de posición inerte, de modo que una directiva que quede nunca podrá hacer referencia a un archivo que ya no existe.
Los False Positives del WAF ya se eliminan desde el panel de administración, sin necesidad de código.
En ocasiones, un cortafuegos basado en firmas puede marcar como sospechosa una solicitud legítima del propio sitio; un ejemplo clásico es un complemento de seguridad que procesa Payloads similares a los de un ataque. Las versiones 2.1.9 a 2.1.11 incorporaron un sistema de excepciones gestionado por el backend que funciona de forma similar a las exclusiones de ModSecurity y a la Allowlist de Wordfence.
- Cada fila del registro del WAF incluye una acción «Allow» que crea una excepción específica para esa regla concreta en esa ruta.
- El ámbito de una excepción abarca una sola regla, un grupo de reglas o —en el caso de un Endpoint propio— todo el motor de una ruta, que opcionalmente puede restringirse a una dirección IP o un CIDR. Una excepción que abarque todo el motor debe incluir siempre una ruta o una dirección IP, de modo que el cortafuegos nunca pueda desactivarse globalmente por error.
- Las excepciones son los datos de toda la red (opción
reportedip_hive_waf_exceptions,db_version10) y están disponibles en todos los planes; el motor de protección en sí mismo sigue siendo gratuito.
La versión 2.1.10 corrigió un error de elevación en el que el filtro previo a WordPress generaba un error fatal con cualquier cuerpo de solicitud POST —la inspección del cuerpo en esa capa había sido una operación nula silenciosa— e hizo que el complemento respetara las mismas excepciones que el motor interno de WordPress. La versión 2.1.11 dividió el ambiguo campo «ID de regla o grupo» en un campo de entrada para el ID de regla y un menú desplegable de grupos que se rellena con las categorías conocidas del motor, de modo que queda claro qué hay que introducir y de dónde procede el valor.
El bloqueo automático fallaba de forma silenciosa en las bases de datos que no utilizaban el huso horario UTC
La corrección más importante de esta versión es la 2.1.14. Las marcas de tiempo de caducidad y de intentos se registran en UTC, pero se comparaban con el reloj de sesión de MySQL (NOW() / CURDATE()). En un servidor cuya zona horaria de la base de datos no es UTC, esa discrepancia hacía que el contador de intentos por IP nunca se acumulara dentro de su ventana; por lo tanto, nunca se alcanzaban los umbrales de Login fallidos ni de XML-RPC y nunca se bloqueaba a ningún infractor, mientras que cada bloqueo recién registrado se trataba como si ya hubiera caducado, lo que dejaba la lista de bloqueados vacía durante un ataque activo.
Todas las columnas de fecha y hora y las comparaciones están ahora alineadas con el UTC en toda la capa de base de datos, el detector de ataques coordinados, el barrido de recuperación de colas, la caducidad de Trusted Devices y las estadísticas diarias. La versión 2.1.15 hizo que el administrador mostrara esas marcas de tiempo en la zona horaria del sitio en lugar de en UTC sin convertir, y la 2.1.18 adaptó las estadísticas de la API a la misma convención UTC. Si tu base de datos funciona con un reloj que no sigue el UTC, la versión 2.1.14 o posterior es la que permite que el bloqueo progresivo funcione.
Menos False Positives, menos ruido en los registros y análisis más precisos
Varias versiones han reforzado la detección, de modo que el tráfico normal ya no acumula bloqueos. La versión 2.1.13 ha impedido que el «Hardening Mode» se active ante ataques de Brute-Force rutinarios en segundo plano: los detectores de Coordinated-Attack Detection ahora contabilizan los failed_login eventos en una ventana de tiempo real en lugar de sumar el contador acumulado de cada IP, con valores predeterminados realistas (distribuido: 10 IP distintas y 50 intentos en 10 minutos; ráfaga: 8 IP y 30 intentos en un minuto). En esa misma versión se rediseñó el Dashboard de seguridad para convertirlo en una vista analítica completa: una barra de titulares, una línea de tiempo apilada agrupada en siete familias de amenazas con un selector de 7/30/90 días, un gráfico de anillo por vector de ataque, un gráfico de barras de grupos de reglas del WAF, un desglose por gravedad y una tabla de principales atacantes.
En cuanto al ruido, la versión 2.1.16 detuvo una /relay-quota que podía activarse en rutas muy transitadas (cortafuegos, Security Headers, verificación de bots) miles de veces por minuto, y la versión 2.1.18 cambió el indicador «API health degraded» de un contador de vida útil que se quedaba atascado para siempre a una ventana móvil que abarca las últimas 50 llamadas en los últimos 7 días, y limitó las filas repetidas api_call_failed a una por minuto, de modo que una ráfaga de fallos ya no puede generar decenas de miles de entradas de registro. La versión 2.1.19 corrigió el Login oculto para sitios con enlaces permanentes con barra final y detrás de un caché de páginas, donde una página de Login almacenada en caché omitía silenciosamente el intercambio de cookies.
Cómo actualizar a Hive 2.1.21
El verificador de actualizaciones integrado consulta GitHub cada 12 horas; las nuevas versiones aparecen en la pantalla «Plugins» como cualquier otra actualización. Para descargar la versión 2.1.21 de inmediato, abre «Plugins» → «Buscar actualizaciones». No hay ninguna migración de esquema más allá de la tabla de WAF Exceptions (db_version 10) añadida en la versión 2.1.9, y el Setup Wizard ahora guía a los nuevos usuarios a través de Extended Protection con valores predeterminados seguros.