Guía de reglas de firewall de Cloudflare para principiantes: 5 reglas gratuitas filtran el 80% del tráfico malicioso (plantillas incluidas)

Introducción

Los logs del servidor llenos de solicitudes de escaneo, miles de accesos maliciosos al día. Tienes Cloudflare en el plan gratuito pero sin ninguna regla de firewall configurada: es como ir desprotegido. Copias tutoriales de internet, pegas el código y no funciona: la prioridad de las reglas estaba al revés.

Esas expresiones como (ip.src.country eq "CN") dan dolor de cabeza al principio, pero tras varios días de pruebas descubrí que las 5 reglas del plan gratuito de verdad bastan. Bien configuradas filtran más del 80% de solicitudes maliciosas sin perjudicar a usuarios legítimos. Este artículo te enseña a configurar esas 5 reglas: principios, prioridades y plantillas listas para usar. En 30 minutos lo tienes.

Capítulo 1: Por qué bastan las 5 reglas del plan gratuito

Mucha gente ve que Cloudflare gratuito solo ofrece 5 reglas personalizadas y piensa: «Esto no puede bastar». El plan Pro tiene 20; ¿hay que actualizar?
Espera, escucha primero.
La mayoría del tráfico malicioso viene de unas pocas fuentes: escáneres en centros de datos, IPs con alta puntuación de amenaza y User-Agent anómalos. Según la experiencia de la comunidad de Cloudflare, 5 reglas bien configuradas bloquean más del 80% de los ataques.

Es la clásica regla 80/20.
Además de las 5 reglas personalizadas, el plan gratuito incluye el Cloudflare Free Managed Ruleset (conjunto de reglas gestionadas gratuito). Está activado por defecto y protege vulnerabilidades críticas como Shellshock y Log4J. Conjunto gestionado + 5 reglas personalizadas: para sitios pequeños y medianos, de verdad basta.
Las 15 reglas extra del plan Pro sirven más para operaciones granulares: varios subdominios con políticas distintas o APIs con estrategias diferentes. Si tu sitio no es tan complejo, 5 reglas cubren la protección esencial.
Claro, siempre que las uses bien. Si la prioridad está mal, 10 reglas no sirven de nada.

Capítulo 2: El secreto de la prioridad de las reglas

Aquí es donde más se tropieza. Yo también empecé con el orden al revés y las reglas que había escrito con esfuerzo no hacían nada.
Las reglas de firewall de Cloudflare se evalúan de arriba abajo, como una cadena de montaje. Primero la regla 1, luego la 2, y así sucesivamente. Cuando una regla coincide, se ejecuta la acción (Allow, Block, Challenge, etc.) y se detiene (excepto Allow, que sigue evaluando).
Imagina al vigilante de tu portal:

1. Primero reconoce: si es de la familia, pasa directo (lista blanca)
2. Luego verifica: desconocidos muestran identificación (desafío)
3. Por último bloquea: sospechosos, fuera (bloqueo)
   Si inviertes el orden y bloqueas antes de verificar, los visitantes legítimos no entran.
   Error habitual: poner el bloqueo por país antes de la lista blanca. Usas UptimeRobot u otro servicio de monitorización extranjero, pero tu primera regla dice «bloquear todas las IP que no sean de China»; el monitor queda bloqueado y no te enteras de que el sitio está caído.
   Enfoque correcto: la lista blanca siempre en primer lugar. Primero deja pasar el tráfico bueno conocido (rastreadores, monitorización, tus propias IP), luego endurece la protección.
   Otro detalle fácil de pasar por alto: las acciones también tienen prioridad. Entre reglas del mismo nivel:

• Allow (permitir) > Skip (omitir) > Challenge (desafío) > Block (bloquear) > Log (registrar)
  Si una solicitud coincide con Allow y Block, gana Allow. Por eso la lista blanca va al principio: máxima prioridad y sin falsos positivos.

Capítulo 3: Las 5 reglas de oro

