Plugin de WordPress: ReportedIP Hive (Full Edition)

ReportedIP Hive es un plugin de seguridad para WordPress impulsado por la comunidad. Convierte cada sitio protegido en un sensor: cuando un sitio es atacado, la red aprende y todos los demás sitios pueden rechazar al atacante antes de que llegue la primera solicitud. Threat Intelligence en tiempo real, dieciséis Attack Sensors, incluido un Web Application Firewall, autenticación de dos factores (2FA) con cuatro métodos, Progressive Block Escalation y conjuntos de reglas de cortafuegos firmados y proporcionados por el servidor. Código abierto, publicado bajo licencia GPLv2+ en GitHub.

Instalación

Inicio rápido

El inicio rápido sustituyó al Setup Wizard de diez pasos en la versión 2.1.54. Hace dos preguntas, modo y clave, lee tu plan de la comprobación de la clave y activa una recomendación para ese plan. Community Network está preseleccionado y necesita una clave comprobada; Local Shield es la alternativa y nunca se bloquea. El botón de experto aplica la misma recomendación y abre los ajustes; también puedes importar una exportación JSON existente. La antigua dirección page=reportedip-hive-wizard redirige al inicio rápido.

Una mejora de plan posterior activa lo que recomienda el nuevo plan para cada ajuste que no hayas cambiado tú mismo; el banner posterior a la mejora enumera lo que ha cambiado. Volver a ejecutar el inicio rápido vuelve a aplicar los valores recomendados para tu plan y los tres interruptores; el resto de ajustes se mantiene.

Modos de funcionamiento

Dos modos, se puede cambiar de uno a otro en cualquier momento sin perder los datos locales.

Qué obtienes en cada nivel

El propio plugin Hive es totalmente funcional en el plan Free: protección local, los dieciséis sensores y los cuatro métodos de autenticación de dos factores (2FA). Los niveles de pago incluyen una infraestructura de entrega gestionada (correo electrónico y SMS) y cuotas más elevadas en la Community Network. Consulta la página de precios para ver la comparación completa y realizar la actualización.

El plan Business admite reservas múltiples. Todas las cifras del plan Business indicadas anteriormente corresponden a una sola licencia. Reserva el plan Business x2, x5, x10 o x20 al finalizar la compra (o cámbialo más tarde en el Portal de Clientes de Stripe) y las comprobaciones/Reports diarios, el límite mensual de correos electrónicos/SMS de 2FA y el número de dominios se adaptarán al número de licencias que tengas; por ejemplo, x5 = 75 dominios y 500 000 comprobaciones al día. Se aplica automáticamente un descuento por volumen a partir de x2. La versión PRO sigue siendo de una sola licencia; las cifras de la versión Enterprise son ilimitadas (uso razonable) y nunca se multiplican.

Orden de consumo del paquete (PRO y Business): primero se agota la asignación mensual incluida (25 SMS / 500 correos electrónicos en PRO, 75 / 2.500 en Business) y, a continuación, el saldo prepagado del paquete. Una vez agotados ambos, la API devuelve un código HTTP 429 y Hive recurre a la autenticación local wp_mail() para el correo electrónico (o los límites máximos fijos de SMS); el resto de métodos de 2FA siguen operativos. Los créditos de los paquetes nunca caducan. Stripe utiliza tax_behavior = inclusive para los paquetes con precio bruto (conforme a PAngV); Stripe Tax gestiona automáticamente la inversión de la obligación de pago (Reverse Charge) y el OSS.

Defensa en 6 capas

Hive aplica sus comprobaciones en orden; cada capa puede interrumpir la solicitud antes de que llegue a la siguiente. Se ha configurado init con prioridad 1 para que otros plugins no se ejecuten en caso de una IP bloqueada.

1. La Whitelist, las IP de confianza y los rangos CIDR siempre están permitidos (tu oficina, servicios de monitorización, etc.).
2. Lista de bloqueo local: direcciones IP que hayas bloqueado manualmente o que hayan superado los umbrales locales. Almacenadas en wp_reportedip_hive_blocked.
3. Web Application Firewall, el conjunto de reglas activo del WAF se compara con la URI, la consulta, el cuerpo y el agente de usuario; si hay una coincidencia, se bloquea a través de la ruta 403 compartida y codificada por referencia. Tiene en cuenta la Whitelist y el autor del contenido para evitar False Positives. Un complemento opcional previo a WordPress puede ejecutar esta capa incluso antes de que se cargue WordPress.
4. Los contadores de intentos, de Login, de comentarios, de XMLRPC, de ráfagas REST y de escaneos 404 activan un bloqueo automático una vez alcanzado el umbral.
5. Reputación de la comunidad: en el modo «Community Network», las direcciones IP con un nivel de confianza ≥ al umbral se bloquean en el perímetro.
6. Desafío de 2FA: las cuentas protegidas deben completar un segundo factor para iniciar sesión.

Los dieciséis Attack Sensors

Cada sensor se puede activar o desactivar y ajustar de forma independiente en Protección → Detección y umbrales. La tabla incluye además tres mecanismos complementarios que recorren el mismo flujo sin contar como sensores propios: las rutas señuelo informan a la comunidad en lugar de bloquear localmente y pertenecen a la capa honeypot, la dirección de Login oculta es un interruptor de acceso y no un detector, y Block Escalation es la escala de respuesta a la que contribuyen todos los sensores. El plugin cuenta dieciséis sensores, igual que su readme: la escalada es la escala de respuesta a la que contribuyen todos los sensores, y el puente de WooCommerce contabiliza los fallos de Login en la tienda online para el sensor de Brute Force existente.

Progressive Block Escalation

Los reincidentes pagan más. La escala predeterminada es 5 min → 15 min → 30 min → 24 h → 48 h → 7 d. Tras 30 días sin incidentes, el contador se reinicia en el paso 1. Los visitantes legítimos que activan el bloqueo por primera vez (CGNAT, administradores que se equivocan al teclear, salida de redes móviles) se recuperan en cuestión de minutos; los atacantes persistentes alcanzan el nivel de 7 días.

La escala, la ventana de reinicio y el interruptor principal se encuentran en Protección → Bloqueo y escalado → Bloqueo progresivo. La recomendación del inicio rápido deja la escala activada, de modo que las instalaciones nuevas escalan desde el primer guardado. La configuración fija block_duration se sigue aplicando cuando la escala está desactivada. La granularidad inferior a una hora la proporciona ReportedIP_Hive_Database::block_ip_for_minutes().

Web Application Firewall y la entrega de reglas

Desde la versión 2.1.2, Hive incluye un Web Application Firewall que inspecciona las solicitudes. Si init este compara el waf con la URI, la cadena de consulta, el cuerpo de la solicitud y el agente de usuario, y bloquea las coincidencias a través de la ruta 403 compartida, segura para la caché y codificada por referencia. Está protegido contra ReDoS (retroceso PCRE limitado, modo «fail-open» ante una regla mal formada), tiene en cuenta las Whitelists y el autor del contenido para evitar False Positives, y añade aproximadamente 4 µs de CPU por solicitud sin consultas adicionales a la base de datos cuando existe una caché de objetos persistente.

Las reglas no están codificadas de forma fija en el complemento. Se suministran desde la Rule API de ReportedIP, son entregadas por el servidor, están versionadas, firmadas con Ed25519 y distribuidas por niveles en cinco conjuntos de reglas (waf, bot_signatures, disposable_domains, scan_paths, tor_exits). El complemento verifica cada conjunto de reglas con una clave pública incluida antes de aplicarlo y siempre recurre a una línea de base incluida, por lo que una fuente manipulada, de tamaño excesivo o inaccesible nunca podrá corromper tus reglas. Las nuevas firmas de ataque llegan a todas las instalaciones en cuestión de horas, sin necesidad de publicar una nueva versión del complemento.

• Gratis en todos los planes: el motor WAF y el conjunto de reglas de referencia «OWASP Top 10» de Paranoia Level 1, totalmente utilizables sin conexión en el modo «Local Shield» a partir de la línea de base incluida.
• Priority Sync (a partir del plan Professional): los conjuntos de reglas más completos, actualizados con frecuencia y firmados de los niveles Paranoia-Level 2 y 3 (cobertura de ofuscación y elusión), además de los feeds en tiempo real de rangos de IP de bots y dominios desechables. La versión gratuita sincroniza la línea de base incluida; la versión Contributor, semanalmente; y las versiones Professional y superiores, diariamente.
• Extended Protection drop-in (opcional): un guardián previo a WordPress auto_prepend_file que ejecuta el WAF antes de que se cargue WordPress. Las pilas de Apache (.htaccess) y las pilas PHP-FPM, incluido nginx + PHP-FPM, se configuran automáticamente a través de un directorio raíz de documentos .user.ini, que cubre todos los Endpoints de PHP independientemente de los bloques de nginx location (desde la versión 2.1.17); las pilas sin una SAPI PHP FastCGI se configuran mediante una línea en el archivo php.ini o en el panel de alojamiento auto_prepend_file o un fragmento de código de nginx fastcgi_param de la pestaña «Configuración del servidor». El guard omite por defecto la inspección del cuerpo de la solicitud para las solicitudes autenticadas, por lo que los editores que hayan iniciado sesión y guarden contenido nunca lo activarán; las reglas de URL y de agente de usuario siguen ejecutándose, y el motor interno de WordPress sigue siendo el mecanismo de seguridad que detecta las capacidades. Desactivado por defecto; al eliminarlo, Hive controla y neutraliza el guard convirtiéndolo en un marcador de posición inerte en lugar de borrarlo (desde la versión 2.1.8), por lo que una directiva residual en un archivo php.ini editado manualmente o en la configuración de nginx nunca podrá apuntar a un archivo inexistente y provocar un error 500 en el sitio. Desactivar el motor WAF o cambiar al modo «solo informe» también neutraliza automáticamente el filtro.
• Códigos de referencia: cada bloque (WAF o sensor) lleva un código correlacionable como WAF_SQLI-3F9A2B71, que se muestra en la página de bloqueo y se incluye como el X-RIP-Ref encabezado. Un visitante bloqueado por error proporciona una cadena corta que el administrador puede cotejar en los registros; el token es un hash unidireccional de la IP, el motivo y la hora, por lo que no se exponen datos personales.

