WAF:

qué para de verdad un firewall de aplicaciones (y qué no)

Seguridad de aplicaciones web  |  unfantasmaenelsistema.com

Un WAF (Web Application Firewall) se pone delante de una aplicación web y examina cada petición HTTP antes de que llegue al servidor. Se vende a menudo como la solución que «protege la web», y esa expectativa es la que causa la mayoría de los disgustos: un WAF filtra patrones de ataque conocidos, pero no entiende la lógica de tu aplicación ni corrige el fallo que hay debajo.

Este artículo explica cómo decide un WAF, los dos modelos de detección, las implementaciones más comunes (Core Rule Set, ModSecurity/Coraza, WAF de CDN), el ajuste de falsos positivos, y por qué conviene verlo como un parche temporal y no como un arreglo. El objetivo es que quien lo despliega tenga expectativas realistas de lo que gana y de lo que sigue teniendo que hacer.

1. Qué mira un WAF y dónde se coloca

Un WAF opera en la capa 7: ve el método, la ruta, las cabeceras, los parámetros de la query, el cuerpo (formularios, JSON, XML) y, si termina el TLS, también el contenido cifrado. Sobre eso aplica reglas y decide: permitir, bloquear, registrar o desafiar (por ejemplo, un CAPTCHA o un JavaScript challenge).

Colocarlo bien importa: si el WAF no ve la IP de origen real (porque hay otro proxy delante), el rate limiting y las reglas por reputación dejan de funcionar. Hay que propagar y confiar en `X-Forwarded-For` solo desde los saltos conocidos.

2. Modelo negativo y modelo positivo

En la práctica casi todos los despliegues empiezan (y se quedan) en modelo negativo, porque el positivo exige conocer la aplicación al detalle. Un punto intermedio útil es aprender el modelo positivo de forma automática a partir de tráfico legítimo observado, y aplicarlo solo a las rutas más sensibles (login, pagos, APIs internas).

3. El OWASP Core Rule Set

El OWASP Core Rule Set (CRS) es el conjunto de reglas de modelo negativo más usado. Es libre, funciona sobre ModSecurity y sobre Coraza, y muchos WAF comerciales lo llevan por dentro con otro nombre. Dos conceptos definen cómo se comporta:

• Paranoia levels (PL1 a PL4). A más nivel, más reglas y más estrictas. PL1 es el punto de partida razonable para la mayoría de sitios; PL3-PL4 solo para aplicaciones que toleran restricciones fuertes (banca, sector público) y con mucho trabajo de tuning
• Anomaly scoring. Cada regla que dispara suma puntos a la petición en lugar de bloquearla de inmediato. Si el total supera un umbral (por defecto 5 en entrada), se bloquea. Esto evita que una sola coincidencia dudosa tumbe tráfico legítimo y da una señal graduada

# CRS: bajar el umbral hace el WAF mas estricto; subirlo, mas permisivo
SecAction "id:900110, phase:1, nolog, pass, \
  setvar:tx.inbound_anomaly_score_threshold=5, \
  setvar:tx.outbound_anomaly_score_threshold=4"
 
# Empezar SIEMPRE en modo solo-deteccion para medir falsos positivos
SecRuleEngine DetectionOnly
 
# Excluir una regla concreta para una ruta concreta (tras confirmar que es FP)
SecRule REQUEST_URI "@beginsWith /api/reports" \
  "id:1001, phase:1, pass, nolog, ctl:ruleRemoveById=942100"

4. Falsos positivos y tuning

El coste real de un WAF no es la licencia ni el hardware: es el tiempo de ajuste. Un WAF sin mantener acaba en uno de dos estados, y los dos son malos: tan estricto que la gente pide excepciones a todo, o tan relajado que no aporta.

• Trata las reglas del WAF como código: en control de versiones, con revisión de cambios y con un entorno de pruebas donde repites tráfico real antes de tocar producción
• Mide: número de bloqueos por regla, top de rutas y parámetros que disparan, ratio detección/bloqueo. Sin métricas, el tuning es a ciegas
• Documenta cada exclusión con el motivo y la fecha; revísalas cuando la aplicación cambie

5. Por qué un WAF se evade

Un WAF de modelo negativo inspecciona una representación del tráfico; si el atacante consigue que el servidor interprete la petición de forma distinta a como la vio el WAF, la regla no aplica. Las familias clásicas:

• Codificación y ofuscación. Doble URL-encoding, entidades HTML, comentarios intercalados, mayúsculas/minúsculas alternadas, notación alternativa. El CRS normaliza mucho, pero es una carrera constante
• HTTP request smuggling / desync. Discrepancias entre cómo el WAF (o un proxy intermedio) y el backend interpretan `Content-Length` y `Transfer-Encoding` permiten «colar» una petición que el WAF no llega a ver entera
• Parámetros duplicados y HTTP Parameter Pollution. El WAF evalúa una copia del parámetro y el backend usa otra
• Lógica de negocio. Un WAF no sabe que un usuario no debería poder cambiar el `account_id` de otra persona, ni que 10.000 peticiones de «consultar saldo» en un minuto son un abuso: eso es IDOR y abuso funcional, invisibles para las firmas
• Canales que no ve. Ataques contra un endpoint interno, contra la cola de mensajes, o a través de una dependencia: el WAF solo mira la puerta de entrada HTTP

6. Dónde encaja de verdad: virtual patching

El uso donde un WAF brilla es el parcheo virtual: cuando se publica una vulnerabilidad en una librería o en tu propio código y el arreglo va a tardar (hay que probar, hay ventana de despliegue, el proveedor no ha sacado parche), una regla específica en el WAF puede bloquear el patrón exacto de explotación mientras tanto.

• Es rápido de aplicar y rápido de revertir, y se puede acotar a una ruta y un parámetro concretos, con lo que el riesgo de falso positivo es bajo
• Es temporal por definición: la regla lleva fecha de caducidad y un ticket que la ata al arreglo real en el código. Un parche virtual que lleva dos años puesto es deuda técnica disfrazada de seguridad
• Funcionó a gran escala con vulnerabilidades muy explotadas: mientras los equipos actualizaban, una regla de WAF frenaba el patrón de ataque más común

Conclusión

Un WAF es una capa útil: filtra el ruido de fondo de internet, frena escáneres y exploits genéricos, y da un botón rápido para contener una vulnerabilidad concreta mientras se corrige. En modo scoring y bien afinado, ese valor es real.

Lo que no es, es un sustituto de escribir código seguro. No entiende tu lógica de negocio, se puede evadir con discrepancias de interpretación, y no ve nada que no pase por su puerta HTTP. La forma sana de desplegarlo: empezar en detección, afinar con métricas, pasar a bloqueo por fases, y tratar cada regla de contención como un parche con fecha de caducidad atada al arreglo de verdad.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)