Większość właścicieli sklepów internetowych słyszała o atakach DDoS. Mało kto jednak zdaje sobie sprawę, że ich sklep może być atakowany w sposób znacznie subtelniejszy – przez zautomatyzowane pobieranie danych z katalogu produktów – scraping. Ataki tego typu są trudne do wykrycia. Potrafią przeciążyć serwer tak samo skutecznie jak klasyczny DDoS, a ich skala w ostatnich miesiącach wyraźnie rośnie. Obsługujemy wiele sklepów opartych na PrestaShop, a kilka z nich padło ofiarą tego zjawiska i chcemy podzielić się tym, czego się nauczyliśmy.

Jak to wygląda w praktyce?

Typowy atak scrappingowy na sklep PrestaShop z nawigacją fasetową (czyli filtrami marek, kategorii, wieku produktu itp.) wygląda następująco. W logach serwera pojawiają się dziesiątki, a potem setki żądań na minutę trafiających w endpointy kategorii – np. /kategorie?q=Marka-BrandA-BrandB-BrandC-BrandD-BrandE-BrandF-BrandG-BrandH – z jedną charakterystyczną cechą: każde żądanie pochodzi z innego adresu IP.

Na pierwszy rzut oka wygląda to jak normalny ruch. User-agenty to standardowe przeglądarki Chrome na Windows. Brak podejrzanych botów w nazwie. Żadnych oczywistych wzorców. Dopiero dokładna analiza ujawnia problem:

• Każde żądanie zawiera kombinację kilkunastu marek w parametrze filtra
• Kombinacje są systematycznie różne – bot przechodzi przez wszystkie możliwe zestawienia
• Adresy IP rotują przez tysiące lokalizacji na całym świecie
• Ruch jest równomierny i ciągły, bez przerw charakterystycznych dla człowieka

W jednym z przypadków które analizowaliśmy, w ciągu jednej sekundy do serwera trafiało ponad 10 żądań z 10 różnych adresów IP. Każde z ciężkim zapytaniem filtrującym po kilkunastu markach jednocześnie.

Dlaczego to boli bardziej niż wygląda?

Nawigacja fasetowa w PrestaShop generuje ogromną liczbę kombinacji URL. Jeśli sklep ma 50 marek i filtry według wieku, kategorii i kolejności sortowania – liczba możliwych kombinacji idzie w dziesiątki tysięcy. Każde takie zapytanie to osobne żądanie do bazy danych z wieloma JOIN-ami i warunkami WHERE.

Przy normalnym ruchu baza danych obsługuje te zapytania bez problemu. Ale gdy 200 botów odpytuje serwer jednocześnie, każdy z innym zestawem 10+ marek, efekt jest taki sam jak klasyczny atak DoS. Przez wyczerpanie zasobów – serwer zaczyna zwracać błędy HTTP 500, strona przestaje działać dla prawdziwych użytkowników.

Co istotne – nie trzeba do tego tysięcy maszyn botnet. Wystarczy kilkaset żądań na minutę, jeśli każde z nich jest wystarczająco kosztowne obliczeniowo dla bazy danych.

Kto za tym stoi i po co?

W zdecydowanej większości przypadków motywem jest zbieranie danych handlowych. Konkretnie:

Monitoring cen i asortymentu to najpowszechniejszy cel. Konkurencja, agregatory cenowe, dystrybutorzy sprawdzający politykę cenową – wszyscy chcą wiedzieć co oferujesz i za ile. Zamiast ręcznie przeglądać sklep, wynajmują gotowe narzędzie scrapingowe.

Budowanie własnych baz produktów – kopie opisów, zdjęć, kategoryzacji. Niszowe sklepy z unikalnym katalogiem są szczególnie atrakcyjnym celem, bo zebranie takiej bazy ręcznie byłoby bardzo pracochłonne.

Analiza rynku – kto wprowadza jakie nowe marki, jak zmienia się dostępność produktów, które kategorie się rozwijają.

Narzędzia do tego celu są dostępne komercyjnie – sieci residential proxy, czyli adresów IP z prawdziwych urządzeń domowych, można wynająć za kilkadziesiąt dolarów miesięcznie. Z perspektywy serwera każde żądanie wygląda jak ruch od zwykłego użytkownika w Polsce, Niemczech czy Brazylii.

Dlaczego blokowanie IP nie działa?

To podstawowy problem z tego typu atakami. Tradycyjne podejście – zablokuj adres IP który zachowuje się podejrzanie – tutaj się nie sprawdza. Każdy bot używa danego IP tylko raz lub kilka razy, po czym rotuje na kolejny.

Blokowanie całych zakresów geograficznych jest możliwe, ale ryzykowne. Przy sklepach działających na rynku europejskim znaczna część adresów pochodzi z Europy Zachodniej, więc agresywny geo-blocking uderza też w prawdziwych klientów.

Co faktycznie działa?

Po przeanalizowaniu kilku takich ataków i przetestowaniu różnych rozwiązań, wypracowaliśmy skuteczne podejście wielowarstwowe.

Warstwa pierwsza: cache

