En 03-02, cuando una sola dirección IP empezó a hacer miles de peticiones por minuto contra la tienda, la solución fue elegante y tardó un minuto: una regla DENY numerada 50 en la NACL de las subredes públicas, con número bajo para que se evaluara antes que el ALLOW general. Funcionó perfectamente.

Funcionó porque era una dirección.

Si mañana las peticiones llegan desde diez mil direcciones repartidas por sesenta países, esa regla no sirve de nada. Y no es solo que haya que escribir diez mil reglas: es que no se puede. Una NACL admite 20 reglas por defecto y un máximo duro de 40. Un grupo de seguridad admite 60. La herramienta que resolvió el problema pequeño no escala al problema grande, y eso no es un defecto de la herramienta: es que son problemas distintos.

Peor aún, hay un daño colateral que casi nadie anticipa la primera vez. El grupo de Auto Scaling asg-mercadofresco-tienda que montamos en 02-01 para resolver las caídas de los viernes hará exactamente aquello para lo que fue diseñado: ver mucha carga y arrancar instancias. Un ataque de denegación de servicio contra una arquitectura elástica no siempre tira el servicio; a veces simplemente lo convierte en una factura de cinco cifras.

AWS Shield es el servicio de protección frente a ataques de denegación de servicio distribuida. En esta lección Marta entiende contra qué se está protegiendo, descubre que la mayor parte de la protección ya la tiene activada y gratis, y toma una decisión razonada —y negativa— sobre los 3.000 dólares mensuales de Shield Advanced.

Advertencia. El contenido de esta lección es estrictamente defensivo: describe cómo detectar y mitigar ataques contra tu propia infraestructura, nunca cómo ejecutarlos. Realizar pruebas de carga o de estrés contra sistemas que no son tuyos es ilegal, y contra los tuyos en AWS requiere seguir la política de pruebas de simulación de AWS. Los ejemplos son didácticos: toda configuración de seguridad, y en particular cualquier plan de respuesta a incidentes que afecte a datos de clientes bajo el RGPD, debe ser revisada por un profesional de seguridad antes de aplicarse a un entorno real.

1. Qué es un ataque de denegación de servicio distribuida
2. Por qué la regla de una sola IP no sirve
3. Taxonomía: capas 3/4 frente a capa 7
4. Ataques volumétricos
5. Ataques de capa de aplicación
6. El daño económico: cuando el escalado juega en tu contra
7. AWS Shield Standard: lo que ya tienes
8. AWS Shield Advanced: qué añade
9. Protección de costes frente al escalado
10. El equipo de respuesta ante incidentes (SRT)
11. Coste real y evaluación honesta para MercadoFresco
12. Arquitectura resiliente: la primera línea de defensa
13. Reducir la superficie expuesta
14. Cachear agresivamente y sobredimensionar
15. Métricas y detección
16. Alarmas hacia alertas-mercadofresco
17. Plan de respuesta: qué mira Marta primero
18. Distinguir un ataque de un viernes muy bueno
19. Qué hacer en caliente y qué documentar después
20. Coste, limpieza y lo que viene

Un ataque de denegación de servicio (DoS) busca dejar un servicio inaccesible para sus usuarios legítimos consumiendo un recurso finito: ancho de banda, conexiones, CPU, memoria o conexiones de base de datos. Distribuida (DDoS) significa que el tráfico procede de muchas fuentes simultáneas —típicamente equipos comprometidos o servicios de terceros abusados—, lo que hace inviable distinguirlas y bloquearlas una a una.

La diferencia con otros ataques importa:

Para MercadoFresco, un ataque de dos horas un viernes por la tarde significa perder unos 1.800 pedidos —900 por hora en el pico— más el daño de que los clientes que quisieron comprar y no pudieron se acuerden de ello la semana siguiente.

Quién los lanza: extorsión («paga o seguimos»), competencia desleal, activismo, o simplemente ruido de fondo automatizado que barre internet buscando objetivos fáciles. Esta última categoría es la más frecuente y la razón de que incluso una tienda mediana necesite pensar en esto.

Merece la pena ver el contraste con números:

Hay además un problema conceptual más profundo. Filtrar en la NACL significa que el paquete ya ha llegado a tu VPC: ha consumido tu ancho de banda de entrada y ha llegado hasta la puerta. Si el ataque satura el enlace, filtrar dentro no ayuda, porque el enlace ya está lleno.

De ahí el principio que organiza toda la defensa contra DDoS:

