Firewall de aplicaciones web para WordPress: cómo bloquea Hive
El firewall de WordPress de ReportedIP Hive revisa cada petición en busca de inyecciones, cross-site scripting y path traversal antes de que un plugin o un tema pueda procesarla. Esta guía explica qué inspecciona, de dónde salen las reglas, cómo resolver un falso positivo sin tocar código y cuándo merece la pena activar la Extended Protection opcional, que actúa antes de WordPress.
¿Para qué sirve un firewall de aplicaciones web en WordPress?
Un firewall de aplicaciones web (WAF) lee el contenido de una petición, no solo su origen. Donde un bloqueo de IP pregunta «¿quién llama a la puerta?», el WAF pregunta «¿qué está enviando?». Una petición con UNION SELECT en un parámetro o ../../wp-config.php en un nombre de archivo se rechaza, aunque nadie haya denunciado todavía esa dirección.
Eso cubre el hueco entre una vulnerabilidad nueva en un plugin y su actualización. La mayoría de los ataques contra WordPress apuntan a fallos conocidos de plugins y usan las mismas pocas técnicas que el OWASP Top 10 recoge desde hace años. Un firewall que reconoce esas técnicas protege un sitio incluso mientras una actualización sigue pendiente.
Qué inspecciona el firewall de Hive en cada petición
El firewall es uno de los 16 sensores de ReportedIP Hive y se ejecuta muy pronto mientras carga WordPress. Las direcciones ya bloqueadas se rechazan antes, así que solo inspecciona lo que queda. Revisa la dirección de la petición con su cadena de consulta, el cuerpo de la petición incluido el JSON y el user agent. La interfaz de Hive está en inglés, así que las etiquetas que cita esta guía también lo están.
La base gratuita que incluye el plugin cubre siete categorías de ataque:
- Inyección SQL
- Cross-site scripting, incluida la inyección de HTML
- Path traversal
- Inyección de comandos
- Intentos de acceso a archivos sensibles como copias de la configuración
- User agents de escáneres conocidos
- Abuso del endpoint batch de la API REST
Con Priority Sync, a partir del plan Professional, llegan más categorías por el feed de reglas, entre ellas la falsificación de peticiones del lado del servidor, Log4Shell, la inyección de objetos PHP, las entidades externas XML, la subida de web shells, la inyección CRLF y la inyección de plantillas.
Los usuarios con sesión iniciada que pueden editar entradas, desde colaboradores hasta administradores, no se inspeccionan, porque los maquetadores y los editores envían marcado y código de forma legítima. El área de administración también queda fuera, con una excepción: las peticiones anónimas a los endpoints de AJAX y de formularios se revisan igualmente. Las IP de la lista blanca, las tareas cron y WP-CLI pasan sin inspección.
Qué pasa cuando una petición coincide con una regla
Una coincidencia termina la petición con la página de bloqueo de Hive y un código de referencia como WAF_SQLI-3F9A2B71. La página es segura frente a la caché: un plugin de caché no puede servir al atacante una copia guardada de una página normal. El código también se envía en la cabecera X-RIP-Ref. Se calcula a partir de la IP, el motivo y la hora con un hash de un solo sentido y no contiene datos personales.
Las coincidencias repetidas desde la misma dirección llevan a un bloqueo de IP mediante la escalera de bloqueo progresivo. Los ataques inequívocos, como el path traversal, la inyección de comandos o la subida de un web shell, bloquean la dirección en la primera coincidencia. La inyección SQL y el cross-site scripting necesitan varias, porque son los que más falsos positivos generan. En modo Community Network, el bloqueo se comparte con la comunidad.
Cada coincidencia queda en el Event Log de ReportedIP Hive > Activity, con la regla, el grupo de reglas, el texto detectado, el método y el user agent. Si quieres observar antes de bloquear, activa Firewall report-only en la tarjeta Firewall & Bots: las coincidencias se registran entonces como «WAF Match (report-only)» y la petición pasa.
De dónde salen las reglas del firewall
Las reglas básicas forman parte del plugin, así que el firewall funciona totalmente sin conexión en modo Local Shield, sin cuenta. En modo Community Network con una clave, Hive puede descargar además conjuntos de reglas de la Rule API de reportedip.com. Son cinco: firmas WAF, identidades de bots verificados, dominios de correo desechables, rutas que prueban los escáneres y nodos de salida de Tor. Los ves con su versión, su número de reglas y su origen en ReportedIP Hive > Tools, pestaña Rules.
Cada conjunto de reglas está firmado. Hive comprueba la firma con una clave guardada en el plugin antes de aplicar una sola regla. Un feed manipulado o dañado se descarta, el último conjunto verificado sigue activo y, si no hay ninguno, entra la base. El firewall nunca depende de una conexión en directo.
La profundidad de las reglas sigue el modelo de niveles de paranoia del OWASP Core Rule Set:
| Nivel | Carácter | Plan |
|---|---|---|
| 1 | Base con pocos falsos positivos | Todos los planes, también Free |
| 2 | Más estricto, más categorías | Desde Professional |
| 3 | Ataques raros y ofuscados, opcional | Desde Professional |
Los niveles 2 y 3 necesitan Priority Sync, que entrega a diario los conjuntos de reglas completos. El nivel se ajusta con Firewall paranoia level en la tarjeta Firewall & Bots de la página Protection.
Cómo una regla defectuosa no tumba el sitio
Las reglas que llegan por un feed son un riesgo en sí mismas: una expresión regular mal escrita puede ocupar la CPU de un servidor durante segundos en cada petición. Hive se protege de varias formas. Cada regla se ejecuta con un presupuesto de tiempo fijo. Una regla que falla deja pasar la petición en lugar de bloquearla, y el plugin registra un aviso. Los cuerpos de petición grandes solo se leen hasta un límite. Y en el servidor, cada regla nueva se revisa automáticamente en busca de patrones peligrosos antes de firmarla y entregarla.
Resolver un falso positivo sin código
Todo firewall de firmas marca de vez en cuando una petición legítima, por ejemplo un buscador que acepta fragmentos de código o tu propia API que recibe muestras de ataques. Hive lo resuelve con las excepciones WAF, disponibles en todos los planes.
Paso 1: encontrar el evento
Pide al visitante el código de referencia y la hora. Abre ReportedIP Hive > Activity, Event Log, filtra por el tipo de evento WAF Block y localiza la entrada por IP, hora y regla. El código de referencia en sí no se guarda en el registro.
Paso 2: permitir la regla
Haz clic en el botón con el escudo de la fila, cuya ayuda emergente dice «Allow this rule on this path (WAF exception)». Hive crea una excepción para exactamente esa regla. La ruta solo se incluye si el registro la guardó, y no es así mientras Minimal logging esté activado, que es el valor por defecto. Sin ruta, la excepción vale para todo el sitio, así que acótala en el paso siguiente.
Paso 3: revisar la excepción
Todas las excepciones aparecen en la tarjeta WAF Exceptions de Tools > Rules. Ahí también puedes añadir una a mano. El campo Scope decide hasta dónde llega: una regla, un grupo de reglas o todo el motor. Una excepción para todo el motor tiene que llevar un prefijo de ruta o un rango de IP, para que el firewall no se desactive por error en todo el sitio. El menú Tools aparece en Expert mode; sin él, el botón Manage rules and exceptions de la tarjeta Firewall & Bots lleva hasta allí.
Extended Protection: bloquear antes de que cargue WordPress
El firewall normal se ejecuta dentro de WordPress. La Extended Protection añade un pequeño guardián que PHP ejecuta antes de WordPress y antes de cualquier código de plugin. Rechaza las peticiones que coinciden y las IP bloqueadas antes y con menos carga en el servidor. Viene desactivada por defecto y es gratuita en todos los planes.
La activas en ReportedIP Hive > Tools, pestaña Server, con Enable extended protection. En Apache y en PHP-FPM, lo que incluye la mayoría de instalaciones con nginx, Hive escribe él mismo el ajuste de servidor necesario. Donde no es posible, el Server Setup muestra una línea para pegar en el php.ini o en la configuración de nginx. El estado indica Running en cuanto el guardián se ha ejecutado para una petición, así que no tienes que adivinar si la instalación ha funcionado.
Hay tres diferencias con el firewall normal. El guardián no ve los roles de WordPress, solo si alguien ha iniciado sesión; con Leave the request body of signed-in users alone, activado por defecto, ignora el cuerpo de las peticiones de los usuarios con sesión, para que un editor que guarda una entrada no sea rechazado. El guardián aplica las mismas excepciones y el mismo nivel de paranoia que el firewall normal. Y un visitante al que rechaza ve una página sencilla con la palabra «Forbidden», sin la página de bloqueo diseñada, sin código de referencia ni botón de contacto. La coincidencia aparece igualmente en el Event Log con la regla, la hora y la IP.
Al desactivar el plugin, Hive quita los ajustes que escribió él mismo y deja un archivo de relleno inofensivo, para que un ajuste de servidor que añadiste a mano no pueda romper el sitio. Elimina tú mismo esa línea después de desinstalar.
Preguntas sobre el firewall de WordPress
¿Es gratuito el firewall de aplicaciones web de Hive?
El motor del firewall, las reglas básicas para siete categorías de ataque, las excepciones WAF y la Extended Protection son gratuitos en todos los planes y funcionan sin conexión en modo Local Shield. El plan Professional añade Priority Sync con conjuntos de reglas completos cada día, niveles de paranoia más estrictos y más categorías como SSRF, Log4Shell y XXE.
¿Bloquea el firewall a los editores que trabajan en WordPress?
El firewall normal no inspecciona a los usuarios con sesión que pueden editar entradas, y el área de administración queda fuera. Con la Extended Protection, el cuerpo de las peticiones de los usuarios con sesión se ignora por defecto. Si un formulario público o tu propio endpoint activa una regla, una excepción WAF para esa regla y esa ruta lo resuelve sin código.
¿Funciona el firewall con nginx?
El firewall normal funciona en cualquier servidor, porque se ejecuta dentro de WordPress. Para la Extended Protection en nginx con PHP-FPM, Hive escribe el ajuste de servidor automáticamente. Si tu hosting no lo permite, el Server Setup muestra una línea para el php.ini o la configuración de nginx que puedes añadir a mano.
¿Qué pasa si el servidor de reglas no está disponible?
Nada deja de funcionar. Hive conserva el último conjunto de reglas verificado y recurre a las reglas básicas del plugin si no hay ninguno. La siguiente sincronización vuelve a intentarlo. Como cada conjunto de reglas se firma y se comprueba antes de usarlo, un feed manipulado tampoco puede cambiar las reglas.
Sigue leyendo
La documentación de Hive explica en detalle el firewall y la entrega de reglas y las excepciones WAF. El resto de funciones está en las guías de ReportedIP Hive.