WAF y protección DDoS para aplicaciones web modernas

Su aplicación no se cae porque los atacantes sean genios. Se cae porque una botnet alquilada por el precio de una pizza lanzó unos cuantos millones de peticiones por segundo contra su endpoint de login, y nadie había decidido de antemano qué tráfico descartar. Un WAF y una estrategia DDoS son exactamente eso: esa decisión, escrita y aplicada en el edge antes de que el tráfico llegue siquiera a tocar su origen.

Sepa qué es lo que realmente le golpea

"DDoS" no es un solo ataque. Son al menos tres, viven en capas distintas y se resuelven con medidas distintas.

Volumétrico (L3/L4). Inundaciones UDP, amplificación DNS y NTP, floods SYN. El objetivo es saturar su ancho de banda o agotar el estado de conexiones de su balanceador. Los ataques de amplificación son especialmente dañinos: el atacante gasta un paquete pequeño y un reflector mal configurado le devuelve a usted una respuesta decenas de veces mayor. Esto no se puede absorber en el origen. Si la inundación supera su enlace de subida, ninguna regla de firewall en su servidor sirve de nada: los paquetes ya llegaron. La única respuesta real es capacidad que no es suya, es decir, una red anycast o un proveedor de scrubbing que se coma la inundación aguas arriba.

Protocolo y agotamiento de estado. Floods SYN que llenan las tablas de conexión, abuso de renegociación TLS, ataques tipo Slowloris que abren conexiones y las alimentan byte a byte. No necesitan casi ancho de banda. Un solo VPS puede mantener miles de sockets abiertos contra un nginx con configuración por defecto. Las soluciones son de nivel de protocolo: SYN cookies, timeouts agresivos, límites de conexión por origen y terminación de TLS en un edge diseñado para ello.

Capa de aplicación (L7). Inundaciones HTTP que parecen usuarios reales. Tormentas de GET contra su endpoint más caro (búsqueda, exportación a PDF, cualquier cosa que se abra en abanico hacia la base de datos), floods de POST contra el login, credential stuffing, peticiones con query strings aleatorias para reventar la caché y que cada golpe pase de largo el CDN y aterrice en su origen. L7 es donde hoy se produce la mayor parte del daño, porque es barato, difícil de distinguir del tráfico legítimo y apunta a su ruta de código más lenta, no a su ancho de banda. Este es el territorio del WAF.

El marco de decisión es simple: los ataques volumétricos se resuelven con la red de otro, los de protocolo con terminación en el edge y ajustes de kernel, y los de L7 con reglas, rate limiting y detección de bots. La mayoría de los equipos solo piensa en el tercero y acaba tumbada por el primero.

Qué hace realmente un WAF

Un firewall de aplicaciones web es un proxy inverso que evalúa cada petición HTTP contra un motor de reglas antes de reenviarla. Ese es todo el truco. El valor está por completo en las reglas, en dónde se ejecutan y en cómo se operan.

Reglas gestionadas: su punto de partida, no su estrategia

Toda plataforma seria incluye conjuntos de reglas gestionadas: Cloudflare Managed Rules, AWS Managed Rules y el OWASP Core Rule Set (CRS) de código abierto para ModSecurity y su sucesor moderno, Coraza. Cubren la capa de ataque genérico: patrones de inyección SQL, payloads XSS, path traversal, firmas de CVE conocidos, huellas de escáneres.

Dos cosas importan en la operación. Primero, CRS usa puntuación por anomalías: cada regla que coincide suma puntos, y la petición se bloquea solo cuando el total cruza un umbral. Eso tolera mucho mejor el tráfico del mundo real que una coincidencia binaria, y el nivel de paranoia controla el compromiso. El nivel 1 es seguro casi en cualquier parte; el nivel 3 y superiores marcarán cuerpos JSON legítimos y exigen un ajuste serio. Segundo, las reglas gestionadas protegen contra formas de ataque conocidas, no contra su lógica de negocio. Ninguna regla gestionada sabe que un usuario no debería poder pagar con una cantidad negativa ni enumerar identificadores de facturas. Esa capa la tratamos en nuestro artículo sobre buenas prácticas de seguridad en APIs, y pertenece a su aplicación, no al WAF.

