Atak DDoS na sklep w Black Friday: kulisy obrony, błędy w planie awaryjnym i realne koszty przestoju

Kontekst incydentu: dlaczego Black Friday to idealny moment na atak

Charakterystyka ruchu w Black Friday i nowe wąskie gardła

Black Friday to dzień, w którym większość sklepów internetowych funkcjonuje na granicy możliwości infrastruktury. Ruch potrafi skoczyć kilkukrotnie w porównaniu do zwykłego dnia roboczego, a każde dodatkowe opóźnienie czy drobny błąd w konfiguracji bywa boleśnie widoczny. Dla cyberprzestępców to środowisko idealne: serwery już są mocno obciążone, zespoły techniczne pracują pod presją, a marketing dociska gaz kampaniami.

Standardowe wąskie gardła, które w zwykły wtorek „tylko” spowalniają sklep, w Black Friday stają się punktami krytycznymi. Należą do nich przede wszystkim:

• zbyt słabe bazy danych, które nie radzą sobie z liczbą zapytań o stany magazynowe i koszyki,
• brak cache’owania kluczowych podstron (lista produktów, homepage, landing kampanii),
• monolityczne aplikacje, w których awaria jednego modułu przenosi się na cały sklep,
• ograniczone zasoby serwera aplikacyjnego i brak auto‑skalowania.

Atak DDoS „dokleja się” do tego naturalnego przeciążenia i popycha infrastrukturę za krawędź. Dla administratora zatrzęsienie ruchem w logach z kampanii remarketingowych może wyglądać podobnie jak początek ataku HTTP flood. Bez dobrego monitoringu i progów alarmowych pojawia się opóźniona reakcja: zespół bierze pierwsze symptomy za „normalne problemy szczytu sprzedaży”, a nie incydent bezpieczeństwa.

Kluczowy jest też aspekt psychologiczny. W Black Friday nikt nie chce „dotykać systemu” ponad konieczność. Często panuje niepisana zasada: żadnych wdrożeń, żadnych większych zmian. Niestety, gdy zaczyna się atak DDoS, trzeba podejmować szybkie decyzje: zmienić konfigurację WAF, przełączyć DNS, odciąć część funkcji. To kłóci się z naturalną ostrożnością w takim dniu i prowadzi do niebezpiecznego paraliżu decyzyjnego.

Dlaczego przestępcy wybierają szczyty sprzedaży i jak wygląda ich motywacja

Atakujący działają kalkulacyjnie. Atak DDoS na sklep w środku spokojnego tygodnia może zaboleć, ale nie wywoła takiej paniki jak uderzenie w Black Friday. Wtedy każda minuta przekłada się na realne straty, zerwane kampanie i wściekłych klientów. Z perspektywy cyberprzestępcy szczyty sprzedaży mają kilka zalet:

• większa skłonność do zapłaty okupu – groźba, że „Black Friday jest skończony”, działa jak silny argument,
• łatwiejsze maskowanie ataku – znaczna część ruchu jest faktycznie legitymowana, więc trudno szybko odróżnić boty od realnych klientów,
• mniejsza gotowość do eksperymentów obronnych – biznes często powstrzymuje zespół techniczny przed radykalnymi krokami, bo boi się „zabić sprzedaż” błędną decyzją,
• większa medialność incydentu – „sklep padł w Black Friday” to atrakcyjniejszy temat dla mediów niż „awaria we wtorek rano”.

W praktyce scenariusz bywa prosty: kilka dni przed Black Friday sklep otrzymuje e‑mail z żądaniem okupu i groźbą ataku DDoS w szczycie. Czasem atakujący demonstruje możliwości krótkim, kilkuminutowym atakiem testowym. Wiele firm ignoruje takie wiadomości, licząc, że to blef. Część płaci – i bywa, że i tak jest atakowana, bo informacja o „chętnym do okupu” rozchodzi się w środowisku przestępczym.

Istotne jest, że atak DDoS nie musi być głównym celem. Czasami stanowi zasłonę dymną dla innych działań: prób włamań na konta administracyjne, kradzieży danych czy manipulacji płatnościami. Zespół patrzy w jedną stronę – na wykresy obciążenia – a w tym czasie trwa zupełnie inny, ciszej zakamuflowany incydent.

Profil przykładowego sklepu i zależność od kanału online

Wyobraźmy sobie średniej wielkości polski sklep internetowy z elektroniką i AGD. Nie jest gigantem pokroju globalnych marketplace’ów, ale miesięcznie obsługuje dziesiątki tysięcy zamówień. Ma też kilka punktów stacjonarnych, lecz największy przychód pochodzi z kanału online. Dla takiego sklepu Black Friday bywa kluczową częścią rocznego wyniku sprzedaży.

Infrastruktura techniczna bazuje na chmurze współdzielonej u popularnego dostawcy, z jednym głównym klastrem aplikacyjnym, osobną bazą danych i podstawowym CDN obsługującym statyczne zasoby. Jest WAF w pakiecie, ale skonfigurowany raczej „domyślnie” niż pod kątem agresywnej obrony przed DDoS. Monitorowanie ruchu działa, lecz alarmy są ustawione głównie na awarie (brak odpowiedzi), a nie na anomalie (nienaturalny rodzaj zapytań).

Dla zarządu kluczowe są KPI sprzedażowe: obrót, wartość koszyka, liczba zamówień, koszt pozyskania klienta. Bezpośrednie metryki bezpieczeństwa i odporności na DDoS pojawiają się w raportach rzadko. Ryzyko DDoS jest postrzegane jako domena „tych największych”, a nie średniego gracza. Taki profil – duży udział e‑commerce w przychodzie, sporo kampanii w Black Friday, a jednocześnie dość podstawowe zabezpieczenia – to klasyczny cel dla przestępców.

Dzień roboczy vs Black Friday – inny wymiar skutków ataku

