A 03-02, quan una sola adreça IP va començar a fer milers de peticions per minut contra la botiga, la solució va ser elegant i va durar un minut: una regla DENY numerada 50 a la NACL de les subxarxes públiques, amb número baix perquè s'avalués abans que l'ALLOW general. Va funcionar perfectament.

Va funcionar perquè era una adreça.

Si demà les peticions arriben des de deu mil adreces repartides per seixanta països, aquesta regla no serveix de res. I no és només que calgui escriure deu mil regles: és que no es pot. Una NACL admet 20 regles per defecte i un màxim dur de 40. Un grup de seguretat n'admet 60. L'eina que va resoldre el problema petit no escala al problema gran, i això no és un defecte de l'eina: és que són problemes diferents.

Pitjor encara, hi ha un dany col·lateral que gairebé ningú no anticipa el primer cop. El grup d'Auto Scaling asg-mercadofresco-tienda que vam muntar a 02-01 per resoldre les caigudes dels divendres farà exactament allò per a què va ser dissenyat: veure molta càrrega i arrencar instàncies. Un atac de denegació de servei contra una arquitectura elàstica no sempre tomba el servei; de vegades simplement el converteix en una factura de cinc xifres.

AWS Shield és el servei de protecció davant d'atacs de denegació de servei distribuïda. En aquesta lliçó la Marta entén contra què s'està protegint, descobreix que la major part de la protecció ja la té activada i gratis, i pren una decisió raonada —i negativa— sobre els 3.000 dòlars mensuals de Shield Advanced.

Advertiment. El contingut d'aquesta lliçó és estrictament defensiu: descriu com detectar i mitigar atacs contra la teva pròpia infraestructura, mai com executar-los. Fer proves de càrrega o d'estrès contra sistemes que no són teus és il·legal, i contra els teus a AWS requereix seguir la política de proves de simulació d'AWS. Els exemples són didàctics: tota configuració de seguretat, i en particular qualsevol pla de resposta a incidents que afecti dades de clients sota el RGPD, ha de ser revisada per un professional de seguretat abans d'aplicar-se a un entorn real.

1. Què és un atac de denegació de servei distribuïda
2. Per què la regla d'una sola IP no serveix
3. Taxonomia: capes 3/4 enfront de capa 7
4. Atacs volumètrics
5. Atacs de capa d'aplicació
6. El dany econòmic: quan l'escalat juga en contra teva
7. AWS Shield Standard: el que ja tens
8. AWS Shield Advanced: què hi afegeix
9. Protecció de costos enfront de l'escalat
10. L'equip de resposta davant d'incidents (SRT)
11. Cost real i avaluació honesta per a MercadoFresco
12. Arquitectura resilient: la primera línia de defensa
13. Reduir la superfície exposada
14. Fer memòria cau agressivament i sobredimensionar
15. Mètriques i detecció
16. Alarmes cap a alertas-mercadofresco
17. Pla de resposta: què mira primer la Marta
18. Distingir un atac d'un divendres molt bo
19. Què fer en calent i què documentar després
20. Cost, neteja i el que ve

Un atac de denegació de servei (DoS) busca deixar un servei inaccessible per als seus usuaris legítims consumint un recurs finit: amplada de banda, connexions, CPU, memòria o connexions de base de dades. Distribuïda (DDoS) significa que el trànsit prové de moltes fonts simultànies —típicament equips compromesos o serveis de tercers abusats—, cosa que fa inviable distingir-les i bloquejar-les una a una.

La diferència amb altres atacs importa:

Per a MercadoFresco, un atac de dues hores un divendres a la tarda significa perdre unes 1.800 comandes —900 per hora al pic— més el dany que els clients que van voler comprar i no van poder se'n recordin la setmana següent.

Qui els llança: extorsió («paga o continuem»), competència deslleial, activisme, o simplement soroll de fons automatitzat que escombra internet buscant objectius fàcils. Aquesta última categoria és la més freqüent i la raó que fins i tot una botiga mitjana hagi de pensar en això.

Val la pena veure el contrast amb números:

Hi ha a més un problema conceptual més profund. Filtrar a la NACL significa que el paquet ja ha arribat a la teva VPC: ha consumit la teva amplada de banda d'entrada i ha arribat fins a la porta. Si l'atac satura l'enllaç, filtrar a dins no ajuda, perquè l'enllaç ja és ple.

D'aquí el principi que organitza tota la defensa contra DDoS:

El trànsit maliciós s'ha de filtrar tan lluny com es pugui de la teva infraestructura, idealment a la xarxa del proveïdor, distribuït entre centenars de punts de presència, abans que convergeixi cap a un únic destí.

Això és exactament el que fa Shield, i explica per què la protecció va associada a CloudFront i Route 53: són serveis que viuen a la vora.

Els atacs es classifiquen per la capa del model OSI en què operen, i aquesta classificació determina la defensa:

La conclusió operativa és la que estructura aquest mòdul: Shield per al volumètric, WAF per a l'intel·ligent. Cap dels dos no substitueix l'altre, i la lliçó següent cobreix el segon.

Els de capa 3 i 4. Existeixen des de fa dècades i avui es llancen gairebé sempre des de botnets o abusant de serveis mal configurats a internet.

L'amplificació per reflexió és la que produeix els atacs de mida més gran registrats: un atacant amb poca amplada de banda pot generar centenars de vegades aquesta quantitat contra el seu objectiu. La mitigació és de xarxa i passa abans d'arribar a tu: no es resol al teu servidor.

La bona notícia per a MercadoFresco és que gairebé tot això ho absorbeix AWS per defecte. La capacitat agregada de la xarxa d'AWS i dels punts de presència de CloudFront és d'un ordre de magnitud que cap atac volumètric dirigit a una botiga mitjana no esgotarà. Contra aquesta família, MercadoFresco ja està protegit sense haver fet res.

Aquí és on una empresa de la mida de MercadoFresco té un problema real, perquè aquests atacs no necessiten volum.

El cas concret que més preocupa la Marta: la cerca de productes. Una petició a /buscar?q=tomate&filtros=ecologico,granel&orden=precio no se serveix de la memòria cau, executa una consulta complexa contra mercadofresco-pedidos i triga uns 200 ms. Cinquanta peticions per segon des de cinquanta adreces diferents —un volum ridícul, indistingible del trànsit normal en un gràfic d'amplada de banda— poden saturar la base de dades sense que cap alarma de xarxa s'immuti.

Aquest és el motiu que Shield sol no basti i que existeixi la lliçó 04-05.

Aquest apartat mereix un càlcul, perquè és l'argument que fa que la direcció d'una empresa entengui el problema.

Suposem un atac de capa 7 sostingut durant 6 hores contra MercadoFresco, amb 5.000 peticions per segon arribant a l'ALB:

El cost d'infraestructura d'un atac així a MercadoFresco és de desenes o pocs centenars de dòlars: molest, no catastròfic. El dany real són les vendes perdudes i la confiança. Aquest càlcul és important perquè és el que evita la decisió emocional de contractar Shield Advanced a 3.000 USD al mes per protegir-se d'un risc de 200 USD.

En arquitectures més grans el càlcul canvia radicalment, i per això existeix la protecció de costos que veurem d'aquí a dos apartats.

Shield Standard està actiu, és gratuït i no cal fer res per tenir-lo. S'aplica automàticament a tots els clients d'AWS.

Què inclou:

• Detecció i mitigació automàtiques dels atacs volumètrics i d'estat de connexió més comuns de capes 3 i 4, en temps real i de manera contínua.
• Mitigació en línia, sense desviar el trànsit ni introduir latència perceptible.
• Protecció integrada a CloudFront, Route 53, Global Accelerator i Elastic Load Balancing, que són precisament els serveis on viu la vora de MercadoFresco.
• Defenses de xarxa aplicades a la infraestructura d'AWS: filtratge de paquets mal formats, límits per origen, protecció davant d'inundacions SYN.

El que importa és on actua:

El filtratge passa abans de CloudFront, és a dir, abans que el trànsit arribi a res teu i abans que generi cost. El que Shield Standard no fa és distingir una petició HTTP legítima d'una altra de maliciosa: això és capa 7 i és feina de WAF.

Verificació pràctica: com que MercadoFresco ja serveix tot el seu trànsit a través de CloudFront (03-04) i resol el DNS amb Route 53 (03-05), ja fa servir Shield Standard en la forma més efectiva sense haver-ho decidit conscientment. Aquesta és una de les raons no evidents de posar una CDN al davant, fins i tot quan l'estalvi de transferència no fos l'argument principal.

Les tres funcions que de debò justifiquen el preu:

1. Detecció específica per recurs. Shield Advanced estableix una línia base del trànsit normal de la teva aplicació —no de la mitjana d'AWS— i detecta desviacions. Pot identificar un atac de 200 Mbps contra un recurs que normalment rep 20 Mbps, un volum que en termes absoluts no cridaria l'atenció de ningú.