El tráfico malicioso debe filtrarse lo más lejos posible de tu infraestructura, idealmente en la red del proveedor, distribuido entre cientos de puntos de presencia, antes de que converja hacia un único destino.

Eso es exactamente lo que hace Shield, y explica por qué la protección va asociada a CloudFront y Route 53: son servicios que viven en el borde.

Los ataques se clasifican por la capa del modelo OSI en la que operan, y esa clasificación determina la defensa:

La conclusión operativa es la que estructura este módulo: Shield para lo volumétrico, WAF para lo inteligente. Ninguno de los dos sustituye al otro, y la lección siguiente cubre el segundo.

Los de capa 3 y 4. Existen desde hace décadas y hoy se lanzan casi siempre desde botnets o abusando de servicios mal configurados en internet.

La amplificación por reflexión es la que produce los ataques de mayor tamaño registrados: un atacante con poco ancho de banda puede generar cientos de veces esa cantidad contra su objetivo. La mitigación es de red y ocurre antes de llegar a ti: no es algo que se resuelva en tu servidor.

La buena noticia para MercadoFresco es que casi todo esto lo absorbe AWS por defecto. La capacidad agregada de la red de AWS y de los puntos de presencia de CloudFront es de un orden de magnitud que ningún ataque volumétrico dirigido a una tienda mediana va a agotar. Contra esta familia, MercadoFresco ya está protegido sin haber hecho nada.

Aquí es donde una empresa del tamaño de MercadoFresco tiene un problema real, porque estos ataques no necesitan volumen.

El caso concreto que más preocupa a Marta: la búsqueda de productos. Una petición a /buscar?q=tomate&filtros=ecologico,granel&orden=precio no se sirve desde caché, ejecuta una consulta compleja contra mercadofresco-pedidos y tarda unos 200 ms. Cincuenta peticiones por segundo desde cincuenta direcciones distintas —un volumen ridículo, indistinguible del tráfico normal en un gráfico de ancho de banda— pueden saturar la base de datos sin que ninguna alarma de red se inmute.

Ese es el motivo de que Shield solo no baste y de que exista la lección 04-05.

Este apartado merece un cálculo, porque es el argumento que hace que la dirección de una empresa entienda el problema.

Supongamos un ataque de capa 7 sostenido durante 6 horas contra MercadoFresco, con 5.000 peticiones por segundo llegando al ALB:

El coste de infraestructura de un ataque así en MercadoFresco es de decenas o pocos cientos de dólares: molesto, no catastrófico. El daño real son las ventas perdidas y la confianza. Este cálculo es importante porque es el que evita la decisión emocional de contratar Shield Advanced a 3.000 USD al mes para protegerse de un riesgo de 200 USD.

En arquitecturas mayores el cálculo cambia radicalmente, y por eso existe la protección de costes que veremos en dos apartados.

Shield Standard está activo, es gratuito y no hay que hacer nada para tenerlo. Se aplica automáticamente a todos los clientes de AWS.

Qué incluye:

• Detección y mitigación automáticas de los ataques volumétricos y de estado de conexión más comunes de capas 3 y 4, en tiempo real y de forma continua.
• Mitigación en línea, sin desviar el tráfico ni introducir latencia perceptible.
• Protección integrada en CloudFront, Route 53, Global Accelerator y Elastic Load Balancing, que son precisamente los servicios donde vive el borde de MercadoFresco.
• Defensas de red aplicadas en la infraestructura de AWS: filtrado de paquetes malformados, límites por origen, protección frente a inundaciones SYN.

Lo importante es dónde actúa:

El filtrado ocurre antes de CloudFront, es decir, antes de que el tráfico llegue a nada tuyo y antes de que genere coste. Lo que Shield Standard no hace es distinguir una petición HTTP legítima de otra maliciosa: eso es capa 7 y es trabajo de WAF.

Verificación práctica: como MercadoFresco ya sirve todo su tráfico a través de CloudFront (03-04) y resuelve el DNS con Route 53 (03-05), ya está usando Shield Standard en su forma más efectiva sin haberlo decidido conscientemente. Esa es una de las razones no evidentes de poner una CDN delante, incluso cuando el ahorro de transferencia no fuera el argumento principal.

Las tres funciones que de verdad justifican el precio:

1. Detección específica por recurso. Shield Advanced establece una línea base del tráfico normal de tu aplicación —no de la media de AWS— y detecta desviaciones. Puede identificar un ataque de 200 Mbps contra un recurso que normalmente recibe 20 Mbps, un volumen que en términos absolutos no llamaría la atención de nadie.