Ta sama wielkość ataku DDoS może mieć zupełnie różne skutki w zależności od dnia i godziny. W „zwykły” wtorek, gdy sklep ma mniejszy ruch, a zespół techniczny jest spokojniejszy, awaria trwająca kilkanaście minut skończy się wstydem, ale nie katastrofą. Można wdrożyć tymczasowe obejścia, a marketing wstrzyma kilka kampanii. Poziom stresu będzie odczuwalny, lecz kontrolowalny.

W Black Friday ta sama godzina przestoju oznacza lawinę konsekwencji:

• zerwane kampanie płatne (Google Ads, kampanie afiliacyjne, influencerzy) z pełnymi budżetami „odpalonymi na maxa”,
• klientów, którzy po kilku próbach rezygnują i przechodzą do konkurencji – często na stałe,
• spiętrzone zamówienia, które „nadrabiane” są później kosztem jakości obsługi,
• nerwowe telefony partnerów logistycznych, którzy szykowali się na zwiększoną liczbę paczek.

Do tego dochodzi wymiar wewnętrzny: zarząd, który co kilka minut dopytuje o status, dział marketingu naciskający, by „cokolwiek przywrócić, nawet jeśli będzie wolniej”, oraz obsługa klienta, która nagle odbiera dziesiątki wiadomości o błędach zamówień czy znikających koszykach. W zwykły dzień roboczy można pozwolić sobie na bardziej spokojną, metodyczną analizę. W Black Friday zespoły często decydują pod presją i popełniają błędy, które pogarszają sytuację.

Jak wyglądał atak krok po kroku – oś czasu zdarzeń

Pierwsze symptomy: spowolnienia, błędy 502/504 i lawina zgłoszeń

Atak DDoS na sklep w Black Friday rzadko przypomina „wyłączenie światła”. Znacznie częściej przypomina powolne zalewanie piwnicy wodą: na początku tylko lekko wilgotno, potem pierwsze kałuże, aż w końcu woda sięga sufitu. W praktyce pierwszym sygnałem bywają:

• wydłużony czas ładowania strony, szczególnie kluczowych podstron (kategorię, koszyk, checkout),
• sporadyczne błędy 502/504 z bram aplikacyjnych lub load balancera,
• niespójne dane w koszyku (produkty „znikają”, wartości się nie aktualizują),
• wzrost liczby zgłoszeń na czacie i infolinii: „nie mogę dokończyć zamówienia”, „strona się wiesza”.

Na poziomie wskaźników technicznych widać rosnącą liczbę zapytań HTTP, czasem kilkukrotnie wyższą niż prognozowany ruch z kampanii. Problem w tym, że w Black Friday wzrost ruchu jest oczekiwany, więc wiele zespołów interpretuje wykresy jako „tak miało być”. Dopiero gdy błędy 502/504 pojawiają się masowo, a dashboard sprzedażowy zaczyna się stabilizować lub spadać, ktoś mówi głośno: „coś jest nie tak, to nie tylko szczyt ruchu”.

W tym momencie przewagę mają te sklepy, które mają zdefiniowane jasne progi alarmowe specyficzne dla Black Friday – inne niż w zwykły dzień. Bez tego biznes i IT nawzajem bagatelizują swoje obserwacje: marketing zakłada, że to „chwilowe problemy serwerów”, admini liczą, że „kampanie zaraz się wyrównają”. Czas ucieka.

Reakcja w pierwszych minutach: co zrobiono, a co przegapiono

Kiedy sklep zaczyna realnie „siadać”, pierwsze decyzje często są intuicyjne i niekoniecznie zgodne z planem awaryjnym. Typowy ciąg zdarzeń:

1. Administratorzy sprawdzają podstawowe parametry – obciążenie CPU, pamięć, status bazy danych.
2. Marketing ogranicza najbardziej agresywne kampanie (np. w social media), zakładając, że to ich „wina”.
3. Obsługa klienta dostaje pierwszą krótką informację: „mamy problemy techniczne, pracujemy nad naprawą”.
4. Zarząd prosi o estymację czasu powrotu do sprawności.

Rzeczy, które często są ignorowane lub odkładane:

• temat zgłoszenia incydentu do dostawcy hostingu/CDN na odpowiedni, krytyczny kanał,
• szybkie przełączenie trybu ochrony DDoS/WAF na bardziej restrykcyjny profil,
• decyzja, czy zamknąć część funkcji (np. widok historii zamówień) na rzecz utrzymania checkoutu,
• solidne spojrzenie w logi pod kątem nietypowych wzorców (boty, pojedyncze IP/ASN, konkretne ścieżki URL).

W ciągu pierwszych 15–30 minut łatwo stracić przewagę. Zespół techniczny jest zalewany pytaniami z biznesu, czasem nie ma jednej osoby odpowiedzialnej za komunikację. Programiści równocześnie grzebią w konfiguracji, monitoringu, logach i panelu hostingu. Bez jasnego lidera incydentu decyzje rozmywają się, a każdy robi „swoje”.

Eskalacja ataku: zmiana wolumenu i wektorów

Po pierwszej fazie „przymiarki” napastnik zwykle zmienia wektory ataku. Jeśli widzi, że prosty HTTP flood nie wystarcza, sięga po bardziej wyrafinowane techniki lub różnicuje źródła ruchu. W przypadku sklepu w Black Friday można zaobserwować następującą sekwencję:

• HTTP GET/POST flood – wiele zapytań do stron produktowych, wyszukiwania i koszyka, generujących wysokie obciążenie bazy danych;
• SYN flood i UDP flood – ukierunkowane na warstwę sieciową, mające zająć porty i zasoby sieciowe serwerów;
• mieszane wektory – równoczesne obciążanie warstwy aplikacji (np. kosztowne zapytania) i infrastruktury sieciowej, aby utrudnić reakcję.