La configuración se encuentra en la página «Protección», en la tarjeta «Cortafuegos y bots» (motor, modo, selector de «Paranoia-Level», verificación de bots, defensa contra el spam). Rule Sync, las excepciones del WAF, el filtro de «Extended Protection» y todos los fragmentos de código del servidor web están en la página «Herramientas» (pestañas «Reglas» y «Servidor»; aparece en el menú en modo experto y siempre es accesible por URL). El registro del cortafuegos está en la página «Actividad».

WAF Exceptions: gestión de False Positives

Desde la versión 2.1.9, el administrador puede resolver un False Positive sin modificar el código, del mismo modo que funcionan las exclusiones de ModSecurity y la Allowlist de Wordfence. Un endpoint propio que recibe legítimamente Payloads similares a ataques (un formulario que acepta HTML, una API de seguridad que recopila datos de ataques notificados, un generador de páginas que envía código sin procesar) activa ocasionalmente una firma de inyección; una excepción permite que ese caso concreto pase, mientras que el motor sigue protegiendo todo lo demás.

• Dónde: Herramientas → Reglas → WAF Exceptions, además de una acción de «Permitir» con un solo clic en cada fila del registro del WAF que rellena automáticamente una excepción específica para esa regla concreta en esa ruta, sin necesidad de memorizar el ID de la regla.
• Ámbitos de aplicación. Una excepción se aplica a una sola regla (por ID de regla, extraída del registro de bloqueos del WAF), a un grupo de reglas (seleccionado de entre las categorías conocidas del motor) o, en el caso de un Endpoint propio, a todo el motor en una ruta, opcionalmente restringida a una dirección IP o un rango CIDR. Una excepción para todo el motor debe incluir siempre una restricción de ruta o de IP, de modo que el cortafuegos nunca pueda desactivarse globalmente por accidente.
• Limítala lo máximo posible. Es preferible una sola regla en una ruta antes que un grupo de reglas, y un grupo de reglas antes que una excepción para todo el motor. El registro de bloqueos recoge el valor coincidente, el destino inspeccionado, el método de solicitud, la URI y el agente de usuario (desde la versión 2.1.11), de modo que puedas ver exactamente qué regla se activó y por qué antes de permitirla.
• La Extended Protection respeta la misma lista. Las excepciones activas se integran en el filtro de seguridad previo a WordPress y se actualizan cada vez que cambia la Allowlist; la capa previa a WordPress y el motor integrado en WordPress nunca discrepan.
• Multisite y planes. Las excepciones son datos válidos para toda la red, disponibles en todos los planes; el motor de protección en sí mismo sigue siendo gratuito.
• Vía de escape para desarrolladores. apply_filters('reportedip_hive_waf_bypass_routes', []) Excluye rutas REST a nivel de código. La coincidencia se comprueba mediante un prefijo anclado frente a la ruta REST de WP resuelta, nunca mediante una subcadena no anclada de la URI sin procesar, por lo que un token de elusión introducido de forma encubierta en un parámetro de consulta no relacionado no puede desactivar el WAF.

Verified Bot Detection, Disposable-Email Blocking y Comment Spam

• Verified Bot Detection (gratuita). Confirma que una solicitud que afirma ser de Googlebot, Bingbot u otro rastreador procede realmente de ellos, mediante una comparación sin DNS con los rangos de IP oficiales del rastreador en primer lugar (Priority Sync) y, a continuación, un sistema de respaldo de Reverse DNS confirmado hacia adelante que resuelve tanto los registros A como los AAAA. Los suplantadores se marcan (por defecto) o se bloquean; un rastreador auténtico nunca se bloquea. facebookexternalhit Se verifica con los rangos de IP publicados por Meta.
• Disposable-Email Blocking (gratis). Comprueba la dirección en el momento del registro (WordPress y WooCommerce) cotejándola con la lista de correos desechables. Tres modos: desactivado / supervisar / bloquear. Los relés de privacidad (Apple «Ocultar mi correo electrónico», Firefox Relay, etc.) constituyen una categoría distinta que se deja pasar por defecto. La lista en tiempo real se basa en Priority Sync.
• «Comment Honeypot» (gratuito). Un campo señuelo invisible, excluido por los lectores de pantalla, en el formulario de comentarios; los bots de spam que rellenan todos los campos son rechazados sin la molestia del CAPTCHA para los visitantes reales. Desde la versión 2.1.52, un bot que cae en la trampa también cuenta para el contador de comentarios de su dirección, de modo que un reincidente alcanza el umbral de bloqueo.
• Filtro de spam en comentarios (gratuito, desde la versión 2.1.52). Puntúa cada comentario entrante según el número de enlaces, la densidad de enlaces, el número de dominios distintos, los dominios de correo desechable, los dominios de nivel superior delatores, un dominio en el nombre del autor y un texto sin mensaje propio detrás de un enlace. Varias señales tienen que coincidir antes de que un comentario cuente. Por defecto se archiva como spam para su revisión; el rechazo directo es opcional, y el filtro puede desactivarse en Protección → Registro y spam.
• Prueba de ejecución del formulario (gratuita, desde la versión 2.1.53). Los formularios de comentarios, registro y restablecimiento de contraseña llevan un campo ancla oculto, y un pequeño script añade un segundo campo cuyo nombre es aleatorio en cada instalación. Un envío que no lleva ninguno de los dos nunca ha mostrado el formulario, que es justo el aspecto de un script que publica directamente en la dirección. No se emite nada específico de la petición, así que las cachés de página no se ven afectadas. En los comentarios el resultado es solo una señal de puntuación: un visitante que navega sin JavaScript ve su comentario archivado para revisión en lugar de rechazado, y ese motivo por sí solo nunca cuenta para un bloqueo; el registro y el restablecimiento de contraseña sí rechazan y explican el porqué. REPORTEDIP_HIVE_DISABLE_FORM_PROOF en wp-config.php desactiva toda la capa.

Bloqueo de nodos de salida de Tor (Professional)

Desde la versión 2.1.41, Hive puede rechazar conexiones procedentes de nodos de salida de Tor conocidos. La función es estrictamente opcional, el interruptor se encuentra en Protección → Bloqueo y escalado y está desactivado por defecto, y requiere un plan Professional: la lista de nodos de salida llega como un tor_exits con el Rule Sync habitual y se actualiza dos veces al día del lado del servidor, por lo que se mantiene al día a medida que rotan los nodos de salida. El indicador de isTor marca de reputación de la comunidad cubre las direcciones que la lista aún no ha detectado.

Los bloqueos de Tor son deliberadamente moderados. Son temporales: 24 horas por defecto, ajustables mediante el reportedip_hive_tor_block_hours filtro, y nunca se notifican a la comunidad, ya que operar un nodo de salida de Tor no constituye prueba de uso indebido. Las IP incluidas en la Whitelist nunca se bloquean en Tor. Una vez que caduca un bloqueo, la siguiente solicitud reevalúa la lista actual de nodos de salida.

Normas de registro

Desde la versión 2.1.51, todas las vías de registro pasan por un único conjunto de reglas: el formulario de registro de WordPress, el registro de clientes de WooCommerce, los registros en Multisite y la creación programática de usuarios. Las tarjetas se encuentran en Protección → Registro y spam y se evalúan en un orden fijo, prevaleciendo la primera coincidencia: Allowlist de IP, Rate Limit, nombres de usuario prohibidos, reglas de correo electrónico y comprobación de direcciones de correo desechables.

• Nombres de usuario prohibidos. Una entrada por línea, además de una lista básica integrada (admin, administrator, root, sysadmin, superadmin, webmaster, hostmaster, postmaster, support, moderator), que se puede desactivar y nunca cuenta para el límite gratuito.
• Reglas de correo electrónico. Una lista con tres modos: desactivado, bloquear las direcciones de la lista o permitir solo las direcciones de la lista. Un nombre de host sin nada delante significa *@host. Una coincidencia en modo «permitir» anula la comprobación de correo desechable; una lista vacía en modo «permitir» se comporta como si estuviera desactivada, por lo que nadie se queda sin acceso.
• Rate Limit. Por dirección IP, tres registros cada 60 minutos por defecto, gratuito y configurable (intervalo de 1 a 60 minutos). Solo rechaza el registro: no se bloquea la IP ni se envía un informe a la comunidad, por lo que una oficina con NAT nunca se ve penalizada por sus vecinos.
• Registro solo con lista de Allowlist (Professional). Si hay rangos de IP en la lista, solo esos rangos pueden crear una cuenta.
• Bloqueo por nombre de usuario desconocido (opcional, desactivado por defecto). Un intento de inicio de sesión con un nombre de usuario que no existe bloquea la IP inmediatamente. Ten en cuenta la contrapartida: el bloqueo resultante actúa como un oráculo de existencia para los nombres de usuario, por lo que esta opción está desactivada por defecto y el incidente nunca se notifica a la comunidad.

Gramática de entradas. Una entrada simple coincide exactamente (sin distinción entre mayúsculas y minúsculas); una entrada que contenga * es un comodín anclado, y una entrada entre barras (/^shop[0-9]+$/) es una expresión regular. Los planes Free disponen de diez entradas simples por lista, comodines incluidos; el plan Professional elimina el límite y habilita las expresiones regulares y el registro solo mediante Allowlist. Un guardado que supere el límite gratuito se rechaza con un aviso del plan en lugar de truncarse silenciosamente.

Los rechazos se registran como prohibited_username, registration_denied y registration_limit y se pueden filtrar en la página «Actividad», en la sección «Registro».

Opciones de bloqueo de acceso

También desde la versión 2.1.51, y gratuito en todos los planes: opciones en Protección → Cabeceras de seguridad que desactivan partes de WordPress que un sitio no utiliza. Todas ellas están desactivadas por defecto y se pueden reactivar en la misma pantalla.

