Introducción a los WAF

Un WAF mal configurado o ausente puede convertir una simple inyección SQL en una brecha total. Comprender cómo funcionan internamente es el primer paso para evadir los que bloquean tus pruebas — y para defender los que proteges.

Evolución histórica de los firewalls

Los firewalls evolucionaron a medida que los ataques se volvieron más sofisticados.

Filtro de paquetes sin estado (stateless) — Opera en capas 3–4 del modelo OSI. Evalúa cada paquete en aislamiento sin recordar conexiones anteriores. Vulnerable al ACK flag spoofing: un atacante envía un paquete con el flag ACK activo y el firewall lo trata como parte de una conexión establecida.

Firewall de estado (stateful) — Mantiene una tabla de conexiones activas. Detecta paquetes fuera de secuencia y valida los flags TCP contra el estado esperado. Resuelve el ACK spoofing, pero opera exclusivamente en capas 3–4.

Application-Level Gateway (ALG / Proxy Firewall) — Actúa como intérprete de protocolo: termina la conexión entrante e inicia una nueva en nombre del cliente. Permite visibilidad completa de protocolos de capa 7 como HTTP y FTP. Base conceptual de la inspección L7.

Deep Packet Inspection (DPI) — Inspecciona la carga útil completa de los paquetes, no solo las cabeceras. Detecta secuencias de bytes características de malware o tráfico C2. Carece de contexto de aplicación: puede detectar un UNION SELECT pero no saber si es legítimo.

Next-Generation Firewall (NGFW) — Combina inspección con estado + DPI + IPS integrado + descifrado SSL/TLS + identificación de usuarios/aplicaciones (via Active Directory, certificados, SAML). Aplica políticas basadas en usuario y aplicación, no solo en tuples IP/puerto. Aún carece de la granularidad necesaria para lógica de aplicaciones web.

Web Application Firewall (WAF)

Un WAF inspecciona tráfico HTTP(S) —entrante y saliente— para detectar intenciones maliciosas. A diferencia de un NGFW que clasifica aplicaciones, un WAF habla HTTP con fluidez: analiza métodos, cabeceras, cookies, query strings y cuerpos POST para detectar ataques como SQLi, XSS, file inclusion e inyección de comandos (OWASP Top 10).

Virtual patching: los WAF pueden mitigar vulnerabilidades conocidas sin requerir cambios en el código fuente. Si una regla no cubre una variante específica de la carga útil, esta la atraviesa igualmente.

Modelos de despliegue

Fingerprinting de WAF

Identificar la presencia y tipo de WAF antes de atacar permite: evitar cargas que serán bloqueadas, seleccionar técnicas de evasión dirigidas y ajustar el ritmo de las pruebas.

1. Inspección pasiva de cabeceras

curl -I http://TARGET

Indicadores de WAF en las respuestas HTTP:

2. Análisis de comportamiento (activo)

Enviar payloads “inofensivos” que coincidan con firmas comunes de ataque:

# Solicitud normal → 200 OK
curl -I "http://MACHINE_IP/search.html?q=test"

# Con SQLi trigger → 403 Forbidden si hay WAF
curl -I "http://MACHINE_IP/search.html?q=test'%20OR%201=1--"

Interpretación de respuestas:

3. Fingerprinting automatizado con wafw00f

wafw00f detecta más de 500 WAF mediante un proceso de sondeo progresivo:

1. Solicitud HTTP estándar: analiza respuesta, código de estado, cabeceras.
2. Si no es concluyente: envía un conjunto controlado de solicitudes maliciosas y mapea comportamientos.
3. Si todavía sin resolver: analiza tiempos de respuesta y patrones residuales.

wafw00f http://TARGET

Resultado: identifica el WAF por nombre o confirma la presencia de “algún control de seguridad” aunque no identifique el tipo exacto.

4. Nmap http-waf-fingerprint

Para escaneo de subred (vs. host individual):

nmap -p 80,443 --script http-waf-fingerprint TARGET_IP

Limitación: permanece silencioso cuando no identifica el WAF por nombre. wafw00f es preferible en análisis de host único.

Detección por firmas vs. por comportamiento

Detección basada en firmas

Compara el contenido de cada paquete contra una lista de firmas maliciosas conocidas. Rápido y con bajo ratio de falsos positivos.

Evasiones comunes:

• Encoding: ' OR 1=1-- → %27%20OR%201%3D1%2D%2D
• Variante de case: UNION SELECT → unIOn sElEcT
• Inserción de comentarios: SELECT → SEL/**/ECT
• Sintaxis alternativa: SLEEP(10) → IF(1=1, SLEEP(10), 1)

Detección basada en comportamiento / anomalías

Aprende la normalidad (longitud de input, número de parámetros, tipos de datos, tasa de sesiones) y marca desviaciones. El input username=' OR '1'='1 se desvía de la normalidad de un nombre de usuario (caracteres especiales, espacios en blanco).

Detección híbrida

