Jak chránit e-shop před DDoS útoky.

Proč se útočí na e-shopy

Výpadek obsahového webu stojí pozornost. Výpadek e-shopu stojí objednávky a ta ztráta není reputační, ale prostě aritmetická: session, které byly v okamžiku výpadku v nákupní cestě, se později nevrátí — nakoupí jinde. Maloobchod je jeden z mála cílů, kde si oběť dokáže hodinu výpadku vyčíslit na koruny. A přesně proto se vyplatí ho vydírat. Výpalné za DDoS chodí do schránek e-shopů právě proto, že příjemce si to spočítá z hlavy.

Útoky se drží kalendáře. Black Friday, sezonní výprodej, limitovaná kolekce, kampaň, za jejíž propagaci jste už zaplatili — hodiny s nejvyšším provozem jsou zároveň hodiny, kdy má vaše infrastruktura nejmenší rezervu a tým nejmenší chuť sahat na nastavení. Útočník, který odebírá váš newsletter, zná váš harmonogram stejně dobře jako vy.

Maloobchod navíc přitahuje útočníky, kteří vás vůbec shodit nechtějí. Scrapery cen, překupnické boty, testeři kradených karet, hrubá síla na slevové kódy — všichni generují automatizovaný provoz o vysokém objemu mířený přesně na endpointy, které by si vybrala i záplava. Jestli bylo odepření služby úmyslné, je rozdíl, který váš databázový pool nedělá.

Co se rozbije jako první

Instinkt velí bát se o homepage. Homepage je přitom jediná stránka, která to přežije, protože se cachuje. Všechno pod ní je z definice dynamické — závisí na session, košíku, živých skladech nebo volání třetí strany — a dynamické znamená, že se každý požadavek počítá pro toho, kdo se zeptal.

Vyplatí se to říct natvrdo: záplava 300 požadavků za sekundu na pokladnu má pro útočníka větší cenu než 300 000 na homepage. To je cenová asymetrie, na které stojí každý útok na aplikační vrstvě, a e-shop ji útočníkovi předává už svým návrhem — nákupní košík se cachovat nedá.

K tomu se v e-commerce přidává problém druhého řádu. Vaše pokladna je dostupná jen tak, jak je dostupná platební brána, synchronizace skladu a API dopravce. Záplava, která znásobí vaše odchozí volání, vás může dostat do limitu u vlastních dodavatelů — a takový výpadek pokračuje i po skončení útoku a ze své strany ho nespravíte. Omezení objemu na edge chrání limity vašich dodavatelů stejně jako vaše servery.

Útok, nebo jen dobrý den?

Tohle je otázka, která e-shopy skutečně stojí peníze, a plete se v obou směrech: když zablokujete skutečný nápor, shodili jste se sami; když útok pustíte dál jako „kampaň zabírá", zjistíte to na konci dne. Samotný objem provozu vám to neřekne. Tyhle signály ano.

• Tvar nákupní cesty. Skutečný nápor zachová zhruba obvyklé poměry mezi zobrazením kategorie, produktu, košíku a objednávkou. Útok jednu fázi nafoukne a zbytek nechá plochý. Trojnásobek session při propadlé konverzi je ten nejjasnější jediný signál, jaký existuje.
• Rozložení cest. Provoz z kampaně dopadá na stránky, které jste propagovali. Útočný provoz mlátí do jednoho endpointu, nebo se rovnoměrně rozprostře po URL v pořadí, ve kterém by člověk neproklikal.
• Poměr cache hitů. Skutečný dav chce tutéž výprodejovou stránku, takže vám poměr zásahů stoupne. Útok ho obvykle sráží — náhodné query stringy, necachovatelné cesty, cílené obcházení cache.
• Vstupní stránky a referrery. Skutečný provoz přichází z rozeslaného e-mailu, z reklam, z vyhledávání a ze sociálních sítí. Záplava přichází bez referreru, nebo s takovým, který neobstojí druhý pohled.
• Různorodost klientů. Lidský provoz má dlouhý a nepořádný chvost verzí prohlížečů a systémů. Automatizovaný provoz se nepřirozeně shlukuje: stejný user agent, stejný TLS otisk, stejné pořadí hlaviček — v objemu, který by takový chvost nikdy nevyprodukoval.
• Geografie proti mapě doručování. Víte, kam skutečně umíte doručit. Špička odjinud není otevírající se trh.