• Acceso a la REST API. Tres modos: abierto, solo para visitantes que hayan iniciado sesión o restringido a roles seleccionados. Los espacios de nombres de la Allowlist permanecen públicos en todos los modos, y se incluyen los Endpoints que, de otro modo, dejarían de funcionar (oembed/1.0, wp-site-health/v1los espacios de nombres habituales del banner de cookies y de los formularios, y la API de la tienda de WooCommerce); reportedip-hive/v1 siempre está permitido para que las rutas de 2FA sigan funcionando. Los visitantes reciben un 401, y los usuarios registrados que no figuran en la lista de roles reciben un 403. Al cerrar la API para los visitantes, también se eliminan los enlaces de descubrimiento REST.
• XML-RPC. Rechaza xmlrpc.php, desactiva los pingbacks, elimina el X-Pingback encabezado en el origen y elimina los enlaces a los manifiestos RSD y WLW. Las contraseñas de aplicación a través de REST no se ven afectadas, ya que son el sustituto moderno de los clientes XML-RPC.
• Fuentes. Las fuentes RSS, Atom y de comentarios devuelven un 404 y los enlaces a las fuentes desaparecen del encabezado de la página.
• Área de administración para visitantes que no han iniciado sesión. Se deniega /wp-admin/ a los visitantes que no hayan iniciado sesión, y con ello el /admin y /dashboard alias, a los que WordPress redirige. El /login alias sigue redirigiendo al formulario de Login a menos que esté activada la opción «Hide Login»: solo esta opción elimina la redirección predeterminada que lo envía a wp-login.php. La opción «Hide Login» también bloquea el acceso a wp-admin para los visitantes; el conmutador permite que esa parte esté disponible de forma independiente. admin-ajax.php y admin-post.php sigue siendo accesible, ya que las llamadas de retorno no autenticadas envían datos allí de forma legítima.
• Ejecución de PHP en «uploads». Escribe un bloque marcador en el directorio «uploads» .htaccess que rechaza las solicitudes a nombres de archivo de tipo PHP, incluida la clásica doble extensión shell.php.jpg. Solo en Apache; en nginx y en servidores desconocidos, la página muestra en su lugar el fragmento de código que hay que pegar en la configuración del servidor. Al desactivarlo, se elimina el bloqueo por completo.
• Huellas digitales de software. Elimina la etiqueta del generador de WordPress y desactiva la visualización de errores de PHP, a menos que WP_DEBUG y WP_DEBUG_DISPLAY estén activadas. Se trata de un refuerzo de seguridad superficial: los números de versión siguen pudiéndose deducir a partir de las URL de los recursos.

El mapa del sitio de usuario (wp-sitemap-users-1.xml) no es una opción independiente. Desaparece mientras está activada la opción «User Enumeration», que es la configuración por defecto, ya que publicaba precisamente la lista que la defensa oculta.

Los rechazos se registran una vez por dirección IP y evento con una limitación de cinco segundos (rest_denied, xmlrpc_denied, feed_denied, admin_guest_denied). Nunca activan la escala de bloqueo y nunca se notifican a la comunidad: se trata de control de acceso, no de detección de ataques.

Preparación del sistema

Dieciocho detectores supervisan aquellas partes de una instalación que fallan de forma silenciosa: doce informan de un fallo y seis proponen una mejora y aparecen como tarjeta de siguiente paso en el panel en lugar de como problema. Los problemas pendientes aparecen en «Estado del sistema» junto con su gravedad, la fecha en que surgieron por primera vez, un enlace a la configuración correspondiente y un enlace a esta página. Además, los problemas críticos y de advertencia generan un aviso resumido en las páginas del complemento; el widget del Dashboard muestra el recuento y wp reportedip status las recoge en el issues campo. Las advertencias y los avisos se pueden descartar en todo el sitio durante siete días; los problemas críticos no se pueden descartar. Un problema que desaparece se olvida y vuelve a aparecer si reaparece.

• Cola de protección no grabable (crítico). Extended Protection está activada, pero el sistema de protección previo a WordPress no puede escribir en su cola de incidencias, por lo que sus bloqueos nunca se importan y nunca se escalan. Corrige los permisos del directorio indicado en el mensaje o desactiva Extended Protection.
• Tareas programadas bloqueadas (crítico). Todos los ganchos cron de Hive llevan más de 24 horas de retraso, por lo que el procesamiento de la cola, la sincronización de reputación y la limpieza están congelados. Suele deberse a un bucle de retorno de WP-Cron defectuoso; configura un cron real del sistema y desactiva DISABLE_WP_CRON.
• WP-Cron desactivado sin un sustituto (advertencia). DISABLE_WP_CRON está activado, ALTERNATE_WP_CRON no está activado, y no se ha ejecutado ningún desencadenante externo desde hace más de una hora.
• Encabezado de IP de confianza sin rangos de proxy (advertencia). Se respeta el encabezado de IP del cliente para todos los pares, por lo que cualquiera que acceda directamente al origen puede suplantar una dirección, eludir un bloqueo o hacerse pasar por una IP incluida en la Whitelist. Define tus rangos de proxy en Community.
• Esquema de la base de datos desactualizado (crítico). La versión del esquema almacenada está desactualizada con respecto a la del plugin. Suele deberse a una migración que se ha interrumpido; al recargar la página del plugin se vuelve a intentar.
• Capa de la comunidad degradada (advertencia). La ventana de solicitudes recientes muestra una baja tasa de éxito. Comprueba el tráfico HTTPS saliente hacia ReportedIP.com y la Community Access Key.
• Se ha alcanzado el límite de Mail Relay (advertencia). Se ha agotado la asignación mensual de correo gestionado y los correos de 2FA recurren a wp_mail(). Contrata un paquete de recarga o espera a que se restablezca el límite.
• Se ha alcanzado el límite de SMS Relay (advertencia). Se ha agotado la asignación mensual de SMS. Los usuarios que tengan el SMS como único método deben añadir un segundo método.
• Fallo en la entrega de correo (advertencia). WordPress ha notificado wp_mail_failed errores, por lo que no llegan los códigos de 2FA ni las alertas. Comprueba la configuración de SMTP. Las direcciones de los destinatarios se han eliminado del mensaje almacenado.
• No hay backend de cifrado (crítico). No está disponible ni libsodium ni OpenSSL, por lo que los secretos TOTP y los números de teléfono no se pueden cifrar en reposo. Pide a tu proveedor de alojamiento que habilite una de las dos extensiones.
• La cola de informes contiene entradas fallidas (advertencia). Los Reports han agotado sus reintentos. Revísalos y vuelve a intentarlos en la pestaña «Cola de la API».
• Atasco en la cola de Reports (advertencia). Los Reports pendientes se están acumulando, lo que normalmente apunta a un problema de cron o de conectividad.
• Dirección de acceso todavía pública (informativo). Hide Login está desactivado, así que cualquier bot sabe dónde está el formulario de acceso. La tarjeta de siguiente paso acepta un slug y activa la función en un solo paso.
• 2FA de tienda incluida pero desactivada (informativo). El sitio usa WooCommerce y el plan incluye el desafío para clientes integrado en el tema, que no está activo. Un clic lo habilita.
• Insignia de pie desactivada (informativo). La insignia «Protected by ReportedIP» no se muestra. Es opcional y un clic la activa.
• Protección Ampliada posible pero inactiva (informativo). El servidor admite el guard previo a WordPress y no está en marcha, así que cada petición bloqueada sigue arrancando WordPress primero.
• Local Shield en lugar de la red comunitaria (informativo). El sitio se protege a sí mismo, pero ni consulta a la red ni aporta a ella.
• Falta tu propio segundo factor (informativo). La autenticación en dos pasos está activa para el sitio y la cuenta que mira la página no tiene ningún método configurado. Se muestra por persona, nunca para todo el sitio.

Fuentes de proxy de confianza (Cloudflare, proxies inversos, equilibradores de carga)

Cuando tu sitio web funciona detrás de Cloudflare, un proxy inverso o un equilibrador de carga, el par de conexión es el proxy, y la dirección real del visitante se transmite en un encabezado HTTP como CF-Connecting-IP o X-Forwarded-For. Selecciona ese encabezado en «Community» → «Encabezado de IP de confianza» y, a partir de la versión 2.1.41, indica las direcciones del proxy en la lista «Fuentes de proxy de confianza» situada justo debajo, una IP o un rango CIDR por línea, por ejemplo, los rangos publicados de Cloudflare.

Una vez configurada la lista, el encabezado solo se tendrá en cuenta para las solicitudes que se conecten realmente desde una dirección de proxy declarada. Cualquiera que acceda directamente al origen no podrá falsificar el encabezado para suplantar una dirección incluida en la lista Whitelist ni eludir un bloqueo activo. Una lista vacía mantiene el comportamiento anterior (se acepta el encabezado de cualquier par), por lo que las configuraciones existentes siguen funcionando, pero si confías en un encabezado, declara tus proxies. La misma comprobación se aplica en el filtro «Extended Protection» previo a WordPress.

Security Headers

Fortalecimiento de los encabezados de respuesta en cada solicitud del front-end. Los encabezados ya enviados por tu servidor u otro plugin se detectan y no se modifican.

• Trío básico (gratuito), X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Avanzado (Professional): HSTS, Permissions-Policy, una Política de Seguridad de Contenido (solo de informe por defecto, con un generador) y el trío de aislamiento entre orígenes (COOP / CORP / COEP).

La pestaña «Configuración del servidor» permite, además, exportar los encabezados configurados como configuración de nginx a nivel de servidor add_header / Apache Header a nivel de servidor.

Protection & Hardening Score

Dos indicadores del Dashboard (de 0 a 100, más una calificación de A+ a F, al estilo del Mozilla Observatory) evalúan tu cobertura de detección y tu nivel de refuerzo de la seguridad, con enlaces directos a cada elemento para activar un sensor. Las funciones bloqueadas (de pago) cuentan a favor del potencial visible, no en contra de tu puntuación, por lo que el plan Free también puede alcanzar la máxima calificación.

Dashboard de seguridad y análisis

Desde la versión 2.1.57 el panel responde a «listo, ¿y ahora?»: un banner de estado indica el plan para el que se aplicó la recomendación, la fecha de configuración y cuántos ajustes se desvían de ella; las tarjetas de próximos pasos (Hide Login apagado, 2FA de tienda incluida pero apagada, badge apagado, protección ampliada posible pero inactiva, Local Shield en lugar de la Community Network, tu propio segundo factor sin configurar) llevan una acción en línea o un enlace y se pueden posponer siete días; una fila por área de protección muestra el estado breve y salta a la tarjeta; y como máximo aparece una tarjeta de plan por visita. El modo experto es un interruptor en la cabecera de la página.

El Dashboard principal se abre con una barra de titulares, los ataques bloqueados en los últimos 30 días, los ataques bloqueados hoy, las direcciones IP bloqueadas actualmente y cuántas de tus capas de protección están activadas (por ejemplo 17 / 20). Debajo, los análisis recogen datos de todos los sensores, no solo de los clásicos contadores de Login y spam.