WAFs comerciales modernos combinan ambos enfoques: comprobación rápida de firmas → inspección de anomalías → puntuación de riesgo ponderada → decisión sobre el paquete.

Anatomía de una regla WAF (ModSecurity / OWASP CRS)

Ejemplo real: regla 942101 del OWASP CRS v3.3.7 para detección de SQLi.

1
SecRule REQUEST_BASENAME "@detectSQLi" \
2
    "id:942101,\
3
    phase:2,\
4
    block,\
5
    capture,\
6
    t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,\
7
    msg:'SQL Injection Attack Detected via libinjection',\
8
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
9
    tag:'attack-sqli',\
10
    tag:'OWASP_CRS',\
11
    tag:'capec/1000/152/248/66',\
12
    tag:'PCI/6.5.2',\
13
    tag:'paranoia-level/3',\
14
    ver:'OWASP_CRS/3.3.7',\
15
    severity:'CRITICAL',\
16
    setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
17
    setvar:'tx.anomaly_score_pl3=+%{tx.critical_anomaly_score}'"

Desglose por sección:

Trigger — SecRule REQUEST_BASENAME "@detectSQLi":

• SecRule: directiva estándar de ModSecurity
• REQUEST_BASENAME: inspecciona el nombre de archivo/endpoint de la URL (e.g., en /api/user/123, el basename es 123)
• @detectSQLi: llama a libinjection, librería C especializada que tokeniza la entrada como un analizador SQL real (en lugar de buscar strings como ' OR 1=1)

Metadatos:

• id:942101: identificador único (esquema de numeración CRS)
• phase:2: se ejecuta durante el procesamiento del cuerpo de la solicitud
• block: acción → rechazar la solicitud
• capture: guarda la carga útil coincidente para logging

Normalización de entrada (antes de que @detectSQLi se ejecute):

• t:none: comenzar con input sin procesar
• t:utf8toUnicode: convierte secuencias UTF-8 a Unicode
• t:urlDecodeUni: decodificación URL recursiva (maneja doble-encoding: %2527 → %27 → ')
• t:removeNulls: elimina bytes nulos (%00), usados para terminar strings en parsers C

Logging y atribución:

• msg: alerta legible que aparece en logs y SIEM
• logdata: detalles forenses: %{TX.0} (carga exacta), %{MATCHED_VAR_NAME} (variable inspeccionada), %{MATCHED_VAR} (valor completo)

Tags (ganchos operativos):

• capec/1000/152/248/66: enlace a CAPEC para modelado de amenazas
• PCI/6.5.2: requisito PCI DSS para protección contra inyección
• paranoia-level/3: CRS usa 4 niveles de paranoia; PL3 es más estricto con mayor tasa de falsos positivos

Puntuación de anomalías:

• tx.sql_injection_score: acumula riesgo SQLi a través de múltiples reglas
• tx.anomaly_score_pl3: alimenta la puntuación de anomalía total de CRS para PL3

Limitaciones de los WAF

Las reglas son la clave: los WAF son tan buenos como sus reglas. En modo log-only (frecuente por altos falsos positivos), ofrecen zero protección activa.

Sin comprensión de lógica de negocio: los WAF filtran sintaxis, no intención. No pueden detectar:

• IDOR: GET /api/user/124 (cambio de 123 a 124) — sin caracteres especiales, sin trigger
• Authorization bypass: /admin accedido por un usuario sin privilegios — URL inofensiva
• Race conditions / replay attacks: sin sintaxis maliciosa detectable

Tráfico cifrado como punto ciego: si el cifrado ocurre antes del WAF, este solo ve blobs cifrados. La terminación TLS en el WAF añade complejidad de gestión de certificados y posibles problemas de privacidad/compliance.

Ataques del lado del cliente invisibles: XSS DOM-based se ejecuta en el navegador y nunca llega al servidor. Scripts propios comprometidos (bibliotecas de analytics) no generan solicitudes sospechosas.

Nuevas superficies de ataque: reglas personalizadas mal configuradas pueden generar RCE (construcción dinámica de reglas ModSecurity sin escape correcto). Regex complejas + payloads grandes → DoS por agotamiento de memoria. La interfaz de administración expuesta puede ser atacada (e.g., CVE-2020-5902 en F5 BIG-IP).

Performance vs. seguridad: la DPI consume CPU. Regex en payloads grandes o decodificación multi-capa genera latencia. Los modelos de detección de anomalías son computacionalmente costosos a escala.

Principio rector

Un WAF correctamente configurado aumenta la seguridad y ayuda con el cumplimiento normativo. Pero un WAF nunca es un sustituto del código seguro. La ciberseguridad se construye mediante una política integral y múltiples capas de defensa.

Ver también

• WAF Bypass Techniques — evasión práctica de reglas CRS, encoding, truncación, protocol manipulation
• HTTP Request Smuggling — bypass de WAF via desincronización de parsers
• Vulnerability Chaining — encadenar WAF bypass con otras vulnerabilidades