WAF, cache y hardening con Cloudflare Free, sin morir en el intento

Con Traefik y AOP, firewall por IPs y monitor del token funcionando, la mitad del valor de tener Cloudflare delante todavía está sin explotar. Esta entrega es sobre lo que hago en el lado de Cloudflare, las reglas WAF que filtran tráfico hostil antes de llegar al origen, el rate limiting de los endpoints sensibles, el hardening de la zona (SSL/TLS, HSTS, Bot Fight Mode) y un par de Cache Rules que reducen drásticamente el tráfico hacia el VPS para los proyectos con bundles hasheados.

Todo lo que cuento está dentro del plan Free. CF Pro elimina varias limitaciones y simplifica algunas reglas, pero el objetivo era ver hasta dónde se puede llegar sin pasar por caja. Spoiler, bastante lejos.

Limitaciones del plan Free que conviene tener claras

Antes de abrir el dashboard, las restricciones que marcan el diseño.

• 5 Custom Rules por zona. No hay margen para experimentar, cada slot cuenta.
• 1 Rate Limit Rule por zona.
• Las Rate Limit Rules en Free no permiten usar el campo ip.src en la expresión, ni directo ni con not (ip.src in $lista). Esto significa que no puedes excluir tu propia IP del rate limit dentro de la regla. La salida es una Custom Rule de tipo Skip que se ejecuta antes y exime tu IP del resto de reglas.
• La acción de un Rate Limit en Free es solo Block. No tienes Managed Challenge, JS Challenge, ni Log only.
• En Custom Rules (no Rate Limit) sí funciona ip.src in $lista. La asimetría no es intuitiva pero es la que hay.

Una IP List a nivel cuenta para tu IP de confianza

Antes de tocar la zona, en Manage Account, Configurations, Lists, creé una IP List llamada trusted_ips con mi IP de casa. Es una lista a nivel cuenta, así que la puedo referenciar desde cualquier zona como $trusted_ips. Si cambia mi IP, edito un solo sitio y todas las zonas se actualizan.

Las cinco recetas WAF

Receta D, Skip para trusted IPs (slot 1, siempre primero)

Esta regla se ejecuta antes que ninguna otra y exime mi IP del resto del WAF y del rate limit. Sin esto, cuando hago pruebas contra mis propias APIs me autobloqueo a los pocos segundos.

• Expresión, ip.src in $trusted_ips
• Acción, Skip
• Componentes a omitir, marcar al menos uno (la UI da error si dejas todo desmarcado), normalmente marco Custom rules restantes, Rate limiting rules y Super Bot Fight Mode.
• Orden, primero.

Le dedico un slot pero a cambio puedo ser tan agresivo como quiera con el resto de reglas sin riesgo de morder mi propia mano cuando trabajo desde casa.

Receta A, geoblock por país

• Expresión, (ip.src.country in {"RU" "CN" "KP" "IR" "BY"}) and not (ip.src in $trusted_ips)
• Acción, Managed Challenge.

Lista corta y conservadora, países desde los que objetivamente no espero tráfico legítimo en proyectos personales y desde los que recibo cantidades desproporcionadas de scanners. Managed Challenge en lugar de Block deja la puerta abierta a un visitante humano (que pueda resolver el reto) sin abrirla a bots automatizados. La cláusula not (ip.src in $trusted_ips) es por seguridad, aunque ya tengo Receta D que skip-ea, prefiero la doble red.

Receta E, bloquear paths de scanner

• Expresión:
  Copiar

  (starts_with(http.request.uri.path, "/wp-")) or
  (http.request.uri.path contains "/.env") or
  (http.request.uri.path contains "/.git/") or
  (http.request.uri.path contains "/phpmyadmin") or
  (http.request.uri.path eq "/xmlrpc.php") or
  (http.request.uri.path contains "/.aws/") or
  (http.request.uri.path contains "/.ssh/") or
  (http.request.uri.path contains "/.DS_Store")

• Acción, Block.

Ninguno de mis proyectos sirve estas rutas. Cualquier petición a estas rutas es siempre hostil, así que no tiene sentido contarlas para un rate limit. Block instantáneo es preferible a darle al atacante 5 intentos antes de cortar.

