Equilibrio entre registro y bloqueo en WAF

Informatec Digital » Recursos » Equilibrio entre registro y bloqueo en WAF

Encontrar el equilibrio entre registrar y bloquear en un WAF se ha convertido en uno de los quebraderos de cabeza más habituales para equipos de seguridad y operaciones. Un firewall de aplicaciones web es capaz de parar ataques muy serios, pero si se configura de forma demasiado agresiva puede tumbar compras, accesos o llamadas API legítimas. Si se configura demasiado “blando”, acaba siendo casi decorativo. La clave está en ajustar con cabeza cuándo registrar, cuándo contar, cuándo permitir y cuándo bloquear.

En este artículo vamos a profundizar en cómo lograr ese equilibrio usando las capacidades modernas de los WAF (listas de permitidos, reglas basadas en frecuencia, modos de aprendizaje, integración con SIEM, machine learning, etc.), apoyándonos en ejemplos concretos de AWS WAF, ModSecurity, WAF en la nube y soluciones on‑premise. Verás cómo limitar falsos positivos sin bajar el nivel de protección, cómo organizar políticas por aplicaciones y cómo usar el registro como aliado, y no como un ruido constante imposible de gestionar.

Qué es un WAF y por qué el registro es tan importante

Un firewall de aplicaciones web actúa como una capa inteligente entre el usuario y el servidor, analizando el tráfico HTTP/HTTPS en tiempo real. A diferencia de un firewall tradicional de red, que mira puertos e IPs, el WAF se mete hasta la cocina: URL, parámetros, cuerpo de la petición, cabeceras, cookies, métodos HTTP, etc.

Su misión es detectar y frenar ataques típicos de la capa 7: inyecciones SQL, XSS, LFI/RFI, ataques contra el control de acceso, abuso de APIs, scraping agresivo, fuerza bruta o incluso ciertos patrones de DDoS a nivel de aplicación. Para ello se basa en conjuntos de reglas, firmas y políticas de seguridad que se actualizan constantemente.

El registro (logging) es el otro lado de la moneda. Cada decisión del WAF —permitir, bloquear o solo contar— puede ir acompañada de un evento detallado en los logs. Estos registros permiten:

• Investigar incidentes: reconstruir qué ocurrió y cómo se intentó explotar una vulnerabilidad.
• Ajustar reglas: detectar falsos positivos viendo qué peticiones legítimas está parando el WAF.
• Cumplir normativas: demostrar que existen controles activos (PCI DSS, GDPR, auditorías internas, etc.).
• Alimentar un SIEM: correlacionar ataques de aplicación con eventos de red, sistema, identidad, etc.

El problema es que un WAF mal afinado puede llenar los logs de miles de eventos irrelevantes, hacer imposible encontrar lo importante y, encima, provocar rechazos injustificados al tráfico legítimo. Ahí entra el arte de jugar con los modos de registro, conteo y bloqueo.

Modelos de seguridad en WAF: listas de bloqueo, listas de permitidos y enfoque híbrido

La mayoría de WAF modernos combinan varios enfoques de filtrado, lo que tiene un impacto directo en cómo se registran y bloquean las peticiones. A grandes rasgos, podemos hablar de dos filosofías clásicas, más un modelo mixto muy habitual.

Un WAF basado en lista de bloqueo sigue un modelo de seguridad negativo. Su idea es: “permito todo salvo lo que sé que es malo”. Funciona a partir de firmas de ataques conocidos (inyección SQL, XSS, patrones de bots, etc.) y reglas que definen qué se considera sospechoso. Es más fácil de desplegar al principio, pero si te quedas solo con este modelo corres el riesgo de que nuevos vectores o variantes de ataques se cuelen sin ser detectados.

Un WAF de lista de permitidos va justo al revés: “bloqueo todo salvo lo explícitamente permitido”. Se basa en un modelo de seguridad positivo. Solo se acepta el tráfico que encaja en el comportamiento legítimo definido: rutas, métodos, parámetros, formatos, tamaños, etc. Es mucho más seguro, pero requiere un trabajo de afinado muy serio y puede generar falsos positivos al principio si no se prepara bien.

Debido a las ventajas e inconvenientes de cada enfoque, cada vez es más habitual un modelo híbrido de lista de permitidos + lista de bloqueo. En este escenario, se definen perfiles de tráfico esperado (por ejemplo, qué se considera una petición normal de login o de pago) y, al mismo tiempo, se aplican firmas y heurísticas para cazar patrones maliciosos típicos. A efectos de registro, el híbrido permite:

