Jak blokować boty i niechciany ruch

Skuteczne odfiltrowanie niechcianych odwiedzin wymaga połączenia analizy, precyzyjnych reguł i automatyzacji. Poniższa instrukcja prowadzi krok po kroku: od rozpoznania problemu, przez decyzje na poziomie sieci i aplikacji, aż po monitoring oraz ciągłe doskonalenie. Dzięki temu ograniczysz koszty, ochronisz zasoby i poprawisz jakość danych analitycznych, a Twoi prawdziwi użytkownicy zauważą szybsze ładowanie stron i mniej błędów po stronie serwera.

Diagnoza i przygotowanie

Ustal cel i definicję niechcianego ruchu

Zanim cokolwiek zablokujesz, spisz, co jest uznawane za niepożądane: skanowanie katalogów, scrapowanie cen, agresywne pobieranie obrazów, testy siłowe logowania, rejestracje spamowe, nadużycia API lub generowanie fałszywych kliknięć. Określ limity, które odróżniają zachowanie człowieka od automatu (np. ile żądań na sekundę, głębokość crawlowania, wzorce URL). Zdefiniuj segmenty usług: publiczne strony, panel klienta, API mobilne, webhooki – każda część wymaga nieco innej polityki.

Wyznacz metryki powodzenia: spadek 5xx i 429, mniejsza liczba nieudanych logowań, mniej zapytań o nienaturalnej porze, stabilniejsze czasy odpowiedzi. Określ tolerancję błędów blokowania: jaki odsetek fałszywie zablokowanych żądań jest akceptowalny i jak szybko musisz reagować na zgłoszenia użytkowników.

Zbierz i skoreluj logi

Skup się na jednoczesnym zebraniu danych z warstw: serwer WWW, proxy, WAF, load balancer, aplikacja, baza danych i dostawca DNS/CDN. Rejestrowane pola to minimum: timestamp, IP, UA, metoda, ścieżka, status, referer, rozmiar, czas odpowiedzi, identyfikator sesji/użytkownika, źródło kraju/ASN, wynik reguły bezpieczeństwa. Ustandaryzuj format (np. JSON Lines), aby łatwo analizować w narzędziach takich jak ELK, ClickHouse, BigQuery czy Snowflake.

Zbuduj szybkie zapytania do wykrywania anomalii: top IP w 5 min, top ścieżek 404/401, liczba prób logowania per konto, wzrost żądań bez referera, odsetek żądań HEAD/OPTIONS. Wprowadź tagowanie ruchu pochodzącego od znanych robotów (np. Googlebot), aby odseparować „dobre” indeksowanie od wrogiej automatyzacji.

Wskaźniki nadużyć i sygnatury

Wyznacz cechy, które powtarzają się w zdarzeniach szkodliwych: nietypowe godziny, brak akceptacji kompresji, niestandardowe kolejności nagłówków, brak obsługi JavaScript, identyczne ciągi w parametrach, próby dostępu do /wp-admin lub /phpmyadmin, nagłe wyskoki w żądaniach do jednego zasobu. Ustal prosty scoring ryzyka i przypisz akcje: przepuść, ogranicz, wyzwanie, blokuj, rejestrowanie tylko.

Przygotuj plan działania na podstawie typu: skanowanie luk – filtr ścieżek; bruteforce – limity per konto i IP; scrapowanie – polityka opóźnień i modyfikacja treści; nadużycia API – klucze i podpisy żądań; flood – mechanizmy sieciowe i cache.

Mapa architektury i wektory

Spisz, gdzie możesz interweniować: DNS i CDN, WAF, reverse proxy, load balancer, brama API, serwer aplikacyjny, warstwa bazy. Zidentyfikuj punkty, których nie wolno przeciążyć (zależności zewnętrzne, kolejki, wyszukiwarki), i przygotuj reguły ochronne wcześniej. Zadbaj o spójność: jeśli ruch przechodzi przez kilka hopów, jedna reputacja IP i wynik reguł powinny „podróżować” w nagłówkach między warstwami.

Blokada na warstwie sieci i transportu

Firewall i listy kontroli dostępu