2. Protecciones automáticas de capa de aplicación. Con esto activado, Shield Advanced escribe y aplica reglas de WAF por su cuenta durante un ataque, basándose en el patrón detectado, y las retira cuando pasa. Es la única forma de responder a un ataque de capa 7 en segundos y de madrugada sin que haya nadie despierto.

3. Protección de costes, que merece su propio apartado.

Es la función menos conocida y la que más veces ha justificado la contratación.

Durante un ataque, tu infraestructura elástica reacciona: el ASG arranca instancias, CloudFront sirve peticiones, el ALB procesa conexiones, la transferencia de salida se dispara. Todo eso se factura.

Shield Advanced ofrece créditos de servicio por los cargos atribuibles a un ataque verificado en los recursos protegidos:

Cómo funciona en la práctica: se abre un caso de soporte durante o después del ataque, AWS verifica que hubo un evento de DDoS en ese recurso y en esa ventana, y aplica un crédito en la factura. No es automático: hay que solicitarlo.

Para una empresa cuya factura durante un ataque puede pasar de 5.000 a 80.000 dólares en una noche, esta función sola paga el servicio. Para MercadoFresco, cuyo ataque más caro imaginable cuesta unos 200 dólares, no.

El Shield Response Team es un equipo de ingenieros de AWS especializados en DDoS, disponible 24/7 para clientes de Shield Advanced con plan de soporte Business o Enterprise.

Qué hace:

• Durante un ataque: investiga contigo, escribe mitigaciones a medida, aplica reglas de WAF en tus Web ACL si le has dado permiso.
• Proactivamente: si le autorizas, puede intervenir sin esperar a que llames, en cuanto sus alarmas se disparen. Esto es lo que se conoce como proactive engagement y hay que activarlo y configurar los contactos.
• Antes: revisa tu arquitectura y recomienda cambios.

La parte a valorar es que darle acceso a tus Web ACL significa autorizar a un tercero a modificar tus reglas de filtrado en producción sin tu intervención previa. Para muchas organizaciones eso es exactamente lo que quieren a las cuatro de la mañana; para otras es un problema de gobierno que hay que documentar.

Son 36.000 USD al año, más transferencia, más soporte. El compromiso anual significa que no se puede contratar «solo mientras dure el susto».

Hagamos la evaluación honesta para MercadoFresco:

Conclusión: MercadoFresco no debe contratar Shield Advanced hoy. El coste equivale aproximadamente a toda su factura de AWS multiplicada por varias veces, para protegerse de un riesgo cuyo impacto directo es de dos órdenes de magnitud menor.

Lo que sí debe hacer, y es el resto de la lección:

1. Aprovechar al máximo Shield Standard, que ya tiene, sirviendo todo por CloudFront.
2. Diseñar la arquitectura para absorber, no para resistir.
3. Montar WAF con reglas por tasa (04-05), que cuesta unos pocos dólares al mes y cubre el 90 % de lo que le preocupa.
4. Tener alarmas y un plan escrito.

Y cuándo sí tendría sentido reconsiderarlo:

• Si MercadoFresco creciera hasta facturar millones y una hora de caída costara decenas de miles.
• Si recibiera un ataque de extorsión con amenaza de repetición.
• Si un cliente corporativo o una normativa lo exigiera contractualmente.
• Si operara en un sector con perfil de objetivo alto (banca, juego, medios, sector público).

Es una decisión de negocio con números, no una decisión técnica. Y saber argumentar el «no» con datos es tan valioso como saber configurar el «sí».

Antes que cualquier servicio de protección, la mejor defensa contra DDoS es una arquitectura que absorbe. Estos son los cuatro principios, y MercadoFresco cumple ya casi todos:

Lo que hace fuerte a esta arquitectura no es ningún producto de seguridad, sino cuatro decisiones tomadas en los módulos 2 y 3:

La regla es simple: lo que no está expuesto no se puede atacar. Revisión de la superficie de MercadoFresco:

La única mejora pendiente es la segunda fila. Aunque el DNS público apunte a CloudFront, el ALB sigue teniendo un nombre DNS público resoluble, y un atacante que lo descubra puede saltarse CloudFront y golpearlo directamente, evitando la caché y el WAF. La mitigación estándar tiene dos partes:

1. Que CloudFront añada una cabecera secreta a cada petición hacia el origen.
2. Que el ALB rechace cualquier petición que no la lleve, mediante una regla del listener.