• Marcar como evento de riesgo alto aquello que incumple la lista de permitidos.
• Tratar como alertas de prioridad media/baja los patrones generales de lista de bloqueo.
• Usar el modo “contar” para ver qué rompería una regla antes de activar el bloqueo.

WAF en red, en host y en la nube: impacto en registro y bloqueo

El modelo de despliegue del WAF condiciona mucho cómo se gestiona el logging y el bloqueo de tráfico. No es lo mismo registrar peticiones en un dispositivo de red que en un agente dentro del servidor o en un servicio gestionado en la nube.

Un WAF basado en red suele desplegarse como appliance físico o virtual en la infraestructura, entre Internet y las aplicaciones. Es el enfoque clásico de fabricantes como F5. Tiene la ventaja de ofrecer alto rendimiento y control granular, pero la configuración y la gestión pueden ser complejas. El registro suele enviarse a syslog o a un SIEM central, y conviene filtrar bien qué se guarda para no saturar almacenamiento ni herramientas de análisis y para diagnosticar problemas en redes IP y DNS.

El WAF basado en host se ejecuta en los propios servidores (o contenedores) donde reside la aplicación, normalmente como módulo o agente (por ejemplo, ModSecurity integrado en un Nginx o Apache; combinarlo con hardening Linux con SELinux mejora la postura de seguridad). Este modelo permite tener más contexto de la aplicación y reglas muy específicas por servicio, a costa de consumir recursos locales y de requerir una gestión más distribuida de los logs. Pueden guardarse en ficheros locales y luego reenviarse, o integrarse con servicios de logging centralizado.

El WAF en la nube (Cloudflare, Akamai, Imperva Cloud, AWS WAF, etc.) se integra con balanceadores, CDN o redes virtuales. Aquí el proveedor suele ofrecer paneles, dashboards y exportación de logs hacia S3, BigQuery, syslog remotos o SIEM. Suele ser más sencillo de activar, pero debes adaptar tus políticas de registro al modelo del proveedor: tipos de eventos, retención, filtros por gravedad, etc.

Elegir uno u otro modelo no es solo decisión técnica, también de cómo quieres trabajar el equilibrio entre registro y bloqueo: un servicio gestionado en la nube simplifica muchos aspectos, pero quizá quieras control absoluto sobre dónde se almacenan los logs por políticas de cumplimiento o confidencialidad, lo que empuja hacia modelos on‑premise o híbridos.

Condiciones, reglas y ACL web: cómo decide el WAF si bloquear, permitir o solo registrar

Independientemente del fabricante, todos los WAF modernos se basan en la idea de condiciones, reglas y políticas de acceso. Entender esto es clave para jugar con los modos de conteo (count), registro y bloqueo sin liarla en producción.

Las condiciones describen qué parte de la petición se inspecciona: IP de origen, cabeceras HTTP concretas (Host, User-Agent, Accept, Content-Type…), parámetros de consulta, cuerpo de la petición, cookies, método HTTP, país de origen, etc. Por ejemplo, en AWS WAF Classic puedes definir una condición de IP con hasta 10.000 direcciones o rangos, o una condición de coincidencia de cadena sobre una porción de la URL.

Las reglas combinan una o varias condiciones y asignan una intención: permitir, bloquear o contar. Cuando una regla tiene varias condiciones, normalmente se evalúan con un AND lógico: todas deben cumplirse para que la regla se active. Una regla normal sin condiciones, en la práctica, no coincide con nada y su acción nunca se dispara.

En muchos WAF, incluyendo AWS WAF, existen también reglas basadas en frecuencia (rate-based). Estas reglas cuentan las peticiones que llegan desde una IP (o conjunto de IPs que cumplen ciertas condiciones) durante una ventana de tiempo, por ejemplo cinco minutos. Si se supera un umbral —digamos 1.000 solicitudes en cinco minutos— la regla pasa a actuar: bloquear o solo contar. Esto es muy útil para:

• Controlar fuerza bruta en formularios de login.
• Limitar scraping agresivo o bots maleducados.
• Mitigar cierto tipo de ataques DDoS a nivel de aplicación.

El siguiente nivel es la Web ACL (Access Control List). Aquí se agrupan las reglas y se define un orden de evaluación y una acción por defecto (ALLOW o BLOCK). Una petición va pasando por las reglas en orden; si coincide con alguna, se aplica su acción y se deja de evaluar el resto. Si no coincide con ninguna, se aplica la acción por defecto definida en la ACL.