• Cronología de eventos de seguridad. Un gráfico de áreas apiladas que agrupa toda la actividad en siete categorías: Login y credenciales, cortafuegos (WAF), escáneres y sondas, bots falsos, reconocimiento y enumeración, spam y inundaciones, y anomalías, en un intervalo seleccionable de 7, 30 o 90 días.
• Distribución de amenazas. Un desglose de qué familia de ataques predominó durante el periodo, para que puedas ver de un vistazo si te enfrentas a ataques de Brute-Force, intentos de explotación a nivel de cortafuegos, escáneres o spam.
• Cortafuegos: principales tipos de ataque. Los bloqueos del WAF clasificados por grupo de reglas (SQL Injection, scripts entre sitios, recorrido de rutas, Log4Shell, agentes de usuario de escáneres, etc.).
• Desglose por gravedad. Recuentos de graves, altos, medios y bajos, para que el volumen de incidentes graves nunca quede oculto dentro de un único total.
• Principales atacantes (30 días). Las direcciones IP de origen más activas con su recuento de impactos, cuándo se detectaron por última vez y si actualmente están bloqueadas o solo bajo vigilancia.
• Actividad reciente. El flujo de eventos en tiempo real, con cada entrada etiquetada con su gravedad y familia de amenazas, además de los detalles relevantes (regla del WAF que se ha aplicado, ruta explorada, nombre del bot suplantado).

Todas las cifras son reales en todos los planes; el Dashboard refleja lo que tu sitio web ha bloqueado realmente. Los planes Professional y Business añaden análisis más detallados (historial y retención de registros más amplios, geografía de los atacantes y el registro de auditoría conforme a las normas de cumplimiento que se describe a continuación).

Desde la versión 2.1.41, las cifras principales también aparecen como un widget de seguridad en el propio Dashboard de WordPress: los ataques bloqueados en los últimos 30 días, los bloqueos de hoy, los bloqueos de IP activos, las capas de protección y la puntuación de detección aparecen directamente en la página principal del Dashboard de WordPress, con enlaces directos al plugin. En entornos Multisite, el widget se muestra en el Dashboard de la red y, para los superadministradores, en los Dashboards de los subsitios con cifras de toda la red. Desde la versión 2.1.51, también incluye el número de incidencias de disponibilidad pendientes; consulta «Disponibilidad del sistema».

Además del Dashboard, hay siete pantallas con tablas de lista: IP bloqueadas, Whitelists, Registros de seguridad, Cola de API, el Audit Event Trail (Business), el gestor de sesiones en Usuarios → Sesiones (Business) y la cuadrícula de administración de 2FA. Una página independiente de «Estado del sistema» enumera todos los problemas de disponibilidad pendientes con su nivel de gravedad, la fecha en que aparecieron por primera vez y un enlace directo a la configuración correspondiente. Desde la 2.1.62 el filtro de eventos del registro de seguridad se puede buscar y selecciona grupos completos, y cada tipo de evento que escribe el plugin figura en un único registro.

Audit Event Trail (Business)

Desde la versión 2.1.62 el registro recoge quién cambió qué en el sitio, no solo lo que ocurrió con las cuentas. Ocho grupos de activación, 48 tipos de evento, cada grupo un interruptor en la página Protección (tarjeta «Privacidad y registros»):

• Inicios y cierres de sesión (desactivado por defecto: son las filas más numerosas, y los intentos fallidos ya están en el registro de seguridad).
• Cuentas de usuario: registro, eliminación, cambios de perfil, correo y contraseña, cambios de rol con el usuario que los hizo, restablecimientos de contraseña, bloqueos de cuenta, sesiones finalizadas, capacidades de rol editadas.
• Páginas y entradas: publicado, retirado, enviado a la papelera, restaurado, eliminado, slug de URL cambiado. Se ignoran los guardados automáticos, las revisiones y los borradores automáticos.
• Plugins, temas y núcleo: instalado, actualizado, activado, desactivado, eliminado, tema cambiado, núcleo actualizado, con la versión anterior y la nueva. Las actualizaciones automáticas también son filas, marcadas como cron.
• Ajustes del sitio: 26 opciones del núcleo (dirección del sitio, enlaces permanentes, lectura, comentarios, registro, actualizaciones automáticas) y cada ajuste de Hive, con el valor antiguo y el nuevo; una lista se guarda como lo añadido y lo eliminado.
• Menús y widgets: menús creados, modificados y eliminados, ubicaciones de menú, widgets añadidos a una barra lateral o retirados de ella.
• Editor de archivos de temas y plugins: un archivo guardado desde el editor integrado, registrado solo si el archivo cambió de verdad.
• Red (solo Multisite): sitios creados, modificados, archivados o eliminados, usuarios añadidos a un sitio o retirados de él, permisos de superadministrador concedidos o revocados.

Cada fila indica el usuario que actuó, la vía de la petición (navegador, WP-CLI, cron, REST, AJAX) y el objeto afectado, con enlace mientras exista. Los secretos nunca se escriben: una clave de datos o un nombre de opción que designe una contraseña, un token, una clave o un código deja sus valores fuera. La retención es de 90 días por defecto, ajustable entre 1 y 365, y la limpieza nocturna se ejecuta en bloques de 5.000 filas como el registro de seguridad. Se guarda en la tabla propia audit_log; la exportación y el borrado RGPD la cubren.

La pestaña bajo Actividad filtra por evento o grupo de activación, usuario, dirección, objeto y rango de fechas, y las exportaciones CSV y JSON respetan el filtro activo. En una red, el administrador de red limita la lista a un sitio o a las filas de red, y cada administrador de sitio tiene una página Registro de auditoría en el menú del sitio con las filas de ese sitio. Por debajo del plan Business la pestaña muestra cinco filas de ejemplo y lo que respondería; allí no se registra nada, y el registro de seguridad de 30 días sigue disponible en todos los planes.

Control de cuentas de usuario y sesiones (Business)

Desde la versión 2.1.51, se puede bloquear una cuenta sin eliminarla: desde la página de perfil del usuario, desde la lista de usuarios (columna «Bloqueados» y acciones masivas) o mediante wp reportedip user block. El bloqueo incluye un mensaje opcional que se muestra al iniciar sesión y una nota interna que nunca se muestra al usuario.

Una cuenta bloqueada conserva todo su contenido, pero no puede iniciar sesión, ni autenticar una contraseña de aplicación, ni completar un restablecimiento de contraseña. El bloqueo cancela inmediatamente todas las sesiones y todos los dispositivos de autenticación de dos factores (2FA) de confianza, por lo que un usuario que ya haya iniciado sesión quedará desconectado en la siguiente solicitud. No se permite bloquearte a ti mismo ni a un superadministrador; en una instalación de un solo sitio, tampoco se permite bloquear al último administrador restante. El bloqueo sigue vigente incluso si caduca el plan, y el levantamiento del bloqueo nunca está sujeto a restricciones.

En «Usuarios → Sesiones» se muestran las sesiones activas de todos los usuarios que han iniciado sesión, con la hora de inicio, la fecha de caducidad, la dirección IP y el dispositivo, y se puede cerrar una sola sesión o todas las sesiones de un usuario. La propia sesión actual nunca se puede cerrar desde esta lista. Los bloqueos y los cierres de sesión se registran en el Audit Event Trail. En el modo Multisite, la página se encuentra en el panel de administración de la red, y un bloqueo se aplica a toda la red, ya que los usuarios y las sesiones de WordPress son globales para la red.

MainWP Integration

Hive se puede gestionar de forma remota desde un Dashboard de MainWP sin necesidad de ningún plugin secundario adicional ni de adquirir ninguna extensión de MainWP. Se integra con el filtro «MainWP Child» mainwp_child_extra_execution , por lo que cada tarea se autentica a través del canal existente de MainWP Child, sin credenciales adicionales ni nuevas vulnerabilidades. La configuración es muy sencilla: instala MainWP Child y Hive en el sitio gestionado, conecta el sitio a tu Dashboard de MainWP como de costumbre, y listo.

Se admiten dos tipos de tareas:

• Sincronización de métricas de seguridad, solo recuentos agregados: bloqueos activos, tamaño de la Whitelist, intentos de Login fallidos, spam en comentarios, bloqueos por reputación, tamaño de la cola, eventos críticos recientes, usuarios con 2FA habilitado. Desde la versión 2.1.6, la sincronización también informa del estado del cortafuegos (waf_enabled, waf_report_only, waf_dropin_enabled, waf_dropin_running, waf_server y un indicador derivado waf_needs_setup indicador derivado), de modo que un Dashboard puede señalar los sitios cuya «Extended Protection» está habilitada pero aún no está en funcionamiento, normalmente un host nginx que sigue esperando su fragmento de código del servidor.
• Aprovisionamiento (reportedip_hive_provision), envía una API Key a un sitio gestionado desde el Dashboard de confianza y, desde la versión 2.1.12, opcionalmente lo cambia al modo «Community Network» en la misma tarea (community indicador). El trabajo de sincronización informa del estado actual de cada sitio secundario operation_mode.

Ninguna IP, nombre de usuario, clave secreta ni API Key sale jamás del sitio gestionado; la Payload de la sincronización se limita únicamente a recuentos e indicadores de estado.

Desde la versión 2.1.47, la extensión MainWP también puede gestionar de forma centralizada la configuración de Hive: lee un esquema de configuración versionado de cada sitio, aplica una política global con modificaciones de campos específicas para cada sitio y detecta desviaciones mediante una «huella digital» de la configuración que se incluye en cada informe de sincronización. La validación siempre se realiza en el propio sitio gestionado, por clave, y los valores restringidos por el plan se omiten de forma controlada.

Gestión de flotas en la nube (Business)

En el plan Business, las mismas políticas de configuración se pueden gestionar sin MainWP, directamente desde tu Dashboard de ReportedIP en la sección «Dominios»: define una política global, anula campos concretos por sitio, aplícala con un solo clic y comprueba de inmediato cuándo un sitio se desvía de la política, incluyendo una comparación en tiempo real entre los valores objetivo y los reales por sitio.

