WAF en modo registro: cómo habilitar gradualmente la protección sin bloquear el tráfico legítimo

Existe una suposición común de que habilitar WAF es una decisión binaria: está bloqueando o no. Los equipos que comienzan desde este punto activan los conjuntos de reglas administrados en modo Bloque directamente en producción, asumen que las reglas son lo suficientemente conservadoras y luego descubren que el formulario de carga del contrato dejó de funcionar, que la integración con pasarela de pago está devolviendo 403 y que el equipo de soporte está recibiendo quejas de clientes que no pueden iniciar sesión. El WAF no se equivocó, pero tampoco conocía la aplicación.

Qué hace el modo Registro y por qué existe

Cloudflare WAF tiene tres acciones posibles para cada regla: Bloquear, que devuelve 403 y finaliza la solicitud; Desafío, que presenta un desafío al cliente; y Log, que registra la ocurrencia sin interferir con el flujo. El modo de registro es el único que permite observar el comportamiento de las reglas frente al tráfico real sin consecuencias para los usuarios.

Cuando un conjunto de reglas se configura con una acción de registro, todas las reglas se activan normalmente (evaluar encabezados, URI, cuerpo, cadena de consulta), pero en lugar de bloquear, simplemente registran el evento. Firewall Events en el panel de Cloudflare captura cada activador: la IP de origen, el URI completo, el ID de regla específico y el contenido exacto que causó la coincidencia. La solicitud llega intacta al servidor de origen. El usuario no nota nada.

La secuencia de despliegue que previene incidentes

El proceso comienza habilitando todos los conjuntos de reglas administrados con la acción establecida en Registrar. El nivel de paranoia de OWASP debe establecerse en 1 desde el principio: este nivel captura los patrones de ataque más obvios con el menor volumen de falsos positivos. Subir al nivel 2 o 3 en la primera activación casi garantiza un ruido excesivo que dificulta distinguir los ataques reales del tráfico legítimo y mal formateado.

Con los conjuntos de reglas en Registro, el panel de Eventos del Firewall se debe revisar diariamente. El objetivo es identificar reglas que se activan de manera consistente en solicitudes legítimas: el mismo URI, el mismo patrón de solicitud, la misma regla. Un plano aislado puede ser ruido; El mismo desencadenante en miles de solicitudes de usuarios reales es un falso positivo que bloqueará el tráfico cuando la acción cambie a Bloquear.

Cuando se identifica un falso positivo, la respuesta es crear una regla de omisión: una regla de firewall que indica al WAF que ignore conjuntos de reglas o reglas específicas cuando coinciden criterios como URI y método HTTP. Un punto final /api/upload que activa la regla 100035 porque acepta archivos con una extensión .php en su nombre recibe una regla de omisión que excluye esa ruta de la inspección mediante esa regla. La exclusión es quirúrgica: el resto del tráfico sigue siendo evaluado.

Después de una o dos semanas con los conjuntos de reglas en Registro, los falsos positivos manejados con reglas de Omisión y sin nuevos activadores en el tráfico legítimo, la acción cambia a Bloquear. El criterio es la estabilidad, no el tiempo transcurrido.

Leer eventos de firewall con precisión

El panel de Eventos del Firewall muestra cada evento con suficiente detalle para tomar una decisión. Además de la IP y el URI, el evento muestra el ID de la regla que se activó (un identificador como 949110 o 100035 consultable en la documentación de Cloudflare) y los datos coincidentes, la parte específica de la solicitud que provocó la coincidencia.

Este campo de datos combinados transforma la investigación de un falso positivo de especulación a un diagnóstico concreto. Si la regla 100035 se activa en POST /api/upload y los datos coincidentes muestran filename=relatorio.php, está claro que la regla reacciona al nombre del archivo, no al contenido malicioso en el cuerpo. La regla de omisión resultante es precisa: ignora la regla 100035 sólo para ese camino. Cualquier otro endpoint que reciba un .php realmente sospechoso continúa siendo evaluado.

Las alertas de notificación de nuevos eventos WAF cierran el ciclo de detección continua. Cuando Cloudflare agrega una nueva firma a un CVE en circulación, la alerta notifica al equipo y Firewall Events muestra si la nueva regla está afectando el tráfico legítimo antes de que sea demasiado tarde.

Integración de análisis WAF y SIEM

Para equipos con operaciones de seguridad establecidas, los datos de Firewall Events se pueden exportar a través de Logpush. Logpush envía eventos WAF a R2, S3, Datadog o Splunk con el conjunto completo de campos: marca de tiempo, IP, país, URI, método, ID de regla, acción realizada y datos coincidentes. Para un equipo con un SOC activo, estos datos alimentan correlaciones que el panel de Cloudflare no proporciona: patrón de ataque distribuido por múltiples IP contra el mismo punto final en el transcurso de horas, variaciones de carga útil que prueban qué regla se puede eludir.

WAF Analytics agrega estos eventos en una serie temporal dentro de Cloudflare. Cuando la acción cambia de Registrar a Bloquear, un aumento inesperado en las respuestas 403 en el tráfico normal indica un falso positivo que escapó de la fase de observación, y el ID de la regla en el evento le indica exactamente qué manejar.

Desarrollar hábitos operativos

WAF no es una configuración única. Las aplicaciones cambian: se agregan nuevos puntos finales, las integraciones de terceros introducen patrones de solicitud que WAF nunca ha visto y Cloudflare actualiza periódicamente los conjuntos de reglas administrados.

Lo que funciona es asignar responsabilidades explícitas: alguien de la plataforma o del equipo de seguridad revisa los eventos del firewall semanalmente. La revisión busca nuevos patrones: reglas que se activan en gran volumen y que no aparecían antes, un aumento en los bloqueos en las horas pico. Cuando un nuevo punto final entra en producción, la secuencia de observación comienza nuevamente para esa ruta: registrar primero, omitir reglas para falsos positivos, bloquear después.