Przy dobrze skalowanym hostingu atak sieciowy może zostać wstępnie „wyczyszczony” już na poziomie dostawcy, ale ataki na warstwę aplikacyjną często przechodzą dalej. Szczególnie bolesne są ataki generujące pozornie poprawne zapytania, np. wyszukiwania z losowymi parametrami, które omijają prostą cache’owanie i wymuszają pracę bazy danych. Jeśli sklep ma rozbudowane filtrowanie produktów, każdy taki request potrafi być kosztowny.

W tym momencie zaczynają się prawdziwe problemy z dostępnością. Strona otwiera się losowo, błędy 504 stają się normą, a panel administracyjny również zaczyna się zacinać. Deweloperzy tracą możliwość sprawnego logowania się do serwerów, bo sesje SSH zrywają się pod naporem ruchu. Bez wcześniejszego przygotowania (np. osobnego, mniej obciążonego kanału dostępowego) zarządzanie incydentem robi się coraz trudniejsze.

Punkt krytyczny: pełna niedostępność sklepu

Punkt krytyczny następuje wtedy, gdy sklep praktycznie przestaje odpowiadać. Dla użytkownika oznacza to brak możliwości wejścia na stronę główną, niekończące się ładowanie lub natychmiastowe błędy. Dla zespołu technicznego to moment, w którym często zapada trudna decyzja: przechodzimy w tryb awaryjny i zakładamy, że mamy do czynienia z pełnoskalowym atakiem DDoS, nie „chwilowym przeciążeniem”.

Charakterystyczne są objawy:

• system monitoringu zapełniony alarmami, czasem sam mający opóźnienia i przestoje,
• API do systemów zewnętrznych (np. bramek płatniczych, systemów magazynowych) przestaje działać lub odpowiada niestabilnie,
• wewnętrzne narzędzia (CRM, panel zamówień) również są powolne, co utrudnia obsługę zamówień zarejestrowanych tuż przed awarią.

Jeśli wcześniej nie wdrożono prostego trybu awaryjnego (np. statycznej strony z informacją o przerwie technicznej, hostowanej w oddzielnym środowisku z ochroną DDoS), klienci po prostu widzą błąd przeglądarki. To najbardziej frustrujący scenariusz: brak jasnej informacji i brak możliwości dokończenia zakupów, nawet jeśli ktoś jest już po wyborze produktów.

Stabilizacja sytuacji: pierwsze skuteczne ruchy obronne

Kiedy emocje opadają na tyle, że można zapanować nad chaosem, następuje etap porządkowania działań. Zwykle pojawia się jedna osoba – lider techniczny lub menedżer produktu – która przejmuje rolę koordynatora. To często punkt zwrotny: od „wszyscy robią wszystko” do „każdy ma konkretną rolę”.

Najpierw porządkowana jest komunikacja wewnętrzna. Zespół uzgadnia prosty rytm raportowania: krótka aktualizacja co 10–15 minut dla zarządu i kluczowych działów, najlepiej na jednym kanale (np. dedykowany kanał w komunikatorze). To odcina lawinę indywidualnych telefonów i maili, które wybijają techników z rytmu.

Równolegle podejmowane są pierwsze poważniejsze decyzje techniczne:

• odcięcie niekrytycznych integracji (np. zewnętrzne widżety rekomendacji, narzędzia A/B testów),
• przełączenie części ruchu przez bardziej agresywny profil WAF / ochrony DDoS, nawet kosztem fałszywych alarmów,
• wymuszenie większego cache’owania stron, kategorii i statycznych zasobów.

To właśnie te „szorstkie” ruchy często zaczynają przynosić pierwsze efekty. Strona może nadal działać niestabilnie, ale pojawiają się krótkie okienka dostępności, w których część klientów jest w stanie złożyć zamówienie. Z perspektywy przychodu to ogromna różnica: ciągła pełna niedostępność vs. nieregularne, ale jednak działanie.

Techniczne kulisy obrony – jakie zabezpieczenia zadziałały, a co zawiodło

Warstwa sieciowa: filtracja u dostawcy hostingu i CDN

Pierwszą linią frontu w obronie przed DDoS-em jest zwykle dostawca infrastruktury: operator chmury, serwerownia, CDN. W dobrze przygotowanym środowisku ruch jest rozłożony na wiele punktów wejścia, a podstawowe ataki wolumenowe są zatrzymywane, zanim dotrą do aplikacji. W praktyce wygląda to różnie.

W analizowanym scenariuszu część ataku sieciowego (UDP/SYN flood) została zatrzymana już na brzegu sieci. Dostawca hostingu włączył automatyczne profile anty-DDoS, ograniczając najbardziej prymitywny zalew pakietów. To sprawiło, że serwery nie zostały całkowicie odcięte od świata, ale… odsłoniło to inne słabości.

To, co nie zadziałało:

• zbyt ogólna konfiguracja reguł – domyślne profile były ustawione na „bezpieczne” progi, które w Black Friday okazały się zbyt wysokie,
• brak wcześniejszych testów trybu awaryjnego u dostawcy – włączenie bardziej agresywnej ochrony wymagało kontaktu przez support, który również był przeciążony,
• niejednoznaczna odpowiedzialność – część zespołu sądziła, że „hosting wszystko filtruje”, podczas gdy dostawca zakładał, że sklep ma własne mechanizmy na poziomie aplikacji.

Gdyby wcześniej przetestowano scenariusz włączenia maksymalnej ochrony DDoS w warunkach „prawie produkcyjnych”, wiele decyzji można by podjąć szybciej i z mniejszą liczbą nieporozumień.

CDN i cache: przyjaciel, który był skonfigurowany „na pół gwizdka”

CDN teoretycznie jest jednym z najmocniejszych narzędzi w obronie: rozprasza ruch, odciąża serwer aplikacyjny, umożliwia filtrowanie na krawędzi sieci. Pod warunkiem, że jest odpowiednio ustawiony. W praktyce sklepy często stosują CDN głównie do obrazków i statycznych skryptów, ignorując jego potencjał w ochronie aplikacyjnej.

