Existe la creencia común de que habilitar el conjunto de reglas administrado de Cloudflare y el conjunto de reglas principales de OWASP es suficiente para tener una aplicación protegida. La premisa ignora para qué fueron diseñados estos conjuntos de reglas y lo que deliberadamente no hacen.
Los conjuntos de reglas administrados son una protección de amplio espectro. Fueron creados para funcionar en cualquier aplicación web, desde un blog de WordPress hasta una API de pagos, sin ningún conocimiento de lo que hace que su aplicación sea diferente de cualquier otra. Esto es precisamente lo que los limita.
Qué cubren los conjuntos de reglas gestionados y dónde generan fricción
El conjunto de reglas administrado de Cloudflare se actualiza automáticamente cuando Cloudflare detecta nuevos kits de exploits, firmas de ataques a gran escala y explotación activa de CVE en software popular. Para un equipo sin un equipo de seguridad dedicado, esto tiene un valor real: cobertura continua sin mantenimiento manual.
El conjunto de reglas básicas de OWASP funciona con clases de ataques catalogadas: inyección SQL, XSS, inclusión de archivos, deserialización insegura. El modelo de puntuación acumula puntos a medida que las reglas se activan en la misma solicitud y la acción ocurre cuando el total cruza un umbral configurable. Este diseño reduce los falsos positivos de reglas aisladas muy sensibles, pero no los elimina.
Los falsos positivos aparecen como era de esperar en tres contextos. Los puntos finales de API que aceptan JSON con comillas, apóstrofes o paréntesis chocan con las reglas SQLi: el motor ve el formulario, no el contexto. Los paneles administrativos con editores de texto enriquecido activan reglas XSS cuando el usuario guarda HTML legítimo en un POST. Los puntos finales de carga binaria permiten reglas de inspección corporal calibradas por texto. Ninguno de estos son ataques; todos son comportamientos de aplicaciones legítimos.
¿Qué reglas personalizadas te permiten hacer?
Las reglas personalizadas operan con conocimientos que los conjuntos de reglas administrados nunca tendrán: el comportamiento específico de su aplicación, el perfil del tráfico legítimo, las amenazas relevantes para su caso de uso.
El lenguaje de expresión de Cloudflare admite condiciones compuestas con and, or y not. Un bloqueo por país de origen ip.geoip.country eq "RU" combinado con http.request.uri.path eq "/api/register" restringe solo el punto final del registro, sin tocar el resto. El campo cf.threat_score gt 10 bloquea las IP con mala reputación sin necesidad de listas negras manuales.
Las listas de permitidos para fuentes confiables son tan importantes como las reglas de bloqueo. Las IP de monitoreo, CI/CD y los operadores internos deben excluirse de todas las inspecciones y se debe aplicar una regla Permitir antes que las demás. Sin esto, una verificación de estado arroja 403 y una implementación provisional se atasca en la limitación de velocidad: horas de investigación de un problema que no debería existir.
La limitación de velocidad en puntos finales sensibles pertenece a reglas personalizadas. Los inicios de sesión, la recuperación de contraseñas y los puntos finales OTP tienen perfiles de tráfico muy diferentes al resto de la aplicación. Una regla que limita de 6 a 5 solicitudes por minuto por IP protege contra el relleno de credenciales sin afectar ninguna otra ruta.
El bloqueo de agentes de usuario de scraper maliciosos también encaja aquí: http.user_agent contains "Scrapy" o http.user_agent eq "" son filtros que un conjunto de reglas genérico no implementará porque dependen de su decisión sobre qué fuentes excluir.
Cómo resolver los falsos positivos sin abrir lagunas
Cuando un conjunto de reglas administrado se activa incorrectamente, al deshabilitar la regla globalmente se elimina la protección de todas las demás rutas en las que funcionó. La respuesta correcta es una regla de omisión con alcance preciso: http.request.uri.path eq "/api/content" and cf.waf.rule_id eq "100016" deshabilita la regla 100016 solo para esa ruta, manteniendo la cobertura en toda la aplicación. Determinar el alcance por cf.waf.rule_id en lugar de por grupo de reglas es la diferencia entre una excepción quirúrgica y un agujero.
Los identificadores de reglas aparecen en los registros de actividad cuando la regla se activa en el modo Registro, otra razón más por la que el período de observación es obligatorio antes de cualquier bloqueo.
Cómo calibrar planes según lo disponible
El plan gratuito ofrece 5 reglas personalizadas y no tiene acceso a conjuntos de reglas administrados. Con 5 reglas, la prioridad es clara: lista permitida de IP internas, bloqueo por alto cf.threat_score, limitación de velocidad en el punto final más crítico. Intentar cubrir todo con cinco reglas da como resultado reglas demasiado amplias con efectos secundarios impredecibles.
El plan Pro llega hasta 20 reglas y desbloquea conjuntos de reglas administrados. El plan Business llega a 100, lo que le permite crear diferentes perfiles de protección por grupo de puntos finales: API públicas con limitación de velocidad más permisiva, paneles administrativos con inspección más agresiva, webhooks de socios con listas permitidas por IP de origen. Con 20 reglas usted toma decisiones; con 100 haces política.
El proceso de calibración que funciona en la práctica
El orden de las operaciones importa más que la configuración específica de cada regla. Comenzar con el bloqueo activo en una aplicación de producción sin una línea base de tráfico es una receta para interrumpir a los usuarios reales.
La secuencia comienza con todos los conjuntos de reglas administrados en modo Registro durante siete a catorce días. El panel de actividad de WAF acumula datos reales: qué reglas se activarían, con qué frecuencia, en qué rutas. Con este mapeo, usted identifica candidatos falsos positivos antes de que se conviertan en incidentes, escribe reglas de omisión con el alcance correcto y configura listas de permitidos y reglas de bloqueo personalizadas.
Sólo entonces tiene sentido pasar a Desafío o Bloqueo administrado, comenzando con las reglas con el menor riesgo de falso positivo (CVE específicos) y avanzando a las más amplias (OWASP SQLi, OWASP XSS) a medida que gane confianza. Calibrar el umbral del conjunto de reglas básicas de OWASP es la última decisión, porque depende de ver la distribución real de las puntuaciones en el tráfico de su aplicación.
WAF calibrado es un proceso iterativo. El tráfico cambia, la aplicación cambia, las nuevas características crean patrones de solicitud que el conjunto de reglas no conocía. Un punto final lanzado sin las correspondientes reglas de omisión generará falsos positivos que solo aparecerán en producción, en el momento equivocado.
Lea también
- Lo que todavía pasa por WAF: técnicas de derivación y cómo mitigar
- DNS proxy vs DNS solamente: qué cambia y cuándo tiene sentido cada modo
- DNSSEC con Cloudflare: qué protege, qué no protege y cómo activar sin problemas
- Cloudflare WAF: Lo que la protección administrada realmente bloquea y lo que aprueba
- WAF en modo registro: cómo habilitar gradualmente la protección sin bloquear el tráfico legítimo
- WAF + Limitación de velocidad + Gestión de bots: la trifecta de protección de bordes