Jedna organizační kontrola přebije všechny předchozí: nápor, který jste způsobili, je někde zdokumentovaný — rozeslání, příspěvek, změna ceny, spolupráce s influencerem. Pokud nikdo ve firmě nedokáže do dvou minut ukázat na příčinu, berte to jako útok, dokud se neprokáže opak. Obranné kroky jsou levné a vratné; výpadek ne.

Boti, kteří jsou odepřením služby tak jako tak

Maloobchod s sebou nese kategorii automatizovaného zneužití, které vás vůbec nechce shodit a dopadne to stejně. OWASP je katalogizuje jako automatizované hrozby webových aplikací a čtyři z nich míří přímo na e-shopy:

• Scraping. Konkurence a srovnávače stahují váš katalog kvůli cenám a skladům, často procházejí tisíce produktů v intervalu mnohem těsnějším, než jakým kdokoli nakupuje. Čistá zátěž originu, nulová tržba.
• Překupnictví a blokování skladu. Boti, kteří skoupí limitovanou zásobu ve vteřině po naskladnění, nebo drží zboží v košíku, aby ho skuteční zákazníci nemohli koupit. Z uvedení kolekce se stane závod, který vaši zákazníci prohrají, a celé startovní pole odnese endpoint vložení do košíku.
• Testování kradených karet. Ukradená čísla se hromadně ověřují na vaší pokladně, protože testovací objednávka za korunu je nejlevnější způsob, jak zjistit, které karty ještě fungují. Zátěž je to nejmenší: platíte poplatek brány za každý pokus, pak chargebacky a nakonec podíl podvodů, kterého si všimne váš zpracovatel plateb.
• Uhádnutí slevových a dárkových kódů. Hrubá síla nad malým prostorem kódů, jeden dotaz do databáze po druhém.

Nic z toho nezastaví objemové prahy, protože nic z toho není objemové. Poráží se to behaviorálními limity na klienta a tím, že drahé cesty začnou klienta něco stát — tedy přesně tou mašinerií, která zastaví i záplavu na aplikační vrstvě.

Obrana v pořadí, ve kterém na ní záleží

1. Cachujte všechno anonymní, agresivně. Plná cache stránek na edge u kategorií a produktů úplně odstraní vaši aplikaci z cesty požadavku u návštěvníků, kteří nejsou přihlášení a nemají nic v košíku. Cache obcházejte podle cookie session nebo košíku, ignorujte neznámé query stringy v klíči cache, aby ?utm_source=… a ?x=91772 ukazovaly na tentýž objekt, a při chybě originu servírujte zastaralý obsah, aby se skomírající backend degradoval do mírně starých cen místo do chyby 502. S TTL 60 sekund vyprodukuje záplava na stránku vašeho bestselleru jeden dotaz na origin za minutu. Proto je CDN pancíř proti útokům, ne jen nástroj na rychlost.

2. Omezte nákupní cestu podle správného klíče. Limity klíčované jen na IP adresu jsou u e-shopů špatně v obou směrech: mobilní operátoři a firemní sítě schovají tisíce skutečných nakupujících za jednu adresu, zatímco botnet dá útočníkovi tisíce adres. Klíčujte na session a na účet, kde ho máte, jinak na otisk klienta, a nejpřísnější limity si nechte na ověřování slevových kódů, odeslání objednávky a reset hesla — tedy tam, kde skutečný zákazník udělá pár pokusů a útočník potřebuje tisíce.