Ese valor de cabecera es exactamente el tipo de secreto rotable que va a Secrets Manager, como vimos en 04-03. Y para completar el cierre se pueden restringir las reglas de entrada de sg-mercadofresco-alb a los rangos de IP publicados de CloudFront, usando la lista gestionada de prefijos com.amazonaws.global.cloudfront.origin-facing:

Con esas dos medidas, el ALB deja de ser un objetivo alcanzable y todo el tráfico está obligado a pasar por el borde, que es donde vive la protección.

Cachear. Una petición servida desde la caché de CloudFront no llega a tu infraestructura, no consume CPU, no toca la base de datos y no cuenta para el escalado. Con la tasa de aciertos que medimos en 03-04, la inmensa mayoría del tráfico del catálogo se queda en el borde. Recomendaciones específicas frente a DDoS:

• Cachear también las respuestas de error (404, 403) durante unos segundos. Un ataque que pide rutas inexistentes es, si no, un ataque que llega íntegro al origen.
• Definir un TTL mínimo razonable para que un atacante no pueda invalidar la caché añadiendo parámetros de consulta aleatorios: la clave de caché debe incluir solo los parámetros que de verdad cambian la respuesta, como configuramos con las políticas de caché.
• Servir una página de mantenimiento estática desde S3 como destino de conmutación por error de Route 53, ya preparada en 03-05: si todo falla, los clientes ven algo.

Sobredimensionar. Absorber es más barato que caer:

• Que la capacidad mínima del ASG sea más de lo estrictamente necesario. MercadoFresco tiene 2 instancias para 900 pedidos/hora cuando una sirve 600.
• Que el escalado reaccione rápido: un periodo de calentamiento corto y umbrales bajos.
• Que el máximo tenga un techo consciente. Este punto es contraintuitivo pero importante: un ASG con máximo 100 durante un ataque es una factura. Un máximo de 20 significa que el servicio se degrada, pero de forma acotada y previsible. Elige el número deliberadamente, no lo dejes por defecto.
• Usar tipos de instancia con rendimiento de red garantizado si el tráfico es alto: las familias con crédito de red pueden verse limitadas justo cuando más falta hacen.

Con Shield Advanced se dispone del espacio de nombres AWS/DDoSProtection en CloudWatch:

Sin Shield Advanced —el caso de MercadoFresco— esas métricas no existen y hay que detectar por señales indirectas. Estas son las que Marta vigila:

Esa última fila es especialmente reveladora. Un pico legítimo de tráfico mantiene o mejora la tasa de aciertos, porque mucha gente pide las mismas páginas populares. Un ataque diseñado para hacer daño pide rutas aleatorias o con parámetros únicos, y hunde la tasa de aciertos. Un gráfico de CacheHitRate cayendo mientras Requests sube es una de las señales más limpias que existen.

Estas son las alarmas que MercadoFresco monta hoy, sin Shield Advanced. CloudWatch se ve a fondo en 05-01; aquí basta con la mecánica:

Dos detalles de campo:

• La alarma 2 se crea en us-east-1, porque CloudFront publica siempre sus métricas ahí, exactamente igual que ocurría con los certificados de ACM en 03-04.
• --treat-missing-data notBreaching evita alarmas falsas de madrugada cuando no hay tráfico.

Y una alarma que no es de seguridad pero salva la factura: el presupuesto con avisos que creamos en 01-02. Si el gasto diario se dispara, alguien se entera aunque nadie esté mirando los paneles.

Un plan de respuesta sirve para no tener que pensar a las tres de la madrugada. Este es el de MercadoFresco, en orden:

Paso 1: confirmar desde fuera. Antes de nada, comprobar que el problema es real y no un fallo de monitorización:

Paso 2: los cuatro gráficos. RequestCount del ALB, CacheHitRate de CloudFront, HTTPCode_Target_5XX_Count y CPUUtilization del ASG. Con esos cuatro se sabe casi siempre qué está pasando.

Paso 5: identificar el patrón. Los registros de acceso que guardamos en mercadofresco-registros-web desde 03-03 son la fuente:

Ese análisis produce las tres respuestas que necesitas para escribir una regla de WAF: desde dónde viene, qué pide y con qué se identifica.

Esta es la parte difícil, y la que separa una respuesta profesional de un apagón autoinfligido. MercadoFresco tiene picos de tráfico legítimos y previsibles los viernes por la tarde. Bloquear tráfico real un viernes a las 19:00 es peor que el ataque.