A nivel de equilibrio entre registro y bloqueo, la ACL es el lugar donde decides si quieres que, por defecto, el sistema sea permisivo (ALLOW y bloqueos solo por reglas específicas) o muy restrictivo (BLOCK salvo excepciones). Además, muchas soluciones permiten marcar reglas en modo “contar” dentro de la ACL, de forma que registran coincidencias pero no detienen el tráfico, ideal para la fase de ajuste.

Listas de permitidos (whitelists) y reducción de ruido en los logs

Las listas de permitidos son una herramienta fundamental para reducir falsos positivos y ruido en el registro. La idea es sencilla: en determinados contextos, indicas al WAF que no aplique una directiva o conjunto de reglas a cierto tráfico concreto que ya has catalogado como de confianza o que sabes que se sale de la norma pero es legítimo.

Por ejemplo, en AWS WAF puedes crear reglas de lista de permitidos para que, si la petición viene de una IP o rango concreto, o si coincide con un patrón de URL y método HTTP conocido, no se apliquen ciertas inspecciones de firma. Esto ayuda a:

• Evitar que APIs internas que usan patrones “raros” generen falsos positivos constantes.
• Reducir la latencia que introduce la inspección profunda en tráfico que ya consideras de confianza.
• Disminuir el volumen de registros innecesarios en los logs del WAF.

En plataformas como ModSecurity, el enfoque recomendado no es tocar las reglas estándar (por ejemplo, OWASP Core Rule Set), sino crear exclusiones específicas por ID de regla para ciertos parámetros, rutas o usuarios. Esto permite mantener la protección global sin dejar agujeros enormes por desactivar reglas enteras en todo el sitio.

La clave está en que las listas de permitidos sean quirúrgicas, no un hachazo. Es mucho mejor excluir una combinación concreta (regla X + parámetro Y en URL Z) que apagar la regla X a nivel global. De ese modo, el registro sigue siendo útil y no generas puntos ciegos innecesarios.

Reglas de protocolo y límites: cuándo bloquear, cuándo avisar

Muchos WAF incorporan un conjunto de reglas de saneamiento de protocolo HTTP que funcionan como primer filtro de tráfico mal formado o sospechoso. Estas reglas revisan cabeceras obligatorias, métodos, tamaños de argumentos, etc., y son una fuente frecuente tanto de buena protección como de falsos positivos si no se entienden bien.

Algunos ejemplos muy habituales:

• Missing Accept Header (cabecera Accept ausente): no es estrictamente una violación del RFC, pero muchas peticiones sin esta cabecera proceden de herramientas automáticas o scripts poco “educados”. Puede afectar a APIs o clientes personalizados que no la envían. En muchos entornos se prefiere registrar y contar antes de bloquear de forma tajante.
• Missing Host Header: según los estándares HTTP/1.1, la cabecera Host es obligatoria. Los WAF la necesitan, además, para decidir qué política aplicar. Bloquear aquí suele ser razonable, pero puede generar falsos positivos en pruebas o tráfico interno mal configurado; conviene monitorizar los logs antes de activar bloqueo estricto.
• Missing User-Agent Header: esta regla intenta frenar bots rudimentarios y tráfico no identificado. El problema es que muchas APIs legítimas pueden no enviar User-Agent. Lo más sensato suele ser registrar y, si se detecta una API constante y legítima, añadir su IP o patrón a una lista de permitidos.
• Validación de GET/HEAD con cuerpo: aunque el RFC no prohíbe estrictamente enviar cuerpo con GET o HEAD, no es una práctica habitual y puede indicar intentos de evasión. En muchos casos, un primer paso es registrar todas estas peticiones y, si se verifica que son anomalías sospechosas, pasar a bloquear.
• Falta de Content-Type con cuerpo: si hay cuerpo y no hay Content-Type, es un claro indicio de uso incorrecto del protocolo o de intento de evasión de análisis. Aquí suele tener sentido ser más agresivo con el bloqueo, sobre todo en entornos expuestos a Internet.

Además de estas reglas de protocolo, es frecuente encontrar límites de argumentos para proteger frente a desbordamientos y ataques de tipo DoS a nivel de aplicación. Por ejemplo:

• Número máximo de argumentos por petición (por defecto, 255 en algunos WAF).
• Longitud máxima de un argumento individual (por ejemplo, 400 caracteres).
• Tamaño total combinado de todos los argumentos (por ejemplo, 64.000 bytes).