Na brzegu sieci zastosuj listy zezwoleń i zablokowań: blokuj prywatne zakresy na publicznych interfejsach, wymuś dopuszczenie tylko TCP 80/443, odrzucaj protokoły nieużywane (UDP, jeśli niepotrzebny). W środowiskach chmurowych wykorzystaj reguły VPC/NSG, w metalowych – nftables/iptables. Pamiętaj o log-only dla nowych reguł, aby ocenić wpływ przed egzekwowaniem.

Jeśli oferujesz panel administracyjny, ogranicz go do VPN lub stałych adresów (allowlist). Rozważ filtrowanie po ASN (np. blokada dostawców hostingowych znanych z agresywnych skanerów) oraz TTL blokady – chwilowe bany automatycznie wygasają, zmniejszając ryzyko trwałej pomyłki.

Rate limiting w LB i serwerach

Stosuj limity równolegle na kilku poziomach: per-IP, per-sieć (/24, /64), per-ścieżka i per-konto. Definiuj dwie wartości: steady rate i burst. Przykład: 10 żądań/sekundę z buforem 20 na /api/login; 2 żądania/sekundę na drogie zasoby raportowe. Odpowiadaj kodem 429, dodając Retry-After oraz korelacyjny identyfikator żądania, by ułatwić diagnostykę.

W NGINX/Envoy/Istio czy bramach API włącz limity oparte na kluczach kompozytowych (IP+User-Agent lub UserID+ClientID), aby utrudnić rozpraszanie ruchu po wielu adresach. Łącz limity lokalne (per-instanse) z globalnymi (w redis/memcached) i pamiętaj o redystrybucji wartości przy autoskalowaniu.

GeoIP, ASN i reputacja IP

Jeśli Twoja usługa jest lokalna, zastosuj weryfikację kraju pochodzenia. Zastanów się nad trybem „dopuszczaj domyślnie, blokuj wyjątki” lub odwrotnie, w zależności od ryzyka. Uzupełnij o reputację adresów: listy Spamhaus DROP/EDROP, FireHOL, Project Honey Pot, AbuseIPDB. Aktualizuj je automatycznie raz dziennie, z buforem karencji na usunięcia, aby nie karać świeżo wyczyszczonych adresów.

Dodaj heurystyki: brak PTR, centra danych vs ISP, nagła zmiana wielu adresów dla jednego konta. Warto oznaczać takie żądania i zamiast twardej blokady zastosować wyzwanie (JavaScript/kapcza), co zmniejsza ryzyko zablokowania legalnych użytkowników łączących się przez VPN.

Ochrona przed DDoS i zasady awaryjne

Włącz automatyczną ochronę L3/L4 u operatora lub w CDN/WAF. Aktywuj profile dla SYN flood, UDP flood, fragmentacji. Skonfiguruj politykę „under attack”: tymczasowe wyzwania dla wszystkich nowych sesji, mocniejsze limity ścieżek newralgicznych i agresywne cache statycznych zasobów.

Przygotuj runbook: jak przełączyć się na tryb tylko-czytanie, jak zredukować dynamikę strony (twarde cache, edge rendering), jak skrócić TTL DNS i przełączyć ruch przez scrubbing center. Ćwicz to cyklicznie – bez testów odzyskiwanie nie zadziała, gdy będzie potrzebne najbardziej.

Kontrole na warstwie aplikacji

WAF i reguły oparte o regex

Włącz podstawowy zestaw reguł OWASP CRS i dostrajaj: zacznij w trybie detekcji, przeanalizuj fałszywe trafienia, dopiero potem egzekwuj. Twórz własne reguły opisujące ścieżki, parametry i nagłówki specyficzne dla Twojej aplikacji. Przykłady: blokada dostępu do /wp-admin na hostach nie-WP; drop, gdy Content-Type nie pasuje do metody (np. JSON przy GET); odrzucenie nadmiernej liczby parametrów.

Wprowadzaj reguły „gałązkowe”: jeśli UA pusta i brak Accept-Language, a jednocześnie łączna liczba żądań na sekundę > X – najpierw wyzwanie, potem ban 10 minut. Pamiętaj o wersjonowaniu reguł i testach kanarkowych: 1% ruchu z nową regułą, obserwacja, rozszerzanie do 100% po weryfikacji.

Filtry User-Agent, nagłówków i TLS fingerprint