La señal más fiable de todas es la conversión. Si llegan 5.000 peticiones por segundo y el número de pedidos por hora sigue en 900, no son clientes. Un pico legítimo mueve las dos métricas a la vez; un ataque solo mueve una. Marta tiene esa métrica de negocio publicada en el espacio de nombres MercadoFresco/Tienda gracias al permiso cloudwatch:PutMetricData que concedimos en 04-01, y es la que mira antes de decidir bloquear nada.

Y la regla de oro operativa:

Ante la duda, empieza contando, no bloqueando. El modo Count de WAF permite ver a quién afectaría una regla antes de aplicarla. Es el tema central de 04-05 y el error más caro de esta disciplina es saltárselo.

Medidas en caliente, de menos a más intrusivas:

Nunca: apagar CloudFront o desviar el DNS al origen. Eso elimina la única capa que te está protegiendo y convierte un incidente en una caída total.

Post-mortem. Cuando pasa, se escribe. Sin culpables y con datos:

1. Cronología con horas exactas: primer indicio, primera alarma, primera acción, mitigación, recuperación.
2. Caracterización: volumen máximo, número de fuentes, países, rutas objetivo, capa.
3. Impacto: minutos de degradación, pedidos perdidos estimados, coste de infraestructura extra.
4. Qué funcionó y qué no: ¿saltó la alarma correcta?, ¿a tiempo?, ¿había alguien?
5. Acciones concretas con responsable y fecha: reglas de WAF que se quedan permanentes, alarmas nuevas, umbrales ajustados.
6. Solicitud de créditos si se tuviera Shield Advanced.

El punto 5 es el que convierte un incidente en una mejora. Un post-mortem sin acciones con fecha es un texto que nadie volverá a leer.

Si hubieras activado Shield Advanced para probar, ten muy presente que el compromiso es de 12 meses: no se cancela sin más. Se gestiona desde la consola de Shield o con aws shield disassociate-drt-role y el proceso de baja de suscripción, que requiere abrir un caso de soporte.

Para deshacer lo creado en esta lección:

La regla del listener con la cabecera verificada no se borra: es una mejora permanente de la postura de seguridad y debe quedarse.

Creer que Shield Standard hay que activarlo. Ya está activo, en todas las cuentas, gratis. Lo que sí es una decisión tuya es aprovecharlo, sirviendo el tráfico por CloudFront y Route 53 en lugar de exponer el origen directamente.

Pensar que Shield protege de todo. Shield es capas 3 y 4. Los ataques de capa 7 —los que de verdad amenazan a una tienda— los filtra WAF. Contratar Shield Advanced y no configurar WAF es gastar 3.000 dólares y seguir expuesto a lo que más probablemente te pase.

Dejar el ALB accesible directamente. Si el nombre DNS del balanceador es resoluble y acepta tráfico de cualquier origen, un atacante puede saltarse CloudFront, la caché y el WAF de un salto. La cabecera verificada más la lista de prefijos de CloudFront cierran esa puerta.

Dejar el máximo del ASG en un número muy alto «por si acaso». Durante un ataque escalarás sin límite y el resultado será una factura, no un servicio disponible. Pon un techo consciente.

Bloquear por IP durante un ataque distribuido. Es agotador, inútil y acabas bloqueando clientes reales que comparten NAT corporativa. Bloquea por patrón de comportamiento, no por origen.

Bloquear sin haber contado primero. El error más caro. Una regla en Block mal calibrada un viernes a las 19:00 hace más daño que el ataque. Count primero, siempre.

Confundir un pico legítimo con un ataque. Mira la conversión a pedido y la tasa de aciertos de caché antes que ninguna otra cosa. Si los pedidos suben con el tráfico, es negocio, no ataque.

Apagar CloudFront «para ver si es cosa suya». Elimina la protección y expone el origen. Nunca.

Consejo: ensaya el plan. Un simulacro trimestral de media hora —«suena la alarma, ¿qué haces?»— vale más que un documento perfecto que nadie ha leído. Y comprueba que los avisos de alertas-mercadofresco llegan de verdad a un teléfono, no solo a un correo que nadie mira de noche.

Consejo: guarda una línea base. Ten a mano el tráfico normal por hora y día de la semana. Sin línea base no se puede decir si 5.000 peticiones por segundo es mucho.

Consejo: separa las rutas caras. Búsqueda, /login y /api/pedidos en grupos de destino distintos —tg-mercadofresco-api ya existe desde 03-03— permite protegerlas con reglas específicas y que su saturación no arrastre al resto del catálogo.