Estos valores son razonables para muchas aplicaciones, pero hay casos —subidas de formularios complejos, filtros avanzados, cargas JSON voluminosas— en los que se disparan falsos positivos. En esos escenarios, el enfoque más prudente es empezar registrando y contando, revisar qué endpoints rompen los límites y ajustar solo para esas rutas, en lugar de levantar todos los límites para todo el sitio.

Falsos positivos: cómo detectarlos y no morir en el intento

Un falso positivo es una petición legítima que el WAF identifica como maliciosa y bloquea o marca como ataque. Son inevitables, especialmente cuando activas conjuntos de reglas amplios como OWASP CRS, pero se pueden gestionar de forma profesional para que no se conviertan en un dolor diario.

La detección de falsos positivos pasa, primero, por una observación cuidadosa de los logs. Revisar qué peticiones están siendo bloqueadas, qué regla las dispara y en qué contexto ocurre (URL, parámetros, usuario, origen, etc.). Herramientas visuales y dashboards ayudan a ver picos de errores 403 o patrones inusuales.

Un enfoque muy recomendado, tanto por proveedores cloud como por la comunidad de ModSecurity, es utilizar un modo simulación o count mode. En este modo, las reglas que quieres probar registran cada coincidencia, pero no bloquean. Así puedes ver, por ejemplo, cuántas peticiones legítimas habría cortado una nueva regla de SQLi antes de atreverse a activarla en producción.

También es buena idea probar las reglas en un entorno de staging o preproducción que reciba tráfico real o simulado. Herramientas como OWASP ZAP o scripts de replay de tráfico pueden ayudarte a simular patrones legítimos y ataques conocidos para comprobar el comportamiento del WAF.

Además, es crucial mirar el impacto operativo y reputacional de los falsos positivos: interrupción de pagos, fallos en el registro de usuarios, llamadas API críticas que fallan sin explicación… Todo ello puede tener un coste directo en ingresos y en imagen de marca. Un exceso de falsos positivos también satura al equipo de seguridad con alertas que no aportan valor, dificultando ver los incidentes de verdad.

Estrategias de ajuste de reglas y uso inteligente del registro

La gestión de falsos positivos no consiste en apagar reglas hasta que “todo funcione”, sino en afinar el WAF con bisturí. Aquí entran en juego buenas prácticas como las siguientes:

Primero, evitar desactivar reglas de forma global. Es preferible crear excepciones muy concretas: excluir el ID de regla solo para una ruta determinada, para ciertos parámetros o para tráfico interno. De esta forma, sigues protegido en el resto de la aplicación y mantienes registros útiles.

Segundo, aprovechar el modo de conteo antes de bloquear. Activar nuevas reglas inicialmente solo en modo registro te permite medir cuántas peticiones legítimas se verían afectadas. Puedes acompañarlo de alertas en el SIEM para detectar rápidamente si una regla genera un volumen anormal de coincidencias.

Tercero, integrar el WAF con un SIEM o plataforma de logging centralizado. Esto facilita correlacionar eventos de WAF con otros indicadores: actividad inusual en sistemas, fallos de autenticación masivos, cambios de configuración sospechosos, etc. También ayuda a priorizar qué reglas ajustar primero según la gravedad y frecuencia de los eventos.

Cuarto, documentar cada cambio: qué regla se ha afinado, para qué endpoint, bajo qué justificación y con qué evidencias. Para esto, consultar la guía de manuales de servidores puede resultar útil. Esta documentación no solo ayuda a mantener el control interno, también es oro puro en auditorías y revisiones de seguridad, donde quieres demostrar que no se desactivan controles a la ligera.

Automatización, machine learning y reglas adaptativas en WAF

A medida que las aplicaciones crecen y el tráfico se vuelve más complejo, gestionar el WAF únicamente a mano se vuelve poco realista. Aquí entran en juego la automatización, el análisis avanzado de logs y, en algunos casos, el uso de machine learning.

En primer lugar, la integración con SIEM permite construir reglas de correlación y respuestas automatizadas: por ejemplo, si un conjunto de IPs dispara repetidamente reglas de inyección o XSS, se puede generar una acción automática para añadir esas IPs a una lista de bloqueo temporal o reforzar el nivel de inspección.

En segundo lugar, algunos WAF incorporan modos de aprendizaje automático (learning mode) que observan el tráfico legítimo durante un periodo definido. A partir de esos datos, proponen o ajustan umbrales, patrones y perfiles de comportamiento normal. Esto ayuda a reducir falsos positivos cuando se pasan reglas a modo bloqueo, y a detectar desviaciones posteriores en el tráfico.