Nie polegaj wyłącznie na UA, ale wykorzystaj go jako sygnał. Utrzymuj listę dozwolonych botów (Google, Bing) z weryfikacją reverse DNS i ponownym lookupem. Wykrywaj nietypowe sekwencje nagłówków, brak ciasteczek, brak kompresji. Dodaj kontrolę odcisku TLS (JA3/JA4) – wiele narzędzi automatyzujących ma charakterystyczne profile, które trudno sfałszować bez pełnej implementacji stosu.

W sytuacjach granicznych zamiast twardej blokady zastosuj „staged challenge”: najpierw lekkie obliczenia JS, potem CAPTCHA, dopiero na końcu ban. Pozwala to odsiewać mniej zaawansowane skrypty bez krzywdzenia realnych użytkowników na słabszych urządzeniach.

CAPTCHA, JavaScript challenge i tokeny

Używaj wyzwań warstwowo: proste sprawdzenie wykonywania JS i ustawienia cookie, a dopiero gdy podejrzenie rośnie – pełna kapcza. Rozważ alternatywy bezobrazkowe (np. niewidoczne wyzwania oparte o działania użytkownika) oraz adaptacyjne – zwiększające poziom trudności przy podejrzanym ruchu. Nie zmuszaj każdego do rozwiązywania zagadek – to pogarsza UX i SEO.

Zabezpiecz krytyczne formularze tokenami jednorazowymi, ogranicz okno ważności, przypinaj token do IP/UA lub identyfikatora urządzenia. W API rozważ podpisy żądań (HMAC), jednorazowe nonce i ograniczenie czasu przyjęcia (skew). Dla aplikacji mobilnych wprowadź atestację urządzenia (np. Play Integrity, App Attest) oraz powiązanie klucza klienta z aplikacją.

Honeypot i pułapki tarpit

Dodaj niewidoczne pola formularza, które człowiek nie wypełni, a proste boty owszem. Umieść odnośniki do nieistniejących ścieżek i monitoruj, kto je odwiedza – to sygnał scraperów. W przypadku żądań z wysokim scoringiem ryzyka zamiast 403 możesz spowolnić odpowiedź i dozować bajty; to marnuje zasoby atakującego i zniechęca do floodu.

Wydziel osobną subdomenę z „atrakcyjnymi” adresami URL, które nie pojawiają się w nawigacji. Każde aktywne odwiedziny oznacz jako silny sygnał automatyzacji. Nie umieszczaj tam wrażliwych danych – to tylko marker zachowania, nie pułapka z prawdziwą zawartością.

API: klucze, JWT, mTLS i limity

Wymagaj identyfikacji klienta: klucze z rotacją, zakresami uprawnień i ścisłymi limitami. Stosuj „zakładkę kosztu” operacji – różne endpointy mają różne koszty, więc licznik powinien rozliczać budżet na podstawie wagi wywołań. Używaj krótkotrwałych JWT z podpisem i odświeżaniem przez bezpieczne ścieżki. Rozważ mTLS dla integracji serwer–serwer, aby wykluczyć anonimowe połączenia.

Włącz mechanizmy anomalii: zbyt wiele błędów 4xx/5xx dla jednego klucza, zbyt szybka zmiana IP, brak rotacji kluczy, nagłe skoki ruchu z jednego AS. Dla webhooków dodaj weryfikację podpisu i allowlistę IP nadawcy, a w razie wątpliwości – retry z backoffem i kwarantanną zdarzeń.

Operacje, monitoring i ciągłe doskonalenie

Tryb obserwacyjny i testy A/B reguł

Każdą nową politykę wdrażaj w dwóch krokach: najpierw log-only z metrykami wpływu, potem egzekwowanie na niewielkim procencie. Przygotuj zestaw benchmarków UX: czas do pierwszego bajtu, TTFB na krytycznych ścieżkach, liczba błędów formularzy. Jeśli wskaźniki spadają, cofnij zmiany i doprecyzuj warunki, zamiast podnosić limity „na ślepo”.

Testuj reguły na danych historycznych (replay) oraz na ruchu syntetycznym: generuj scenariusze człowieka (scroll, klik, pauzy) i automatu (seryjne GET bez cookie). Wersjonuj polityki i utrzymuj changelog – łatwiej zrozumieć korelacje między incydentami a wdrożeniami.

Alerty, dashboardy i playbooki