2. Proteccions automàtiques de capa d'aplicació. Amb això activat, Shield Advanced escriu i aplica regles de WAF pel seu compte durant un atac, basant-se en el patró detectat, i les retira quan passa. És l'única manera de respondre a un atac de capa 7 en segons i de matinada sense que hi hagi ningú despert.

3. Protecció de costos, que mereix el seu propi apartat.

És la funció menys coneguda i la que més vegades ha justificat la contractació.

Durant un atac, la teva infraestructura elàstica reacciona: l'ASG arrenca instàncies, CloudFront serveix peticions, l'ALB processa connexions, la transferència de sortida es dispara. Tot es factura.

Shield Advanced ofereix crèdits de servei pels càrrecs atribuïbles a un atac verificat als recursos protegits:

Com funciona a la pràctica: s'obre un cas de suport durant o després de l'atac, AWS verifica que hi va haver un esdeveniment de DDoS en aquell recurs i en aquella finestra, i aplica un crèdit a la factura. No és automàtic: cal sol·licitar-lo.

Per a una empresa la factura de la qual durant un atac pot passar de 5.000 a 80.000 dòlars en una nit, aquesta funció sola paga el servei. Per a MercadoFresco, que en l'atac més car imaginable perd uns 200 dòlars, no.

El Shield Response Team és un equip d'enginyers d'AWS especialitzats en DDoS, disponible 24/7 per a clients de Shield Advanced amb pla de suport Business o Enterprise.

Què fa:

• Durant un atac: investiga amb tu, escriu mitigacions a mida, aplica regles de WAF a les teves Web ACL si li has donat permís.
• Proactivament: si l'autoritzes, pot intervenir sense esperar que el cridis, tan bon punt les seves alarmes es disparin. Això és el que es coneix com a proactive engagement i cal activar-ho i configurar els contactes.
• Abans: revisa la teva arquitectura i recomana canvis.

La part a valorar és que donar-li accés a les teves Web ACL significa autoritzar un tercer a modificar les teves regles de filtratge en producció sense la teva intervenció prèvia. Per a moltes organitzacions això és exactament el que volen a les quatre de la matinada; per a d'altres és un problema de govern que cal documentar.

Són 36.000 USD a l'any, més transferència, més suport. El compromís anual significa que no es pot contractar «només mentre duri el sotrac».

Fem l'avaluació honesta per a MercadoFresco:

Conclusió: MercadoFresco no ha de contractar Shield Advanced avui. El cost equival aproximadament a tota la seva factura d'AWS multiplicada diverses vegades, per protegir-se d'un risc l'impacte directe del qual és de dos ordres de magnitud menor.

El que sí que ha de fer, i és la resta de la lliçó:

1. Aprofitar al màxim Shield Standard, que ja té, servint-ho tot per CloudFront.
2. Dissenyar l'arquitectura per absorbir, no per resistir.
3. Muntar WAF amb regles per taxa (04-05), que costa uns pocs dòlars al mes i cobreix el 90 % del que li preocupa.
4. Tenir alarmes i un pla escrit.

I quan sí que tindria sentit reconsiderar-ho:

• Si MercadoFresco creixés fins a facturar milions i una hora de caiguda costés desenes de milers.
• Si rebés un atac d'extorsió amb amenaça de repetició.
• Si un client corporatiu o una normativa ho exigís contractualment.
• Si operés en un sector amb perfil d'objectiu alt (banca, joc, mitjans, sector públic).

És una decisió de negoci amb números, no una decisió tècnica. I saber argumentar el «no» amb dades és tan valuós com saber configurar el «sí».

Abans que qualsevol servei de protecció, la millor defensa contra DDoS és una arquitectura que absorbeix. Aquests són els quatre principis, i MercadoFresco ja en compleix gairebé tots:

El que fa forta aquesta arquitectura no és cap producte de seguretat, sinó quatre decisions preses als mòduls 2 i 3:

La regla és simple: el que no està exposat no es pot atacar. Revisió de la superfície de MercadoFresco:

L'única millora pendent és la segona fila. Encara que el DNS públic apunti a CloudFront, l'ALB continua tenint un nom DNS públic resoluble, i un atacant que el descobreixi pot saltar-se CloudFront i colpejar-lo directament, evitant la memòria cau i el WAF. La mitigació estàndard té dues parts:

1. Que CloudFront afegeixi una capçalera secreta a cada petició cap a l'origen.
2. Que l'ALB rebutgi qualsevol petició que no la porti, mitjançant una regla del listener.

