ReportedIP 2.1.21 — Fortalecimiento del cortafuegos de WordPress
ReportedIP 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, todas las versiones desde la 2.1.5 hasta la 2.1.21 se han centrado en 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 falsos positivos del panel de administración y se ha corregido un error de bloqueo automático en bases de datos que no utilizan el huso horario UTC.
Todo el núcleo de detección es gratuito 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 versiones de GitHub. 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 lanzaron 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 la protección 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 | Mortal ArithmeticError Se ha corregido el mecanismo de coincidencia CIDR; los rastreadores legítimos ya no se bloquean por enumeración de usuarios; las direcciones IP de bucle invertido y privadas nunca se identifican 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 por tipo de evento agrupado en los registros; se ha corregido la exportación de registros en formato JSON/CSV. |
| 2.1.8 | Desactivar la «Protección ampliada» 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 falso positivo desde el panel de administración, sin necesidad de código; formulario de excepciones y preguntas frecuentes que se explican por sí mismos. |
| 2.1.12 | La configuración de MainWP permite cambiar un sitio gestionado al modo «Red comunitaria». |
| 2.1.13 | El panel de control de seguridad se ha rediseñado para ofrecer una vista analítica completa; el «Modo de refuerzo» ya no se activa ante ataques de fuerza bruta 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 | Detuvo a un fugitivo /relay-quota una consulta que podría ejecutarse con cada solicitud del front-end. |
| 2.1.17 | La «Protección ampliada» cubre automáticamente todos los puntos finales PHP en nginx; el filtro omite la inspección del cuerpo de la solicitud para los editores que han 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 inicio de sesión oculto 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 asistente de configuración 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 guardia antes WordPress se carga. En nginx, eso solía significar pegar un código escrito a mano location fragmento de código — que solo protege el bloque en el que se inserta, por lo que las solicitudes gestionadas por sus propios bloques (wp-login.php, el controlador frontal almacenado en caché) lograban eludir el 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 En su lugar, PHP-FPM respeta auto_prepend_file está ahí para cada solicitud, independientemente de Nginx location bloques, sin necesidad de intervención manual. El fragmento de código de nginx / php.ini se mantiene como opción de reserva únicamente para las pilas que no cuentan con una SAPI de PHP FastCGI, 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, antes 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 API REST podría detectar una firma de XSS/SQLi y devolver un error 403. La versión 2.1.17 detecta el wordpress_logged_in utiliza una cookie y omite la inspección del cuerpo de la solicitud para las peticiones 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. Al desactivar el WAF, o al configurarlo en modo «solo informe», también se desactiva el mecanismo de protección previo a WordPress.
Ahora, la desinstalación también es segura. Antes de la versión 2.1.8, al desactivar el complemento mientras el auto_prepend_file La directiva se encontraba en un archivo que Hive no puede editar (un nginx fastcgi_param o un archivo php.ini editado manualmente) hacía que PHP apuntara a un guard eliminado y provocaba un error 500 en cada solicitud. Ahora, al eliminarlas, se suprimen las directivas controladas por Hive y se deja un marcador de posición inactivo, de modo que una directiva que haya quedado nunca podrá hacer referencia a un archivo que ya no existe.
Los falsos positivos 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 cargas útiles similares a las 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 lista de permitidos de Wordfence.
- Cada fila del registro del WAF incluye una acción «Permitir» 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 punto final 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á disponible 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 serie es la 2.1.14. Las marcas de tiempo de caducidad y de intento 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 era UTC, esa discrepancia hacía que el contador de intentos por IP nunca se acumulara dentro de su intervalo de tiempo, por lo que nunca se alcanzaban los umbrales de intentos fallidos de inicio de sesión ni de XML-RPC y nunca se bloqueaba a ningún usuario infractor, mientras que cada bloqueo recién registrado se consideraba ya caducado, lo que dejaba la lista de bloqueados vacía durante un ataque activo.
Todas las columnas de fecha y hora y las comparaciones son ahora coherentes 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 dispositivos de confianza y las estadísticas diarias. La versión 2.1.15 permitió al administrador mostrar 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 falsos positivos, menos ruido en los registros y análisis más precisos
Varias actualizaciones han endurecido los criterios de detección, por lo que el tráfico normal ya no genera bloqueos. La versión 2.1.13 ha impedido que el «Modo de refuerzo» se active ante ataques de fuerza bruta rutinarios en segundo plano: los detectores de ataques coordinados ahora cuentan cada uno de los failed_login eventos en un intervalo de tiempo real, en lugar de sumar el contador de vida útil de cada IP, con valores predeterminados realistas (distribuido: 10 direcciones IP distintas y 50 intentos en 10 minutos; ráfaga: 8 direcciones IP y 30 intentos en un minuto). En esta misma versión se ha rediseñado el panel de control 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 WAF, un desglose por gravedad y una tabla de principales atacantes.
En cuanto al ruido, la versión 2.1.16 puso fin a una situación fuera de control /relay-quota una consulta que podía ejecutarse en rutas frecuentes (cortafuegos, encabezados de seguridad, verificación de bots) miles de veces por minuto, y en la versión 2.1.18 se cambió el indicador «API health degraded» de un contador permanente que se quedaba atascado indefinidamente a una ventana móvil que abarcaba las últimas 50 llamadas realizadas en los últimos 7 días, y se limitó la frecuencia de las repeticiones api_call_failed a una fila por minuto, de modo que una ráfaga de fallos ya no pueda escribir decenas de miles de entradas de registro. La versión 2.1.19 corrigió el inicio de sesión oculto en sitios con enlaces permanentes con barra final y protegidos por un caché de páginas, en los que una página de inicio de sesión 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 tu Complementos pantalla, como cualquier otra actualización. Para descargar la versión 2.1.21 de inmediato, abre Complementos → Buscar actualizaciones. No hay ninguna migración de esquema más allá de la tabla «WAF-exceptions» (db_version 10) Se ha vuelto a incluir en la versión 2.1.9, y ahora el asistente de configuración guía a los nuevos usuarios a través de la «Protección ampliada» con valores predeterminados seguros.