Receta B, rate limit en /admin con métodos de escritura

Esta receta usa la única Rate Limit Rule disponible en Free. Limita los intentos contra el endpoint de admin de mi blog y, de paso, contra rutas clásicas de scanner que no estaban en E (porque la receta E las bloquea ya, esto es duplicación intencional para zonas donde no aplique E).

• Expresión:
  Copiar

  (http.request.uri.path eq "/admin" and http.request.method in {"POST" "PUT"}) or
  (starts_with(http.request.uri.path, "/wp-")) or
  (http.request.uri.path contains "/.env") or
  (http.request.uri.path contains "/phpmyadmin") or
  (http.request.uri.path eq "/xmlrpc.php")

• Características, IP. Umbral, 5 peticiones en 10 segundos. Acción, Block 10 segundos.

El method in {"POST" "PUT"} evita que la navegación normal del panel admin (peticiones GET de la SPA) consuma el contador. Solo cuentan los intentos de login o de modificación.

En zonas con varios subproyectos (la mía con muchas APIs distintas) la receta B no es la mejor opción y prefiero un rate limit más genérico tipo starts_with(http.request.uri.path, "/api/"). Como el slot es uno, eliges según el perfil de la zona.

Hardening de zona

Seguridad > Configuración

• Bot Fight Mode, ON.
• Browser Integrity Check, ON.
• Security Level, Medio.
• Challenge Passage, 30 minutos (default).
• Privacy Pass Support, ON si aparece.

SSL/TLS

• Always Use HTTPS, ON.
• Automatic HTTPS Rewrites, ON.
• Minimum TLS Version, TLS 1.2. No subo a 1.3. La razón es que los clientes 1.3 ya negocian 1.3 incluso con mínimo 1.2 (la negociación elige lo más alto soportado por ambos extremos), pero subir el mínimo a 1.3 expulsa a clientes legítimos con stack viejo (curl antiguos, webhooks de proveedores con stack lento de actualizar, monitores). Reviso a los pocos meses, si Análisis > SSL/TLS me dice que el 0% del tráfico usa 1.2, entonces sí lo subo.
• TLS 1.3 (toggle separado), ON.
• Opportunistic Encryption, ON.

HSTS, conservador

Esta es la decisión más delicada del hardening, porque HSTS es efectivamente irreversible. Si activas HSTS con includeSubDomains y un subdominio futuro tiene un fallo de TLS temporal, los visitantes que ya hayan cacheado el header no podrán entrar y no hay forma de saltar el error en el navegador. Y si añades preload, sales de la lista codificada en navegadores tardándote meses.

Mi configuración inicial es deliberadamente prudente.

• Estado, On.
• Max Age, 6 meses.
• Incluir subdominios, OFF.
• Preload, OFF.
• No-Sniff Header, ON.

En 1 a 2 meses sin incidentes, valoro ampliar a includeSubDomains. Preload solo lo encendería si tengo total certeza operacional. La regla mental es HSTS estricto se gana, no se elige.

Cache Rules, lo que sí cachea bien CF Free

Una de las cosas que cambia drásticamente la experiencia (y el ancho de banda hacia mi VPS) son las Cache Rules para los assets estáticos. Con bundles modernos hasheados (Vite, Webpack, Next.js) los nombres de fichero ya incluyen un hash de contenido, así que cualquier cambio cambia el nombre y no hay riesgo de servir contenido obsoleto. La conclusión natural es cache largo, sin remordimiento.

Mi origen (Express sirviendo la carpeta dist/ de Vite) enviaba Cache-Control: public, max-age=14400, 4 horas. Es razonable pero conservador, los assets podrían cachearse mucho más. Una sola Cache Rule cubre los proyectos Vite que hospedo.

• Expresión:
  Copiar

  (http.host in {"e2e.mi-zona.com" "otra-app.mi-zona.com"}) 
  and starts_with(http.request.uri.path, "/assets/")

• Ajustes:
  • Elegibilidad, Elegible para caché.
  • Edge TTL, Ignorar Cache-Control del origen y usar este TTL, 1 año (31536000s).
  • Browser TTL, Override origin, 1 año.