Aquest valor de capçalera és exactament el tipus de secret rotable que va a Secrets Manager, com vam veure a 04-03. I per completar el tancament es poden restringir les regles d'entrada de sg-mercadofresco-alb als rangs d'IP publicats de CloudFront, fent servir la llista gestionada de prefixos com.amazonaws.global.cloudfront.origin-facing:

Amb aquestes dues mesures, l'ALB deixa de ser un objectiu abastable i tot el trànsit està obligat a passar per la vora, que és on viu la protecció.

Memòria cau. Una petició servida des de la memòria cau de CloudFront no arriba a la teva infraestructura, no consumeix CPU, no toca la base de dades i no compta per a l'escalat. Amb la taxa d'encerts que vam mesurar a 03-04, la immensa majoria del trànsit del catàleg es queda a la vora. Recomanacions específiques davant de DDoS:

• Desar també a la memòria cau les respostes d'error (404, 403) durant uns segons. Un atac que demana rutes inexistents és, si no, un atac que arriba sencer a l'origen.
• Definir un TTL mínim raonable perquè un atacant no pugui invalidar la memòria cau afegint paràmetres de consulta aleatoris: la clau de memòria cau ha d'incloure només els paràmetres que de debò canvien la resposta, com vam configurar amb les polítiques de memòria cau.
• Servir una pàgina de manteniment estàtica des d'S3 com a destinació de commutació per error de Route 53, ja preparada a 03-05: si tot falla, els clients veuen alguna cosa.

Sobredimensionar. Absorbir és més barat que caure:

• Que la capacitat mínima de l'ASG sigui més de l'estrictament necessari. MercadoFresco té 2 instàncies per a 900 comandes/hora quan una en serveix 600.
• Que l'escalat reaccioni ràpid: un període d'escalfament curt i llindars baixos.
• Que el màxim tingui un sostre conscient. Aquest punt és contraintuïtiu però important: un ASG amb màxim 100 durant un atac és una factura. Un màxim de 20 significa que el servei es degrada, però de manera acotada i previsible. Tria el número deliberadament, no el deixis per defecte.
• Fer servir tipus d'instància amb rendiment de xarxa garantit si el trànsit és alt: les famílies amb crèdit de xarxa es poden veure limitades just quan més falta fan.

Amb Shield Advanced es disposa de l'espai de noms AWS/DDoSProtection a CloudWatch:

Sense Shield Advanced —el cas de MercadoFresco— aquestes mètriques no existeixen i cal detectar per senyals indirectes. Aquestes són les que la Marta vigila:

Aquesta última fila és especialment reveladora. Un pic legítim de trànsit manté o millora la taxa d'encerts, perquè molta gent demana les mateixes pàgines populars. Un atac dissenyat per fer mal demana rutes aleatòries o amb paràmetres únics, i enfonsa la taxa d'encerts. Un gràfic de CacheHitRate caient mentre Requests puja és un dels senyals més nets que existeixen.

Aquestes són les alarmes que MercadoFresco munta avui, sense Shield Advanced. CloudWatch es veu a fons a 05-01; aquí n'hi ha prou amb la mecànica:

Dos detalls de camp:

• L'alarma 2 es crea a us-east-1, perquè CloudFront publica sempre les seves mètriques allà, exactament igual que passava amb els certificats d'ACM a 03-04.
• --treat-missing-data notBreaching evita alarmes falses de matinada quan no hi ha trànsit.

I una alarma que no és de seguretat però salva la factura: el pressupost amb avisos que vam crear a 01-02. Si la despesa diària es dispara, algú se n'assabenta encara que ningú no miri els taulers.

Un pla de resposta serveix per no haver de pensar a les tres de la matinada. Aquest és el de MercadoFresco, en ordre:

Pas 1: confirmar des de fora. Abans de res, comprovar que el problema és real i no una fallada de monitoratge:

Pas 2: els quatre gràfics. RequestCount de l'ALB, CacheHitRate de CloudFront, HTTPCode_Target_5XX_Count i CPUUtilization de l'ASG. Amb aquests quatre se sap gairebé sempre què està passant.

Pas 5: identificar el patró. Els registres d'accés que guardem a mercadofresco-registros-web des de 03-03 són la font:

Aquesta anàlisi produeix les tres respostes que necessites per escriure una regla de WAF: d'on ve, què demana i amb què s'identifica.

Aquesta és la part difícil, i la que separa una resposta professional d'una apagada autoinfligida. MercadoFresco té pics de trànsit legítims i previsibles els divendres a la tarda. Bloquejar trànsit real un divendres a les 19:00 és pitjor que l'atac.

