Versiones

ReportedIP Hive 2.1.72: bloqueos de grupo y página Protection en cinco pestañas

9 de octubre de 2026 · Patrick Schlesinger

ReportedIP Hive 2.1.72 permite que varios sitios WordPress compartan sus bloqueos de IP como grupo, reconstruye la página Protection en cinco pestañas y evita que un sitio notifique el servidor en el que se ejecuta. Cierra seis versiones publicadas entre el 28 de septiembre y el 9 de octubre de 2026, con dos reglas contra la inyección SQL que ahora se incluyen en la base sin conexión del cortafuegos y más de veinte correcciones para redes Multisite, formularios y el inicio de sesión oculto.

Actualiza desde el escritorio de WordPress o descarga el ZIP actual en la página de producto de Hive. La entrada de versión anterior trataba Hive 2.1.66 y la protección de formularios; esta recoge lo que ha cambiado desde entonces. La interfaz del plugin está en inglés, por eso los nombres de menús y botones se citan en el original.

¿Qué cambió entre Hive 2.1.66 y 2.1.72?

Versión	Fecha	Cambio principal
2.1.67	28 de septiembre de 2026	Bloqueos de grupo, el propio servidor ya no se notifica, el formulario de comentarios rechaza bots
2.1.68	29 de septiembre de 2026	Dos reglas de inyección SQL en la base, Priority Sync desde Contributor
2.1.69	30 de septiembre de 2026	Página Protection en cinco pestañas, user agents entre comillas tratados como bots
2.1.70	2 de octubre de 2026	Huellas de flota más estables, formularios de la administración de red corregidos
2.1.71	5 de octubre de 2026	Un Multisite con varios dominios ya no deja fuera al administrador
2.1.72	9 de octubre de 2026	Direcciones desechables rechazadas en comentarios y formularios

¿Cómo funcionan los bloqueos de grupo en Hive 2.1.67?

Una Community Access Key puede unirse a un grupo en tu cuenta de reportedip.com. Cada dirección que notifica un miembro queda bloqueada en todos los demás miembros durante la ventana de bloqueo del grupo. Hive refleja la lista del grupo como bloqueos de un tipo propio, group: una entrada sigue bloqueada hasta el vencimiento que indica el servicio y se levanta en cuanto sale de la lista.

• La lista blanca manda. Tu propia lista blanca sigue estando por encima de cualquier entrada del grupo, y un bloqueo que pusiste a mano nunca se toca.
• La lista blanca del grupo llega a cada miembro. Las direcciones y rangos en la lista blanca del grupo entran en la lista blanca de cada sitio con el origen Group, tanto en IPv4 como en IPv6.
• No queda nada obsoleto. Cuando la clave sale del grupo, el plan deja de incluir grupos o el sitio pasa a Local Shield, se levanta todo lo que el grupo había puesto.
• Visible donde trabajas. El panel muestra una tarjeta del grupo, y Activity > IP Lists tiene una pestaña Group con cada dirección listada, el miembro que la notificó y lo que este sitio hizo con ella.

Los grupos se incluyen a partir del plan Professional. Los miembros pueden ser sitios WordPress con Hive y servidores Linux con el agente, mezclados en un mismo grupo. La configuración y las capturas están en la guía Compartir bloqueos de IP entre sitios WordPress; los límites por plan y los webhooks están en la página de documentación de grupos.

¿Por qué un sitio ya no notifica su propio servidor?

wp-cron, las peticiones REST al propio sitio y la precarga de cachés salen de la dirección pública del propio host, lo que parece un visitante externo. Cinco sensores notifican directamente y se saltaban la comprobación de esa dirección, así que hubo sitios que notificaron la IPv6 pública de su propio servidor. Eso gastaba la cuota de notificaciones de la cuenta y ponía el servidor en la lista de la comunidad que leen otros sitios.

Desde 2.1.67 ese límite está en los dos puntos por los que pasa cada decisión: la cola de notificaciones y la llamada de bloqueo, junto a las comprobaciones de direcciones privadas y de la lista blanca. Además, un host recuerda su dirección en ambas familias, IPv4 e IPv6, la primera vez que responde por cada una. Un bloqueo que pongas a mano sigue funcionando.