Reglas personalizadas: donde están las victorias reales

Las reglas de WAF de mayor valor que escribimos para clientes son aburridas y específicas:

• Bloquear peticiones a /wp-login.php y /xmlrpc.php en aplicaciones que no son WordPress. Solo con esto el ruido puede caer en picado.
• Restringir los paneles de administración por ASN, país o mTLS en lugar de confiar en que la contraseña aguante. Nunca confíen solo en la ubicación de red; verifiquen la identidad en cada petición.
• Forzar tipos de contenido: una API que solo habla JSON debería rechazar multipart/form-data en el edge.
• Desafiar o bloquear peticiones sin Accept-Language, con versiones antiguas de TLS o con huellas JA4 que coincidan con herramientas de bots conocidas. El fingerprinting TLS es, discretamente, una de las señales más fuertes disponibles, porque falsificar la pila TLS de un navegador es mucho más difícil que falsificar un User-Agent.

Una expresión de regla personalizada en Cloudflare tiene este aspecto:

(http.request.uri.path contains "/admin"
  and not ip.geoip.asnum in {13335 16509}
  and not cf.bot_management.verified_bot)

Legible, versionable, testeable. Traten estas expresiones como código: pull requests, revisión y primero en staging.

Modelos de seguridad positivo y negativo

Modelo negativo: permitir todo y bloquear lo malo conocido. Eso son las reglas gestionadas. Modelo positivo: definir exactamente qué está permitido (métodos, rutas, tipos de parámetros, esquemas de cuerpo) y rechazar todo lo demás. Los modelos positivos son drásticamente más fuertes y drásticamente más caros de mantener, porque cada cambio de producto se convierte en un cambio del WAF. El punto medio pragmático: operar un modelo negativo de forma global y aplicar validación positiva basada en esquemas solo en las superficies de mayor riesgo, como autenticación, pagos y webhooks. Si ya publican una especificación OpenAPI, hay herramientas que la compilan en reglas de validación, lo que convierte su contrato de API en una frontera de cumplimiento.

Rate limiting: el control más infravalorado

La mayoría de los incidentes L7 que vemos no tienen nada de exótico. Son un endpoint recibiendo 200 veces su tráfico normal. El rate limiting lo resuelve, pero solo si se elige bien la clave de agregación.

• Clave por IP para superficies anónimas. Barato, pero débil frente a ataques distribuidos e injusto con los usuarios detrás de CGNAT, algo habitual en las redes móviles de América Latina y cada vez más frecuente entre operadores en España. Miles de usuarios reales pueden compartir una sola IP.
• Clave por sesión o token de API para superficies autenticadas. Preciso, y sobrevive a la rotación de IPs.
• Clave por objetivo para cosas como el login: limiten los intentos por cuenta, no solo por origen, o una campaña distribuida de credential stuffing atravesará su límite por IP sin despeinarse.

Fijen los límites con datos, no con intuiciones: midan la tasa p99 de peticiones legítimas por clave durante una semana y pongan el límite en un múltiplo cómodo. En el origen, nginx ofrece una última línea de defensa sólida:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;

location /api/auth/ {
    limit_req zone=login burst=10 nodelay;
    limit_req_status 429;
}

Y en AWS WAF, una regla basada en tasa con alcance acotado mantiene la inundación completamente fuera del origen:

statement {
  rate_based_statement {
    limit              = 300
    aggregate_key_type = "IP"
    scope_down_statement {
      byte_match_statement {
        search_string         = "/api/auth"
        positional_constraint = "STARTS_WITH"
        field_to_match { uri_path {} }
        text_transformation {
          priority = 0
          type     = "LOWERCASE"
        }
      }
    }
  }
}