El senyal més fiable de tots és la conversió. Si arriben 5.000 peticions per segon i el nombre de comandes per hora continua en 900, no són clients. Un pic legítim mou les dues mètriques alhora; un atac només en mou una. La Marta té aquesta mètrica de negoci publicada a l'espai de noms MercadoFresco/Tienda gràcies al permís cloudwatch:PutMetricData que vam concedir a 04-01, i és la que mira abans de decidir bloquejar res.

I la regla d'or operativa:

Davant del dubte, comença comptant, no bloquejant. El mode Count de WAF permet veure a qui afectaria una regla abans d'aplicar-la. És el tema central de 04-05 i l'error més car d'aquesta disciplina és saltar-se'l.

Mesures en calent, de menys a més intrusives:

Mai: apagar CloudFront o desviar el DNS a l'origen. Això elimina l'única capa que t'està protegint i converteix un incident en una caiguda total.

Post-mortem. Quan passa, s'escriu. Sense culpables i amb dades:

1. Cronologia amb hores exactes: primer indici, primera alarma, primera acció, mitigació, recuperació.
2. Caracterització: volum màxim, nombre de fonts, països, rutes objectiu, capa.
3. Impacte: minuts de degradació, comandes perdudes estimades, cost d'infraestructura extra.
4. Què va funcionar i què no: va saltar l'alarma correcta?, a temps?, hi havia algú?
5. Accions concretes amb responsable i data: regles de WAF que es queden permanents, alarmes noves, llindars ajustats.
6. Sol·licitud de crèdits si es tingués Shield Advanced.

El punt 5 és el que converteix un incident en una millora. Un post-mortem sense accions amb data és un text que ningú no tornarà a llegir.

Si haguessis activat Shield Advanced per provar, tingues molt present que el compromís és de 12 mesos: no es cancel·la sense més. Es gestiona des de la consola de Shield o amb aws shield disassociate-drt-role i el procés de baixa de subscripció, que requereix obrir un cas de suport.

Per desfer el que s'ha creat en aquesta lliçó:

La regla del listener amb la capçalera verificada no s'esborra: és una millora permanent de la postura de seguretat i s'ha de quedar.

Creure que Shield Standard s'ha d'activar. Ja està actiu, a tots els comptes, gratis. El que sí que és una decisió teva és aprofitar-lo, servint el trànsit per CloudFront i Route 53 en lloc d'exposar l'origen directament.

Pensar que Shield protegeix de tot. Shield és capes 3 i 4. Els atacs de capa 7 —els que de debò amenacen una botiga— els filtra WAF. Contractar Shield Advanced i no configurar WAF és gastar 3.000 dòlars i continuar exposat al que més probablement et passi.

Deixar l'ALB accessible directament. Si el nom DNS del balancejador és resoluble i accepta trànsit de qualsevol origen, un atacant pot saltar-se CloudFront, la memòria cau i el WAF d'un salt. La capçalera verificada més la llista de prefixos de CloudFront tanquen aquesta porta.

Deixar el màxim de l'ASG en un número molt alt «per si de cas». Durant un atac escalaràs sense límit i el resultat serà una factura, no un servei disponible. Posa-hi un sostre conscient.

Bloquejar per IP durant un atac distribuït. És esgotador, inútil i acabes bloquejant clients reals que comparteixen NAT corporativa. Bloqueja per patró de comportament, no per origen.

Bloquejar sense haver comptat primer. L'error més car. Una regla en Block mal calibrada un divendres a les 19:00 fa més mal que l'atac. Count primer, sempre.

Confondre un pic legítim amb un atac. Mira la conversió a comanda i la taxa d'encerts de memòria cau abans que cap altra cosa. Si les comandes pugen amb el trànsit, és negoci, no atac.

Apagar CloudFront «per veure si és cosa seva». Elimina la protecció i exposa l'origen. Mai.

Consell: assaja el pla. Un simulacre trimestral de mitja hora —«sona l'alarma, què fas?»— val més que un document perfecte que ningú no ha llegit. I comprova que els avisos de alertas-mercadofresco arriben de debò a un telèfon, no només a un correu que ningú no mira de nit.

Consell: guarda una línia base. Tingues a mà el trànsit normal per hora i dia de la setmana. Sense línia base no es pot dir si 5.000 peticions per segon és molt.

Consell: separa les rutes cares. Cerca, /login i /api/pedidos en grups de destinació diferents —tg-mercadofresco-api ja existeix des de 03-03— permet protegir-les amb regles específiques i que la seva saturació no arrossegui la resta del catàleg.

