Mały sklep, serwer od miesięcy na 100 procentach i dziesiątki tysięcy odwiedzających na godzinę, którzy nie byli klientami

Większość tego, co wyglądało na zabezpieczenie albo rozwiązanie, w tym przypadku nie działała.

Zdjęcia nie były problemem, choć było ich najwięcej

Najwięcej żądań dotyczyło plików statycznych, więc zdjęcia były oczywistym podejrzanym. Kosztowały 2 procent jednego rdzenia procesora. Całe obciążenie pochodziło z żądań do WordPressa, a każde z nich, nawet błąd 404 czy żądanie o robots.txt, uruchamia cały sklep z wtyczkami.

Cache by nie pomógł, a do tego i tak nie działał

Wtyczka cache była zainstalowana, a jej plik konfiguracyjny twierdził, że wszystko jest włączone. W praktyce nie działała: brakowało plików i ustawienia, bez których WordPress ją ignoruje. Ważniejsze: nawet działający cache niczego by nie zmienił. Cache przyspiesza powtarzające się adresy, a tu prawie każdy adres był inny.

Limity i automatyczne bany nie mogły zadziałać

Zapora ogranicza tempo żądań z jednego adresu i banuje adresy, które zbierają odpowiedzi z błędami. Oba mechanizmy patrzą na nadawcę. Bot wysyłał około trzech żądań na godzinę z jednego adresu, przy limicie dwóch na sekundę, i za każdym razem dostawał poprawną odpowiedź. W oczach zapory był wzorowym gościem. Żadna obrona oparta na adresie nadawcy nie mogła tu zadziałać.

Blokada po adresie strony nie widziała parametrów

Zapora potrafi blokować po wzorcu adresu. Okazało się, że dopasowuje wyłącznie ścieżkę, bez parametrów po znaku zapytania, a ruch botów różnił się właśnie parametrami. Taka reguła wygląda na zastosowaną i nic nie robi. Znaleźliśmy to w kodzie źródłowym zapory, zanim ktokolwiek na niej polegał.

Boty dostosowały się w ciągu miesiąca

Pierwsza reguła odrzucała ruch po kształcie adresu. Miesiąc później ruch wrócił: ten sam wolumen, prawie 30 000 adresów w dziesięć minut, dokładnie pod progiem reguły, i przeniesiony z kategorii na strony tagów produktów. Ktoś obserwował odpowiedzi i stroił atak. Jedna cecha nie wystarcza na długo; reguły muszą być trudne do obejścia, a nie tylko łapać dzisiejszy ruch.

Najlepsza cecha była w danych od początku

Druga reguła opiera się na zachowaniu, którego prawdziwa przeglądarka nie pomija, gdy klient klika filtr. Ta cecha była widoczna już w pierwszej godzinie logów, w 67 113 z 68 110 żądań. Za pierwszym razem wybraliśmy cechę najbardziej rzucającą się w oczy, a nie najtrudniejszą do podrobienia. Dziś obie warstwy działają razem.

Strona zbanowała samą siebie

WordPress uruchamia swoje zadania okresowe, wywołując własny publiczny adres. Podczas zalewu każde wejście bota uruchamiało te zadania, ponad 1 300 wywołań w dziesięć minut z adresu samego serwera. Zapora potraktowała to jak atak i zbanowała własny serwer strony na dobę. Wysyłka maili i zadania sklepu stanęły, a nasze testy z serwera dostawały odmowę, co przez chwilę wyglądało na fałszywy alarm nowej reguły.

Blokada botów nie może banować klientów

Odrzucone żądanie liczy się do automatycznego bana. Gdyby reguła była zbyt ostra, klient klikający „zaznacz wszystkie” w filtrze dostałby ban na dobę. Progi wzięliśmy z danych: klienci zaznaczali kilka wartości, boty znacznie więcej, a obie grupy się nie pokrywały.