16 Attack Sensors que detectan intrusiones en WordPress en tiempo real

17 de diciembre de 2025 Actualizado 20 de septiembre de 2026 Patrick Schlesinger

La eficacia de la detección de ataques en WordPress depende directamente de la calidad de las señales que supervisa. ReportedIP Hive cuenta con 16 sensores independientes que vigilan las interfaces de Login, comentarios, REST, XMLRPC y errores 404, cada uno de ellos con un umbral ajustable y un valor predeterminado razonable.

En esta guía se enumeran los 16 sensores, los umbrales predeterminados con los que vienen de fábrica y el tipo de ataque que detiene cada uno de ellos.

¿Qué es ReportedIP Hive?

ReportedIP Hive es un completo plugin de seguridad para WordPress que combina protección contra ataques de Brute Force, un conjunto completo de autenticación de dos factores (2FA) e Threat Intelligence de la comunidad (opcional). La capa de detección que aquí se describe es gratuita en todos los modos, incluido el modo «Local Shield», que funciona totalmente sin conexión. El conjunto completo de funciones de ReportedIP Hive se puede consultar en el centro de productos.

Los 16 sensores de detección y sus valores predeterminados

Cada sensor cuenta los eventos por dirección IP dentro de una ventana móvil. Si se supera el umbral, la dirección IP pasa a la lista de bloqueo. Los valores predeterminados son deliberadamente conservadores; puedes ajustarlos al alza o a la baja en «Configuración» → «Protección».

Intentos fallidos de Login: 5 fallos / 15 min.
Ataque de «spray» de contraseñas, nombres de usuario únicos desde una misma IP, 5/10 min. Los contadores están cifrados con hash, por lo que no se almacenan nombres de usuario en texto plano.
Spam en los comentarios: 5 / 60 min, evaluado antes de que se active el filtro de comentarios.
Uso indebido de XMLRPC: 10 / 60 min, con system.multicall vigilados por separado.
Uso indebido de contraseñas de aplicaciones: intentos de autenticación básica REST/XMLRPC que tratan de eludir la autenticación de dos factores (2FA), 5 / 15 min.
Rate Limit de la REST API: 240 en 5 minutos a nivel global; 20 en 5 minutos para rutas sensibles.
Defensa contra la User Enumeration: bloquea ?author=N, /wp-json/wp/v2/users y las búsquedas de oEmbed, y enmascara los errores de Login.
404 / detección por escáner: 12 / 2 min, además de un bloqueo inmediato de rutas conocidas como maliciosas, como .env, wp-config.bak y /.git/.
El Web Application Firewall analiza la URI, la cadena de consulta, el cuerpo y el User-Agent comparándolos con un conjunto de reglas firmadas y proporcionadas por el servidor (SQLi, XSS, recorrido de rutas, inyección de comandos, SSRF, Log4Shell y otras). El motor y la referencia OWASP Top 10 son gratuitos en todos los planes; los conjuntos de reglas más exhaustivos de los Paranoia-Level 2 y 3 se incluyen en Priority Sync del plan Professional.
Verified Bot Detection: primero se comprueba si se trata de Googlebot, Bingbot u otros rastreadores comparándolos con sus rangos de IP oficiales y, a continuación, se recurre a un sistema de Forward-confirmed reverse DNS como alternativa. Los suplantadores se marcan o se bloquean; los rastreadores auténticos nunca se bloquean.
Protección contra registros fraudulentos, un conjunto de normas único para todas las plataformas de registro: dominios de correo electrónico desechables con modos de desactivación, supervisión y bloqueo (los servidores de privacidad, como «Ocultar mi correo electrónico» de Apple, pasan por defecto), nombres de usuario prohibidos, normas de admisión y bloqueo de correos electrónicos, y un límite de registros por dirección IP.
Prueba de envío del formulario: un campo de anclaje oculto más un campo gemelo añadido mediante script, con un nombre diferente en cada instalación, en los comentarios, registros y restablecimientos de contraseña; un envío que no incluyera ninguno de estos campos nunca mostraba el formulario. Veredicto de cuatro vías, gratuito en todos los planes.
La comprobación de amenazas de la comunidad en formularios, comentarios, registros y restablecimientos de contraseña se realiza comparándolos con la Community Network, aplicando el mismo umbral que se aplica en la página de Login; una dirección a la que el sitio web denegaría el acceso no podrá publicar un comentario.
Anomalía geográfica: un Login desde un país en el que ese usuario nunca se ha conectado, lo que puede, opcionalmente, revocar las cookies de los Trusted Devices.
Política de contraseñas, longitud mínima, clases de caracteres y una comprobación opcional de k-anonimato de «Have-I-Been-Pwned».
Los hooks de Login de WooCommerce, así como los formularios de pago y de «Mi cuenta», se registran por separado de wp-login.php.

Dos elementos en la misma pantalla que no son sensores. El Comment Honeypot es un campo señuelo invisible, excluido de los lectores de pantalla, en el formulario de comentarios: los bots que rellenan todos los campos son rechazados, y un visitante real nunca ve un CAPTCHA. Pertenece a la capa del «Honeypot» y no a los sensores de recuento. Y los endpoints de consentimiento de Real Cookie Banner, Complianz, Borlabs y CookieYes están exentos de la Rate Limit REST de forma predeterminada, ya que en un sitio web que cumple con la normativa parecen aparecer en cada una de las páginas visitadas. Ninguno de ellos cuenta para un bloqueo, por lo que ninguno se considera un sensor.

¿Por qué los motores de búsqueda y los rastreadores de IA no los detectan?

Desde la versión 2.0.5, Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot y otros rastreadores verificados quedan excluidos de los desencadenantes de errores 404 y de ráfagas REST, por lo que un rastreo legítimo de URL obsoletas nunca hace que un bot entre en la escala de bloqueo. La excepción es deliberada: una solicitud a una ruta de Honeypot como /.env sigue activando la respuesta al instante, incluso si proviene de un «Googlebot» autodenominado; esa solicitud es el indicador de ataque.

Cómo el hecho de contar se convierte en un obstáculo

Los sensores de tipo «Brute-Force» comparten una escala de recuento de fallos: 3 fallos → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Tras el decimoquinto fallo, la dirección IP pasa a ser una entrada real en la blocked tabla a través del canal canónico handle_threshold_exceeded() , que a su vez activa la escala de escalación progresiva y, en modo «Comunidad», pone en cola un informe anonimizado.