Jak wykrywać scraping profili NAP na podstawie wzorców ruchu

Scraper profili NAP rzadko zdradza się jednym spektakularnym skokiem ruchu. Częściej wygląda jak zwykły użytkownik, tylko zbyt regularny, zbyt konsekwentny i podejrzanie zainteresowany wyłącznie stronami zawierającymi nazwę firmy, adres oraz numer telefonu. Pojedyncze żądanie niczego nie dowodzi. Dopiero zestawienie tempa wejść, kolejności odwiedzanych adresów, powtarzalności sesji i cech klienta HTTP pozwala oddzielić indeksowanie, monitoring danych oraz automatyczne kopiowanie profili od normalnego ruchu.

Największym błędem jest blokowanie na podstawie samego adresu IP. Współczesne scrapery korzystają z rotacyjnych serwerów proxy, sieci mobilnych, adresów IPv6 i przeglądarek sterowanych automatycznie. Jeden proces może w ciągu godziny pojawić się z kilkuset adresów, zachowując przy tym identyczny rytm pobierania stron. Skuteczna detekcja wymaga więc analizy zachowania, a nie tylko pochodzenia żądania.

Które wzorce ruchu najczęściej zdradzają scraper profili NAP

Pierwszym sygnałem jest nienaturalna koncentracja na stronach profilowych. Zwykły użytkownik trafia na stronę firmy, przechodzi do mapy, galerii, opinii albo wraca do wyników wyszukiwania. Scraper zazwyczaj pobiera kolejne profile bez zainteresowania elementami pomocniczymi.

W logach wygląda to na przykład tak:

• 80–100% żądań dotyczy adresów typu /firma/, /profil/, /lokalizacja/ albo /branża/miasto/nazwa-firmy;
• klient otwiera kilkadziesiąt profili, ale nie pobiera formularza kontaktowego, mapy, zdjęć ani sekcji opinii;
• kolejne adresy są odwiedzane zgodnie z numeracją rekordów, alfabetem lub kolejnością linków w paginacji;
• sesja nie wykonuje typowych działań użytkownika, takich jak filtrowanie, cofanie, zmiana kategorii czy przejście do strony głównej;
• po każdym profilu następuje niemal identyczna przerwa.

Szczególnie charakterystyczny jest niski rozrzut czasu między żądaniami. Człowiek może otworzyć trzy strony w ciągu dziesięciu sekund, a potem przez minutę czytać opis. Automat pracujący z odstępem 1,8–2,2 sekundy przez 40 minut tworzy znacznie równiejszy wykres.

Dobrym punktem startowym jest oznaczanie sesji, które spełniają jednocześnie co najmniej trzy warunki:

• ponad 30 stron profilowych w ciągu 10 minut;
• minimum 85% żądań skierowanych do profili NAP;
• mediana odstępu między żądaniami poniżej 4 sekund;
• współczynnik zmienności odstępów poniżej 0,35;
• brak wejść na inne typy podstron;
• przechodzenie przez co najmniej 10 kolejnych stron paginacji;
• brak plików typowych dla pełnej przeglądarki albo pobieranie ich zawsze w identycznej kolejności.

Nie są to uniwersalne wartości do natychmiastowego blokowania. Portal odwiedzany przez handlowców, agencje SEO lub pracowników call center może generować legalne sesje o podobnej intensywności. Progi trzeba zestawić z ruchem rzeczywistych użytkowników. W praktyce najlepiej policzyć 95. i 99. percentyl liczby profili otwieranych w ciągu 10 minut, a następnie ustawić pierwszy alert nieco powyżej 99. percentyla.

Jeżeli 99% normalnych użytkowników otwiera maksymalnie 12 profili w ciągu 10 minut, próg ostrzegawczy można ustawić na 20–25. Gdy użytkownicy biznesowi regularnie otwierają po 40 profili, limit 25 będzie generował fałszywe alarmy i szybko zostanie wyłączony przez administratorów.

Drugim mocnym sygnałem jest przewidywalna kolejność adresów URL. Scraper zwykle nie wybiera profili losowo. Idzie po linkach znalezionych na stronie kategorii albo zwiększa identyfikator rekordu:

/profil/10421
/profil/10422
/profil/10423

Taki wzorzec jest prosty do wykrycia nawet wtedy, gdy automat zmienia IP. Wystarczy analizować podobieństwo ścieżek, kolejność identyfikatorów i wspólne cechy klienta. Ruch użytkowników jest bardziej chaotyczny: przeskakuje między branżami, miastami, wynikami wyszukiwania i profilami polecanymi przez serwis.

Trzecim sygnałem jest praca poza naturalnymi godzinami ruchu, ale sama pora nie może być podstawą blokady. Regularne pobieranie 20 profili na minutę od 02:00 do 05:00 jest podejrzane, szczególnie gdy powtarza się codziennie. Nie oznacza jednak automatycznie ataku. Może to być legalna integracja, audyt danych albo robot wyszukiwarki działający z rozproszonych centrów danych.

Jak łączyć logi, fingerprinting i analizę sesji

Największą skuteczność daje połączenie kilku warstw danych. Sam log serwera zawierający IP, adres URL, kod odpowiedzi i User-Agent jest zbyt ubogi. Do analizy scrapingu profili NAP warto zapisywać przynajmniej:

• dokładny czas żądania z rozdzielczością do milisekund;
• adres IP oraz prefiks sieci;
• metodę HTTP i ścieżkę URL;
• kod odpowiedzi;
• liczbę przesłanych bajtów;
• nagłówek User-Agent;
• Accept, Accept-Language, Accept-Encoding i Referer;
• identyfikator sesji lub anonimowy identyfikator klienta;
• fingerprint połączenia TLS, jeżeli infrastruktura go udostępnia;
• informację o wykonaniu JavaScriptu;
• identyfikator reguły WAF albo wyniku oceny ruchu automatycznego;
• kategorię odwiedzonej podstrony: profil, lista, wyszukiwarka, mapa, opinie lub formularz.

Dane najlepiej agregować w kilku oknach czasowych: 1 minuta, 10 minut, 1 godzina i 24 godziny. Krótkie okno wykrywa agresywne pobieranie. Dłuższe ujawnia „powolny scraping”, w którym klient otwiera jeden profil co 20–40 sekund, ale robi to bez przerwy przez całą dobę.

W praktyce przydatny jest prosty wynik ryzyka. Przykładowy model może przyznawać punkty za konkretne zachowania:

• +25 punktów: ponad 30 profili w 10 minut;
• +20 punktów: udział profili w ruchu przekracza 90%;
• +15 punktów: klient przechodzi po kolejnych identyfikatorach rekordów;
• +15 punktów: ten sam fingerprint występuje z co najmniej 10 adresów IP;
• +10 punktów: odstępy między żądaniami są wyjątkowo regularne;
• +10 punktów: brak aktywności JavaScript mimo deklarowania aktualnej przeglądarki;
• +10 punktów: User-Agent nie pasuje do zestawu nagłówków;
• +5 punktów: sesja działa bez przerwy dłużej niż godzinę.

Przy wyniku poniżej 30 punktów ruch można jedynie rejestrować. Zakres 30–59 punktów uzasadnia ograniczenie tempa lub dokładniejszą obserwację. Przy 60–79 punktach sensowne jest zastosowanie wyzwania przeglądarkowego. Wynik 80 punktów i więcej może uruchamiać czasową blokadę, pod warunkiem że wcześniej wykluczono zweryfikowane roboty, partnerów technicznych i firmowe integracje.

Najbardziej irytującym problemem jest rotacja IP. Blokada pojedynczych adresów często daje tylko chwilowy efekt, a przy korzystaniu z sieci mobilnych może uderzyć w wielu prawdziwych użytkowników. Lepsze rezultaty daje grupowanie ruchu według kombinacji:

fingerprint TLS + kolejność nagłówków + rodzina User-Agent + wzorzec ścieżek + rytm żądań.

