Wykrywanie botów: listy adresów IP a podpisy kryptograficzne

Nazwa Applebot lub Googlebot w nagłówku User-Agent nie uwierzytelnia żądania HTTP. Dwie przydatne metody to porównanie adresu z informacjami opublikowanymi przez dostawcę robota oraz poprawny podpis wiadomości HTTP powiązany z zaufanym identyfikatorem agenta. Obie wymagają utrzymania; żadna automatycznie nie przyznaje dostępu.

Apple publikuje listę CIDR Applebota i opisuje kontrolę DNS. Prefiks CIDR określa zakres adresów. Po rozszerzeniu puli zapisana lista może pomijać nowe zakresy. Data źródła i ostatniej udanej aktualizacji powinny zatem znaleźć się w dzienniku weryfikacji.

Co potwierdza kontrola IP

Zgodność wiąże zaobserwowany adres źródłowy z zakresem opublikowanym dla danego robota. Cała sieć firmy hostingowej nie jest równoważną listą dozwolonych adresów. Z kolei wynajęta infrastruktura może umożliwiać weryfikację adresową, jeżeli dostawca robota publikuje odpowiednio konkretne zakresy.

Nawiązana sesja TCP utrudnia proste podszywanie się pod adres źródłowy napastnikowi spoza ścieżki komunikacji. Nie oznacza to bezwarunkowej gwarancji tożsamości: proxy zmienia widocznego partnera połączenia, infrastruktura może zostać przejęta, a HTTP/3 używa QUIC zamiast TCP. Znaczenie ma punkt sieciowy połączony z wiarygodną informacją dostawcy.

Kontrola DNS bez lokalnej listy zakresów

Reverse DNS z potwierdzeniem w przód łączy wyszukanie wsteczne, sprawdzenie nazwy hosta właściwej dla dostawcy i wyszukanie adresu tej nazwy. Sam rekord wsteczny nie wystarcza. Poniższy schemat nie przedstawia rzeczywistego wyniku zapytania DNS dla przykładowego adresu.

Zaobserwowane IP klienta: 192.0.2.10 (adres dokumentacyjny)
1. Zapytanie PTR zwraca nazwę hosta.
2. Znormalizowana nazwa kończy się dokładnie na .applebot.apple.com
   i zawiera co najmniej jedną etykietę hosta przed tym sufiksem.
3. Zapytanie A/AAAA zawiera pierwotny adres IP klienta.
4. Dopiero wtedy: weryfikacja adresu zakończona powodzeniem.

Odrzucone: fakeapplebot.apple.com
Odrzucone: host.applebot.apple.com.attacker.example
Limit czasu lub rozbieżność: brak weryfikacji.

Dozwolona domena pochodzi z dokumentacji danego robota, nie z dowolnej informacji w żądaniu. Istotne są normalizacja wielkości liter, końcowa kropka DNS i dokładne granice etykiet domeny. Pamięć podręczna DNS wymaga ograniczonej ważności; awarie i odpowiedzi negatywne wymagają jawnej reguły obsługi. Metoda eliminuje lokalną kopię CIDR, lecz nadal zależy od poprawnego i dostępnego DNS. Liczba zapytań sieciowych zależy od pamięci podręcznej i rozwiązywania nazw.

Utrzymanie i obsługa błędów

Pobieranie zakresów wymaga oficjalnego źródła HTTPS, walidacji CIDR, atomowej aktualizacji oraz monitorowania wieku listy i błędów. Pusty wynik pobrania nie powinien bez kontroli zastępować poprawnej listy. Zachowanie ostatniej poprawnej wersji również ma ograniczenia: dodane lub usunięte zakresy pozostają nieuwzględnione do aktualizacji. Dopuszczalny wiek danych jest częścią polityki dostępu.

Nieaktualna lista może blokować robota lub błędnie klasyfikować ruch. Żaden z tych skutków nie jest pewny; wpływ na indeksowanie nie musi być widoczny w ciągu jednego dnia. Nieudana weryfikacja oznacza „niezweryfikowane”, a nie „ludzkie” ani koniecznie „złośliwe”.

Co wnosi podpis

RFC 9421 definiuje podpisy wybranych składników wiadomości HTTP. Web Bot Auth dodaje odnajdywanie i wiązanie kluczy weryfikacyjnych dla ruchu automatycznego. Według stanu na 24 października 2026 odpowiedni protokół IETF pozostaje dokumentem Internet-Draft, a nie ukończonym RFC. Implementacje mogą stosować różne profile; eksperymentalna integracja Google i udokumentowana integracja Cloudflare nie są automatycznie zamienne.

Poprawna weryfikacja wiąże podpisane elementy z kluczem przypisanym do zaakceptowanego identyfikatora agenta. Samodzielnie opublikowany klucz nie dowodzi sam w sobie prawnej tożsamości firmy ani uprawnienia do odczytu chronionej treści. Zaufanie do identyfikatora i zasady dostępu pozostają osobnymi decyzjami. Kradzież klucza podważa również założenie, że podpis może utworzyć wyłącznie zamierzony agent.

Podpisy mogą zachować użyteczność po zmianie hostingu lub źródłowego IP. Rotacja i unieważnianie kluczy, ważność pamięci podręcznej, bezpieczne pobieranie kluczy i zgodna weryfikacja nadal wymagają pracy po obu stronach. Google wyraźnie zaznacza, że nie każde żądanie uczestniczących agentów jest podpisane. Sam brak podpisu nie dowodzi podszywania się.

Wybór ścieżki weryfikacji

Nie istnieje ogólna zasada nakazująca kontrolę IP przed podpisem. Kolejność zależy od dostawcy, dostępnych dowodów, opóźnienia i polityki dostępu. Wyniki warto zapisywać oddzielnie: adres zweryfikowany, podpis zweryfikowany, weryfikacja nieudana lub niedostępna oraz dostęp dozwolony lub odmówiony. Uwierzytelnienie jest jednym z elementów decyzji; limity żądań i ograniczenia treści nadal obowiązują.

Kontrola praktyczna: analiza grup ruchu GA4

Narzędzie kontroli ruchu GA4 grupuje raportowane dane według przeglądarki, systemu, kraju oraz źródła/medium sesji. Zamiast prawdopodobieństwa botów pokazuje konkretne wskazówki: brak sesji z zaangażowaniem, zerowy średni czas, brakujące wymiary lub termin automatyzacji w nazwie przeglądarki. Zmienny próg minimalny wyłącza małe grupy z tych reguł, ale ich wiersze pozostają widoczne.

Te obserwacje nie potwierdzają tożsamości robota. Kampanie, zachowanie związane ze zgodą, niepełny pomiar lub testy wewnętrzne mogą tworzyć podobne wzorce. Kraj i ruch Direct nie dowodzą automatyzacji. Eksport CSV wspiera porównanie z logami serwera lub CDN; raport nie zawiera jednak adresów IP klientów ani zweryfikowanych podpisów. Dane nie są wykluczane ani zmieniane.

Google automatycznie wyklucza znane boty i nie ujawnia ich wykluczonej liczby w GA4. Brak pasujących reguł oznacza więc tylko brak wskazań wybranych kontroli w zwróconych wierszach. Źródła: wykluczanie znanych botów przez Google i schemat Data API.