Devuelvan 429 con una cabecera Retry-After y asegúrense de que su propio frontend y sus clientes móviles la respetan. En nuestra experiencia, la primera víctima de un límite de tasa recién estrenado suele ser el bucle de reintentos del propio equipo.

Modos de fallo que muerden de verdad

Las configuraciones de WAF y DDoS fallan de formas predecibles. Diseñen contra ellas desde el primer día.

Origen expuesto. Pusieron Cloudflare delante, pero su origen sigue respondiendo a cualquiera que encuentre su IP en el historial de DNS, en los logs de certificate transparency o en Shodan. El atacante se salta todo su edge. Solución: limitar el firewall del origen para aceptar tráfico solo desde los rangos de IP publicados por su proveedor de edge, usar authenticated origin pulls (mTLS entre edge y origen) y rotar la IP del origen después de activar la protección, porque los datos históricos de DNS sobreviven a su migración.

Inundaciones que revientan la caché. Los atacantes añaden query strings aleatorias para que cada petición falle en caché. Solución: normalizar las claves de caché para ignorar parámetros desconocidos y, si su plataforma lo permite, aplicar rate limiting específicamente sobre los fallos de caché.

Bloqueos por falsos positivos. Una actualización de reglas gestionadas empieza a bloquear a su proveedor de webhooks, a su pasarela de pagos o al proxy de su mayor cliente. Solución: nunca desplieguen reglas directamente en modo bloqueo. Ejecuten las reglas nuevas en modo conteo o registro durante al menos una semana, revisen qué habrían bloqueado y solo entonces promuévanlas. Mantengan un mecanismo de lista de excepciones de emergencia que puedan aplicar en minutos, no en horas.

El WAF como manta de falsa tranquilidad. Un WAF filtra patrones de petición. No arregla un IDOR, un flujo de autenticación roto ni un fallo de lógica de negocio, y un atacante competente codificará, fragmentará y mutará sus payloads para rodear las reglas de firma. Las pruebas ofensivas periódicas son lo que distingue cobertura real de puro teatro; vean introducción al pentesting para saber cómo delimitarlas bien.

Modo bloqueo durante un incidente que no pueden ver. Si los únicos logs de su WAF viven en un panel que nadie abre, no ajustarán nada y no confiarán en nada. Envíen los logs del WAF al mismo pipeline que los logs de su aplicación, con el identificador de regla, la acción y el campo coincidente en cada evento. Y recuerden que esos logs contienen direcciones IP, que son datos personales bajo el RGPD (y la LOPDGDD en España): definan retención y control de acceso igual que para cualquier otro registro con datos de usuarios.

Elegir su stack

No hay una respuesta universal, pero sí un valor por defecto defendible para la mayoría de los equipos de producto.

• Cloudflare (planes Pro o Business en adelante). Absorción DDoS anycast incluida, buenas reglas gestionadas, reglas personalizadas expresivas, puntuación de bots y rate limiting en un solo lugar. Es el estándar de facto tanto en el ecosistema startup latinoamericano como entre los SaaS españoles, y el camino más rápido de cero a protegido.
• AWS WAF más CloudFront más Shield. La opción correcta cuando ya están metidos de lleno en AWS, quieren infraestructura como código desde el primer día y necesitan que las decisiones del WAF convivan con el ALB y API Gateway. Requiere más montaje, y el coste escala con reglas y peticiones, así que vigilen la factura.
• Fastly con su Next-Gen WAF (antes Signal Sciences). Excelente cuando necesitan lógica avanzada en el edge con VCL o Compute y una detección L7 fuerte con pocos falsos positivos.
• Coraza o ModSecurity autogestionados con CRS. Control total, sin coste por petición, y la única opción en algunos entornos regulados o aislados; también la vía habitual cuando el tráfico debe permanecer en un proveedor de hosting local o cumplir requisitos de residencia de datos. Pero el ajuste, las actualizaciones y el escalado corren de su cuenta, y la protección volumétrica es cero: un WAF autogestionado detrás de un enlace saturado no protege nada.