Una empresa de venda d'entrades per a concerts, amb arquitectura idèntica a la de MercadoFresco, factura 40 milions d'euros a l'any concentrats en les hores següents a cada posada a la venda. Una hora de caiguda durant una posada a la venda costa uns 350.000 euros. L'any passat va patir dos atacs de capa 7 que van degradar el servei 40 minuts cadascun, i va rebre un correu d'extorsió amenaçant de repetir-los. No té equip de guàrdia nocturna.

Avalua si ha de contractar Shield Advanced. Estructura la resposta en: cost anual del servei, pèrdua esperada sense ell, funcions concretes que aporten valor en aquest cas, requisits addicionals que cal pressupostar, i decisió amb justificació.

Un dimarts a les 04:12 salten les alarmes de MercadoFresco. Les dades dels primers deu minuts:

• RequestCount de l'ALB: de 200/min a 45.000/min en 30 segons.
• CacheHitRate de CloudFront: del 89 % a l'11 %.
• CPUUtilization de l'ASG: 97 % a les 2 instàncies; l'ASG escala a 12.
• DatabaseConnections d'RDS: de 25 a 190 (el límit és 200).
• Mètrica MercadoFresco/Tienda/PedidosPorHora: 3 (el normal a aquella hora és 5-10).
• Registres de l'ALB: 8.400 IP diferents, 61 països, el 78 % demana /buscar?q=<cadena aleatòria>&pagina=<numero aleatori>.
• Agent d'usuari: el 91 % declara Mozilla/5.0 (compatible; Baiduspider/2.0).

Respon: (a) atac o pic legítim, i amb quins tres senyals ho justifiques?; (b) quina capa i quina tècnica?; (c) per què és especialment eficaç contra aquesta arquitectura?; (d) quines tres mesures aplicaries, en ordre, i quin és el risc de cadascuna?; (e) què hauria fet Shield Advanced que no es pot fer sense ell?

Escriu el procediment complet, amb ordres, per impedir que algú pugui colpejar alb-mercadofresco-tienda saltant-se CloudFront. Ha de cobrir: on es guarda el valor secret, com l'envia CloudFront, com el verifica l'ALB, què passa amb les peticions que no el porten, com es reforça a més amb grups de seguretat, i com es rota el valor sense causar tall de servei.

Solució 1

Cost anual del servei:

Pèrdua esperada sense ell: dos incidents de 40 minuts l'any passat × 350.000 €/hora × 0,67 h ≈ 470.000 € anuals en pèrdua directa, sense comptar reputació ni el fet que existeix una amenaça explícita de repetició, que eleva la probabilitat futura.

Funcions que aporten valor en aquest cas concret:

1. Proteccions automàtiques de capa 7. No hi ha guàrdia nocturna i els atacs passen a les finestres de venda, que poden ser de matinada. Shield Advanced escriu i aplica regles sol, en segons. És la funció decisiva aquí.
2. SRT amb intervenció proactiva. Supleix literalment l'absència d'equip de guàrdia.
3. Protecció de costos. Amb aquesta concentració de trànsit, l'escalat durant un atac pot generar càrrecs de desenes de milers.
4. Detecció per recurs. El trànsit d'aquesta empresa és extremadament punxegut per naturalesa; una línia base genèrica no distingiria un atac d'una posada a la venda. Només la línia base específica del recurs pot fer-ho.

Requisits addicionals a pressupostar: el pla de suport Business o Enterprise, la feina de configurar Web ACL i permisos per a l'SRT, la definició de contactes d'emergència i un assaig del procediment.

Decisió: contractar, sense dubtar-ho. 40.000 USD davant d'una exposició de 470.000 € anuals és una relació de més de deu a un, amb amenaça explícita de repetició i sense capacitat interna de resposta nocturna. És exactament el perfil per al qual existeix el producte. I convé subratllar el contrast amb MercadoFresco: el mateix servei, la mateixa arquitectura i la decisió contrària, perquè la variable que decideix no és tècnica sinó el cost d'un minut de caiguda.

Solució 2

(a) Atac, amb tres senyals concloents:

1. La conversió s'ha esfondrat en termes relatius. 45.000 peticions per minut produeixen 3 comandes per hora, quan el normal a aquella hora amb 200 peticions per minut és de 5-10. Si fossin clients reals, les comandes haurien pujat amb el trànsit.
2. La taxa d'encerts de memòria cau s'enfonsa del 89 % a l'11 %. Un pic legítim demana contingut popular i la manté o la millora. Aquí s'estan demanant URL úniques a propòsit.
3. La corba és vertical: de 200 a 45.000 en 30 segons, i a les 04:12 d'un dimarts, que és el vall absolut de trànsit d'una botiga d'alimentació espanyola.