¿Cómo es la nueva página Protection?

Desde 2.1.69 la página Protection tiene cinco pestañas en lugar de quince tarjetas: Core protection, Forms, Firewall & Bots, Advanced y Operations, cada una con un indicador de estado. Un interruptor ocupa una fila, con una frase clara a la izquierda y el botón a la derecha. Un interruptor que tu plan no incluye indica el plan necesario en lugar de aparecer en gris.

• Los ajustes expertos de cada área están detrás de Show technical details; el modo experto los abre por defecto.
• Cada pestaña tiene un solo Save changes y un solo Restore defaults, que escribe la recomendación para tu plan.
• Un botón Check protection junto al banner de estado vuelve a ejecutar la comprobación de configuración y cuenta los problemas y avisos abiertos.
• 2.1.72 reúne Extended Protection en una sola tarjeta con un solo estado y un solo botón.

El registro de ajustes, el esquema remoto para MainWP y la flota en la nube, y cada enlace a la página, siguen igual. La lista de comprobación de endurecimiento recorre los interruptores en orden.

¿Qué reglas de cortafuegos y antispam son más estrictas?

Dos reglas de inyección SQL se suman a la base sin conexión

La inyección basada en errores extrae datos del mensaje de error de la base de datos mediante EXTRACTVALUE() o UPDATEXML(), y una inyección de segundo orden viaja en el cuerpo de un trackback y se activa más tarde. Hasta ahora ambas reglas llegaban solo por Rule Sync. Desde 2.1.68 vienen en la base incluida, así que un sitio en modo Local Shield también queda cubierto, tanto en el motor dentro de WordPress como en la guarda previa a WordPress. La clase de ataque se describe en la entrada de OWASP sobre inyección SQL.

Priority Sync empieza con el plan Contributor

Contributor recibe ahora el conjunto de reglas WAF de Paranoia Level 2 y las listas de rangos IP de bots, actualizados cada semana. El nivel 3 y la actualización diaria siguen en Professional. El motor aplica ese techo por sí mismo, y al bajar de plan vuelve de inmediato al nivel base.

El formulario de comentarios rechaza un bot como cualquier otro formulario

Un comentario de un cliente que nunca ejecutó el script de la página sumaba unos puntos de spam y aun así podía llegar a la cola de moderación. Desde 2.1.67 se rechaza de entrada, con el mismo texto y la misma línea de registro que el formulario de registro y los seis plugins de formularios. Un enlace en el texto del comentario cuenta ahora igual que un enlace en el campo web: medido con 349 comentarios de spam reales, la tasa de acierto contra bots que superan la comprobación del script subió del 42 al 50 por ciento.

User agents entre comillas y direcciones desechables

Ningún navegador pone su user agent entre comillas, un cliente headless mal configurado sí. Desde 2.1.69 un envío así se rechaza, se bloquea y se notifica al momento, y la nueva regla base waf_ua_quoted detiene al mismo cliente en las dos capas del cortafuegos. Desde 2.1.72 los comentarios y cada formulario protegido piden a un remitente con una dirección de correo desechable una dirección permanente; el ajuste ofrece Block, Monitor y Off, y Block es el valor por defecto.

¿Qué cambia para redes Multisite y flotas gestionadas?

• Varios dominios, un administrador. Con Hide Login activado, un administrador que seguía My Sites hacia otro dominio de la red acababa en la página de bloqueo. Desde 2.1.71 esos enlaces apuntan al inicio de sesión de ese dominio, con la página de administración como redirect_to.
• Los formularios de la administración de red funcionan. WordPress no incluye un admin-post.php para la red, así que descartar avisos, sincronizar el grupo y las acciones de 2FA respondían 404. Corregido en 2.1.70, y guardar la página Protection allí vuelve a la administración de red desde 2.1.69.
• Sin falsas desviaciones tras una actualización. La huella de ajustes que reciben MainWP y la flota de reportedip.com solo cubre los valores que difieren de los predeterminados. Una versión que añade un ajuste ya no marca cada sitio como modificado.
• Grupos de casillas en los paneles. Los roles, los métodos de 2FA y los grupos de disparadores del registro de auditoría se muestran como casillas en MainWP y en la flota en lugar de un campo JSON en bruto.