• Participación estrictamente voluntaria. Cada sitio decide: la opción «Gestión de la flota en la nube» en la pestaña «Configuración general» de Hive está desactivada por defecto. Sin ella, el sitio rechaza todas las solicitudes de gestión.
• Solo solicitudes firmadas. Cada envío está firmado con Ed25519 por el servicio de flota de ReportedIP.com y se verifica en tu sitio web mediante una clave pública incluida en el plugin, además de contar con un plazo de validez de cinco minutos, identificadores de solicitud de un solo uso, un enlace a la propia dirección de tu sitio web y una prueba de tu Community Access Key. No hay que gestionar ninguna contraseña, token ni credencial adicional.
• Las mismas reglas que en MainWP. Ambos Dashboards utilizan el mismo protocolo de configuración; cada valor se valida en tu sitio web antes de escribirse, y los ajustes restringidos por el plan se omiten, nunca se imponen.
• Requiere Hive 2.1.48 o una versión posterior, el modo «Community Network» y un plan «Business» (o «Enterprise»).

Redes Multisite

La Full Edition es exclusiva para redes (Network: true, desde la versión 2.0.0): WordPress oculta la activación por sitio para que la configuración de seguridad se mantenga uniforme en toda la red. Las nueve tablas se encuentran en $wpdb->base_prefix, lo que hace que cada decisión sobre amenazas se aplique a toda la red, los intentos de Brute Force entre sitios se agreguen en un contador central y un único bloqueo excluya la IP de todos los subsitios a la vez.

• Los administradores de red disponen de todas las opciones de configuración, de una vista de registros de todos los sitios y del registro de auditoría con un filtro por sitio.
• Los administradores de sitio de un subsitio disponen de una interfaz de «Estado/Registros» de solo lectura, del registro de auditoría de su propio sitio (Business) y de exactamente dos ajustes editables por sitio: el slug de la 2FA en el frontend y roles adicionales con 2FA obligatoria (un subsitio puede exigir 2FA a más roles, nunca a menos).
• Cron solo se ejecuta en el sitio principal; no hay sincronizaciones duplicadas ni operaciones de limpieza por subsitio.
• WAF Exceptions son datos de toda la red, gestionados por el administrador de red.

Autenticación de dos factores (2FA)

Se admiten cuatro métodos, que se pueden combinar por usuario. Los Recovery Codes se generan durante la primera configuración. Las claves están cifradas en reposo (libsodium con OpenSSL como alternativa).

• TOTP: RFC 6238 (6 dígitos, ventana de 30 segundos). Funciona con Google Authenticator, Authy, 1Password, Bitwarden, etc.
• Correo electrónico: OTP de seis dígitos a través del proveedor de correo configurado; con Rate Limit (3 códigos cada 15 minutos, 5 intentos de verificación por código, tiempo de espera de 60 segundos para reenviar).
• SMS: OTP de seis dígitos a través del SMS Relay gestionado de ReportedIP (plan Professional y superiores; ver más abajo). El número de teléfono está cifrado en reposo.
• WebAuthn, Passkeys, llaves de seguridad (YubiKey), autenticadores de plataforma (Touch ID, Face ID, Windows Hello). Analizador CBOR propio, sin dependencias externas.
• Trusted Devices, tokens de «recordar este dispositivo» opcionales con caducidad configurable (por defecto, 30 días). Almacenados wp_reportedip_hive_trusted_devices como hash SHA-256.
• Recovery Codes: 10 códigos de un solo uso xxxx-xxxx ; aviso de nivel bajo de códigos cuando quedan ≤ 3.

Claves de seguridad de hardware (YubiKey)

Desde la serie 2.1.33–2.1.36, las llaves de hardware FIDO2 son un elemento fundamental: la serie YubiKey 5 (USB-A, USB-C, Lightning y los modelos NFC que se acercan al teléfono), la línea de llaves de seguridad de Yubico y cualquier otro autenticador CTAP2 funcionan en las tres superficies de verificación: la página intersticial de wp-login, el desafío de la tienda de WooCommerce y la página de restablecimiento de contraseña. Las llaves de seguridad más antiguas que solo admiten U2F (CTAP1) no son compatibles oficialmente.

• Para configurarlo, abre tu página de perfil (Usuarios → Perfil → Autenticación de dos factores), selecciona «Añadir llave de seguridad» → «Llave de seguridad (USB / NFC)», asigna un nombre a la llave, insértala y toca el contacto dorado cuando el navegador te lo indique. En un teléfono, mantén la llave en posición horizontal contra la parte trasera, cerca de la parte superior (NFC). No se requiere ningún PIN FIDO2 para el registro.
• Una clave por cuenta es gratuita. El plan Business incluye llaves de seguridad avanzadas: varias llaves por cuenta, la posibilidad de registrar una segunda YubiKey y guardarla en un lugar seguro como copia de seguridad, además de la detección automática del modelo («YubiKey Serie 5 con NFC» que aparece junto a la clave) y alertas por correo electrónico cada vez que se añade o se elimina una llave.
• ¿Has perdido tu llave? Inicia sesión con uno de tus Recovery Codes (o con tu clave de respaldo en el plan Business) y, a continuación, elimina la llave perdida en tu página de perfil. Al eliminar la última llave, el método queda desactivado por completo.
• Detección de clones: cada inicio de sesión aumenta el contador de firmas de la llave. Una autenticación cuyo contador no aumente se rechaza, se registra y se notifica al titular de la cuenta por correo electrónico en todos los planes.
• Algoritmos: ES256 en todas las claves; Ed25519 se negocia automáticamente en el firmware 5.2.3+ de YubiKey cuando el servidor dispone de libsodium.

Protección contra ataques de Brute Force en la autenticación 2FA

La escala del verificador de 2FA es 3 → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Cuando el recuento alcanza el escalón superior, la IP pasa a la ruta central auto_block_ip() (evento 2fa_brute_force), lo que activa una escalada progresiva y la generación de informes en modo «Community», al igual que cualquier otro sensor.

Headless 2FA REST

Para la integración con aplicaciones, el complemento expone tres rutas bajo el espacio de nombres reportedip-hive/v1:

• POST /2fa/challenge nombre de usuario + contraseña → token de desafío + métodos habilitados (20 solicitudes / 5 min por IP).
• POST /2fa/verify token + método + código → establece la cookie de autenticación (30 solicitudes / 5 minutos por IP).
• GET /2fa/methods analiza los métodos activos para el usuario actual.

Desencadenantes adaptativos de refuerzo (Professional)

Aplicar la 2FA a un rol implica solicitar el segundo factor en cada inicio de sesión. Los desencadenantes adaptativos, añadidos en la versión 2.1.51, son el término medio para el resto de usuarios: a los usuarios que hayan configurado un método solo se les volverá a solicitar cuando haya cambiado algún aspecto del inicio de sesión. La matriz se encuentra en Protección → Autenticación de dos factores → Aplicación, con una columna por disparador y una fila por rol.

• Un nuevo país, una nueva dirección IP, una nueva red (la /24 o IPv6 /64) o un nuevo dispositivo, cada uno de ellos comparado con el historial del propio usuario. La detección del país requiere el modo «Community Network»; en «Local Shield», ese desencadenante permanece inactivo.
• Cada N días desde la última verificación superada y cada N inicios de sesión, pudiendo configurarse el valor de N junto a la matriz.
• Más de N sesiones simultáneas para ese usuario.

Un desafío activado ignora la cookie de Trusted Device, que es precisamente la clave: el dispositivo es de confianza, pero las circunstancias no lo son. La Allowlist de direcciones IP para la autenticación 2FA y el reportedip_2fa_bypass filtro siguen sin aplicarse. A los usuarios que no tienen ningún método configurado nunca se les bloquea el acceso; se registra el salto (2fa_stepup_skipped_no_method) y se les recuerda que deben configurar uno. El historial es individual para cada usuario, por lo que el primer inicio de sesión tras activar un desencadenante nunca solicita un desafío, y el rol de administrador solo puede activarse una vez que un administrador haya superado un desafío en el sitio.

Login en la interfaz de WooCommerce

El Frontend 2FA en la interfaz de Hive se integra en el tema activo de tu tienda; los clientes que inician sesión a través [woocommerce_my_account], el proceso de pago clásico o los bloques de carrito y pago de WooCommerce completan su segundo factor de autenticación en una página con el tema aplicado. El estado del carrito y del proceso de pago se mantiene tras la redirección, y la cookie de Trusted Device se comparte con el flujo de Login de WordPress.

• Ruta de configuración: 2FA → Login en la interfaz de usuario para WooCommerce.
• Slugs configurables, slug del desafío (por defecto reportedip-hive-2fa) y el slug de configuración (por defecto reportedip-hive-2fa-setup); ambos son editables, se comprueba que no haya conflictos y las reglas de reescritura se vacían automáticamente al modificarlos.
• Rebaja de plan, desactivación parcial en los planes «Free» y «Contributor»; se conservan los ajustes, las opciones de slug y el estado de incorporación; no hay pérdida de datos al volver a actualizar.
• Detección de conflictos: Hive muestra un aviso de administración cuando Solid Security, el plugin WP Two-Factor o Wordfence 2FA controlan el formulario de inicio de sesión, y desactiva el desafío en la interfaz pública para evitar solicitudes duplicadas.
• Disponibilidad del plan: «Professional» y superiores. Los sensores gratuitos de fallos de Login de WooCommerce (woocommerce_login_failed, woocommerce_checkout_login_form_failed_login) se mantienen en todos los planes y siguen alimentando el contador de ataques Brute-Force.

Entrega de correo electrónico y SMS

La capa de correo funciona a través de un contrato de proveedor acoplable (ReportedIP_Hive_Mailer). El proveedor predeterminado es el de WordPress wp_mail(); los integradores pueden sustituirlo por el suyo propio sin modificar el resto del plugin. En los planes Professional y superiores, el correo transaccional (códigos de 2FA, notificaciones de seguridad) puede utilizar en su lugar el Mail Relay gestionado de ReportedIP: una infraestructura de remitente compatible con SPF, DKIM y DMARC, de modo que los correos con OTP no acaban en la carpeta de spam, como suele ocurrir con el correo no autenticado wp_mail() de un alojamiento compartido.