Zbuduj pulpity na żywo: wolumen żądań, procent 4xx/5xx/429, udział wyzwań, top reguł blokujących, top krajów/ASN. Ustal progi alertów dynamiczne (względem mediany/historycznego percentyla), aby nie zasypywać zespołu fałszywymi alarmami w sezonowych pikach. Dołącz przykładowe logi do powiadomień, by skrócić czas rozpoznania.

Przygotuj playbook: co zrobić, gdy rośnie ruch na /login; jakie reguły doraźne aktywować; jak eskalować do dostawcy CDN/WAF; kiedy uruchomić tryb „under attack”. Dołącz matrycę decyzyjną (np. progi QPS i błędów), aby dyżurny nie musiał improwizować.

Minimalizacja fałszywych trafień i ścieżki odwołań

Włącz whitelistę zaufanych partnerów i monitorów (np. uptime boty). Dla użytkowników końcowych udostępnij formularz odblokowania: proś o timestamp, IP, identyfikator błędu; automatyzuj sprawdzenie, czy blokada jest aktualna i zasadna. Zastanów się nad tzw. soft-deny: zamiast 403 serwuj wersję statyczną lub wymagaj dodatkowego potwierdzenia, co pozwala na kontynuowanie sesji bez pełnego odcięcia.

Używaj korelacji: jeśli użytkownik zalogowany ma wysoki poziom zaufania, preferuj ograniczenie prędkości zamiast blokady. Zbieraj sygnały z zewnętrznych systemów antyfraudowych i punktuj je obok reguł technicznych – łącznie dają lepszy obraz ryzyka.

Automatyzacja: SIEM, SOAR, IaC

Przekazuj zdarzenia do SIEM i buduj reguły, które wykrywają anomalie w wielu systemach jednocześnie: np. wzrost błędów logowania + wzrost 401 + odchylenie JA3. Z SOAR automatyzuj akcje: tymczasowa blokada IP, podniesienie poziomu wyzwań w WAF, powiadomienie właściciela usługi. Zasady i listy reputacyjne trzymaj jako kod (IaC), z przeglądem PR i testami jednostkowymi dla reguł.

Wprowadzaj automatyczną rotację kluczy, okresowe czyszczenie starszych banów i wygaszanie wyjątków. Dzięki temu środowisko nie „zarasta” przypadkowymi zmianami, a konfiguracja pozostaje przewidywalna i audytowalna.

Współpraca z dostawcami i zgodność

Uzgodnij z dostawcą CDN/WAF, jakie dane telemetryczne są dostępne i jak szybko eskalują incydenty. Wykorzystaj programy zaufanych botów (Verified Bots) i feedy reputacyjne. Pamiętaj o prywatności: minimalizuj dane osobowe w logach, skracaj IP, wprowadzaj retencję. Transparentność wobec użytkownika – jasne komunikaty błędów, informacja o wyzwaniach – zmniejsza liczbę zgłoszeń i poprawia zaufanie.

Jeśli działasz w regulowanych branżach, dokumentuj uzasadnienie blokad i proces odwołań. Zadbaj o dostępność: zapewnij alternatywę dla osób z ograniczeniami (np. audio CAPTCHA lub kontakt do wsparcia), aby bariery bezpieczeństwa nie wykluczały legalnych użytkowników.

Praktyczne przykłady i priorytety wdrożenia

1) Szybkie zwycięstwa: aktywuj ochronę DDoS u dostawcy, dodaj podstawowe limity na /login i /search, zweryfikuj znane boty, włącz minimalny zestaw reguł WAF w trybie detekcji. 2) Średni horyzont: reguły oparte o profil nagłówków i JA3, reputacja IP, honeypoty, adaptacyjne wyzwania. 3) Długofalowo: podpisy API, mTLS, atestacja aplikacji mobilnej, automatyzacja w SOAR i polityki jako kod.

W kolejnych iteracjach analizuj skutki: sprawdź, o ile zmniejszyły się zapytania do drogich endpointów, czy spadła liczba 5xx, jak zmienił się TTFB. Ustal budżet ryzyka i systematycznie podnoś poprzeczkę tylko tam, gdzie widać korzyść. Celem nie jest „blokować wszystko”, lecz mądrze rozdzielać zasoby między realnych ludzi a boty.