Resultado, los /assets/index-HASH.js dejan de tocar mi VPS prácticamente nunca tras la primera petición. Y como el HASH cambia con cada deploy, no hay riesgo de servir versiones antiguas.

Heurística para añadir Cache Rules con seguridad

1. curl -sI https://<host>/path-a-un-estatico dos veces.
2. Si la segunda ya es cf-cache-status: HIT con un cache-control razonable, no toques.
3. Si ves MISS→HIT con max-age corto y el archivo tiene hash en el nombre (foo-HASH.js), override TTL a 1 año es seguro.
4. Si el archivo no tiene hash (styles.css, app.js), no subas TTL. Cualquier deploy futuro serviría contenido obsoleto durante toda la ventana de cache.

Lo que descarté: cachear Next.js 16 en CF Free

Probé cuatro caminos para cachear endpoints públicos de mi blog (Next.js 16 App Router). Ninguno dio HIT estable. La razón es que Next.js 16 inyecta automáticamente la cabecera Vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch en todas las respuestas, y CF Free solo acepta Vary: Accept-Encoding como cacheable. Cualquier otra cosa convierte la respuesta en cf-cache-status: DYNAMIC, sin cache.

Los caminos probados y descartados.

• Middleware Next.js que reescribe la cabecera Vary a Accept-Encoding. Next.js inyecta su Vary después, llegan dos cabeceras y CF se queda con la más estricta.
• Fijar Vary en el Route Handler, mismo problema.
• Response Header Transform Rule en CF que elimina Vary, parece aplicarse después de la decisión de cache.
• Cloudflare Worker Free con caches.default, el strip funciona pero el Cache API empieza a fallar y al final el Worker abre fallback abierto sin cache.

Soluciones realistas, subir a CF Pro para Custom Cache Key que ignore Vary, meter un proxy delante de Next que reescriba antes de llegar a CF, o esperar a una versión de Next que permita opt-out del RSC Vary (no existe hoy). Lo dejé documentado y abandoné el camino. No todas las batallas merecen pelearse.

Cómo aplicar todo a una zona nueva, en orden

El orden de las operaciones evita ventanas de autobloqueo.

1. Asegurar que tu IP está en la IP List trusted_ips (nivel cuenta).
2. Crear las reglas en este orden, primero la D (Skip), luego A (geoblock), luego E (block scanner paths). Después decidir B o un rate limit genérico según el perfil de la zona.
3. Aplicar Security Settings (Bot Fight Mode, Browser Integrity Check, Security Level).
4. Aplicar SSL/TLS (Always HTTPS, Min TLS 1.2, HSTS conservador).
5. Validar desde tu IP normal, todo carga.
6. Validar desde una IP fuera de trusted_ips (móvil con datos), un GET a /.env debe devolver 403.

Trampas de la UI

• Skip sin checkboxes, la UI da error action parameters are required for the skip action. Hay que marcar al menos un componente a omitir.
• Banner rojo persistente, el error de Skip puede seguir visible en pantallas siguientes aunque ya no aplique. Se cierra con la X y, si el formulario actual es válido, Implementar funciona.
• Rate Limit con ip.src, no funciona en Free. Si lo intentas, error literal not entitled, the use of field ip.src is not allowed.
• Regla creada en zona DNS only, se puede pre-configurar pero no aplica hasta que algún registro pase a nube naranja.

Lo que vendría con CF Pro o superior

Si en algún momento subo a Pro, las cosas que cambian.

• Managed Challenge en Rate Limits (mejor UX para el usuario legítimo).
• ip.src in $trusted_ips directo en expresiones de Rate Limit (elimina la necesidad de la receta D).
• Más Rate Limit Rules por zona, separar /admin de /api/ en reglas distintas.
• Managed Rules de Cloudflare (OWASP Core Rule Set gestionado).
• Custom Cache Key para sortear el problema del Vary RSC de Next.js.

Lo que sigue

Con esto el lado Cloudflare está cubierto. Edge filtra, cachea lo que puede y endurece TLS. La última pieza de la serie es algo que no se ve hasta que pasa, un bug silencioso que aparece en cualquier app que dependa de la IP del cliente cuando metes Cloudflare delante de Traefik. Lo cuento en el post final.