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—, 2FA con cuatro métodos, Progressive Block Escalation y conjuntos de reglas de cortafuegos firmados y entregados por el servidor. Código abierto, publicado bajo licencia GPLv2+ en GitHub.

Instalación

Setup Wizard (10 pasos)

El asistente se ejecuta al activarlo por primera vez y se puede volver a iniciar en cualquier momento desde la configuración del plugin. Cada paso se guarda inmediatamente en el servidor en cada navegación (incluido el botón «Atrás»), por lo que puedes detenerlo y reanudarlo sin perder ninguna configuración.

Modos de funcionamiento

Dos modos: cambia entre ellos en cualquier momento sin perder los datos locales.

Qué incluye cada nivel

El plugin Hive en sí mismo es totalmente funcional en el Free tier: 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 de la Community Network. Consulta la página de precios para ver la comparación completa y realizar la actualización.

La versión Business admite reservas múltiples. Todas las cifras de la versión Business indicadas anteriormente corresponden a una sola licencia. Reserva la versión Business x2, x5, x10 o x20 al finalizar la compra (o cámbiala más tarde en el Portal de clientes de Stripe) y las comprobaciones/Reports diarios, la asignación mensual de correos electrónicos y 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 Unlimited (uso razonable) y nunca se multiplican.

Orden de consumo del paquete (PRO y Business): primero se agota el límite mensual incluido (25 SMS / 500 correos 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 de estado 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 la PAngV); Stripe Tax gestiona automáticamente la facturación inversa 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 aplica init con prioridad 1 para que otros complementos no se ejecuten en caso de una IP bloqueada.

1. Whitelist: las direcciones IP y los rangos CIDR de confianza siempre tienen acceso permitido (tu oficina, servicios de monitorización, etc.).
2. Lista de bloqueo local: direcciones IP que has bloqueado manualmente o que han superado los umbrales locales. Almacenadas en wp_reportedip_hive_blocked.
3. The Web Application Firewall (WAF): the active ruleset of the WAF is compared with the URI, query, body, and user agent; if there is a match, it is blocked through the shared, reference-coded 403 path. It takes into account Whitelists and content authors to avoid False Positives. Un complemento opcional previo a WordPress puede ejecutar esta capa incluso antes de que se cargue WordPress.
4. Contadores de intentos: los contadores de Login, comentarios, XMLRPC, ráfagas REST y 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.

The Sixteen Attack Sensors

Cada sensor se puede activar o desactivar y ajustar de forma independiente en Ajustes → Protección. Las dos últimas filas —Block Escalation y el puente de Login de WooCommerce— son mecanismos complementarios que siguen el mismo flujo en lugar de ser sensores independientes: Block Escalation 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 Ajustes → Bloqueo → Progressive Block Escalation. El paso «Protección» del asistente muestra el interruptor principal, de modo que las instalaciones nuevas tienen en cuenta la escalada 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 si coincide el waf con el 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 ataques ReDoS (retroceso PCRE limitado, comportamiento «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.com: entregadas por el servidor, versionadas, firmadas con Ed25519 y distribuidas por niveles en cuatro conjuntos de reglas (waf, bot_signatures, disposable_domains, scan_paths). El complemento verifica cada conjunto de reglas con una clave pública incluida antes de aplicarlo y siempre recurre a un conjunto de reglas de referencia incluido, 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 lanzar una nueva versión del complemento.

• Gratis en todos los planes: el motor WAF y el conjunto de reglas de referencia «OWASP Top 10 - Paranoia Level 1», totalmente utilizables sin conexión en el modo «Local Shield» a partir de la línea de base incluida.
• Priority Sync (plan Professional y superiores): los conjuntos de reglas más completos, actualizados con frecuencia y firmados de «Paranoia Level 2/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. El plan Free sincroniza la línea de base incluida; el plan Contributor, semanalmente; y los planes 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 abarca todos los Endpoints de PHP independientemente de los bloques de nginx location (desde la versión 2.1.17); las pilas sin una SAPI de PHP FastCGI se configuran mediante una línea de php.ini o del 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 tiene en cuenta 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), de modo que una directiva que quede en un archivo php.ini o en una configuración de nginx editada manualmente nunca podrá apuntar a un archivo que no exista y provocar un error 500 en el sitio. Desactivar el motor WAF o cambiar al modo de solo informe también neutraliza el filtro automáticamente.
• 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 emite 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 y el estado en tiempo real se encuentran en el menú dedicado al cortafuegos: un Dashboard de «Visión general» (estado por módulo, contadores de 7 días, eventos recientes del cortafuegos), una pestaña «WAF» (motor / modo / selector de «Paranoia Level»), una pestaña de «Verificación de bots», una pestaña de «Defensa contra el spam» (correo electrónico desechable + honeypot), una vista del estado de «Rule Sync» y una pestaña de «Configuración del servidor» que reúne todos los fragmentos de código del servidor web en un solo lugar.

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 cargas útiles 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. Cortafuegos → WAF → 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 saberse de memoria el ID de la regla—.
• Ámbitos de aplicación. Una excepción se aplica a una sola regla (por ID de regla, extraído 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 un rango de IP o 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, el URI y el agente de usuario (desde la versión 2.1.11), de modo que puedes 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 vuelven a integrar 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 Honeypot

• Verified Bot Detection (Free). Confirma que una solicitud que afirma ser de Googlebot, Bingbot u otro rastreador procede realmente de ellos: primero se realiza una comparación sin DNS con los rangos de IP oficiales del rastreador (Priority Sync) y, a continuación, se recurre a un 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 (Free). Comprueba la dirección en el momento del registro (WordPress y WooCommerce) cotejándola con la lista de correos desechables. Tres modos: desactivado / monitorizar / bloquear. Los relés de privacidad (Apple «Ocultar mi correo electrónico», Firefox Relay, …) constituyen una categoría distinta que se deja pasar por defecto. La lista en tiempo real se basa en Priority Sync.
• «Comment Honeypot» (Free). Un campo señuelo invisible, excluido de 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.

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 (Free) — 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 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 Free tier también puede alcanzar la máxima calificación.

Dashboard de seguridad y análisis

El Dashboard principal se abre con una barra de titulares: ataques bloqueados en los últimos 30 días, ataques bloqueados hoy, 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 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 periodo 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, cross-site scripting, recorrido de rutas, Log4Shell, agentes de usuario de escáneres, etc.).
• Desglose por gravedad. Recuentos de «Crítico», «Alto», «Medio» y «Bajo», para que el volumen de incidentes graves nunca quede oculto tras 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).