W dniu ataku okazało się, że:

• strona główna i część kategorii faktycznie były silnie cache’owane, co chwilowo łagodziło problem,
• kluczowe podstrony, jak wyszukiwarka i listing z zaawansowanymi filtrami, były praktycznie pozbawione cache,
• Większość ruchu szła bezpośrednio do serwerów aplikacyjnych, bo CDN omijał dynamiczne endpointy (np. API do koszyka).

CDN „uratował” więc wizerunkowo stronę główną (czasem ładowała się poprawnie), ale nie ochronił tego, co naprawdę krytyczne z punktu widzenia przychodów – procesu zakupowego. Z perspektywy użytkownika sytuacja była absurdalna: można było oglądać promocje, ale dodanie produktu do koszyka kończyło się błędem.

WAF i reguły aplikacyjne: kiedy automat nie wystarcza

Zapora aplikacyjna (WAF) była teoretycznie skonfigurowana i włączona. W praktyce opierała się głównie na gotowych regułach producenta, bez większej personalizacji pod specyfikę sklepu. To wystarczyło na typowe skanery, prymitywne boty i proste próby nadużyć, ale nie na dobrze przygotowany atak DDoS w warstwie aplikacyjnej.

Podczas incydentu zespół próbował dynamicznie zaostrzać reguły, m.in.:

• blokował lub ograniczał liczbę zapytań z pojedynczego IP w krótkim oknie czasowym,
• wprowadzał challenge (np. CAPTCHA) dla podejrzanego ruchu,
• tymczasowo blokował ruch z wybranych krajów, które nie były istotnym rynkiem docelowym.

To przyniosło częściową poprawę, ale okazały się też efekty uboczne: część realnych klientów trafiła na utrudnienia lub blokady. Bez przygotowanych wcześniej „gotowych zestawów reguł na Black Friday” każda zmiana była kompromisem między dostępnością a bezpieczeństwem, testowanym na żywym organizmie.

Architektura aplikacji: które elementy były szczególnie wrażliwe

Pod presją widać nagle wszystkie techniczne „długi”, które latami były odkładane na później. Okazało się, że aplikacja ma kilka newralgicznych punktów, które atakujący bez trudu wykorzystał:

• ciężkie zapytania do bazy – wyszukiwarka produktów i niektóre filtry generowały zapytania bez odpowiednich indeksów,
• brak rozdzielenia ruchu – panel administracyjny działał w tym samym klastrze co frontend, więc ruch użytkowników utrudniał też pracę obsługi,
• brak prostego mechanizmu degradacji funkcji – nie dało się szybko wyłączyć „drogich” funkcji (np. rekomendacji w czasie rzeczywistym) bez modyfikacji kodu.

Atakujący prawdopodobnie przeanalizował sklep z wyprzedzeniem i wybrał najcięższe ścieżki URL, aby maksymalnie obciążyć bazę danych. Sklep nie miał przygotowanego wariantu „lite”, który można by włączyć jednym przełącznikiem – z uproszczonym szablonem, bez części dynamicznych komponentów.

Monitoring i alerty: dane były, ale nikt nie miał czasu ich czytać

Systemy monitoringu (APM, logi, metryki infrastruktury) działały. Problem nie leżał w braku danych, ale w ich nadmiarze i chaotycznym dostępie. W pierwszej fazie ataku dashboardy świeciły na czerwono, alarmy sypały się z wielu źródeł naraz. W takiej sytuacji kluczowe staje się nie „więcej danych”, tylko właściwa ich agregacja.

Rzeczy, które okazały się pomocne:

• prosty, wspólny dashboard z kilkoma KPI: liczba zapytań na sekundę, błędy 5xx, czas odpowiedzi checkoutu,
• logi z WAF / CDN pokazujące najczęściej atakowane ścieżki i wzorce zapytań,
• porównanie ruchu „sprzed ataku” i „w trakcie” – pozwoliło odróżnić realnych użytkowników od botów.

To, co zawiodło, to automatyka alertów – zwykłe progi alarmowe były ustawione pod normalne dni. W Black Friday nawet legalny ruch przekraczał je wielokrotnie, co doprowadziło do „głuchoty na alarmy”. Ekipa przyzwyczaiła się, że „w tym dniu wszystko świeci na czerwono”, więc prawdziwy incydent zlał się z „normą świąteczną”.

Plan awaryjny na papierze vs rzeczywistość pod presją

Procedury w Confluence kontra decyzje na Slacku

Formalnie plan awaryjny istniał. Był opisany w dokumentacji, miał zdefiniowane etapy i listy kontaktów. W teorii brzmiało to solidnie: „w przypadku incydentu typu X robimy Y, kontaktujemy się z Z” i tak dalej. Gdy doszło do realnego ataku, życie zweryfikowało te zapisy bardzo brutalnie.

Największa różnica polegała na tym, że:

• nikt nie miał czasu szukać dokumentu w intranecie w środku kryzysu,
• część numerów telefonów i kontaktów była nieaktualna (zmiany w zespole, nowy opiekun po stronie dostawcy),
• decyzje i tak zapadały tam, gdzie wszyscy byli obecni – na głównym kanale w Slacku / Teams.

Plan istniał, ale nie był „wgrany w mięsień” organizacji. Nikt nie przećwiczył go w formie symulacji, więc wielu osobom trudno było nawet przypomnieć sobie, że taki dokument istnieje. Na pierwszy plan wyszły nawyki: kto z kim zwykle rozmawia, jak zazwyczaj rozwiązuje się problemy.

Brak jasno wyznaczonego „incident commander”

Kolejna luka ujawniła się bardzo szybko: nie było jednej, z góry określonej osoby odpowiedzialnej za prowadzenie incydentu. Efekt był przewidywalny – chaos decyzyjny. Kilka przykładów z praktyki:

• równoległe, sprzeczne polecenia – jedna osoba zleca „wyłączmy kampanie”, inna: „zostawmy ruch, musimy spróbować go obsłużyć”,
• podwójne lub potrójne zgłoszenia do tego samego dostawcy – różne osoby piszą w tej samej sprawie, ale innym kanałem, rozmywając priorytet,
• brak jasnej narracji do zarządu – różne osoby raportują inne liczby i inne scenariusze.

Rola „incident commander” nie musi oznaczać najbardziej technicznej osoby w pokoju. Chodzi o kogoś, kto:

• podejmuje decyzje na podstawie informacji od specjalistów,
• dba o to, żeby zespół techniczny mógł spokojnie pracować,
• odpowiada za komunikację z biznesem i zewnętrznymi partnerami.

W firmach, które mają taką rolę zdefiniowaną i przećwiczoną, ataki DDoS są mniej chaotyczne, nawet jeśli skala problemu jest podobna.

Teoretyczne RTO/RPO a psychologia „jeszcze chwilę wytrzymamy”

W dokumentach często pojawiają się wskaźniki RTO (maksymalny akceptowalny czas przestoju) i RPO (maksymalna akceptowalna utrata danych). Na spotkaniach brzmi to profesjonalnie. Podczas Black Friday te liczby zderzają się z emocjami.

W scenariuszu ataku DDoS pojawił się dobrze znany mechanizm: „jeszcze trochę poczekajmy, zaraz się uspokoi”. Każde kolejne 10–15 minut przestoju było racjonalizowane:

• „może kampanie za chwilę spadną, nie wyłączajmy wszystkiego”,
• „nie ma sensu aktywować pełnego trybu awaryjnego, bo może to tylko chwilowe”,
• „nie róbmy drastycznych ruchów, żeby nie zepsuć sytuacji jeszcze bardziej”.

W efekcie realny RTO był wielokrotnie przekraczany, zanim ktoś oficjalnie przyznał: „nasz cel czasowy już nie obowiązuje, teraz walczymy o minimalizację dalszych strat”. Bez wcześniejszych ćwiczeń trudno jest w praktyce „zaufać liczbom” i podjąć bolesne decyzje na czas, np. całkowicie odciąć część usług czy przełączyć ruch do prostszego środowiska.

Komunikacja z klientami: między milczeniem a paniką

Plan awaryjny zawierał gotowe szablony komunikatów na wypadek problemów technicznych. Problem w tym, że dotyczyły one krótkich, planowanych przerw serwisowych, a nie dynamicznego ataku w szczycie sprzedażowym. W praktyce powstał dylemat: jak dużo powiedzieć klientom i jak często.

Pojawiły się różne głosy:

• „nie piszmy, że to atak, bo to źle wygląda, nazwijmy to awarią techniczną”,
• „musimy dać konkretną godzinę powrotu, inaczej klienci się zdenerwują”,
• „nie obiecujmy terminów, bo nie mamy pewności, to tylko pogorszy sytuację”.

Ostatecznie komunikaty były wprowadzane stopniowo: baner na stronie (kiedy tylko była dostępna), informacje na social mediach, szablony odpowiedzi dla obsługi klienta. Te działania pomogły obniżyć frustrację części klientów, ale brakowało jednego, spójnego komunikatu od marki – krótko, konkretnie, w jednym miejscu, do którego odsyłają wszystkie kanały.

Współpraca z partnerami zewnętrznymi: kto za co odpowiada

W trakcie incydentu na scenę wchodzą również partnerzy: software house, dostawca platformy SaaS, integratorzy płatności i logistyki. Jeśli wcześniej nie ustalono granic odpowiedzialności, Black Friday staje się festiwalem „to nie u nas”.

W praktyce wyglądało to tak:

• hosting wskazywał na „atak spoza naszej sieci, od strony aplikacji”,
• dostawca platformy tłumaczył się „nietypowym ruchem z kampanii marketingowych”,
• software house sugerował „potrzebę optymalizacji zapytań, ale nie w tym momencie”.

Granice SLA i „szare strefy” odpowiedzialności

Na poziomie umów wszystko wyglądało klarownie: SLA gwarantujące dostępność, czasy reakcji na incydent, procedury eskalacji. Problemy zaczęły się, gdy trzeba było zastosować te zapisy do konkretnego, trwającego ataku.

Pojawiły się typowe „szare strefy”:

• czy atak DDoS jest „awarią usługi”, czy „siłą wyższą”, za którą dostawca nie bierze pełnej odpowiedzialności,
• czy gwarantowany czas reakcji liczony jest od pierwszego zgłoszenia, czy od „potwierdzenia incydentu” po stronie dostawcy,
• czy przełączenie sklepu w tryb awaryjny (np. stronę statyczną) leży po stronie klienta, czy usługodawcy.

Bez precyzyjnych zapisów i wspólnego zrozumienia scenariuszy DDoS, rozmowy szybko zamieniają się w spór interpretacyjny zamiast realnej współpracy. W Black Friday ma to dodatkowy wymiar – każda minuta dyskusji o paragrafach to kolejne utracone koszyki.

Lepsze doświadczenia mają te zespoły, które jeszcze przed sezonem doprecyzowały z dostawcami:

• jakie działania są podejmowane automatycznie przy wykryciu ataku,
• kto podejmuje decyzję o agresywnych blokadach,
• kto odpowiada za komunikację do zarządu i biznesu po obu stronach.

Największe błędy popełnione przed, w trakcie i po ataku

Zaniedbane przygotowania przed sezonem

Większość problemów, które eksplodowały w Black Friday, miała swoje źródło wiele miesięcy wcześniej. Nie chodziło o brak kompetencji, lecz o typowe odkładanie tematów „nie na już”.

Najbardziej bolesne zaniedbania przed atakiem:

• brak testów obciążeniowych pod realny scenariusz Black Friday – testy robiono na przykładowych kampaniach, ale nie na ruchu zbliżonym do faktycznych szczytów,
• niewykorzystane możliwości istniejącego WAF/CDN – dostępne były reguły rate limiting, challenge (CAPTCHA, JS), czy gotowe profile dla e-commerce, ale nikt ich wcześniej nie skonfigurował i nie sprawdził wpływu na UX,
• brak „trybu degradacji” zaplanowanego w architekturze – aplikacja nie miała prostych przełączników: wyłącz rekomendacje, uprość listing, ogranicz głębokie filtrowanie,
• nieaktualny plan kontaktów – zmiany w strukturze zespołu, nowe osoby po stronie dostawców, nieodświeżone listy dyżurów.

Część zespołu przyznawała otwarcie: plany istniały jako prezentacje z poprzednich lat, ale nikt nie przełożył ich na konkretne zmiany w infrastrukturze i aplikacji. Zakładano, że „jakoś to będzie”, bo wcześniejsze sezony przeszły bez większych incydentów.

Błędy decyzyjne w środku ataku

Gdy atak już trwał, presja czasu i stres sprzyjały uproszczeniom i skrótom myślowym. Kilka decyzji, które z perspektywy czasu okazały się kosztowne:

• zbyt późne odcięcie części funkcji – zespół długo próbował utrzymać „pełny” sklep z wszystkimi wodotryskami, zamiast szybko przejść w tryb ograniczony,
• niekonsekwentna polityka blokad – naprzemienne dokręcanie i luzowanie reguł WAF/CDN prowadziło do huśtawki: chwilowej poprawy, po której wracał pełny ruch ataku,
• zbyt optymistyczne komunikaty wewnętrzne – przekazywanie do zarządu informacji typu „jeszcze 15 minut” w sytuacji, gdy nikt nie miał na to twardych podstaw, generowało dodatkową presję i napięcia,
• ignorowanie sygnałów z monitoringu – gdy „wszystko się paliło”, niektóre wykresy i metryki, które od razu wskazywały najcięższe ścieżki URL, zostały zauważone zbyt późno.

Naturalną reakcją w kryzysie jest próba zrobienia „czegoś, cokolwiek”. Bez jednej osoby koordynującej działania, część zadań się dublowała, inne – kluczowe – nie miały właściciela. Tylko niektóre decyzje (jak tymczasowe ograniczenie ruchu z wybranych krajów) przyniosły wymierny efekt, ale i one były wprowadzane z opóźnieniem.

Co poszło nie tak po ustaniu ataku

Gdy sklep wrócił do względnej stabilności, duża część zespołu odetchnęła i skupiła się na dokończeniu dnia sprzedażowego. Zrozumiałe ludzkie zmęczenie zderzyło się jednak z potrzebą „zebrania tego na świeżo”. Kilka elementów, które zostały odłożone zbyt daleko w czasie:

• brak natychmiastowego post-mortem – formalne omówienie incydentu odbyło się dopiero po kilku tygodniach, gdy część szczegółów została już zapomniana,
• nieustrukturyzowane notatki – informacje z czatu, maili i osobistych notatek nie zostały od razu zebrane w jedno miejsce, co utrudniło późniejszą analizę,
• odłożone poprawki „na po sezonie” – kilka krytycznych usprawnień technicznych przesunięto na bliżej nieokreśloną przyszłość, bo „teraz trzeba obsłużyć bieżący biznes”,
• brak jasnego komunikatu „co się stało i co z tym zrobimy” dla całej organizacji – wiedza pozostała głównie w zespole technicznym.

To, co zrobiono dobrze, to szybkie zebranie listy „quick wins” – zmian możliwych do wdrożenia w ciągu kilku dni, bez dużych projektów. Problemem było to, że bez priorytetyzacji i wsparcia biznesu część z nich konkurowała z nowymi feature’ami w sprintach i przegrywała w codziennej walce o zasoby.

Emocjonalne „aftershocks” w zespole

Aspekt, który często jest pomijany: po kilkunastu godzinach pracy pod ciągłym napięciem ludzie są po prostu wyczerpani. W omawianym przypadku pojawiły się później pretensje i poczucie niesprawiedliwości:

• „dlaczego zespół X nie wszedł do akcji wcześniej, wszystko było na nas”,
• „robiliśmy co mogliśmy, a i tak pojawiła się narracja, że IT zawaliło Black Friday”,
• „nikt z góry nie zapytał, jak my to przeżyliśmy, tylko od razu: co z wynikami sprzedaży”.

Dobre post-mortem nie kończy się więc tylko na checklistach i wykresach. Przydaje się także prosta przestrzeń, gdzie każdy może powiedzieć, co go frustrowało, co zadziałało i czego zabrakło. Bez „polowania na winnych”, raczej z nastawieniem na usprawnienie całego systemu.

Realne koszty przestoju – nie tylko utracone transakcje

Bezpośrednie straty sprzedażowe

Najbardziej oczywisty koszt to brak transakcji w godzinach, gdy sklep praktycznie nie działał albo działał w sposób mocno ograniczony. W tym przypadku można było policzyć:

• średnią wartość koszyka w Black Friday,
• średnią liczbę transakcji na minutę w „zdrowych” godzinach,
• liczbę minut, gdy flow zakupowy był realnie zablokowany lub upośledzony.

Te proste wyliczenia dały szacunkową kwotę utraconego przychodu. Dla zarządu były to najbardziej namacalne liczby, ale kontekst był szerszy: część klientów po prostu kupiła później lub przeniosła zakupy na inne kanały (np. marketplace), część – odeszła do konkurencji na stałe.

Utracone koszyki i efekt „przerwanych intencji”

Oprócz twardej liczby transakcji, mocno ucierpiał współczynnik konwersji. W logach analitycznych widać było tysiące porzuconych koszyków i sesji przerwanych w ostatnim kroku procesu zakupowego. Technicznie dało się to zmierzyć:

• wzrost liczby błędów 5xx i timeoutów w kroku „Zamówienie” i „Płatność”,
• skokowy spadek współczynnika ukończenia checkoutu,
• nietypowy rozkład czasu trwania sesji – wiele zbyt krótkich wizyt bez przejścia do karty produktu.

Część z tych klientów można było później odzyskać, wysyłając kampanie „dokończ zakupy” lub oferując kody rabatowe. Nie naprawiło to jednak całkowicie uszczerbku na zaufaniu – szczególnie u osób, które miały za sobą frustrujące próby wielokrotnego złożenia zamówienia.

Koszty operacyjne po stronie zespołów

Przestój w takim dniu zwykle oznacza nadgodziny, dodatkowe dyżury i przesunięcia w planach. Po stronie firmy i partnerów pojawiły się m.in.:

• dodatkowe godziny pracy zespołów technicznych – często w trybie „all hands on deck”, z koniecznością rekompensaty w dniach wolnych lub finansowo,
• zwiększone obciążenie obsługi klienta – wymagało zaangażowania dodatkowych osób, czasem z innych działów, do odpowiadania na wiadomości i telefony,
• przesunięcia w sprintach – część zaplanowanych zadań wypadła z realizacji, bo priorytetem stało się gaszenie pożaru i późniejsze usprawnienia.

Te koszty są mniej „medialne” niż utracony przychód, ale składają się na realną cenę incydentu. Zmiana planów w jednym zespole pociąga korekty w kolejnych – łańcuch opóźnień bywa odczuwalny jeszcze długo po zakończeniu ataku.

Wizerunek marki i utrata zaufania

Podczas incydentu kanały social media i skrzynki mailowe obsługi klienta szybko wypełniły się komentarzami. Były wśród nich zarówno spokojne pytania o status, jak i bardzo emocjonalne wiadomości typu „zepsuliście mi Black Friday”. Część trafiała dodatkowo na publiczne grupy i fora.

Wpływ na wizerunek można było uchwycić w kilku wymiarach:

• wzrost liczby negatywnych wzmianek i komentarzy w mediach społecznościowych,
• pojedyncze materiały w mediach branżowych, wyłapujących „wpadki” dużych marek w Black Friday,
• feedback od kluczowych klientów B2B, dla których dostępność sklepu jest elementem oceny partnera.

Na plus działała transparentna, spokojna komunikacja tam, gdzie udało się ją szybko zorganizować. Część klientów doceniła szczerość („mamy atak, pracujemy nad tym, wrócimy z dodatkową zniżką dla Was”), część – po prostu poszła dalej. W długim horyzoncie większe znaczenie miało to, czy firma konsekwentnie poprawiła swoje bezpieczeństwo, niż sam fakt jednorazowego incydentu.

Zerwane lub poluzowane kampanie marketingowe

Atak zastał sklep w środku szeroko zakrojonych działań marketingowych: kampanie płatne, newslettery, działania z influencerami. Zatrzymanie lub ograniczenie tych aktywności w trakcie dnia oznaczało dodatkowe, ukryte koszty:

• niewykorzystane budżety mediowe – czasem z blokadą zwrotu, bo emisja technicznie się odbyła, nawet jeśli strona docelowa nie działała,
• utracone „okno atencji” u klientów, którzy kliknęli w reklamę lub link od influencera i trafili na niedostępny sklep,
• konieczność renegocjacji ustaleń z partnerami – np. przesunięcia publikacji lub dodatkowe świadczenia w ramach rekompensaty.

Zespół marketingu był w trudnej sytuacji: z jednej strony szkoda było „wyłączać maszynę”, na którą pracowano tygodniami, z drugiej – kierowanie dużego ruchu na sklep w trakcie ataku pogłębiało problemy techniczne. Brak jasnych procedur, kiedy i jak wstrzymywać kampanie, prowadził do nerwowych, niespójnych decyzji.

Dług technologiczny przyspieszony przez incydent

Paradoksalnie, atak przyspieszył ujawnienie długów technologicznych, które można było ignorować latami. W raporcie po incydencie pojawiły się m.in.:

• konieczność refaktoryzacji najcięższych zapytań i endpointów,
• potrzeba rozdzielenia panelu administracyjnego od warstwy frontendowej,
• wymóg wprowadzenia prostego feature togglingu i trybu „lite” aplikacji,
• przegląd i modernizacja rozwiązań w obszarze WAF/CDN i balancerów.

Z perspektywy finansowej oznaczało to dodatkowe projekty, budżety i czas – często kosztem nowych funkcji produktowych. Trudno było jednak te inwestycje odłożyć na później, bo incydent pokazał, że bez nich kolejny sezon może skończyć się podobnie lub gorzej.

Ryzyko prawne i regulacyjne

Choć atak DDoS najczęściej nie wiąże się bezpośrednio z wyciekiem danych, może mieć konsekwencje prawne. W tym przypadku trzeba było rozważyć kilka kwestii:

• czy przestój nie naruszył zapisów regulaminu wobec klientów (np. gwarantowanych okien promocji),
• czy konieczne jest zgłoszenie incydentu do regulatora lub innych instytucji (w zależności od branży i skali),
• jak rozwiązać reklamacje osób, które twierdziły, że „nie zdążyły skorzystać z oferty” przez problemy techniczne.

Najczęściej zadawane pytania (FAQ)

Dlaczego Black Friday jest tak podatny na ataki DDoS na sklepy internetowe?

W Black Friday infrastruktura sklepu już działa na granicy wydolności: ruch rośnie wielokrotnie, bazy danych są obciążone, a każdy błąd konfiguracji szybko wychodzi na wierzch. Cyberprzestępcy wykorzystują ten naturalny stres test systemu i „doklejają” do niego atak DDoS, który przepycha środowisko za krawędź.