Com a confirmació addicional: 8.400 IP a 61 països no corresponen a la geografia de clients de MercadoFresco, i un 91 % d'agents d'usuari idèntics declarant ser un rastrejador xinès és una falsificació evident —els rastrejadors reals s'identifiquen i respecten robots.txt, i cap no genera 45.000 peticions per minut contra una cerca.

(b) Capa 7, inundació HTTP GET dirigida contra el punt d'enllaç de cerca amb paràmetres aleatoris. El volum en bits per segon és modest; el dany no ve de l'amplada de banda.

(c) És especialment eficaç per tres motius encadenats que ataquen exactament els punts forts de l'arquitectura:

1. Anul·la la memòria cau de CloudFront. Cada q=<cadena aleatòria> genera una clau de memòria cau diferent, així que el 100 % de les peticions són fallades i arriben a l'origen. La CDN, que és la primera línia de defensa, queda neutralitzada.
2. Ataca la ruta més cara. La cerca no es desa a la memòria cau, executa una consulta complexa i toca la base de dades a cada petició.
3. Satura el recurs que no escala. L'ASG escala a 12 instàncies, però cada instància obre connexions a mercadofresco-pedidos, que té un límit de 200. L'escalat empitjora el problema: més instàncies signifiquen més connexions contra una base de dades que no creix. A 190 de 200 connexions, el pas següent és que la botiga sencera deixi de poder consultar res.

(d) Tres mesures, en ordre:

1. Regla de WAF per taxa sobre /buscar, en Count durant 2-3 minuts. Risc: cap, no bloqueja res; només costa aquests minuts. Serveix per confirmar quantes peticions legítimes caurien.
2. Passar la regla a Block amb llindar per IP, i afegir un bloqueig per agent d'usuari falsificat. Risc: baix, perquè a les 04:12 el trànsit legítim és mínim i el patró està molt caracteritzat. Un rastrejador legítim que quedés bloquejat no suposa cap dany real a aquella hora.
3. Augmentar el TTL mínim de les respostes de cerca i desar els errors a la memòria cau. Risc: resultats de cerca lleugerament desactualitzats durant unes hores, acceptable. Com a quarta mesura, si la base de dades continua al límit, derivar les lectures a mercadofresco-pedidos-lectura.

El que no cal fer: bloquejar les 8.400 IP una a una —tornaran amb unes altres—, ni apagar la cerca sencera, ni desviar el DNS a l'origen.

(e) Shield Advanced hauria fet tres coses impossibles sense ell: detectar l'anomalia contra la línia base específica d'aquest recurs i no contra un llindar fix; aplicar automàticament regles de WAF a les 04:12 sense que la Marta es despertés, que és exactament la finestra en què va passar; i proporcionar les mètriques DDoSDetected i DDoSAttackRequestsPerSecond que caracteritzen l'atac sense haver de descarregar i analitzar gigabytes de registres a mà. A més, permetria sol·licitar crèdits pel cost de l'escalat a 12 instàncies.

Solució 3

Procediment complet.

1. Generar i guardar el valor secret. Va a Secrets Manager (04-03), no a un fitxer ni a la consola:

2. Que CloudFront l'enviï. A la definició de l'origen origen-tienda-alb de la distribució E2QWERTY123ABC s'afegeix una capçalera personalitzada X-Origen-Verificado amb aquest valor. S'envia a cada petició a l'origen i no és visible per al client.

3. Que l'ALB la verifiqui. Regla de prioritat 1 al listener HTTPS que reenvia al grup de destinació només si la capçalera coincideix:

4. Què passa amb les altres. L'acció per defecte del listener passa a ser una resposta fixa 403, de manera que qualsevol petició que no porti la capçalera —és a dir, qualsevol que no vingui de CloudFront— es rebutja al balancejador, sense arribar a les instàncies i sense consumir res:

5. Reforç amb grups de seguretat. Es restringeix l'entrada de sg-mercadofresco-alb al port 443 des de la llista de prefixos gestionada de CloudFront, en lloc de 0.0.0.0/0:

Són dues capes independents: encara que algú esbrinés el valor de la capçalera, hauria d'originar, a més, el trànsit des d'un rang de CloudFront.

6. Rotació sense tall. La clau és acceptar dos valors simultàniament durant la transició, exactament el mateix principi d'AWSCURRENT/AWSPENDING de 04-03:

1. Generar el valor nou i guardar-lo al secret com a versió AWSPENDING.
2. Modificar la regla de l'ALB perquè accepti els dos valors a l'array Values.
3. Actualitzar l'origen de CloudFront amb el valor nou i esperar que la distribució acabi de desplegar-se a tots els punts de presència (uns minuts).
4. Verificar als registres que ja no arriba cap petició amb el valor antic.
5. Retirar el valor antic de la regla de l'ALB i promocionar la versió a AWSCURRENT.

Invertir l'ordre —canviar CloudFront abans que l'ALB accepti el valor nou— provoca un tall total de servei durant tot el desplegament de la distribució. És l'error clàssic d'aquesta operació, i el motiu pel qual es fa un dimarts al matí i no un divendres a la tarda.

Ara ja saps contra què et protegeixes. Un atac de denegació de servei distribuïda no busca robar res: busca esgotar un recurs finit, i per això la defensa no és un permís ni una clau, sinó capacitat, distància i filtratge. Entens per què la regla DENY numerada 50 de 03-02 va funcionar contra una IP i és inútil contra deu mil: una NACL admet 40 entrades, i filtrar dins de la teva VPC significa que el paquet ja ha consumit la teva amplada de banda. El trànsit maliciós s'ha de descartar a la vora, lluny.

Distingeixes les dues famílies i les seves defenses: els atacs volumètrics de capes 3 i 4 —inundació UDP, reflexió i amplificació, inundació SYN, fragmentació—, que es mesuren en gigabits i que la xarxa d'AWS absorbeix; i els atacs de capa 7 —inundació HTTP, slowloris, abús de la cerca, farciment de credencials—, que arriben amb volum ridícul, semblen trànsit legítim i són els que de debò amenacen una botiga com MercadoFresco. Shield per als primers, WAF per als segons.

Saps que Shield Standard ja està actiu i és gratuït, que actua a CloudFront, Route 53 i ELB, i que MercadoFresco el fa servir des de 03-04 sense haver-ho decidit: posar una CDN al davant era també una decisió de seguretat. I coneixes el que hi afegeix Shield Advanced —detecció per recurs, proteccions automàtiques de capa 7, mètriques DDoSDetected i DDoSAttackBitsPerSecond, protecció de costos enfront de l'escalat i accés a l'SRT 24/7— juntament amb el preu real de 3.000 USD al mes amb compromís anual. Has fet l'avaluació amb números i la resposta per a MercadoFresco és no: 36.000 dòlars a l'any per cobrir un risc d'infraestructura de dos-cents. I saps exactament què hauria de canviar perquè la resposta fos la contrària, perquè l'exercici de l'empresa d'entrades és la mateixa arquitectura amb la decisió oposada.

El que sí que has fet és el que de debò protegeix una empresa d'aquesta mida: arquitectura. Servir-ho tot des de la vora, reduir la superfície tancant l'accés directe a l'ALB amb una capçalera verificada guardada a Secrets Manager i la llista de prefixos de CloudFront a sg-mercadofresco-alb, fer memòria cau agressivament inclosos els errors, i sobredimensionar amb un sostre conscient a l'ASG perquè l'escalat no es converteixi en la factura de l'atacant. Has muntat tres alarmes cap a alertas-mercadofresco per 0,30 USD al mes, sabent que la de CloudFront va a us-east-1. I tens un pla de resposta amb un ordre clar i, sobretot, la taula que distingeix un atac d'un divendres molt bo: la conversió a comanda i la taxa d'encerts de memòria cau abans que cap altra cosa.

Però el pla acaba sempre al mateix punt. Quan la Marta identifica el patró —aquelles rutes, aquells països, aquell agent d'usuari falsificat, aquella taxa de peticions per IP— necessita una eina que miri dins de la petició HTTP i decideixi segons el seu contingut, no segons el seu origen. Ni Shield ni un grup de seguretat no ho poden fer: un treballa amb paquets i l'altre amb IP i ports. A la lliçó 04-05, «AWS WAF», tancarem el mòdul amb aquesta eina: la Web ACL que s'associa davant de la distribució E2QWERTY123ABC i de l'alb-mercadofresco-tienda, els grups de regles gestionades per AWS, les declaracions de coincidència i les transformacions de text que impedeixen les evasions trivials, les regles per taxa per protegir /login i /api/pedidos, i —per damunt de tot— el mètode de desplegament que evita el desastre: començar en Count, llegir els registres, ajustar les excepcions i només llavors passar a Block.