• La autenticación de dos factores (2FA) por SMS es una función del plan Professional que se ofrece exclusivamente a través del relé gestionado de ReportedIP.com, sin necesidad de una cuenta de SMS propia, credenciales de Twilio ni contrato con un operador. Se configura automáticamente con un plan de pago; actívala en Protección → Autenticación de dos factores → SMS. El intervalo de reenvío por destinatario aumenta gradualmente (0 s → 30 s → 1 m → 2 m → 5 m → 15 m), de modo que se puede volver a solicitar un SMS lento o no recibido sin penalización, mientras que una ráfaga real sigue estando limitada.
• Límites mensuales y paquetes de prepago. El plan PRO incluye 25 SMS / 500 correos electrónicos al mes; el plan Business, 75 / 2.500 (por licencia). Los paquetes de prepago amplían estas cuotas; consulta la tabla de planes anterior para ver los precios y el apartado sobre el orden de consumo de los paquetes para saber exactamente qué ocurre cuando se agota una cuota (spoiler: el correo vuelve a utilizar el sistema local wp_mail(), y ningún método de 2FA deja de funcionar).
• Plantillas de correo con marca personalizada (Business y superiores). El plan Business permite personalizar el correo transaccional White-label: tu logotipo, colores e identidad del remitente en los correos de 2FA y de notificación, en lugar de la marca ReportedIP, a juego con el inicio rápido y las páginas de 2FA White-label.

Resumen de la configuración

Todos los ajustes están en una sola página, ReportedIP Hive → Protección: catorce tarjetas, una por área, cada una con un estado breve, un buscador que abre la tarjeta correspondiente y dos profundidades. La vista simple muestra los dieciséis ajustes del día a día; el interruptor de experto en la cabecera muestra todos los campos. Lo que no es un ajuste (el drop-in de protección ampliada, los fragmentos de servidor, la sincronización de reglas, las excepciones, importar/exportar, el correo de prueba) está en Herramientas, visible en el menú en modo experto y siempre accesible por URL. Cada opción está en un único registro canónico, incluye una descripción de una sola frase y se depura en un solo lugar, de modo que la página de Protección, el formulario de MainWP y la flota en la nube muestran el mismo campo con el mismo texto, y el inicio rápido escribe a través del mismo registro. Cada opción del registro se puede gestionar de forma remota. Solo unas pocas permanecen locales por diseño: la identidad de conexión (modo de funcionamiento, clave API, endpoint), la propia activación de la gestión remota, el interruptor de borrado de datos al desinstalar, el interruptor maestro del Hardening Mode (su estado «sin valor almacenado» es lo que activa el refuerzo automáticamente a partir del plan Professional) y el interruptor de protección ampliada, que necesita una directiva del servidor junto a él.

Los valores predeterminados más importantes:

Tablas de la base de datos

Nueve tablas, creadas al activar el plugin y con el prefijo wp_reportedip_hive_. Versión del esquema 17, con migración idempotente paso a paso en cada actualización del plugin; eliminación opcional al desinstalar. La migración v16 se incluyó con la versión 2.1.50 y elimina los umbrales de bloqueo por reputación que se almacenaban por debajo del mínimo del 25 %, de modo que la pantalla de configuración muestra lo que realmente se aplica. En Multisite, todas las tablas se encuentran en $wpdb->base_prefix , de modo que las decisiones sobre amenazas se aplican a toda la red. La migración v17 llegó con la 2.1.62 y añade las columnas de objeto del registro de auditoría.

• logs eventos de seguridad, detalles en JSON, gravedad, indicador de notificación; la fuente de los análisis del Dashboard (tendencias de 7, 30 y 90 días, desgloses por familia y gravedad, principales atacantes).
• whitelist IP de confianza y rangos CIDR; caducidad opcional.
• blocked bloqueos activos (manuales / automáticos / por reputación), con blocked_until.
• attempts contadores por IP y por tipo de intento, con marcas de tiempo de primer/último intento; operación «upsert» atómica a prueba de conflictos en una clave única (IP, tipo de intento) desde la versión v15 del esquema.
• api_queue Informes pendientes y fallidos a la API de la comunidad; lógica de reintentos.
• stats Agregados diarios (Logins fallidos, bloqueos, spam, XML-RPC, reputación) para resúmenes de tendencias e informes.
• trusted_devices Tokens de dispositivos 2FA (hash SHA-256), IP y nombre del dispositivo, caducidad.
• audit_log registro de auditoría de solo adición sobre quién cambió qué (Business); añadido en el esquema v9, columnas de objeto desde el esquema v17.
• waf_exceptions Lista de permitidos del WAF gestionada por el backend (ámbito de regla / grupo / ruta, IP/CIDR opcional); añadida en el esquema v10, para toda la red.

Códigos cortos de front-end y pie de página automático

Incrusta una pequeña insignia «protegido por Hive» en cualquier lugar del sitio. Todos los códigos cortos generan un único <rip-hive-banner> componente web y obtienen cifras en tiempo real de una caché transitoria de 6 horas (sin llamada a la API por cada visita a la página).

• [reportedip_badge] pequeña insignia (tono de protección predeterminado).
• [reportedip_stat] una única estadística (tono de confianza por defecto).
• [reportedip_banner] banner ancho (tono «comunidad» por defecto).
• [reportedip_shield] icono de escudo (tono predeterminado de Contributor).

Atributos comunes: stat (p. ej. attacks_30d, reports_total), tone (protect / trust / community / contributor), color, background, label, intro. El pie de página automático que activa el inicio rápido utiliza el mismo componente con una variante y una alineación configurables.

Referencia de WP-CLI

Las herramientas de 2FA, el Hardening Mode y (desde la versión 2.1.41) la búsqueda de direcciones IP de la comunidad son totalmente programables:

wp reportedip 2fa status [--user=<id>]
wp reportedip 2fa enable <user_id> --method=<totp|email|sms|webauthn> [--secret=<base32>]
wp reportedip 2fa disable <user_id> [--method=<m>]
wp reportedip 2fa reset <user_id>
wp reportedip 2fa enforce --role=<role> [--remove]
wp reportedip 2fa audit [--user=<id>] [--since=<date>]
wp reportedip 2fa cleanup
wp reportedip hardening <status|activate|deactivate>
wp reportedip lookup <ip> [--format=<table|json|csv|yaml>]
wp reportedip status [--format=<table|json|csv|yaml>]
wp reportedip user block <user> [--message=<text>] [--note=<text>]
wp reportedip user unblock <user>
wp reportedip user list [--format=<table|json|csv|yaml>]

wp reportedip status reports el modo de funcionamiento, el plan y, a partir de la versión 2.1.51, incluye un issues campo que enumera los problemas de disponibilidad pendientes como key (severity), lo que permite utilizarlo como sonda de monitorización. Los user comandos requieren un plan Business para el bloqueo; el desbloqueo siempre funciona.

Compatibilidad con el complemento de caché

Desde la versión 1.5.2, la respuesta de página bloqueada define DONOTCACHEPAGE, DONOTCACHEDB y DONOTCACHEOBJECT (respetado por WP Rocket, W3 Total Cache, WP Super Cache y LiteSpeed Cache) y emite Cache-Control: no-store, no-cache, must-revalidate, max-age=0, Pragma: no-cache además del conjunto del núcleo de WordPress nocache_headers() . Un único atacante bloqueado ya no puede contaminar la caché de la página con un 403 que, de otro modo, recibirían los visitantes legítimos hasta que caducara la caché.

Filtros y ganchos de acción

• apply_filters('reportedip_hive_external_url', $url, $context) sustituyen cualquiera de las URL externas (política de privacidad, registro, FAQ, etc.).
• apply_filters('reportedip_hive_rest_bypass_routes', $routes) Amplía la lista de prefijos de rutas REST que eluden el monitor de ráfagas (integraciones de banners de cookies).
• apply_filters('reportedip_hive_scan_paths', $paths) Amplían la lista de rutas de Honeypot para el detector de escaneos.
• apply_filters('reportedip_hive_decoy_paths', $paths) Amplía la lista de rutas señuelo.
• apply_filters('reportedip_hive_waf_bypass_routes', $routes) Excluye rutas REST del WAF a nivel de código (coincidencia de prefijo anclado con la ruta resuelta; vacía por defecto). Da prioridad a las excepciones del WAF gestionadas por el backend para False Positives puntuales.
• apply_filters('reportedip_hive_mail_provider', $provider) Sustituir por su propio proveedor de correo electrónico (implementar interface-mail-provider.php).
• apply_filters('reportedip_hive_blocked_page_strings', $strings, $context) anular los textos que ven los visitantes en la página de bloqueo 403 (White-label; claves doc_title, title, message, reason). Desde la versión 2.1.41.
• apply_filters('reportedip_hive_reputation_block_hours', 24) / apply_filters('reportedip_hive_tor_block_hours', 24) Duración de los bloqueos temporales por reputación y de los nodos de salida de Tor.
• do_action('reportedip_hive_threshold_exceeded', $ip, $event_type, $details) Se activa con cada detección confirmada por un sensor, independientemente de la configuración de bloqueo automático y de notificaciones. Desde la versión 2.1.41.
• do_action('reportedip_hive_ip_blocked', $ip, $reason, $blocked_until) se activa cuando se bloquea una IP; $blocked_until es una fecha y hora en UTC o null en el caso de bloqueos permanentes.
• do_action('reportedip_hive_ip_unblocked', $ip) se activa cuando se levanta un bloqueo.
• do_action('reportedip_hive_report_queued', $ip, $category_ids, $report_type) Se activa una vez por cada informe que entra en la cola de la API (ID de categoría separados por comas; negative o positive).
• do_action('reportedip_hive_access_denied', $ip, $context) se activa justo antes de que se muestre la página de bloqueo 403. Desde la versión 2.1.41.
• do_action('reportedip_hive_2fa_verified', $user_id, $method) se activa tras superar un desafío de dos factores, tanto en el formulario de Login como en el Endpoint REST de verificación. Desde la versión 2.1.51, la wp_login también se activa allí: hasta entonces solo se activaba para los Logins que nunca habían pasado por una verificación, lo que hacía que el sensor de anomalías geográficas, el correo de nuevo dispositivo, el registro de auditoría y el recordatorio de 2FA no detectaran ningún Login con verificación.
• apply_filters('reportedip_hive_reputation_threshold_floor', 25) Aumenta el umbral mínimo del 25 % para el bloqueo por confianza de la comunidad. No es posible reducirlo.
• apply_filters('reportedip_hive_2fa_bypass', false, $user) Omite el segundo factor para un usuario, lo cual también respetan los desencadenantes adaptativos de refuerzo.