Basta de teoría; vamos al grano. Estas 5 reglas están ordenadas por prioridad de mayor a menor; puedes copiarlas directamente.

Regla 1 (máxima prioridad): Lista blanca — protege a tus aliados

Función: dejar pasar tráfico legítimo conocido y evitar falsos positivos.
Casos de uso:

• Rastreadores de buscadores (Google, Bing, Baidu, etc.)
• Servicios de monitorización (UptimeRobot, StatusCake, etc.)
• IP de tu oficina y de casa
  Expresión:

(cf.client.bot) or (ip.src in {1.2.3.4 5.6.7.8})

Acción: Allow
Notas:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

• cf.client.bot identifica rastreadores legítimos verificados por Cloudflare, incluidos Google y Bing
• Sustituye {1.2.3.4 5.6.7.8} por tus IP, separadas por espacios
• Si no necesitas lista blanca por IP, simplifica a (cf.client.bot)

Regla 2: Desafío ASN de centros de datos — filtra tráfico de datacenter

Función: verificación humana para tráfico procedente de centros de datos.
Casos de uso:
Escáneres y herramientas de rastreo suelen alojarse en VPS y servidores cloud; los usuarios normales rara vez acceden desde IP de datacenter. Un desafío y los bots se retiran.
Expresión:

(ip.geoip.asnum in {13335 15169 16509 14618 45090})

Acción: Managed Challenge
Tabla de ASN (datacenters habituales):

Regla 3: Puntuación de amenaza + filtro de IP de riesgo

Función: bloquear IPs de alto riesgo según la inteligencia de amenazas de Cloudflare.
Casos de uso:
Cloudflare puntúa cada IP (0-100); cuanto más alto, más peligroso. Más de 10 puede ser spam; más de 40, comportamiento malicioso; más de 50, bloqueo directo.
Expresión:

(cf.threat_score gt 10)

Acción: Challenge (puntuación 10-40) o Block (más de 50)
Umbrales recomendados:

• Regla 3A: (cf.threat_score gt 10 and cf.threat_score le 50) → Challenge
• Regla 3B: (cf.threat_score gt 50) → Block
  Pero consumen 2 reglas. Si el cupo aprieta, usa gt 10 + Challenge y observa una semana antes de ajustar.

Regla 4: Bloqueo de User-Agent anómalo

Función: filtrar UA vacío, rastreadores maliciosos y herramientas automatizadas.
Casos de uso:
Los navegadores normales envían User-Agent (informan al servidor «soy Chrome», etc.). Si el UA está vacío o es python-requests, curl u otra herramienta de script obvia, casi seguro no es un humano.
Expresión:

(http.user_agent eq "") or (http.user_agent contains "python-requests") or (http.user_agent contains "curl") or (http.user_agent contains "sqlmap") or (http.user_agent contains "nikto") or (http.user_agent contains "MJ12bot")

Acción: Block
UA maliciosos habituales:

• python-requests — scripts Python
• curl — herramienta de línea de comandos
• sqlmap — herramienta de inyección SQL
• nikto — escáner de vulnerabilidades
• MJ12bot — rastreador Majestic SEO (no respeta robots.txt)
• masscan — escáner de puertos
• ZmEu — escáner
  Precauciones:
• No bloquees UA de Mozilla, Chrome, Safari y otros navegadores principales
• Prueba primero con acción Log una semana para ver qué UA anómalos aparecen en los logs
• Si tu sitio ofrece API, puede que debas excluir el UA de tu propio cliente

Regla 5: Protección de rutas sensibles

Función: proteger páginas de administración, APIs sensibles y archivos de configuración.
Casos de uso:
/wp-admin y /wp-login.php de WordPress son las rutas más escaneadas. Archivos como .env y .git filtrados suponen un desastre.
Expresión:

(http.request.uri.path contains "/wp-login" or http.request.uri.path contains "/wp-admin" or http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git") and not (ip.src in {1.2.3.4})

Acción: Block o Challenge
Notas:

• Sustituye {1.2.3.4} por tu IP para acceder al panel sin bloqueo
• Si no quieres lista blanca por IP, elimina and not (ip.src in {1.2.3.4}) y usa Challenge
  Otras rutas sensibles:
• /xmlrpc.php (interfaz XML-RPC de WordPress, objetivo frecuente de DDoS)
• /phpMyAdmin (panel de base de datos)
• /config.php
• /.sql (copias de seguridad de base de datos)
  Añade rutas según tu stack tecnológico.

Flujo completo de evaluación

Con las 5 reglas configuradas, el flujo es:

Solicitud entrante
   ↓
Regla 1: ¿Rastreador legítimo o IP en lista blanca? → Sí → Permitir
   ↓ No
Regla 2: ¿ASN de datacenter? → Sí → Desafío → Pasar/Bloquear
   ↓ No
Regla 3: ¿Puntuación de amenaza > 10? → Sí → Desafío/Bloquear
   ↓ No
Regla 4: ¿User-Agent anómalo? → Sí → Bloquear
   ↓ No
Regla 5: ¿Ruta sensible? → Sí → Bloquear/Desafío
   ↓ No
Permitir, llegar al origen

Este flujo filtra la gran mayoría de ataques automatizados sin perjudicar a usuarios legítimos.

Capítulo 4: Pasos de configuración en la práctica

Ver las reglas no basta; hay que configurarlas. Sigue estos pasos.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Paso 1: Entrar en la configuración del firewall
Inicia sesión en Cloudflare Dashboard → selecciona tu dominio → menú izquierdo «Security» (Seguridad) → «WAF» → pestaña «Custom rules» (Reglas personalizadas).

Paso 2: Crear la primera regla (lista blanca)

1. Haz clic en «Create rule» (Crear regla)
2. Nombre: Lista blanca-rastreadores y monitorización (el nombre es libre, que te sirva para identificarla)
3. Editor de expresiones: por defecto es Expression Builder (editor visual). Para pegar código, haz clic en «Edit expression»
4. Pega la expresión:

   (cf.client.bot) or (ip.src in {1.2.3.4})
   

Recuerda cambiar la IP por la tuya
5. Acción: «Allow»
6. Haz clic en «Deploy» (Implementar)

Paso 3: Crear las 4 reglas restantes
Con el mismo método, crea las reglas 2-5. Nombre, expresión y acción según el capítulo 3.

Paso 4: Ajustar el orden
Tras crear las 5 reglas verás la lista. Arrastra el icono de seis puntos a la izquierda de cada regla para ordenar:

• Lista blanca arriba (prioridad 1)
• Desafío ASN segundo
• Puntuación de amenaza tercero
• UA anómalo cuarto
• Rutas sensibles quinto

Paso 5: Probar las reglas
Tras configurar, prueba:

1. Lista blanca: con tu IP el sitio debe cargar con normalidad
2. Bloqueo por UA: en terminal:

   curl -A "sqlmap" https://tudominio.com
   

Debe mostrarse la página de bloqueo
3. Logs de bloqueo: Cloudflare Dashboard → Security → Events

Si las reglas no aplican, comprueba:

• Sintaxis de la expresión
• Orden de prioridad
• Acción elegida

Capítulo 5: Técnicas avanzadas y preguntas frecuentes

Con las 5 reglas básicas ya bloqueas la mayoría de ataques. Pero hay detalles que merece la pena pulir.

Cómo saber si las reglas funcionan

Cloudflare ofrece un indicador muy útil: CSR (Challenge Solve Rate, tasa de resolución de desafíos).
Fórmula: CSR = desafíos resueltos con éxito / total de desafíos emitidos
Cuanto más bajo, mejor. CSR cercano a 0% indica que casi todos los desafiados son bots. Puedes cambiar Challenge por Block para ahorrar recursos del servidor.
CSR alto (por ejemplo, más del 50%) sugiere falsos positivos con usuarios reales; ajusta las condiciones.
Ver CSR: Security → Events → haz clic en una regla → estadísticas detalladas.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Cómo evitar falsos positivos

Es lo que más preocupa. Algunos consejos:

1. Prueba nuevas reglas en modo Log durante 7 días
   • Acción «Log» (solo registra, no bloquea)
   • Tras una semana revisa Security Events y cambia a Challenge o Block si no hay falsos positivos
2. Lista blanca para tus IP y monitorización
   • Añade tus IP habituales a la regla 1
   • Las IP de UptimeRobot están en su web oficial
3. No empieces con Block
   • Usa Challenge primero
   • Si CSR se acerca a 0%, considera Block
4. Vigila caídas anómalas de tráfico
   • Si el tráfico legítimo cae mucho tras configurar reglas, revisa Security Events

Cómo responder a ataques repentinos

Si el sitio sufre un ataque CC o DDoS y el tráfico se dispara, activa temporalmente el modo Under Attack (el famoso «escudo de 5 segundos»):
Security → Settings → Security Level → «I’m Under Attack»
Muestra una página de carga de 5 segundos con verificación JS. Los bots no pasan; los humanos esperan 5 segundos. Cuando termine el ataque, vuelve a Medium o Low.
También puedes endurecer reglas temporalmente:

• Cambiar Challenge por Block
• Bloqueo geográfico temporal si el ataque viene de un país concreto

Si 5 reglas no bastan

A veces el cupo aprieta. Opciones:

1. Combina reglas similares con or
   • La regla 4 ya une varios UA anómalos con or
   • Una regla por tipo de escenario
2. Crea listas de IP
   • Cloudflare permite listas con miles de IP
   • En reglas: ip.src in $blacklist
   • Una regla gestiona muchas IP sin consumir cupo
3. Considera el plan Pro
   • 20 reglas y más funciones avanzadas
   • Si el sitio genera ingresos, merece la inversión

Preguntas frecuentes

P: ¿Qué hacer si las reglas no funcionan?
R: Revisa:

• Errores de sintaxis en la expresión (Cloudflare lo indica)
• Orden de prioridad (lista blanca arriba)
• Si una regla superior ya hizo Allow o Skip

P: ¿Mi propia IP queda bloqueada?
R: Añádela a la lista blanca de la regla 1:

(cf.client.bot) or (ip.src in {tu IP})

P: ¿Qué umbral de puntuación de amenaza conviene?
R: Recomendaciones:

• Conservadora: cf.threat_score gt 30 (menos bloqueos, menor riesgo de falsos positivos)
• Equilibrada: cf.threat_score gt 10 (recomendada)
• Agresiva: cf.threat_score gt 5 (más bloqueos, puede afectar a usuarios con VPN)
  Empieza con 10, observa una semana y ajusta según CSR y falsos positivos.

P: ¿Por qué Googlebot queda bloqueado?
R: Confirma que la regla 1 (lista blanca) tiene la prioridad más alta. cf.client.bot reconoce Google, Bing y otros rastreadores principales; con la lista blanca en primer lugar, no se bloquean.

Conclusión

En resumen:
Las 5 reglas de firewall del plan gratuito bastan. La clave es configurarlas con la prioridad correcta:

1. Lista blanca primero, protege a tus aliados
2. Desafío ASN, filtra tráfico de datacenter
3. Puntuación de amenaza, bloquea IPs de alto riesgo
4. UA anómalo, filtra herramientas automatizadas
5. Rutas sensibles, protege la puerta trasera
   Tras configurar, tarda unos 30 minutos en aplicarse. Una semana después revisa Security Events: los escáneres que antes consumían ancho de banda quedarán fuera.
   Configúralo ahora. Cloudflare Dashboard te espera; las plantillas están arriba, copia, pega, cambia las IP y en media hora lo tienes.
   Una semana después vuelve a revisar los datos de bloqueo. Si funciona bien, guarda este artículo para futuros ajustes. Si tienes dudas, repasa el capítulo 5.
   Tu sitio merece una mejor protección.