Case Study: Mitigación de Escaneos Automatizados en el Edge con Cloudflare WAF
Si crees que por tener un blog estático o un HomeLab pequeño estás a salvo de los bots de internet, eres un iluso. Los scripts automatizados escanean rangos enteros de IPs y dominios las 24 horas del día buscando paneles de administración desprotegidos, archivos expuestos o rutas vulnerables.
Este caso de estudio documenta el análisis forense, la estrategia de hardening y el despliegue de una matriz de seguridad perimetral utilizando el WAF (Web Application Firewall) de Cloudflare, logrando interceptar y neutralizar ataques automatizados en el Edge (la periferia de la red) antes de que toquen mi infraestructura local.
El Escenario: Ataque en ráfaga detectado
Durante una auditoría rutinaria de los logs de tráfico, identifiqué un escaneo automatizado de vulnerabilidades de alta intensidad (Directory Busting / Web Scraping). Un actor malicioso intentó realizar un reconocimiento agresivo de la infraestructura lanzando más de 25 peticiones HTTP en apenas 3 segundos desde un nodo proxy.
===================================================================================
[WAF_EDGE_LOG_EXTRACT] - TARGET: alvarezops.tech
===================================================================================
Timestamp (GMT+2) Action Origin IP Address Service Rule ID
------------------- ------ ------- --------------- -------------- ------------
2026-05-17 00:59:35 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:35 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:35 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:34 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:34 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:34 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:34 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:34 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:33 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:33 Block France 185.177.72.29 Custom rules 622c1a4d****
2026-05-17 00:59:33 Block France 185.177.72.29 Custom rules 622c1a4d****
...
[+14 Peticiones idénticas mitigadas en el intervalo de 00:59:33 a 00:59:35]
===================================================================================
Gracias a la implementación previa del proxy reverso de Cloudflare, este tráfico no llegó a consumir ancho de banda ni recursos de computación de mi servidor host. El WAF actuó como escudo perimetral inmediato.
Diseño de la Matriz de Reglas Personalizadas
Para proteger los servicios y el portfolio, diseñé un modelo de filtrado por capas basándome en el principio de menor privilegio. A continuación, detallo la lógica de producción aplicada en el perfil de Cloudflare:
| Orden | Nombre de la Regla | Condición / Match (Lógica) | Acción | Propósito Técnico |
|---|---|---|---|---|
| 1 | Lista Blanca: Bots Legítimos | Known Bots == true |
Skip | Permite el rastreo de motores de búsqueda oficiales (Google, Bing) y bots de IA autorizados, evitando falsos positivos en el SEO. |
| 2 | Filtrado de Hostnames Válidos | Hostname not in [mis-subdominios-publicos] |
Block | Mitiga ataques dirigidos a IPs directas o escaneos que intentan resolver subdominios privados o inexistentes. |
| 3 | Mitigación de Herramientas de Escaneo | User Agent contains [herramientas-automatizadas] |
Block | Portazo inmediato a herramientas de reconocimiento |
| 4 | Falsos Objetivos (Honeypot) | URI Path contains "/wp-admin" |
Block | Al ser un sitio estático, cualquier petición buscando rutas de WordPress delata a un bot malicioso. Bloqueo directo y radical. |
| 5 | Restricción Geográfica (Geofencing) | Country != ES |
Managed Challenge | Aplica un desafío interactivo (Captcha invisible) a todo el tráfico fuera de mi región de operación, erradicando el ruido internacional. |
Imagen del panel WAF de cloudflare
Restricciones del Entorno y Optimización de Recursos (Plan Free)
Un factor crítico en el diseño de esta arquitectura fue la gestión de limitaciones del plan gratuito de Cloudflare. La cuenta Free impone un techo estricto en la capacidad de despliegue:
- Máximo de 5 reglas personalizadas (Custom Rules).
- Máximo de 1 regla de límite de tasa (Rate Limiting).
Debido a esta limitación de recursos, no es posible atomizar la seguridad en decenas de reglas individuales. En su lugar, realicé un análisis de riesgos para identificar los vectores de ataque más probables en mi entorno y diseñé una matriz optimizada combinando múltiples expresiones lógicas dentro de un mismo comodín. Cada una de las 5 reglas activas fue pensada estratégicamente para cubrir el mayor espectro de amenazas posible (desde la reputación de la IP hasta el Geofencing), logrando un blindaje perimetral robusto y eficiente a coste cero.
Aviso OPSEC y Gestión de Logs: La telemetría en el Edge es volátil. Debido a la limitación de 24 horas (Rolling Window) en la retención de eventos del plan Free de Cloudflare, este extracto se capturó en caliente durante el incidente. Esto subraya una máxima innegociable en ciberseguridad: si detectas una anomalía, captura y aísla la evidencia inmediatamente antes de que la rotación del servidor la destruya.
Configuración de la regla de Rate Limiting disponible:
Aprovechando la única regla de control de tasa permitida, protegí exclusivamente los endpoints y formularios de inicio de sesión de mis entornos de desarrollo:
- Filtro:
URI Path contains "/login" or "/admin" - Acción: Block (Si un actor excede el umbral crítico de peticiones por minuto).
Análisis Forense: ¿Por qué actuó el WAF antes que el Rate Limiting?
Una duda de ingeniería común tras analizar los logs de este incidente es: Si el atacante lanzó 25 peticiones en 3 segundos, ¿por qué los eventos fueron mitigados por las Reglas Personalizadas y no por la regla de Rate Limiting?
La respuesta radica en el orden de prioridad y evaluación del tráfico de la arquitectura de Cloudflare. Cuando un paquete HTTP llega al Edge, pasa por una cadena secuencial de inspección donde las capas se ejecutan de forma escalonada:
- Capa 1: Custom Rules (Firewall): Analiza la estructura del paquete (IP, país, User-Agent, URI). Si hay coincidencia y la acción es
Block, el paquete se destruye inmediatamente y el flujo de procesamiento se detiene. - Capa 2: Rate Limiting Rules: Cuenta el volumen de peticiones por tiempo. Solo procesa los paquetes que han logrado sobrevivir a la Capa 1.
En este caso de estudio, el bot fue interceptado de forma fulminante en la primera línea de defensa (Capa 1) al hacer match con los criterios de las Reglas Personalizadas. Al ejecutarse la acción de bloqueo inmediato, las peticiones murieron en el acto, por lo que el contador del motor de Rate Limiting (Capa 2) nunca llegó a recibir tráfico. Esto representa el escenario defensivo ideal: neutralizar la amenaza en la capa más externa posible.
Conclusión y Lecciones Aprendidas
Desplegar seguridad en el Edge transforma por completo la postura defensiva de una infraestructura. Al delegar la primera línea de defensa en la red global de Cloudflare, se consiguen tres objetivos críticos:
- Aislamiento total del Host: El servidor doméstico permanece oculto tras el proxy, haciendo inviable el descubrimiento de la IP pública real.
- Optimización de Recursos: El tráfico malicioso es descartado a miles de kilómetros de distancia, manteniendo la CPU y el ancho de banda del HomeLab al 100% de disponibilidad para tráfico legítimo.
- Visibilidad Centralizada: Centralizar la ingesta de eventos HTTP facilita el análisis forense y la toma de decisiones rápidas para ajustar las reglas en tiempo real.
Nota de OPSEC: Por motivos de seguridad operacional (Security through Obscurity), los nombres de los subdominios de gestión, las herramientas específicas de análisis y las rutas exactas de los endpoints de mis entornos de desarrollo han sido anonimizados en este artículo.