Preguntas frecuentes

Las preguntas que nos hacen con más frecuencia. Cada respuesta incluye un enlace a la sección correspondiente más arriba, cuando procede.

General

Instalación y configuración

Modos y sensores

2FA

Rendimiento y compatibilidad

Privacidad y RGPD

Personalización y ampliación

add_filter('reportedip_hive_rest_bypass_routes', function ($routes) {
    $routes[] = '/my-consent-plugin/v1';
    return $routes;
});

add_filter('reportedip_hive_scan_paths', function ($paths) {
    $paths[] = '/.aws/credentials';
    return $paths;
});

Cuotas, planes y cuenta

Solución de problemas

El complemento no bloquea ninguna dirección IP

Comprueba si está activado el «Report-Only Mode», que registra las amenazas sin bloquearlas. Comprueba también que el umbral de bloqueo no esté fijado demasiado alto (por defecto, 75 %) y que el «Bloqueo automático» esté activado (la estrategia de duración queda desactivada mientras el bloqueo automático está desactivado).

El mapa del sitio del usuario ha desaparecido tras la actualización

Un plugin, una aplicación o un feed ha dejado de funcionar tras activar un interruptor de bloqueo

Abre Protección → Cabeceras de seguridad y desactiva de nuevo el interruptor sospechoso; el cambio es inmediato. Casos típicos: una aplicación móvil o un servicio tipo Jetpack que aún utiliza XML-RPC, un front-end sin interfaz gráfica o un plugin de editor de bloques que llama a la REST API sin haber iniciado sesión (añade su espacio de nombres a la Allowlist en lugar de volver a abrir la API), un servicio de podcasts o boletines informativos que lee el feed RSS, y un proveedor de pagos que realiza envíos a /wp-admin/. La página «Actividad» enumera cada rechazo con su ruta en «Cortafuegos», para que puedas identificar al solicitante antes de cambiar nada. Un registro rechazado inesperadamente se registra en «Registro» junto con la regla que se ha aplicado.

Errores de conexión a la API en el modo «Community Network»

Asegúrate de que tu servidor pueda realizar solicitudes HTTPS salientes a reportedip.com. Algunos servidores bloquean las conexiones salientes de forma predeterminada. Comprueba la API Key en el Dashboard.

Se bloquea a los visitantes del banner de cookies

Desde la versión 1.5.0, los cuatro espacios de nombres de consentimiento habituales (real-cookie-banner, complianz, borlabs-cookie, cookie-law-info) se omiten de forma predeterminada. Si tu pila utiliza un espacio de nombres diferente, amplía la lista de omisiones a través del reportedip_hive_rest_bypass_routes filtro.

Se bloquea a usuarios legítimos

Añade sus direcciones IP o rangos CIDR a la Whitelist local. Las IP incluidas en la Whitelist nunca se bloquean, independientemente de su reputación.

¿Te has quedado sin acceso? (tu propia IP bloqueada, wp-admin inaccesible)

Si tu propia IP ha acabado en la lista de bloqueados y no puedes acceder a wp-admin, puedes restablecer el acceso directamente en la base de datos, a través de phpMyAdmin o de la consola de la base de datos de tu proveedor de alojamiento. Utiliza preferentemente la interfaz de administración (el formulario de la Whitelist cuenta con la opción «Añadir mi IP» desde la versión 2.1.41) siempre que sea accesible; la ruta directa a la base de datos es la salida de emergencia, no la herramienta habitual, ya que elude la validación del plugin.

Añade tu IP pública actual a la tabla de la Whitelist; las direcciones incluidas en la Whitelist tienen prioridad sobre cualquier bloqueo:

INSERT INTO wp_reportedip_hive_whitelist (ip_address, ip_type, reason, added_by, is_active)
VALUES ('203.0.113.42', 'ipv4', 'Self-rescue: restore admin access', 1, 1);

Utiliza 'ipv6' o 'cidr' como ip_type para una dirección IPv6 o un rango; para prefijos IPv6 residenciales rotativos, incluye en la lista Whitelist tu red /64 como 'cidr'. added_by es tu ID de usuario de WordPress (1 para la primera cuenta de administrador). Como alternativa, elimina tu fila de la tabla de bloqueo:

DELETE FROM wp_reportedip_hive_blocked WHERE ip_address = '203.0.113.42';

Sustituye el wp_ prefijo por el prefijo real de tu tabla de wp-config.php si difiere (en Multisite, las tablas del plugin utilizan el prefijo base). El cambio surtirá efecto en la siguiente solicitud. Si Extended Protection (el filtro previo a WordPress) está activa y el bloqueo persiste, elimina también el archivo de la lista de bloqueados almacenado en caché wp-content/uploads/reportedip-hive/blocked-*.list el filtro tiene un comportamiento de «fail-open» y el archivo se recrea automáticamente en la siguiente sincronización.

El cortafuegos bloquea una solicitud legítima (False Positive del WAF)

Abre Actividad, busca el bloqueo en el registro (el X-RIP-Ref de la página bloqueada coincide con una entrada del registro) y haz clic en Permitir; esto creará una excepción específica para esa regla concreta en esa ruta. Consulta WAF Exceptions para obtener orientación sobre el alcance. Las excepciones también se aplican al filtro de «Extended Protection» previo a WordPress.

Extended Protection está activada pero muestra «no se está ejecutando»

Es habitual en servidores con nginx donde no se detecta la directiva .user.ini no se tiene en cuenta (p. ej., user_ini.filename está desactivada, o la raíz de documentos no es la ruta de análisis). La pestaña «Firewall» → «Configuración del servidor» muestra las opciones manuales: la línea del grupo de PHP-FPM / php.ini auto_prepend_file o el fragmento de código de nginx fastcgi_param . El estado se puede verificar, ya que indica si la protección se ha ejecutado realmente para la solicitud actual. El motor integrado en WordPress protege el sitio en cualquier caso; el complemento solo adelanta las mismas comprobaciones.

Alto uso de la API / agotamiento de comprobaciones

Las respuestas se almacenan en caché localmente (con ETag) durante 24 horas de forma predeterminada. Si sigues agotando las comprobaciones, aumenta cache_duration o amplía tu plan. Supervisa la cola y la cuota en el Dashboard.

Bloqueo por la autenticación de dos factores (2FA)

Utiliza uno de los Recovery Codes guardados durante la configuración de la 2FA. Si los has perdido, un administrador puede restablecer la 2FA para cualquier usuario en Usuarios → 2FA. Como último recurso: wp reportedip 2fa reset <user_id>.

Desde la versión 2.1.22, un usuario al que se le ha impuesto la 2FA y que nunca la ha configurado ya no queda bloqueado de forma predeterminada: una vez agotados el periodo de gracia y los intentos permitidos, se le permite el inicio de sesión y se le envía directamente a la inscripción obligatoria (sin opción de saltarse el proceso). Los administradores y los superadministradores de Multisite nunca pueden quedar bloqueados de forma definitiva, incluso si se vuelve a activar la política «Bloquear inicio de sesión».

El editor de bloques (Gutenberg) sigue sufriendo limitaciones de rendimiento

El editor de bloques realiza más de 50 llamadas REST en pocos segundos. Desde la versión 1.2.2, los usuarios que han iniciado sesión no se ven afectados por el controlador global de picos de tráfico REST; solo se contabilizan los picos de tráfico de los usuarios anónimos. Asegúrate de que utilizas la versión 1.2.2 o una posterior.

RGPD y privacidad

El plugin está diseñado teniendo en cuenta la privacidad y es GDPR Compliant.

• Modo «Local Shield»: ningún dato sale de tu servidor. Toda la detección y el bloqueo se realizan de forma local.
• Modo «Community Network»: se comparten la IP del atacante, la Threat Category y la marca de tiempo, y cada solicitud identifica la propia instalación (dirección del sitio, versión del plugin/WordPress; datos que se utilizan para el recuento de dominios de la licencia y la asistencia técnica). No se comparten nombres de usuario, contraseñas, contenido de comentarios ni datos de los usuarios finales.
• Los agentes de usuario se truncan a 50 caracteres antes de su almacenamiento.
• Limpieza automática: los registros de seguridad se eliminan tras el periodo de retención configurado (por defecto, 30 días). La anonimización automática se activa antes (por defecto, 7 días).
• Cifrado en reposo: las claves TOTP, las credenciales de WebAuthn y los números de teléfono de SMS se cifran con libsodium (con OpenSSL como alternativa).
• Sin seguimiento de visitantes: sin cookies, sin píxeles de seguimiento. La única telemetría es la identidad de la instalación (dirección del sitio, versión del plugin/WordPress) enviada con las solicitudes de la API en modo «Community», datos sobre tu instalación, nunca sobre tus visitantes.
• Integración con las herramientas de privacidad de WordPress: Hive registra un exportador y un borrador de datos personales en el núcleo de WordPress, por lo que las solicitudes de Herramientas → Exportar/Borrar datos personales incluyen automáticamente los registros de Hive correspondientes al tema solicitado (filas de registro, Trusted Devices, entradas del registro de auditoría). También aporta un párrafo sugerido a la guía de la política de privacidad de WordPress (Protección → Privacidad y registros → Guía de la política) que puedes copiar en tu propia política.
• Código abierto: El código fuente completo está publicado en GitHub; cada línea es auditable.

Aspectos destacados del Changelog