Todos los recuentos son reales en todos los planes: el Dashboard refleja lo que su sitio web ha bloqueado realmente. Los planes Professional y Business plan añaden análisis más detallados (historial y retención de registros más amplios, ubicación geográfica de los atacantes y el registro de auditoría conforme a las normas de cumplimiento que se describe a continuación).

Audit Event Trail (Business)

Un registro del ciclo de vida del usuario de solo adición —Logins, intentos fallidos de Login, restablecimientos de contraseña, actualizaciones de perfil, cambios de rol (incluido el usuario en funciones), registros y detección de nuevas direcciones IP— con filtros, exportación a CSV / JSON, integración con WordPress para la exportación y supresión de datos conforme al RGPD, y limpieza de la retención (1 año en el plan «Business», configurable en el plan «Enterprise»). Almacenado en la audit_log (esquema v9). Los registros de seguridad estándar de 30 días siguen estando disponibles en todos los planes; el registro de auditoría es el registro de cumplimiento normativo adicional.

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 , de modo que cada tarea se autentica a través del canal existente de MainWP Child: sin credenciales adicionales ni nuevas vulnerabilidades. La configuración es sencilla: instala MainWP Child y Hive en el sitio gestionado, conecta el sitio a tu Dashboard de MainWP como de costumbre, y listo.

Se gestionan 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á activada pero aún no está en funcionamiento —por lo general, un host nginx que todavía está 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 cambia a modo «Community Network» en la misma tarea (community indicador). La tarea de sincronización informa del estado actual de cada sitio secundario operation_mode.

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

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 todas las decisiones relacionadas con amenazas se tomen a nivel de red: los intentos de Brute Force entre sitios se agrupan en un contador central, y un único bloqueo excluye la IP de todos los subsitios a la vez.

• Los administradores de red disponen de la interfaz de configuración completa y de una vista de registros de todos los sitios.
• Los administradores de un subsitio disponen de una interfaz de usuario de «Estado/Registros» de solo lectura, además de exactamente dos opciones de personalización editables por sitio: el slug de «Frontend 2FA» y los roles adicionales para la aplicación de la autenticación de dos factores (un subsitio puede exigir la autenticación de dos factores para más roles, nunca para 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 se cifran en reposo (libsodium con OpenSSL como alternativa).

• TOTP — RFC 6238 (6 dígitos, ventana de 30 segundos). Funciona con Google Authenticator, Authy, 1Password, Bitwarden, …
• 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.

Hardware Security Key (YubiKey)

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

• Configuración: abre tu página de perfil (Usuarios → Perfil → Autenticación de dos factores), selecciona «Añadir clave de seguridad» → «Clave de seguridad (USB / NFC)», asigna un nombre a la clave, insértala y toca el contacto dorado cuando el navegador te lo solicite. 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 Business plan incluye claves de seguridad avanzadas: varias claves por cuenta —registra una segunda YubiKey y guárdala en un lugar seguro como copia de seguridad—, además de 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 clave.
• ¿Has perdido tu llave? Inicia sesión con uno de tus Recovery Codes (o con tu llave 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 incrementa 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 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 último escalón, la IP pasa a la ruta central auto_block_ip() (evento 2fa_brute_force) que activa la escalada progresiva y la notificación en modo «Community», al igual que cualquier otro sensor.

Headless 2FA REST

Para integraciones 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 — muestra los métodos activos para el usuario actual.

Login en la interfaz de WooCommerce

El Frontend 2FA de Hive en la interfaz de usuario se integra en el tema activo de tu tienda: los clientes que inician sesión a través de [woocommerce_my_account], el proceso de pago clásico o los bloques «Carrito» y «Pago» de WooCommerce completan su segundo factor de autenticación en una página con el diseño del tema. 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 de 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 actualizan automáticamente al modificarlos.
• Rebaja de plan: desactivación suave 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 subir de plan.
• 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 Login, 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.

Envío de correo electrónico y SMS

La capa de correo funciona a través de un contrato con un proveedor conectable (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.com —una infraestructura de remitentes compatible con SPF, DKIM y DMARC—, de modo que los correos con OTP no acaben en la carpeta de spam, como suele ocurrir 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; no se requiere 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 Ajustes → 2FA → 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 un SMS lento o no recibido puede volver a solicitarse sin penalización, mientras que una ráfaga real sigue estando limitada.