Una empresa de venta de entradas para conciertos, con arquitectura idéntica a la de MercadoFresco, factura 40 millones de euros al año concentrados en las horas siguientes a cada puesta a la venta. Una hora de caída durante una puesta a la venta cuesta unos 350.000 euros. El año pasado sufrió dos ataques de capa 7 que degradaron el servicio 40 minutos cada uno, y recibió un correo de extorsión amenazando con repetir. No tiene equipo de guardia nocturna.

Evalúa si debe contratar Shield Advanced. Estructura la respuesta en: coste anual del servicio, pérdida esperada sin él, funciones concretas que aportan valor en este caso, requisitos adicionales que hay que presupuestar, y decisión con justificación.

Un martes a las 04:12 saltan las alarmas de MercadoFresco. Los datos de los primeros diez minutos:

• RequestCount del ALB: de 200/min a 45.000/min en 30 segundos.
• CacheHitRate de CloudFront: de 89 % a 11 %.
• CPUUtilization del ASG: 97 % en las 2 instancias; el ASG escala a 12.
• DatabaseConnections de RDS: de 25 a 190 (el límite es 200).
• Métrica MercadoFresco/Tienda/PedidosPorHora: 3 (lo normal a esa hora es 5-10).
• Registros del ALB: 8.400 IP distintas, 61 países, el 78 % pide /buscar?q=<cadena aleatoria>&pagina=<numero aleatorio>.
• Agente de usuario: el 91 % declara Mozilla/5.0 (compatible; Baiduspider/2.0).

Responde: (a) ¿ataque o pico legítimo, y con qué tres señales lo justificas?; (b) ¿qué capa y qué técnica?; (c) ¿por qué es especialmente eficaz contra esta arquitectura?; (d) ¿qué tres medidas aplicarías, en orden, y cuál es el riesgo de cada una?; (e) ¿qué habría hecho Shield Advanced que no se puede hacer sin él?

Escribe el procedimiento completo, con comandos, para impedir que alguien pueda golpear alb-mercadofresco-tienda saltándose CloudFront. Debe cubrir: dónde se guarda el valor secreto, cómo lo envía CloudFront, cómo lo verifica el ALB, qué pasa con las peticiones que no lo llevan, cómo se refuerza además con grupos de seguridad, y cómo se rota el valor sin causar corte de servicio.

Solución 1

Coste anual del servicio:

Pérdida esperada sin él: dos incidentes de 40 minutos el año pasado × 350.000 €/hora × 0,67 h ≈ 470.000 € anuales en pérdida directa, sin contar reputación ni el hecho de que existe una amenaza explícita de repetición, que eleva la probabilidad futura.

Funciones que aportan valor en este caso concreto:

1. Protecciones automáticas de capa 7. No hay guardia nocturna y los ataques ocurren en las ventanas de venta, que pueden ser de madrugada. Shield Advanced escribe y aplica reglas solo, en segundos. Es la función decisiva aquí.
2. SRT con intervención proactiva. Suple literalmente la ausencia de equipo de guardia.
3. Protección de costes. Con esa concentración de tráfico, el escalado durante un ataque puede generar cargos de decenas de miles.
4. Detección por recurso. El tráfico de esta empresa es extremadamente picudo por naturaleza; una línea base genérica no distinguiría un ataque de una puesta a la venta. Solo la línea base específica del recurso puede.

Requisitos adicionales a presupuestar: el plan de soporte Business o Enterprise, el trabajo de configurar Web ACL y permisos para el SRT, la definición de contactos de emergencia y un ensayo del procedimiento.

Decisión: contratar, sin dudarlo. 40.000 USD frente a una exposición de 470.000 € anuales es una relación de más de diez a uno, con amenaza explícita de repetición y sin capacidad interna de respuesta nocturna. Es exactamente el perfil para el que existe el producto. Y conviene subrayar el contraste con MercadoFresco: el mismo servicio, la misma arquitectura y la decisión contraria, porque la variable que decide no es técnica sino el coste de un minuto de caída.

Solución 2

(a) Ataque, con tres señales concluyentes:

1. La conversión se ha desplomado en términos relativos. 45.000 peticiones por minuto producen 3 pedidos por hora, cuando lo normal a esa hora con 200 peticiones por minuto son 5-10. Si fueran clientes reales, los pedidos habrían subido con el tráfico.
2. La tasa de aciertos de caché se hunde de 89 % a 11 %. Un pico legítimo pide contenido popular y la mantiene o la mejora. Aquí se están pidiendo URL únicas a propósito.
3. La curva es vertical: de 200 a 45.000 en 30 segundos, y a las 04:12 de un martes, que es el valle absoluto de tráfico de una tienda de alimentación española.