• 2.1.62: El registro de auditoría recoge quién cambió qué: ocho grupos de activación (cuentas, páginas y entradas, plugins y temas, ajustes con valor antiguo y nuevo, menús y widgets, el editor de archivos, la red) con el usuario que actuó, la vía de la petición y el objeto afectado, un interruptor por grupo, 90 días de retención por defecto con limpieza por bloques, un filtro por sitio para redes y una página Registro de auditoría para cada administrador de sitio. Cada tipo de evento vive en un único registro; el filtro del registro de eventos se puede buscar y selecciona grupos completos, y el spam de formularios vuelve a los gráficos.
• 2.1.58–2.1.61: La prueba de ejecución de formularios puede exigir un cálculo (Professional), un sustituto del captcha que sus propios formularios usan mediante una pequeña API; Contact Form 7 y Ultimate Member están cubiertos en Professional, Formidable Forms y Elementor Forms en Business; el filtro de spam de comentarios lee ocho señales más; los ajustes de formularios tienen su propia tarjeta y cada ajuste indica el plan al que pertenece.
• 2.1.57: La página Actividad abre en el registro de eventos tras una barra de filtros que se puede guardar como marcador, la página Comunidad se divide en Ajustes, Comunidad e Insignias (insignia de pie de un clic y generador de banners), el panel lleva una sola línea de estado y áreas de protección plegadas, y los avisos sobre la cola de informes callan mientras nada pueda enviarla. Una clave rechazada ya no cuenta como intento fallido en la ventana de salud de la API.
• 2.1.56: Las páginas Ajustes y Cortafuegos fueron sustituidas por una página de Protección (una tarjeta por área del registro, buscador, profundidad sencilla y experta, un servicio de guardado compartido con MainWP, la flota y la importación) y una página de Herramientas para el drop-in, la sincronización de reglas, las excepciones del WAF, importar, exportar, reiniciar y el correo de prueba. El panel ganó un banner de estado, tarjetas de siguiente paso desde seis detectores informativos y una fila por área de protección. Las direcciones antiguas redirigen.
• 2.1.54–2.1.55: El asistente de instalación se convirtió en un inicio rápido de una página que lee el plan de la comprobación de la clave y activa una recomendación acorde a través del registro de configuración; una mejora de plan posterior activa lo que el nuevo plan recomienda para los valores sin tocar. Cada ajuste guardado sigue ahora un único estándar y el panel muestra las últimas noticias de reportedip.com en el idioma del administrador.
• 2.1.52–2.1.53: Defensa de comentarios y formularios. Un filtro de spam puntuado con unas veinte señales (un comentario a la espera de moderación ya no es un veredicto de spam), una prueba de ejecución resistente a la caché en los formularios de comentario, registro y restablecimiento, y la consulta de reputación comunitaria ampliada de la página de acceso a esos mismos tres formularios. Gratis en todos los planes.
• 2.1.51: Cinco nuevas protecciones. Defensa del registro (nombres de usuario prohibidos, reglas de correo electrónico, un límite de registro por IP, un bloqueo de acceso para inicios de sesión con nombres de usuario que no existen), controles de bloqueo de acceso para REST, XML-RPC, feeds, wp-admin, PHP en subidas y huellas de versión, y un registro de preparación del sistema con doce detectores, todo ello gratuito en todos los planes. Bloqueo de cuentas y del gestor de sesiones en Usuarios → Sesiones en el plan Business; desencadenantes adaptativos de refuerzo de dos factores por rol en el plan Professional. Se han trasladado setenta opciones al registro de configuración (169 en total, todas descritas, 71 gestionables de forma remota); la importación de configuraciones ya no puede eludir el sanitizador, y Hardening Mode ahora también limita los umbrales en las superficies de Login de WooCommerce y de contraseñas de aplicación.
• 2.1.48–2.1.50: Gestión de flotas en la nube (Business) a través de tres rutas REST firmadas con Ed25519 con una ventana de vigencia, ID de solicitud de un solo uso y vinculación de audiencia; activación opcional y desactivada por defecto. Un umbral mínimo del 25 % por debajo del umbral de bloqueo de confianza de la comunidad, con la migración a la v16 que elimina los valores mínimos almacenados, y gestión completa de IP en WP-CLI (whitelist, block, unblock, blocked list, attempts reset) junto con wp reportedip status.
• 2.1.42–2.1.47: La auditoría de seguridad y corrección: admin-ajax.php realizada dentro de la puerta de bloqueo y el cortafuegos, códigos TOTP de un solo uso, una excepción del WAF que ya no oculta las reglas que hay detrás, sondas codificadas en porcentaje detectadas por tres sensores más y cuarenta y dos controladores AJAX en un guardián de permisos compartido. Además, una identidad de instalación al estilo de wp.org en cada solicitud de API, una ficha de dominios con licencia en el Dashboard, el registro de configuraciones canónicas con su protocolo remoto versionado y las actualizaciones de plugins visibles de nuevo para MainWP y ManageWP.
• 2.1.37–2.1.41: Bloqueo opcional de nodos de salida de Tor (Professional, conjunto de reglas firmado tor_exits ), rangos de origen de proxies de confianza contra el Spoofing de encabezados reenviados, un widget de seguridad en el Dashboard de wp-admin, un veto de «bloqueo nulo» para la infraestructura verificada por la comunidad, una búsqueda de IP más completa con wp reportedip lookup, ganchos de integración estables (reportedip_hive_threshold_exceeded), contadores de intentos a prueba de conflictos (esquema v15), además de un cortafuegos más estricto: las exenciones para rastreadores requieren una señal verificable, los grupos de reglas de Payload bloquean al primer impacto, las compilaciones de lanzamiento vuelven a incluir los conjuntos de reglas integrados y cuatro reglas cierran la cadena de la pantalla de inicio de sesión CVE-2026-64638 (XSS2Shell). El dominio se ha trasladado a reportedip.com.
• 2.1.33–2.1.36: Compatibilidad oficial con YubiKey y llaves de seguridad de hardware: procedimientos completos de WebAuthn en las tres superficies de verificación, un gestor de claves múltiples con detección de modelos basada en certificación (Business), detección de claves clonadas mediante regresión del contador de firmas con alertas por correo en todos los planes, Ed25519 cuando libsodium está disponible, y una sección de 2FA en lenguaje sencillo rediseñada con un método predeterminado seleccionable por el usuario.
• 2.1.26–2.1.32: Verificación cruzada de rastreadores verificados (un agente de usuario Googlebot Spoofing no compra nada), un mecanismo central de protección que nunca bloquea a un bot verificado, bloqueos basados en la reputación de la comunidad que cubren todas las superficies, prevención del autobloqueo para las propias direcciones del servidor, Block Escalation ponderada por volumen y la mejora de rendimiento: de 36 a 11 consultas por solicitud, lectura de un encabezado de Blocklist de 8 KB y TTFB del Dashboard de 920 a 278 ms (esquema v13).
• 2.1.25: El WAF bloquea la clase de ataques de confusión de rutas REST del núcleo de WordPress en todos los planes (reglas estructurales, no coincidencia de tokens), inspecciona una copia descodificada del cuerpo de la solicitud (cerrando una vía de elusión del Payload codificado) y los bloqueos de Paranoia-Level 2/3 muestran su categoría de referencia específica.
• 2.1.22–2.1.24: La autenticación de dos factores (2FA) obligatoria pasa a ser de inscripción forzada en lugar de bloqueo (los administradores y superadministradores nunca pueden quedar bloqueados de forma definitiva); el envío duplicado del desafío de 2FA ya no deja a los usuarios en el estado «sesión caducada»; la prueba de RCE de PHPUnit eval-stdin.php (CVE-2017-9841) queda bloqueada en todos los planes.
• 2.1.14–2.1.20: Corrección del alojamiento en producción: fechas y horas coherentes con UTC (el bloqueo automático fallaba de forma silenciosa en servidores de bases de datos que no utilizaban UTC), Hide Login funciona detrás de las cachés de página y en sitios con barra final o que utilizan Nginx, Extended Protection se configura automáticamente en nginx + PHP-FPM y omite la inspección del cuerpo para los editores que han iniciado sesión, la salud de la API utiliza una ventana móvil y se ha eliminado el sondeo de cuotas de retransmisión en rutas de alto tráfico.
• 2.1.9–2.1.13: WAF Exceptions gestionadas por el backend con una acción de «Permitir» con un solo clic (esquema v10), registro de bloqueos autoexplicativo (valor coincidente, destino, método, URI, agente de usuario), el aprovisionamiento de MainWP puede cambiar los sitios al modo «Comunidad», y el Dashboard de seguridad se ha convertido en una vista analítica completa (siete familias de amenazas, gráfico de grupos de reglas del WAF, principales atacantes).
• 2.1.0–2.1.8: El lanzamiento del cortafuegos: un «Rule Delivery Framework» (marco de entrega de reglas) proporcionado por el servidor y firmado con Ed25519 que alimenta un Web Application Firewall (WAF) que inspecciona las solicitudes (motor gratuito + configuración básica «Paranoia-Level-1», nivel PRO 2/3 mediante Priority Sync), Verified Bot Detection, Disposable-Email Blocking, Comment Honeypot, Security Headers (básicos gratuitos, avanzados PRO), Protection & Hardening Score en el Dashboard, códigos de referencia de la página de bloqueo (X-RIP-Ref), el Audit Event Trail empresarial (esquema v9), MainWP Integration y un área de administración del cortafuegos, seguido de correcciones de False Positives para rastreadores legítimos y la eliminación a prueba de fallos mediante «drop-in».
• 2.0.x: Activación Multisite en toda la red (Network: true), gestión de niveles por blog, banners de actualización de nivel, monitores de contraseñas de aplicaciones y anomalías geográficas reforzados, Frontend 2FA en la interfaz de usuario de WooCommerce disponible a partir de PRO+, Hardening Mode para ataques coordinados y detección e informe de rutas señuelo.
• 1.5.2: Compatibilidad con plugins de caché en la página 403; la limitación de la autenticación de dos factores (2FA) pasa a ser un bloqueo de escalación real; init prioridad 1.
• 1.5.1: Mayor claridad en la pestaña de bloqueo (Solo informar > Bloqueo automático > estrategia de duración); intercambio en línea de los editores de longitud fija y de escalera.
• 1.5.0: Progressive Block Escalation (escalera de 5 m → 7 d); los Endpoints del banner de cookies se omiten por defecto; se han relajado los valores predeterminados para los errores 404 y el spam en los comentarios.
• 1.2.4: El botón «Reintentar» de la cola de la API ahora realmente activa la llamada a la API.
• 1.2.0: Siete nuevos sensores: monitor de contraseñas de aplicaciones, monitor de ráfagas REST, bloqueo de User Enumeration, detector de errores 404 y escaneos, anomalías geográficas, solidez de contraseñas y ocultación de la URL de inicio de sesión.
• 1.1.0: Sistema de envío de correos centralizado con plantilla de marca.
• 1.0.0: Lanzamiento público inicial: bloqueo de IP, 2FA con 4 métodos, Setup Wizard, tablas de listas.

Historial completo: Changelog.md en GitHub.

¿Buscas la edición más ligera?

Última actualización: 20. septiembre 2026 · Mantenido por el equipo de ReportedIP