Nie trzeba oczekiwać pełnej zgodności wszystkich parametrów. Scraper może losować User-Agent, ale pozostawić tę samą kolejność nagłówków i ten sam sposób negocjowania połączenia. Może zmienić fingerprint, lecz nadal odwiedzać rekordy w identycznej kolejności. Liczy się powtarzalny zestaw cech.

Trzeba też uważać na automatyczne przeglądarki, takie jak Chromium uruchamiane przez Playwright, Puppeteer lub Selenium. Potrafią one wykonywać JavaScript, pobierać obrazy i przechowywać cookies. Prosty test „czy klient obsługuje JavaScript” już ich nie odfiltruje. Różnicę częściej pokazuje zachowanie: brak ruchów bocznych, seryjne odwiedzanie profili, identyczne czasy przebywania na stronie oraz powtarzanie tej samej ścieżki po zmianie adresu IP.

Jak reagować, żeby nie zablokować użytkowników i wyszukiwarek

Najgorsza reakcja to natychmiastowe odcięcie całego podejrzanego ruchu kodem 403. Taka reguła wygląda zdecydowanie, ale szybko blokuje współdzielone sieci, klientów firmowych, systemy monitorujące oraz legalne roboty. Obrona powinna działać stopniowo.

Pierwszy poziom to logowanie i klasyfikacja bez ingerencji. Reguły powinny przez 7–14 dni działać w trybie obserwacyjnym. W tym czasie trzeba sprawdzić:

• ile sesji przekracza planowane limity;
• które adresy URL są pobierane najczęściej;
• czy alarmy obejmują partnerów, wyszukiwarki lub pracowników;
• jaki odsetek ruchu pochodzi z centrów danych, sieci mobilnych i łączy konsumenckich;
• ilu podejrzanych klientów wraca po zmianie IP.

Drugi poziom to ograniczanie prędkości, a nie pełna blokada. Dla publicznego katalogu można zacząć od limitu rzędu 30–60 stron profilowych na 10 minut na jeden identyfikator klienta. Po przekroczeniu limitu serwer może opóźniać odpowiedzi, zwracać kod 429 albo wymagać wykonania dodatkowego wyzwania.

Kod 429 Too Many Requests jest czytelniejszy niż 403, ponieważ informuje, że problemem jest częstotliwość, a nie całkowity zakaz dostępu. Dobrze dodać nagłówek Retry-After, na przykład z wartością 300 sekund. Nie każdy scraper go respektuje, ale legalne integracje mają wtedy jasną informację, kiedy mogą ponowić żądanie.

Trzeci poziom to wyzwanie przeglądarkowe. Powinno być uruchamiane dopiero po przekroczeniu progu ryzyka. Pokazywanie CAPTCHA każdemu użytkownikowi po otwarciu kilku profili obniża konwersję, utrudnia korzystanie z serwisu osobom z niepełnosprawnościami i nie zatrzymuje bardziej zaawansowanych operatorów korzystających z usług automatycznego rozwiązywania testów.

Pełna blokada ma sens, gdy klient:

• ignoruje wielokrotne odpowiedzi 429;
• zmienia IP, ale zachowuje fingerprint i wzorzec pobierania;
• próbuje omijać limity przez równoległe sesje;
• odpytuje nieistniejące identyfikatory w celu odkrywania rekordów;
• pobiera profile przez wiele godzin bez żadnych zachowań typowych dla człowieka;
• po wyzwaniu natychmiast wraca z nowej infrastruktury.

Lista wyjątków musi obejmować zweryfikowane roboty wyszukiwarek, ale nie wolno ufać samej nazwie w User-Agent. Napis Googlebot można ustawić w jednej linijce kodu. Tożsamość robota powinna być sprawdzana technicznie, na przykład przez potwierdzenie adresu zgodnie z procedurą opisaną przez właściciela wyszukiwarki.

W serwisach publikujących dane firmowe trzeba dodatkowo oddzielić dane organizacji od danych osób fizycznych. Nazwa spółki, adres biura i numer centrali nie zawsze są danymi osobowymi. Profil jednoosobowej działalności zawierający imię i nazwisko przedsiębiorcy, prywatny numer telefonu albo adres prowadzenia działalności może już pozwalać na identyfikację konkretnej osoby. Publiczna dostępność danych nie oznacza, że każdy sposób ich dalszego zbierania i wykorzystywania jest automatycznie dozwolony.

