Reglas WAF esenciales contra las técnicas de ataque más comunes

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Un firewall de aplicaciones es tan bueno como las reglas que lo gobiernan. Tener un WAF instalado sin afinar sus reglas es como poner una puerta blindada y dejarla entornada. En esta guía, parte de nuestro pilar de seguridad y hardening de WordPress, repasamos las reglas WAF WordPress que de verdad frenan las técnicas de ataque más comunes, con el criterio necesario para no bloquear a tus propios clientes por el camino.

Este artículo es la continuación práctica de WAF para WordPress: qué es, tipos y cómo elegir el tuyo: allí explicamos el qué y el cuál; aquí entramos en el cómo.

Reglas WAF WordPress contra inyección SQL

La inyección SQL sigue siendo una de las técnicas más rentables para un atacante: manipular una consulta a la base de datos para leer o alterar datos que no debería tocar. Las reglas WAF esenciales aquí detectan y bloquean patrones característicos en parámetros de URL y cuerpos POST:

• Secuencias típicas de inyección (UNION SELECT, comentarios SQL, OR 1=1) en parámetros no esperados.
• Caracteres de escape y comillas en campos que deberían ser numéricos o de formato fijo.
• Intentos de inferencia por tiempo (funciones de retardo) propios de la inyección ciega.

El WAF actúa como red de contención, pero la defensa de fondo son las consultas preparadas en el código. El NVD del NIST publica de forma continua vulnerabilidades de inyección en plugins de WordPress: cada una es un recordatorio de por qué esta regla no es negociable.

Reglas contra cross-site scripting (XSS)

El XSS inyecta scripts que se ejecutan en el navegador de tus visitantes, con consecuencias que van desde el robo de sesión hasta la desfiguración de la página. Las reglas de WAF filtran:

• Etiquetas <script>, manejadores de eventos (onerror, onload) y esquemas javascript: en parámetros.
• Codificaciones y ofuscaciones habituales que intentan evadir filtros simples.

Aquí el equilibrio importa: campos legítimos como comentarios o editores de contenido pueden contener fragmentos que disparen falsos positivos. Una regla bien afinada distingue el contexto en lugar de bloquear a ciegas.

Reglas contra inclusión de ficheros y directory traversal

Los ataques de LFI (Local File Inclusion) y directory traversal buscan leer ficheros sensibles del servidor —empezando por wp-config.php, que contiene las credenciales de la base de datos— o incluir ficheros maliciosos. Las reglas esenciales bloquean:

• Secuencias de recorrido de directorios (../ y sus variantes codificadas).
• Referencias a rutas del sistema (/etc/passwd, php://, wp-config.php) en parámetros.
• Intentos de acceso directo a ficheros que nunca deberían servirse por HTTP.

Reglas contra fuerza bruta y abuso de autenticación

Las oleadas de intentos de login contra wp-login.php y XML-RPC son constantes en cualquier WordPress expuesto. Las reglas WAF que las contienen combinan varias tácticas:

• Limitación de tasa (rate limiting): bloquear una IP tras un número de intentos fallidos en una ventana de tiempo.
• Protección de XML-RPC: mitigar los ataques de amplificación que usan system.multicall para probar cientos de contraseñas en una sola petición.
• Bloqueo geográfico o por reputación cuando el tráfico legítimo no procede de determinadas regiones.

Este vector es tan habitual que le dedicamos un análisis propio en fuerza bruta a wp-login.php: cómo detectarla y frenarla. El Learning Center de Wordfence documenta la escala real de estas campañas, que se cuentan por millones de intentos diarios contra la comunidad WordPress.

Reglas contra subida de ficheros maliciosos

Si un atacante consigue subir un shell PHP, el juego termina. Las reglas de WAF que reducen ese riesgo inspeccionan las subidas para bloquear extensiones ejecutables donde no corresponden, contenido con firmas de webshell conocidas y peticiones que intentan escribir en directorios que deberían ser de solo lectura. Como refuerzo, conviene impedir la ejecución de PHP en wp-content/uploads a nivel de servidor, tal como recomienda la guía de Hardening WordPress.

El arte de evitar falsos positivos

Aquí está la diferencia entre un WAF que protege y uno que ahuyenta clientes. Reglas demasiado agresivas bloquean el proceso de compra, los formularios o el panel de administración legítimo. Un despliegue serio sigue este orden:

• Empezar en modo monitorización (log, no bloqueo) para ver qué dispararían las reglas sin afectar a nadie.
• Crear excepciones dirigidas para rutas y parámetros legítimos que generen ruido, en lugar de desactivar la regla entera.
• Revisar los logs con regularidad: los falsos positivos de hoy y los ataques reales de mañana viven en el mismo registro.

En PathSentinel afinamos estos conjuntos de reglas en entornos exigentes —incluidos banca y comercios con datos de tarjeta—, donde un falso positivo en el checkout cuesta ventas y un falso negativo cuesta un incidente. El equilibrio no se improvisa: se mide.

Reglas de flota, no de sitio en sitio

Estas reglas ganan potencia cuando se aplican de forma transversal a toda una cartera de webs, no ajustando cada sitio a mano. Esa es la lógica que conecta con la gestión de parches para agencias: una regla de virtual patching bien escrita protege cincuenta sitios a la vez frente a una vulnerabilidad recién publicada, mientras despliegas el parche definitivo con calma.

Un WAF sin reglas afinadas es decoración. Con estas reglas esenciales bien ajustadas, se convierte en la capa que filtra el ruido hostil antes de que llegue a tu código.