En trabajos de investigación y entornos de laboratorio se han usado técnicas de aprendizaje supervisado para entrenar modelos que distingan entre tráfico legítimo y malicioso, afinando políticas que luego se utilizan en producción. Aunque no es una varita mágica, este enfoque puede ayudar a descubrir patrones sutiles que las reglas clásicas basadas en firmas no detectan con facilidad.

Por último, el testing automatizado continuo (con herramientas como OWASP ZAP, scripts personalizados o pipelines de CI/CD) permite validar que los cambios en el WAF no rompen funcionalidades críticas ni dejan resquicios obvios. Integrar estas pruebas en el ciclo de despliegue hace que la seguridad sea parte natural del flujo de desarrollo, en lugar de un parche de última hora.

Diseño de políticas por aplicación y listas negras por servicio

En entornos complejos —por ejemplo, un proveedor de hosting o un ISP— no basta con una política WAF “única” para todo, especialmente cuando existe TI en la sombra. Es frecuente tener múltiples dominios o aplicaciones detrás de un mismo balanceador, cada una con necesidades de seguridad y perfiles de tráfico distintos. Aquí es donde cobra sentido diseñar políticas y listas específicas por servicio.

Un caso ilustrativo es el de un balanceador HTTP/S que actúa como proxy inverso para varios sitios (por ejemplo, www.empresa1.com y www.empresa2.com) detrás de una sola IP virtual. En este escenario, es posible configurar el WAF para que, nada más llegar la petición, se evalúe el encabezado Host y la IP de origen antes incluso de entrar en el módulo de balanceo.

La lógica sería algo así: el WAF comprueba si la combinación de SERVER_NAME (Host) e IP de cliente coincide con una lista negra específica del sitio. Si la IP figura como prohibida para www.empresa2.com pero no para www.empresa1.com, se responde con un 403 Forbidden solo en el primer caso. El tráfico “limpio” pasa al módulo de balanceo, que decide qué backend sirve la petición.

Esto permite mantener, por ejemplo, listas negras por dominio, en lugar de una lista global para todo el punto de acceso. A nivel de registro, cada rechazo se anota en syslog con detalles como el ID de regla, la condición que ha coincidido, la URL, el host y la IP del cliente, facilitando el análisis posterior y la ampliación o depuración de esas listas.

La moraleja es que, cuanto más segmentadas estén tus políticas (por aplicación, por entorno, por tipo de usuario), más fino puedes hilar el equilibrio entre registro y bloqueo: puedes ser muy estricto en portales administrativos y algo más flexible en webs informativas, por ejemplo, siempre con evidencia en los logs de por qué se ha tomado cada decisión.

Más allá del WAF clásico: WAAP y protección de APIs

El panorama de amenazas no se ha quedado quieto. Hoy en día, muchas aplicaciones son nativas de la nube, usan arquitecturas de microservicios y exponen APIs públicas y privadas que se convierten en el objetivo principal de los atacantes. El WAF tradicional ha ido evolucionando hacia plataformas más amplias conocidas como WAAP (Web Application and API Protection) o WAAS (Web Application & API Security).

Estas soluciones no solo descubren automáticamente aplicaciones web, también identifican endpoints de API, aceptan especificaciones como OpenAPI o Swagger y usan esa definición para comprobar la conformidad de las peticiones: tipos de datos esperados, parámetros permitidos, límites de tamaño, etc. Según el endpoint (por ejemplo, uno que maneja datos muy sensibles), se puede aplicar un nivel de escrutinio y bloqueo mucho más alto.

A nivel de registro, WAAP tiende a generar eventos más ricos en contexto: qué endpoint exacto de la API se ha atacado, qué operación (GET, POST, PUT…), qué usuario o token estaba implicado, qué parte de la especificación se ha violado, etc. Esto permite ajustar mejor las decisiones de bloqueo, en vez de basarse solo en patrones genéricos de payload.

Además, muchas herramientas WAAP incluyen protección DoS específica para aplicaciones y APIs, filtrado por geolocalización, reputación de IPs, detección de bots y scraping, y opciones de personalizar niveles de alerta por servicio. De nuevo, se trata de tener la flexibilidad de decidir dónde quieres mano dura y dónde priorizar fluidez, sin renunciar a una buena base de registros para investigar cualquier incidente.

En conjunto, un WAF bien ajustado —ya sea clásico, basado en WAAP o integrado en un ecosistema en la nube— se convierte en un componente esencial de la defensa moderna de aplicaciones y APIs, capaz de combinar registro detallado, bloqueo inteligente y adaptación continua al cambiante panorama de amenazas.