El compromiso, dicho con honestidad: las plataformas gestionadas de edge cambian algo de control y una factura recurrente por una capacidad de absorción que ustedes no pueden construir. Por debajo de una escala empresarial realmente grande, ese cambio casi siempre compensa.

Lista de despliegue: de origen desnudo a edge defendido

1. Inventaríen su superficie pública: cada dominio, subdominio, API y URL de callback de terceros. Los atacantes enumeran; ustedes también deberían.
2. Pongan el edge delante: migren el DNS a su proveedor, activen el proxy y confirmen TLS de extremo a extremo.
3. Blinden el origen: restrinjan el tráfico entrante a los rangos de IP del edge, activen authenticated origin pulls y después cambien la IP del origen.
4. Activen las reglas gestionadas en modo conteo. Déjenlas observar tráfico de producción durante una o dos semanas.
5. Revisen los bloqueos potenciales, añadan excepciones puntuales y pasen a modo bloqueo un conjunto de reglas a la vez.
6. Añadan rate limiting en autenticación, búsqueda, checkout y cualquier endpoint que toque consultas caras, con las claves descritas más arriba.
7. Escriban dos o tres reglas personalizadas para su tráfico basura conocido: rutas muertas de CMS, geocercado del panel de administración, forzado de tipos de contenido.
8. Conecten los logs del WAF y las métricas del edge (peticiones bloqueadas, tasas de desafío, tasas de error del origen, ratio de aciertos de caché) a su stack de observabilidad, con alertas ante cambios bruscos.
9. Hagan las pruebas de carga a través del edge, no rodeándolo, para saber que sus límites se disparan correctamente bajo presión.
10. Escriban el runbook: quién puede activar el modo "bajo ataque", quién puede publicar una regla de emergencia y cómo es la ruta de escalado hacia su proveedor. Y luego ensáyenlo, exactamente como el proceso que describimos en el manual de respuesta a incidentes.

Los pasos 4 y 5 son donde más equipos hacen trampa: lo ponen todo en bloqueo el primer día, rompen el checkout para un segmento real de clientes y luego apagan el WAF entero en pleno pánico. El modo conteo primero no es teatro de prudencia. Es la diferencia entre un control en el que confían y una casilla que temen.

Operarlo: la parte que nadie presupuesta

Un WAF no es una compra, es una práctica. Las reglas se desactualizan a medida que su aplicación cambia. Las herramientas de bots evolucionan cada mes, y las redes de proxies residenciales debilitan la reputación de IP año tras año. Presupuesten una porción pequeña y recurrente de tiempo de ingeniería: revisen bloqueos muestreados cada semana al principio, cada mes cuando el sistema se estabilice. Sigan dos números en el tiempo: los reportes de falsos positivos que llegan a soporte, y las peticiones por segundo que alcanzan el origen durante ventanas de ataque frente a ventanas de calma. El primero les dice si están siendo demasiado agresivos; el segundo, si el edge está absorbiendo algo de verdad. Si ambos son planos y aburridos, el sistema funciona. Aburrido es la meta.

Cómo puede ayudar Innovation T

Innovation T diseña y opera seguridad en el edge para sistemas en producción: arquitectura y ajuste de WAF en Cloudflare y AWS, revisiones de resiliencia DDoS, blindaje del origen, diseño de rate limiting y la observabilidad para demostrar que todo funciona. Construimos las reglas, los pipelines y los runbooks, y después formamos a su equipo para que los haga suyos.

Si su aplicación está a un momento viral o a una botnet enfadada de una caída, arreglémoslo antes de que ocurra. Exploren nuestros servicios o hablen con nuestro equipo sobre una revisión enfocada de seguridad en el edge.