Ikony bez kompromisů

V únoru začal na Heurece neznámý spammer hromadně přidávat recenze na produkty z formuláře na produktovém detailu. Jednalo se o text s odkazem na falešnou stránku, kde bylo plno reklam. Největší problém způsobily e-mailové notifikace, které uživatelům ohlašují novou recenzi na jimi sledované produkty. Bylo jich tolik, že zahltily e-mailové schránky našich uživatelů, e-mailové fronty na serverech a dokonce to došlo tak daleko, že nás poskytovatelé e-mailových služeb začali rate-limitovat, což způsobilo nemalé komplikace.
Jako nejrychlejší možnost ochrany jsme spammerovi zablokovali rozsahy IP adres a mazali jsme jím vytvořené uživatelské účty včetně obsahu. Spammer byl však vytrvalý, stále dokola hledal cesty, jak naše rychlé opravy obejít a v určitých intervalech se vracel. Museli jsme dokonce dočasně vypnout přidávání produktových recenzí z webu.
Mezitím spammer našel další místo na Heurece, kterým jsou naše Poradny. Diskuse u produktů, kam si zákazníci chodí pro radu a obchody, značky a uživatelé jim radí. I zde byly na nové příspěvky navěšené e-mailové notifikace, kterých tak začalo chodit ještě více.
E-mailové fronty se začaly nekontrolovatelně plnit a jejich zaplnění a postupný rate-limit ze stran e-mailových poskytovatelů způsobili, že se začaly na Heurece zpožďovat jiné důležité e-maily, jako například Souhrn objednávky nákupu v našem Heureka košíku, či jiné zprávy třeba o aktivacích.
Urychleně jsme začali pracovat na opravě kontrolního mechanismu, abychom mohli vypnuté přidávání recenzí opětovně spustit. Vyčistili jsme e-mailové fronty, začali nasazovat ReCaptchu a společně s PR a Support oddělením začali připravovat komunikaci směrem k vyspamovaným zákazníkům.
Kde byl největší problém a jak jsme se z toho poučili? Jak šel sled událostí minutu po minutě a může se podobný útok opakovat? Čtěte dál!
Díky ucpaným frontám jsme uživatelům neodesílali důležité e-maily včas. Hlavním problémem byly hlavně e-maily o Shrnutí objednávek z našeho košíku, dotazníky z programu Ověřeno zákazník nebo i informace o docházejícím kreditu e-shopů.
U několika e-mailových služeb jsme dosáhli na rate-limit, což zvětšilo prodlevu v odesílání celé fronty. Také jsme si teoreticky u poskytovatelů e-mailových schránek mohli poškodit reputaci – to je ale pouze spekulace.
Dalším dopadem bylo, že jsme zahltili schránky našich uživatelů, zákazníků a e-shopů. V některých případech se jednalo až o tisíce e-mailů.
Uživatelé Heureky v době vypnutí vkládání nových příspěvků nemohli psát recenze na produkty z webu a příspěvky do Poraden. Také nám po nasazení reCaptchy vznikla drobná chyba, kterou jsme přehlédli a nějakou dobu nešly přidávat odpovědi v Poradně. Přišli jsme tak o několik příspěvků.
A v neposlední řadě nás práce ohledně spammera zdržela od naplánované práce v našich sprintech.
Jakmile bylo po všem, všichni zúčastnění jsme si společně sedli a celý problém podrobně rozebrali.
Za předchozí roky v monolitu Heureky vzniklo spoustu přešlapů, které si neseme dodnes. V současné době celou starou Heureku přepisujeme do responzivního designu a spolu s tím se věnujeme i přepisu funkčních celků do mikroslužeb, kde všechny tyto přešlapy opravujeme nebo řešíme lépe. Není bohužel v našich silách všechno vyřešit najednou. Jde o postupný a dlouhotrvající proces a není tak divu, že občas tvrdě narazíme, jako nyní.
Hlavním problémem byly nezabezpečené formuláře ve starém monolitu, neměli jsme CSRF ochranu a captchu jsme měli jen pro nepřihlášené uživatele. Spammer si mohl vytvořit stovky účtu z jedné IP adresy, i zde chybí sofistikovaná ochrana. Rovněž byl problém, že jsme na přidávané příspěvky neměli žádné metriky nebo alerty, které by nás včas upozornily na nekalou aktivitu. V rámci oprav a úprav jsme se také hůře orientovali ve starém monolitickém kódu.
Všechna místa, kde odesíláme e-maily v monolitu starou metodou, napojíme na naši jednotnou e-mailovou službu Mailservice, abychom měli plný přehled o tom, co odesíláme.
Vytvoříme samostatné e-mailové fronty pro kritické služby, jako jsou notifikace o nákupu v košíku, docházejícím kreditu apod. tak, aby nebyly ovlivněny zaplněnou frontou notifikacemi o novém příspěvku. Vyřešíme priority a důležitosti jednotlivých e-mailů.
Vytvoříme kvalitní metriky a alertingy na rychlost přidávání příspěvků, abychom spammera odhalili rychle a automaticky. Přidáme i lepší metriky na úroveň SMTP serveru a uděláme alerty na úrovni naší jednotné služby na odesílání e-mailů.
Odhalíme v celém kódu Heureky další kritická místa, zejména tam, kde probíhají vstupy od uživatelů, aby se podobná akce nemohla opakovat.
Uděláme další úrovně zabezpečení všech formulářů.
Chybami se učíme a díky nim jsme lepší. Když se na to díváme zpětně, vypadá to jako školácká chyba. Spoustu věcí bychom dnes udělali jinak. Ale na to bychom bez tohoto incidentu nejspíš nepřišli.
Vyzkoušeli jsme si krizovou komunikaci napříč týmy a odděleními a do budoucna zapracujeme na reakční době. Dost možná nám v tom pomohou nové metriky.
Neopomíjejte podobné detaily. Definujte si kroky ke zlepšení předem, inspirujte se námi. Ne vždy se v rámci přepisu kódu do mikroslužeb vyplatí zanevřít na údržbu starého kódu pod vidinou, že brzy bude nový.
Jak byste to řešili vy? Stalo se vám něco podobného? Dejte nám o tom vědět na našem Twitteru.
Seznam kategorií