Dlatego mechanizm obronny powinien rejestrować zdarzenia bezpieczeństwa, ale nie gromadzić bezterminowo pełnych historii zachowania wszystkich odwiedzających. Dla operacyjnej analizy ruchu często wystarcza retencja szczegółowych logów przez 14–30 dni, a dłuższe przechowywanie statystyk zagregowanych. Konkretny okres trzeba dopasować do celu, skali ryzyka, obowiązków bezpieczeństwa oraz polityki retencji organizacji.

Właściciel katalogu NAP powinien też zdecydować, czy chce całkowicie utrudniać masowy dostęp, czy udostępnić kontrolowane API. Przy regularnym zapotrzebowaniu partnerów API z kluczem, limitem i rejestrem wykorzystania jest łatwiejsze do nadzorowania niż ciągła walka ze scraperami. Nie rozwiązuje jednak problemu nieautoryzowanego kopiowania — część operatorów nadal wybierze publiczne strony, żeby ominąć limity lub warunki licencji.

FAQ

Czy wysoki ruch z jednego IP zawsze oznacza scraping?
Nie. Wspólny adres może należeć do biura, operatora komórkowego, uczelni albo firmowej bramy internetowej. IP powinno być jednym z sygnałów, a nie samodzielną podstawą blokady.

Jaki limit żądań ustawić na początku?
Najpierw należy policzyć 99. percentyl liczby profili otwieranych przez zwykłe sesje. Gdy wynosi on 12 profili na 10 minut, pierwszy próg obserwacyjny można ustawić na 20–25, a ograniczenie tempa na 30–40. Limit bez pomiaru ruchu będzie przypadkowy.

Czy plik robots.txt zatrzyma scraper?
Nie. Uczciwe roboty zwykle respektują zawarte w nim reguły, ale złośliwy automat może je całkowicie zignorować. robots.txt opisuje zasady indeksowania; nie jest mechanizmem kontroli dostępu.

Czy zmiana kodu HTML utrudnia kopiowanie danych NAP?
Tylko chwilowo. Zmiana nazw klas, kolejności pól lub struktury DOM może przerwać prosty parser, ale operator szybko go poprawi. Częste modyfikacje HTML utrudniają utrzymanie serwisu bardziej niż profesjonalnemu scraperowi.

Czy ukrywanie numeru telefonu za JavaScriptem wystarczy?
Nie. Przeglądarki automatyczne wykonują JavaScript i mogą odczytać dane po wyrenderowaniu strony. Rozwiązanie ograniczy najprostsze skrypty, ale nie powinno być główną warstwą ochrony.

Czy CAPTCHA jest skuteczniejsza od rate limitingu?
CAPTCHA lepiej zatrzymuje krótkie serie podejrzanych żądań, ale mocniej przeszkadza użytkownikom. Rate limiting jest mniej uciążliwy i powinien być zastosowany wcześniej. CAPTCHA ma sens dopiero po przekroczeniu wyższego progu ryzyka.

Czy można zablokować cały ruch z centrów danych?
Technicznie tak, lecz jest to ryzykowne. Z takich sieci korzystają także systemy monitorujące, narzędzia firmowe, usługi dostępności i legalne integracje. Bezpieczniej podnieść punktację ryzyka dla tego ruchu niż odrzucać go automatycznie.

Od czego zacząć wdrożenie detekcji?
Najpierw oznacz w logach wszystkie strony zawierające profile NAP i policz, ile takich stron otwiera pojedyncza sesja w ciągu 1, 10 i 60 minut. Nie zaczynaj od CAPTCHA ani blokady krajów. Pierwszym błędem do usunięcia jest brak rozróżnienia między ruchem na profilach a pozostałymi odsłonami — bez tego każdy limit będzie zgadywaniem.

Więcej informacji na: katalog NAP – https://aiqo.pl