Como confirmación adicional: 8.400 IP en 61 países no corresponden a la geografía de clientes de MercadoFresco, y un 91 % de agentes de usuario idénticos declarando ser un rastreador chino es una falsificación evidente —los rastreadores reales se identifican y respetan robots.txt, y ninguno genera 45.000 peticiones por minuto contra una búsqueda.

(b) Capa 7, inundación HTTP GET dirigida contra el punto de enlace de búsqueda con parámetros aleatorios. El volumen en bits por segundo es modesto; el daño no viene del ancho de banda.

(c) Es especialmente eficaz por tres motivos encadenados que atacan exactamente los puntos fuertes de la arquitectura:

1. Anula la caché de CloudFront. Cada q=<cadena aleatoria> genera una clave de caché distinta, así que el 100 % de las peticiones son fallos de caché y llegan al origen. La CDN, que es la primera línea de defensa, queda neutralizada.
2. Ataca la ruta más cara. La búsqueda no se cachea, ejecuta una consulta compleja y toca la base de datos en cada petición.
3. Satura el recurso que no escala. El ASG escala a 12 instancias, pero cada instancia abre conexiones a mercadofresco-pedidos, que tiene un límite de 200. El escalado empeora el problema: más instancias significan más conexiones contra una base de datos que no crece. A 190 de 200 conexiones, el siguiente paso es que la tienda entera deje de poder consultar nada.

(d) Tres medidas, en orden:

1. Regla de WAF por tasa sobre /buscar, en Count durante 2-3 minutos. Riesgo: ninguno, no bloquea nada; solo cuesta esos minutos. Sirve para confirmar cuántas peticiones legítimas caerían.
2. Pasar la regla a Block con umbral por IP, y añadir un bloqueo por agente de usuario falsificado. Riesgo: bajo, porque a las 04:12 el tráfico legítimo es mínimo y el patrón está muy caracterizado. Un rastreador legítimo que quedara bloqueado no supone daño real a esa hora.
3. Aumentar el TTL mínimo de las respuestas de búsqueda y cachear los errores. Riesgo: resultados de búsqueda ligeramente desactualizados durante unas horas, aceptable. Como cuarta medida, si la base de datos sigue al límite, derivar las lecturas a mercadofresco-pedidos-lectura.

Lo que no hay que hacer: bloquear las 8.400 IP una a una —volverán con otras—, ni apagar la búsqueda entera, ni desviar el DNS al origen.

(e) Shield Advanced habría hecho tres cosas imposibles sin él: detectar la anomalía contra la línea base específica de este recurso y no contra un umbral fijo; aplicar automáticamente reglas de WAF a las 04:12 sin que Marta se despertara, que es exactamente la ventana en la que ocurrió; y proporcionar las métricas DDoSDetected y DDoSAttackRequestsPerSecond que caracterizan el ataque sin tener que descargar y analizar gigabytes de registros a mano. Además, permitiría solicitar créditos por el coste del escalado a 12 instancias.

Solución 3

Procedimiento completo.

1. Generar y guardar el valor secreto. Va a Secrets Manager (04-03), no a un fichero ni a la consola:

2. Que CloudFront la envíe. En la definición del origen origen-tienda-alb de la distribución E2QWERTY123ABC se añade una cabecera personalizada X-Origen-Verificado con ese valor. Se envía en cada petición al origen y no es visible para el cliente.

3. Que el ALB la verifique. Regla de prioridad 1 en el listener HTTPS que reenvía al grupo de destino solo si la cabecera coincide:

4. Qué pasa con las demás. La acción por defecto del listener pasa a ser una respuesta fija 403, de modo que cualquier petición que no lleve la cabecera —es decir, cualquiera que no venga de CloudFront— se rechaza en el balanceador, sin llegar a las instancias y sin consumir nada:

5. Refuerzo con grupos de seguridad. Se restringe la entrada de sg-mercadofresco-alb al puerto 443 desde la lista de prefijos gestionada de CloudFront, en lugar de 0.0.0.0/0:

Son dos capas independientes: aunque alguien averiguara el valor de la cabecera, tendría que además originar el tráfico desde un rango de CloudFront.

6. Rotación sin corte. La clave está en aceptar dos valores simultáneamente durante la transición, exactamente el mismo principio de AWSCURRENT/AWSPENDING de 04-03:

1. Generar el valor nuevo y guardarlo en el secreto como versión AWSPENDING.
2. Modificar la regla del ALB para que acepte los dos valores en el array Values.
3. Actualizar el origen de CloudFront con el valor nuevo y esperar a que la distribución termine de desplegarse en todos los puntos de presencia (unos minutos).
4. Verificar en los registros que ya no llega ninguna petición con el valor antiguo.
5. Retirar el valor antiguo de la regla del ALB y promocionar la versión a AWSCURRENT.

Invertir el orden —cambiar CloudFront antes de que el ALB acepte el valor nuevo— provoca un corte total de servicio durante todo el despliegue de la distribución. Es el error clásico de esta operación, y el motivo por el que se hace un martes por la mañana y no un viernes por la tarde.

Ahora sabes contra qué te proteges. Un ataque de denegación de servicio distribuida no busca robar nada: busca agotar un recurso finito, y por eso la defensa no es un permiso ni una clave, sino capacidad, distancia y filtrado. Entiendes por qué la regla DENY numerada 50 de 03-02 funcionó contra una IP y es inútil contra diez mil: una NACL admite 40 entradas, y filtrar dentro de tu VPC significa que el paquete ya ha consumido tu ancho de banda. El tráfico malicioso hay que descartarlo en el borde, lejos.

Distingues las dos familias y sus defensas: los ataques volumétricos de capas 3 y 4 —inundación UDP, reflexión y amplificación, inundación SYN, fragmentación—, que se miden en gigabits y que la red de AWS absorbe; y los ataques de capa 7 —inundación HTTP, slowloris, abuso de la búsqueda, relleno de credenciales—, que llegan con volumen ridículo, parecen tráfico legítimo y son los que de verdad amenazan a una tienda como MercadoFresco. Shield para los primeros, WAF para los segundos.

Sabes que Shield Standard ya está activo y es gratuito, que actúa en CloudFront, Route 53 y ELB, y que MercadoFresco lleva usándolo desde 03-04 sin haberlo decidido: poner una CDN delante era también una decisión de seguridad. Y conoces lo que añade Shield Advanced —detección por recurso, protecciones automáticas de capa 7, métricas DDoSDetected y DDoSAttackBitsPerSecond, protección de costes frente al escalado y acceso al SRT 24/7— junto con su precio real de 3.000 USD al mes con compromiso anual. Has hecho la evaluación con números y la respuesta para MercadoFresco es no: 36.000 dólares al año para cubrir un riesgo de infraestructura de doscientos. Y sabes exactamente qué tendría que cambiar para que la respuesta fuera la contraria, porque el ejercicio de la empresa de entradas es la misma arquitectura con la decisión opuesta.

Lo que sí has hecho es lo que de verdad protege a una empresa de este tamaño: arquitectura. Servir todo desde el borde, reducir la superficie cerrando el acceso directo al ALB con una cabecera verificada guardada en Secrets Manager y la lista de prefijos de CloudFront en sg-mercadofresco-alb, cachear agresivamente incluidos los errores, y sobredimensionar con un techo consciente en el ASG para que el escalado no se convierta en la factura del atacante. Has montado tres alarmas hacia alertas-mercadofresco por 0,30 USD al mes, sabiendo que la de CloudFront va en us-east-1. Y tienes un plan de respuesta con un orden claro y, sobre todo, la tabla que distingue un ataque de un viernes muy bueno: la conversión a pedido y la tasa de aciertos de caché antes que cualquier otra cosa.

Pero el plan termina siempre en el mismo punto. Cuando Marta identifica el patrón —esas rutas, esos países, ese agente de usuario falsificado, esa tasa de peticiones por IP— necesita una herramienta que mire dentro de la petición HTTP y decida en función de su contenido, no de su origen. Ni Shield ni un grupo de seguridad pueden hacerlo: uno trabaja con paquetes y el otro con IP y puertos. En la lección 04-05, «AWS WAF», cerraremos el módulo con esa herramienta: la Web ACL que se asocia delante de la distribución E2QWERTY123ABC y del alb-mercadofresco-tienda, los grupos de reglas gestionadas por AWS, las declaraciones de coincidencia y las transformaciones de texto que impiden las evasiones triviales, las reglas por tasa para proteger /login y /api/pedidos, y —por encima de todo— el método de despliegue que evita el desastre: empezar en Count, leer los registros, ajustar las excepciones y solo entonces pasar a Block.