Dodatkowo zespoły techniczne i biznes są wtedy pod dużą presją – trwa wiele kampanii, zarząd i marketing patrzą na wyniki sprzedaży w czasie rzeczywistym. To sprzyja opóźnionym reakcjom i paraliżowi decyzyjnemu, bo wszyscy boją się podjąć ryzykowne działania (np. zmienić konfigurację WAF czy przełączyć DNS) w momencie szczytu sprzedaży.

Jak rozpoznać, że to atak DDoS, a nie „normalny” szczyt ruchu w Black Friday?

Na pierwszy rzut oka objawy mogą wyglądać podobnie: rosnące opóźnienia, sporadyczne błędy 502/504, większe obciążenie serwerów. Różnica polega na tym, że w ataku DDoS często widać nienaturalną strukturę ruchu – np. duże serie podobnych zapytań HTTP, nagły wyskok ruchu z jednego kraju lub sieci, powtarzalne patterny w user‑agentach.

Pomocne są progi alarmowe oparte nie tylko na dostępności (czy strona odpowiada), ale na anomaliach: liczbie zapytań na sekundę, typach endpointów, które są obciążone, czy nagłej zmianie konwersji przy rosnącym ruchu. Jeśli wykresy wizyt rosną, a sprzedaż się stabilizuje lub spada, to mocny sygnał, że coś jest nie tak i może chodzić o atak, a nie tylko o „udany marketing”.

Jakie elementy infrastruktury sklepu najczęściej stają się wąskim gardłem podczas ataku DDoS w Black Friday?

Najczęściej „pękają” te miejsca, które już są słabsze w zwykłe dni, ale wtedy tylko spowalniają działanie sklepu. W Black Friday i podczas DDoS stają się krytyczne. W praktyce są to przede wszystkim:

• bazy danych, które nie radzą sobie z lawiną zapytań o stany magazynowe, koszyki i sesje użytkowników,
• brak cache’owania podstawowych podstron (lista produktów, strona główna, landing kampanii),
• monolityczne aplikacje, gdzie awaria jednego modułu „kładzie” cały sklep,
• ograniczone zasoby serwerów aplikacyjnych i brak automatycznego skalowania.

Jeżeli do tego dochodzi słabo skonfigurowany WAF i monitoring nastawiony głównie na „czy działa”, a nie „czy działa podejrzanie”, sklep jest szczególnie podatny na to, że atak DDoS dobije go w momencie szczytu ruchu.

Jakie są realne skutki ataku DDoS na sklep w Black Friday w porównaniu ze zwykłym dniem?

Technicznie ten sam wolumen ataku w zwykły wtorek może oznaczać kilkanaście minut problemów, trochę wstydu i konieczność krótkiej analizy po incydencie. W Black Friday konsekwencje są znacznie poważniejsze, bo każda minuta przekłada się bezpośrednio na utracony przychód i zaufanie klientów.

Przestój w szczycie wywołuje kaskadę problemów: zrywają się drogie kampanie płatne, klienci po kilku nieudanych próbach przechodzą do konkurencji, zamówienia „na później” spiętrzają się i generują chaos w logistyce, a obsługa klienta zostaje zalana skargami. Do tego dochodzi silne napięcie wewnątrz firmy – presja zarządu, nerwowe decyzje marketingu i ryzyko, że ktoś „ratując sytuację”, przypadkowo ją pogorszy.

Dlaczego atakujący wybierają szczyty sprzedaży i żądają okupu za przerwanie ataku DDoS?

Dla przestępców Black Friday to sytuacja, w której sklep ma bardzo dużo do stracenia w krótkim czasie. Groźba „zepsucia” jednego z najważniejszych dni sprzedażowych zwiększa szansę, że firma zapłaci okup, bo biznes postrzega to jako mniejsze zło niż utratę kluczowego przychodu czy reputacji.

Atakujący korzystają też z tego, że ruch jest faktycznie wyższy i bardziej chaotyczny, co utrudnia szybkie odróżnienie botów od prawdziwych klientów. Często wysyłają e‑maile z żądaniem okupu kilka dni przed szczytem, czasem ilustrując groźbę krótkim testowym atakiem. Nawet jeśli jakaś firma zapłaci, nie ma gwarancji, że atak nie nastąpi – informacja o „sklepie gotowym do okupu” może krążyć w środowisku przestępczym.

Czy atak DDoS podczas Black Friday może maskować inne działania przestępcze?

Tak, DDoS bywa wykorzystywany jako zasłona dymna. Gdy cała uwaga zespołu jest skupiona na wykresach obciążenia, odzyskiwaniu dostępności i gaszeniu pożaru marketingowego, łatwiej przeoczyć inne, cichsze działania atakujących.

W tym czasie mogą trwać próby logowania na konta administracyjne, testowanie słabszych zabezpieczeń paneli wewnętrznych, próby kradzieży danych klientów czy manipulacje płatnościami. Dlatego oprócz reagowania na sam atak DDoS przydaje się równoległe monitorowanie logów bezpieczeństwa, alerty na nietypowe logowania i jasny podział ról: kto walczy o wydajność, a kto pilnuje bezpieczeństwa.

Jak średni sklep internetowy może się przygotować na atak DDoS w Black Friday?

Nawet bez ogromnych budżetów da się znacząco ograniczyć ryzyko. Kluczowe kroki to: wzmocnienie bazy danych i cache’owanie najważniejszych podstron, przetestowanie automatycznego skalowania, dostosowanie reguł WAF do realnego ruchu sklepu, a także przećwiczenie scenariusza awaryjnego – kto, co i kiedy robi, gdy pojawią się symptomy ataku.

Pomaga też zmiana podejścia biznesu: uwzględnienie ryzyka DDoS w planowaniu kampanii (np. margines czasowy na przygotowanie), włączenie wskaźników bezpieczeństwa do raportów zarządu oraz ustalenie z góry, jak firma reaguje na żądania okupu. Dzięki temu, gdy przyjdzie kryzys, zespół nie będzie musiał improwizować wszystkiego od zera.