3. Nepouštějte strojový provoz do cesty s výzvami. Platební webhooky, synchronizace s ERP a sklady, feedy pro srovnávače a Google Merchant nemohou vyřešit výzvu prohlížeče a nikdy ji nesmějí dostat. Tyhle cesty explicitně povolte, dobré boty ověřujte místo blokování a hlídejte, aby endpointy tvaru API vracely 429 a ne HTML mezistránku — důvody jsou v článku jak chránit API před DDoS útoky. Zahozený platební callback znamená objednávku vedenou jako nezaplacenou, což je dražší než samotný útok.

4. Berte CAPTCHA jako daň z konverze. Každé přerušení mezi zákazníkem a tlačítkem koupit stojí objednávky a nejvíc stojí přesně na stránkách, které máte největší nutkání chránit. Ověření má být pro skutečné prohlížeče neviditelné a vyhrazené klientům, kteří se už chovali jako automat. Pokud je odpovědí vaší ochrany na záplavu zeď s CAPTCHA před pokladnou, útočník svého cíle dosáhl vaší vlastní obranou.

5. Zajistěte, aby edge nešel obejít. Nic z toho neplatí, pokud váš origin server pořád odpovídá internetu přímo. Útočníci si vytáhnou historii DNS a certificate transparency logy a zkoušejí neproxované subdomény — admin., staging., mail. — a pošlou záplavu rovnou kolem vaší filtrace. Zafirewallujte origin tak, aby přijímal HTTP jen z vaší ochranné sítě, a projděte si jak skrýt IP adresu originu.

6. Přípravu na sezonu udělejte před zámrazem změn. V klidném týdnu předtím: zaznamenejte, jak vypadá normál na jednotlivých endpointech, ať máte s čím srovnávat; zapněte upozornění na útok a nasměrujte je do kanálu, který někdo skutečně sleduje; dopředu rozhodněte, kdo smí během výprodeje měnit pravidla filtrace; ověřte, že máte stavovou stránku a připravené odpovědi pro podporu; a zkontrolujte, že vaše logy nejsou vzorkované — uprostřed incidentu je špatná chvíle zjišťovat, že nevidíte jednotlivé požadavky. Pokud je e-shop dole už teď, projděte nejdřív jak zastavit DDoS útok a k této sekci se vraťte potom.

Jak Itnetic chrání e-shopy

Itnetic stojí před vaším e-shopem jako reverzní proxy, kterou zapnete dvěma DNS záznamy. Do platformy se nic neinstaluje, což tady platí dvojnásob: jakákoli obrana běžící uvnitř aplikace už na požadavek, který se chystá odmítnout, vydala workera i spojení do databáze.

Anonymní provoz narazí na edge na neviditelnou bránu s výzvou — skutečné prohlížeče projdou bez CAPTCHA a skriptované záplavy mířené na přihlášení, vyhledávání a vkládání do košíku se k vašemu backendu vůbec nedostanou. Behaviorální signatury a filtrování podle reputace IP zachytí klienty, kteří předstírají user agent prohlížeče — tedy standardní chování scraperů a testerů karet — a pravidla WAF umožňují povolit, zablokovat nebo vyzvat podle cesty, metody, země či otisku klienta. Limity ohraničí endpointy, které musejí zůstat dynamické, zatímco cache na edge servíruje katalog, aniž se dotkne originu. Platební callbacky a integrační cesty lze označit jako API zónu, takže strojoví klienti dostanou správné stavové kódy místo stránky s výzvou, kterou nevyřeší.

Když provoz během výprodeje vyskočí, jsou to logy a analytika na úrovni požadavků, díky nimž odpovíte na jedinou otázku, na které v tu chvíli záleží — jsou to zákazníci, nebo útok — ze skutečné skladby provozu, ne z odhadu. Útočný provoz se nikdy nezapočítává do kvóty přenosu, protože být pod útokem v nejrušnějším týdnu by nemělo navíc generovat fakturu, a DDoS ochrana je součástí každého tarifu včetně toho bezplatného.

DDoS ochrana Itnetic naběhne zhruba za pět minut, což je dost krátce na to, aby se dala zapnout během incidentu — a mnohem lépe se zapíná před ním. Pokud chcete nejdřív kontext, začněte článkem co je DDoS mitigace.