Las dos vías de gestión se describen en la sección de MainWP y la sección de Multisite de la documentación de Hive.

¿Qué errores corrigieron las seis versiones?

• Un rastreador verificado ya no se bloquea por una ruta de escáner. Una dirección demostrada por el rango publicado del rastreador o por DNS inverso con confirmación directa (FCrDNS) conserva su excepción. Un user agent por sí solo sigue sin bastar (2.1.72).
• Un formulario abierto mucho tiempo se acepta. El script de la página renueva su respuesta antes de que caduque, cuando la pestaña vuelve a estar visible y en el momento del envío (2.1.72).
• Las acciones en lote funcionan tras un filtro. Borrar o reintentar elementos de la cola, registros, bloqueos o entradas de la lista blanca no hacía nada después de filtrar (2.1.72).
• El inicio de sesión oculto vuelve a mostrar el error real. Una sesión caducada o una cookie bloqueada ya no aparece como «Invalid credentials.» (2.1.67).
• Una sesión caducada ya no bloquea una oficina entera. Una visita a wp-admin sin sesión se sigue rechazando y registrando, pero ya no alimenta la escala de bloqueo (2.1.67).
• Hide Login y su slug se activan juntos. Los valores se escriben ahora antes que los interruptores en cada canal, MainWP y la flota incluidos (2.1.69).
• Los pies de correo nombran el sitio por su dirección. Un texto de enlace que nombra algo distinto de su destino es una señal de phishing para Microsoft 365 y Gmail (2.1.72).
• Las instalaciones vuelven a contarse en wordpress.org. Las actualizaciones siguen llegando solo por el canal de versiones de ReportedIP (2.1.70).

Desde 2.1.68 el registro de auditoría también sigue el interruptor Log user agents, desactivado por defecto, como siempre hizo el registro de seguridad. La sección de RGPD enumera lo que guarda Hive.

Preguntas sobre Hive 2.1.72

¿Qué plan incluye los bloqueos de grupo en Hive?

Los bloqueos de grupo requieren el plan Professional o superior. Una clave en un plan inferior recibe un aviso, y la sincronización sigue preguntando, así que una mejora de plan no exige ningún paso en el sitio. Una clave sin grupo no nota ningún cambio. En cuanto el plan incluye grupos y la clave no está en ninguno, el panel muestra un siguiente paso con un enlace a la sección Groups de tu cuenta.

¿Cambian mis ajustes de protección con la nueva página de cinco pestañas?

Tus ajustes guardados se quedan exactamente como estaban. La página de cinco pestañas lee y escribe el mismo registro que las tarjetas antiguas, y MainWP y la flota en la nube usan el mismo esquema remoto. Solo Restore defaults escribe valores nuevos, y únicamente en la pestaña donde lo pulses. Un ajuste nuevo llega activado: desde 2.1.72 las direcciones de correo desechables se rechazan en comentarios y formularios protegidos, configurable en la pestaña Forms.

¿Qué debo comprobar tras actualizar a 2.1.72?

Abre la página Protection y pulsa Check protection para ver los puntos abiertos. En la pestaña Forms, decide cómo tratar las direcciones de correo desechables; Block es el valor por defecto. Si varios de tus sitios comparten atacantes, crea un grupo en tu cuenta y añade sus claves.

Sigue leyendo

• Bloqueos de grupo en Hive
• Cortafuegos y entrega de reglas
• Bots, correo desechable y spam en comentarios
• Funciones por plan

¿Gestionas también servidores Linux junto a WordPress? La versión 0.3.48 del Linux Agent lleva los mismos grupos al cortafuegos del kernel. Versiones anteriores de Hive: Hive 2.1.62 con el registro de auditoría y Hive 2.1.57 con la administración reconstruida.