Najszybszy efekt w sytuacji kryzysowej daje włączenie cache na poziomie serwera lub aplikacji. Jeśli wyniki zapytań filtrujących są cachowane choćby przez 5 minut, bot dostaje odpowiedź wygenerowaną raz – baza danych nie jest wielokrotnie obciążana. W PrestaShop należy upewnić się, że cache Smarty i cache stron są aktywne. Przed Apache warto rozważyć Varnish.

Warstwa druga: blokowanie po wzorcu zapytania

Kluczowa obserwacja: prawdziwy użytkownik wybierający filtry w sklepie rzadko kiedy zaznacza więcej niż 2-4 marki naraz. Bot systematycznie odpytuje kombinacje 8-15 marek w jednym URL.

Na poziomie konfiguracji serwera Apache można dodać reguły RewriteEngine blokujące zapytania zawierające więcej niż określoną liczbę segmentów po parametrze filtra marek. Reguła zliczająca myślniki oddzielające nazwy marek w query stringu jest wystarczająco precyzyjna, żeby nie dotknąć prawdziwych użytkowników, a skutecznie blokować automatyczne kombinatoryczne odpytywanie.

Ważne: reguły należy umieszczać na poziomie vhosta lub w konfiguracji serwera. Działają wtedy przed uruchomieniem PHP, co oznacza zero obciążenia bazy danych dla zablokowanych żądań.

Warstwa trzecia: dodatkowe sygnały botów

Przy bardziej zaawansowanych atakach warto szukać dodatkowych cech charakterystycznych dla konkretnego scrapera. W jednym z analizowanych przypadków każde żądanie bota zawierało parametr zmiany waluty (SubmitCurrency) z rotującymi wartościami. Prawdziwi użytkownicy prawie nigdy nie zmieniają waluty przez URL przy każdym kliknięciu w filtr. Taki specyficzny wzorzec można zablokować jedną prostą regułą, nie dotykając normalnego ruchu.

Warstwa czwarta: Fail2ban

Nawet przy rotacji IP, każdy adres zwykle wykonuje kilka żądań zanim zostanie zmieniony. Fail2ban skonfigurowany do wykrywania wzorca scrapingowego w logach i banowania IP po 3-5 takich żądaniach skutecznie spowalnia atak – boty muszą szybciej rotować adresy, co zwiększa ich koszty operacyjne.

Warstwa piąta: Cloudflare lub inny WAF

Cloudflare w planie Pro oferuje rate limiting i bot management, które są skuteczne przeciwko rozproszonym atakom. Jednak – co warto podkreślić – reguły Cloudflare działają po dotarciu żądania do edge node, czyli zanim trafią na serwer, ale wymagają poprawnej konfiguracji. Rate limiting na endpoincie katalogu z progiem np. 10 żądań na minutę z jednego IP eliminuje większość botów bez wpływu na prawdziwych użytkowników.

Jednak przy atakach z tysięcy różnych IP rate limiting per-IP ma ograniczoną skuteczność. Lepiej wtedy polegać na regułach wzorcowych opisanych wyżej.

Sygnały ostrzegawcze w logach

Jak rozpoznać że twój sklep jest właśnie scrapowany? Na to warto zwrócić uwagę:

Wzrost ruchu bez wzrostu konwersji – jeśli ruch w GA rośnie, ale sprzedaż pozostaje taka sama, może to oznaczać ruch botów (choć boty często w ogóle nie uruchamiają JavaScript i nie są widoczne w GA).

Błędy HTTP 500 w logach serwera – szczególnie jeśli pojawiają się nagle i masowo, to sygnał że baza danych nie jest przeciążona.

Wiele różnych IP odpytujących te same kombinacje URL – widoczne dopiero po analizie logów serwera, nie w Google Analytics.

Duże zapytania z parametrami filtrów w logach – szczególnie długie URL z wieloma nazwami marek.

Stałe wartości rozmiaru odpowiedzi przy błędach 500 – jeśli wszystkie błędy 500 mają dokładnie ten sam rozmiar (np. 629 bajtów), to błąd generyczny zwracany przez przeciążoną aplikację.

Wnioski

Scraping katalogów sklepów nie jest nowym zjawiskiem, ale jego skala i zaawansowanie wyraźnie rosną. Dostępność tanich sieci residential proxy sprawia, że tego rodzaju działania są w zasięgu każdego konkurenta z budżetem kilkudziesięciu dolarów miesięcznie.

Skuteczna ochrona nie polega na jednym rozwiązaniu, lecz na kilku warstwach działających jednocześnie. Cache chroni serwer przed przeciążeniem nawet gdy bot przejdzie, reguły wzorcowe blokują charakterystyczne kombinatoryczne zapytania. Natomiast monitoring logów pozwala wykrywać nowe wzorce i reagować zanim sytuacja stanie się kryzysowa.

Jeśli zarządzasz sklepem PrestaShop i chcesz sprawdzić czy jesteś celem tego rodzaju ataków – zacznij od analizy logów serwera. To co zobaczysz może Cię zaskoczyć.

Masz pytania dotyczące bezpieczeństwa swojego sklepu lub serwera? Skontaktuj się z nami – chętnie przeanalizujemy sytuację i doradzimy odpowiednie rozwiązania. Jesteśmy na TAK, żeby Ci pomóc.