Cloudflare WAF: lo que realmente bloquea la protección administrada y lo que aprueba

La mayoría de equipos activan Cloudflare WAF como si instalaran un antivirus: una vez configurado, el problema está solucionado. Esta premisa es errónea y el costo de no entenderla es una falsa sensación de seguridad que puede ser más peligrosa que ninguna protección.

WAF es una capa eficaz contra una clase específica de amenazas. Contra otra clase, proporciona fricción, no barrera. Conocer la diferencia determina cómo se calibra el sistema y qué se debe construir a nivel de aplicación.

Qué hacen realmente los conjuntos de reglas gestionados

Las reglas administradas cubren las clases de ataques más comunes: inyección SQL, secuencias de comandos entre sitios, recorrido de directorio, carga de shell web, explotación de CVE conocidos en marcos populares. Funcionan mediante coincidencia de firmas: el motor inspecciona la solicitud y comprueba si algún patrón coincide con los registrados en las reglas.

Este modelo tiene una limitación intrínseca: opera sobre la forma de la solicitud, no sobre su significado para la solicitud. Una regla que detecta ' OR 1=1 -- en un parámetro de consulta desencadenará un ataque SQLi y un usuario legítimo que buscará tutoriales de SQL. La regla no tiene forma de saber qué representa ese parámetro en el contexto de su aplicación: solo ve bytes.

Esto genera falsos positivos predecibles. En aplicaciones con editores de texto enriquecido, los puntos finales que aceptan HTML como entrada legítima fallan en las reglas XSS. Las API que reciben JSON con caracteres especiales entran en conflicto con las reglas SQLi. La protección es real, pero no quirúrgica.

Qué puede hacer un atacante paciente

Los conjuntos de reglas administrados son excelentes contra ataques a productos básicos: escáneres automatizados, herramientas como sqlmap en modo estándar, scripts kiddies que activan cargas útiles genéricas. Cualquiera que use estos vectores sin personalización presionará WAF y se detendrá allí.

El escenario diferente es que el atacante sabe qué WAF está protegiendo al objetivo (a menudo información pública a través de encabezados, cookies o comportamiento de respuesta). Con este conocimiento, prueba sistemáticamente técnicas de bypass: codificación inusual (codificación de URL en múltiples niveles, normalización Unicode, mayúsculas y minúsculas en palabras clave SQL), cargas útiles fragmentadas en cuerpos grandes, combinaciones que explotan el límite de procesamiento del motor.

Contra un atacante decidido que personaliza las cargas útiles para el objetivo específico, WAF añade trabajo, no imposibilidad. Esto todavía tiene valor: aumentar el costo de un ataque reduce la cantidad de atacantes dispuestos a pagar por él. Pero no es una barrera absoluta y tratarla como tal es peligroso.

Hay una categoría de vulnerabilidad en la que WAF simplemente no encaja: la lógica empresarial. Si su aplicación permite a un usuario ver los datos de otra persona manipulando los ID en la URL (IDOR), WAF no lo detectará. La solicitud es formalmente válida, sin carga útil maliciosa. El problema está en la lógica de la aplicación y la única protección eficaz está en el código.

Niveles y lo que realmente cubre cada plan

La protección DDoS de capa 3 y 4 está disponible en todos los planes, siempre activada y sin configuración: mitigación volumétrica en el borde, antes de que el tráfico llegue a su infraestructura.

El WAF de capa 7, con reglas administradas, comienza en el plan Pro a $20 por mes. Este nivel desbloquea el conjunto de reglas administrado de Cloudflare y el conjunto de reglas principales de OWASP. El plan gratuito solo permite 5 reglas personalizadas, sin acceso a ningún conjunto de reglas administrado. Para la mayoría de aplicaciones con requisitos de seguridad reales, Pro es el suelo mínimo aceptable.

Las acciones disponibles por regla son: Bloquear (devuelve 403 inmediatamente), Desafío (muestra un desafío de JavaScript que los bots no pueden resolver), Desafío administrado (Cloudflare decide automáticamente el nivel del desafío), Registrar (registra sin realizar ninguna acción), Omitir (omite reglas específicas o grupos completos) y Permitir (pasa sin inspección). La composición de estas acciones es donde ocurre gran parte de la calibración.

Un detalle que lo invalida todo

Hay un requisito previo que no es obvio en la documentación inicial: WAF solo funciona para registros DNS con el proxy Cloudflare activo, lo que la interfaz llama "nube naranja". Los registros configurados como solo DNS (icono gris) apuntan directamente a la IP de origen. El tráfico no pasa por Cloudflare, por lo que no se aplican reglas WAF, ni mitigaciones de DDoS periféricas ni desafíos de JavaScript.

Esto afecta a los subdominios que se dejan como DNS únicamente por conveniencia: entornos de prueba, API internas a las que se accede desde el exterior, servicios auxiliares. Si el atacante descubre estos subdominios (y las herramientas de enumeración DNS hacen que esto sea trivial), tiene una ruta directa al origen sin pasar por el WAF. Mapear sus registros DNS y el estado de cada uno debe ser parte de la auditoría de seguridad.

Lo que tu equipo necesita decidir antes de activarse

Habilitar conjuntos de reglas administrados sin un período de observación es una receta para bloquear el tráfico legítimo en producción. El camino operativamente seguro comienza con todas las reglas en el modo Registro: ves lo que se bloquearía sin bloquear nada, analizas el patrón de disparo e identificas falsos positivos antes de cambiar a Bloquear o Desafío.

La decisión más crítica es cómo manejar las reglas que se activan incorrectamente. Deshabilitar la regla globalmente crea una laguna para el ataque real contra el que protegía. La respuesta correcta es una regla de omisión con alcance preciso: esta regla administrada específica, en esta ruta específica, para esta condición específica. El alcance cerrado preserva la cobertura durante el resto de la aplicación.

También vale la pena decidir de antemano el umbral de sensibilidad para el conjunto de reglas básicas de OWASP. Funciona por puntuación acumulada: cada regla que se activa suma puntos y la acción ocurre cuando el total excede un límite configurable. Un límite demasiado bajo bloquea el tráfico legítimo; demasiado alto, no detecta ataques sofisticados. El punto de equilibrio depende de la naturaleza de su aplicación y del perfil de tráfico observado.