Middleware Serwera, Który Zatrzymuje Fałszywe Crawlery Zanim Dotrą Do Aplikacji

Potok żądań w aplikacji internetowej to elegancka rzecz. Żądanie przychodzi na serwer WWW, przechodzi przez stos middleware'u, dociera do kontrolera i zwraca odpowiedź. Każdy middleware w stosie ma możliwość sprawdzenia żądania, jego modyfikacji, przekazania go dalej lub odrzucenia go w całości. Ta architektura jest idealna do implementacji detekcji botów, ponieważ weryfikacja odbywa się zanim żądanie dotknie logiki aplikacji. Fałszywy crawler twierdzący, że to Googlebot, zostaje zidentyfikowany i zablokowany na poziomie middleware'u, a kontroler nigdy nie dowie się, że żądanie istniało. Nie marnuje się cykli CPU na renderowanie strony. Nie wykonuje się zapytań do bazy danych. Nie populuje się wpisy cache'u. Fałszywego bota zatrzymuje się u drzwi, a zasoby serwera, które zostałyby zużyte, są zachowane dla legytymnych odwiedzających.

Motywacja do zbudowania tego middleware'u pochodzi z konkretnego i kosztownego problemu. Duża aplikacja zużywała przepustowość i zasoby serwera w tempach, które nie korelowały z jej rzeczywistą bazą użytkowników. Dzienniki dostępu ujawniły ogromne wolumeny żądań od agentów użytkownika twierdzących, że to Googlebot, Bingbot i różne inne legalne crawlery. Śledztwo potwierdziło, że większość z nich była fałszywa, pochodząca z dostawców chmury obliczeniowej, a nie od wyszukiwarek, które tam się powoływały. Każde fałszywe żądanie zużywało te same zasoby serwera co rzeczywiste: ten sam czas wykonania PHP, te same zapytania do bazy danych, tę samą alokację pamięci, tę samą przepustowość odpowiedzi. Pomnożone przez tysiące fałszywych żądań na godzinę, koszt był znaczny. Rozwiązanie middleware'u zostało zaprojektowane, aby wyeliminować to marnotrawstwo, łapiąc fałszywe crawlery zanim zużyją jakiekolwiek zasoby aplikacji.

Implementacja podąża za prostym wzorcem, który każdy programista backendowy może się nauczyć. Middleware przechwytuje każde przychodzące żądanie, sprawdza, czy ciąg user agent pasuje do znanego wzorca crawlera wyszukiwarki, a jeśli tak, weryfikuje adres IP żądania pod względem infrastruktury crawlera za pomocą API detekcji botów. Żądania, które twierdzą, że to crawlery, ale nie przechodzą weryfikacji, są blokowane odpowiedzią 403. Żądania, które przechodzą weryfikację, lub te, które w ogóle nie twierdzą, że to crawlery, przechodzą przez stos middleware'u normalnie. Całe sprawdzenie dodaje minimalną latencję, ponieważ wyniki weryfikacji są buforowane na adres IP, co oznacza, że każdy unikatowy adres IP jest weryfikowany tylko raz.

Logika Decyzji Stojąca Za Blokowaniem Na Poziomie Middleware'u

Wybór blokowania na poziomie middleware'u zamiast na poziomie serwera WWW (Nginx lub Apache) lub na poziomie aplikacji (w kontrolerach) jest celową decyzją architektoniczną z określonymi kompromisami. Blokowanie na poziomie serwera WWW jest najbardziej efektywnym rozwiązaniem pod względem zużycia zasobów, ponieważ żądanie nigdy nie dociera do PHP. Jednak konfiguracja serwera WWW do detekcji botów zwykle obejmuje statyczne listy IP na czarnej liście lub proste dopasowanie user agent'a, z których żadne nie zapewnia dynamicznej, opartej na API weryfikacji potrzebnej do dokładnego rozróżnienia rzeczywistych crawlerów od fałszywych. Utrzymanie statycznej czarnej listy milionów adresów IP jest niepraktyczne, a samo dopasowanie user agent'a nie może weryfikować tożsamości, ponieważ user agent'y są trywialne do podrobienia.

Blokowanie na poziomie aplikacji, w kontrolerach lub klasach usług, jest najbardziej elastycznym rozwiązaniem, ale najmniej wydajnym. W momencie dotarcia żądania do kontrolera, stos middleware'u już się wykonał, trasa została rozwiązana i potencjalnie kosztowne operacje, takie jak inicjalizacja sesji i autentykacja, już się odbyły. Blokowanie w tym punkcie oszczędza czas wykonywania kontrolera, ale marnuje wszystko, co się działo przed nim. W przypadku aplikacji o dużym ruchu, gdzie fałszywe żądania botów liczą się w tysiącach na godzinę, to marnowanie przetwarzania się sumuje.

Warstwa middleware'u znajduje się w optymalnym punkcie potoku. Wykonuje się przed obsługą sesji, przed autentykacją, przed middleware'em specyficznym dla trasy i oczywiście przed logika kontrolera. Ale ma dostęp do pełnego obiektu żądania, w tym nagłówkami, adresami IP i parametrami zapytania, co oznacza, że może realizować wyrafinowaną logikę weryfikacji zamiast prostego dopasowania wzorców. Middleware może wywołać zewnętrzny API, wyniki cache'u, zastosować logikę warunkową na podstawie deklarowanej tożsamości i rejestrować wyniki weryfikacji do analizy. Ta kombinacja efektywności i elastyczności czyni middleware naturalnym domem dla detekcji botów w aplikacji internetowej.

Strategia cache'u jest szczególnie ważna dla wydajności. Bez buforowania każde żądanie od deklarowanego crawlera wymagałoby llamania API w celu weryfikacji adresu IP. Nawet przy szybkim API, dodałoby to latencję do każdego żądania. Rozwiązaniem jest buforowanie wyników weryfikacji z kluczem adresu IP i czasem wygaśnięcia kilka godzin lub nawet pełny dzień. Crawlery wyszukiwarek działają ze stabilnych zakresy IP, które rzadko się zmieniają, więc buforowany wynik weryfikacji pozostaje ważny przez wydłużone okresy. Gdy żądanie przybywa od deklarowanego Googlebot, middleware najpierw sprawdza cache. Jeśli adres IP został zweryfikowany jako legalne w okresie cache'u, żądanie jest natychmiast dozwolone. Jeśli adres IP został zweryfikowany jako fałszywy, jest natychmiast blokowany. Tylko adresy IP po raz pierwszy wymagają faktycznego wywołania API, a po tym początkowym wywołaniu, wynik jest serwowany z cache'u z znikoma latencją.

Co Się Dzieje Z Żądaniami, Które Zostają Zablokowane

Blokowanie fałszywego crawlera nie jest po prostu kwestią zwrócenia odpowiedzi 403 i ruszenia dalej. Decyzja blokowania i jej kontekst powinny być zalogowane do analizy. Każde zablokowane żądanie reprezentuje punkt danych o tym, kto próbuje uzyskać dostęp do witryny, co udaje i skąd pochodzi. Z czasem ten dziennik ujawnia wzorce, które informują szersze decyzje bezpieczeństwa. Może konkretny ASN jest odpowiedzialny za nieproporcjonalny udział fałszywych crawlerów. Może fałszywe żądania Googlebot'a osiągają szczyt w określonych porach dnia. Może konkretna ścieżka URL przyciąga więcej fałszywych crawlerów niż inne, co sugeruje, że boty celują w określoną treść.

Odpowiedź na zablokowane żądanie może być bardziej zróżnicowana niż całkowita 403. Niektóre implementacje zwracają 429 (Zbyt Wiele Żądań) aby zamaskować fakt, że bot został zidentyfikowany, utrudniając operatorowi bota dostosowanie jego podejścia. Inne zwracają 200 z pustą treścią, co marnuje minimalną przepustowość, jednocześnie uniemożliwiając botowi poznanie, że został wykryty. Bardziej agresywne podejścia zwracają 403 z wiadomością wskazującą, że weryfikacja crawlera nie powiodła się, która jest przejrzysta, ale daje operatorom botów informacje o mechanizmie detekcji. Wybór zależy od filozofii operatora witryny dotyczącej przejrzystości w stosunku do bezpieczeństwa operacyjnego.

W przypadku botów, które twierdzą, że to crawlery, ale są faktycznie legalnymi usługami, które przypadkowo używają ciągów user agent'a podobnych do wyszukiwarek, blokowanie może być bardziej destrukcyjne niż zamierzone. Na przykład niektóre narzędzia monitorowania SEO używają user agent'ów podobnych do Googlebot'a, aby symulować, jak Google widzi stronę. Te narzędzia nie przejdą weryfikacji, ponieważ to nie Google, nawet jeśli ich cel jest legalne z perspektywy operatora witryny. Middleware może to uwzględnić, utrzymując białą listę znanych zakresów IP dla zaufanych usług trzecich, lub stosując weryfikację tylko do określonych wzorców user agent'a, ignorując inne. Elastyczność podejścia middleware'u pozwala na tego rodzaju zróżnicowaną politykę bez wymagania zmian w konfiguracji serwera WWW ani kodzie aplikacji.

Weryfikacja Synchroniczna Versus Asynchroniczna

Pytanie, czy weryfikować boty synchronicznie czy asynchronicznie, wpływa zarówno na skuteczność blokowania, jak i na wpływ na wydajność aplikacji. Weryfikacja synchroniczna oznacza, że middleware wstrzymuje żądanie, wywołuje API weryfikacji, czeka na odpowiedź, a następnie albo zezwala, albo blokuje żądanie na podstawie wyniku. To podejście zapewnia natychmiastowe blokowanie, ale dodaje latencję do pierwszego żądania z każdego adresu IP. Dzięki buforowaniu latencja dotyczy tylko pierwszego żądania, ale w przypadku aplikacji o dużym ruchu nawet to okazjonalne opóźnienie może być nie do zaakceptowania.

Weryfikacja asynchroniczna podejmuje inne podejście. Pierwsze żądanie z nowego adresu IP jest dozwolone, podczas gdy zadanie weryfikacji jest umieszczane w kolejce w tle. Gdy wynik weryfikacji powraca, jest buforowany, a wszystkie kolejne żądania z tego adresu IP są obsługiwane zgodnie z wynikiem. To podejście dodaje zero latencji do potoku żądań, ale pozwala na małą liczbę początkowych żądań od fałszywych botów przed blokowaniem. W przypadku większości aplikacji ten kompromis jest akceptowalny. Fałszywy bot, który wysyła trzy żądania zanim zostanie zablokowany, zużył znacznie mniej zasobów niż ten, który wysyła tysiące żądań bez przeszkód.

System kolejkowania czyni podejście asynchroniczne prostym. Middleware wysyła zadanie weryfikacji, które wywołuje API detekcji botów, przechowuje wynik w cache'u i opcjonalnie aktywuje zdarzenie, na które inne części aplikacji mogą słuchać. Zadanie wykonuje się w sekundach, co oznacza, że okno, w którym niezweryfikowany ruch botów może przejść, jest niezwykle wąskie. W przypadku aplikacji korzystających z szybkiego cache'u w pamięci, buforowany wynik jest natychmiast dostępny dla wszystkich instancji aplikacji, więc nawet w środowisku z równoważeniem obciążenia weryfikacja musi się odbyć tylko raz na adres IP na wszystkich serwerach.

Hybrydowe podejście łączy to, co najlepsze z obu stron. Znane user agent'y botów, które pasują do wzorców o wysokim zaufaniu, aktywują synchroniczną weryfikację z wynikami cache'u, dodając minimalną latencję. Wzorce o niższym zaufaniu aktywują asynchroniczną weryfikację, zezwalając na pierwsze żądanie, podczas gdy weryfikacja działa w tle. To podejście warstwowe optymalizuje dla powszechnego przypadku, jednocześnie obsługując przypadki graniczne w sposób elegancki. Pozycja middleware'u w potoku żądań czyni go idealnym miejscem do implementacji tej logiki, ponieważ ma dostęp do wszystkich informacji potrzebnych do podjęcia decyzji dotyczącej routingu i wykonuje się przed jakąkolwiek kosztowną logiką aplikacji.

Mierzalny Wpływ Blokowania U Drzwi

Wyniki implementacji middleware'u detekcji botów są widoczne prawie natychmiast w metrykach serwera. Najbardziej dramatyczna zmiana jest w zużyciu przepustowości. Fałszywe crawlery żądają kompletnych stron HTML, w tym wszystkich zasobów, do których się odwołują w odpowiedzi. Każde zablokowane żądanie oszczędza przepustowość, która byłaby użyta do transmisji pełnej odpowiedzi, która w przypadku stron bogatych w zawartość może wynosić dziesiątki lub setki kilobajtów na żądanie. Przez tysiące zablokowanych żądań na godzinę oszczędności przepustowości gromadzą się w znaczne redukcje kosztów, szczególnie w przypadku aplikacji hostowanych u dostawców, którzy pobierają opłaty za gigabajt transferu.

Wykorzystanie CPU spada, ponieważ serwer nie wykonuje już kodu PHP, nie uruchamia zapytań do bazy danych i nie renderuje szablonów dla żądań, które nie przynoszą żadnej wartości. Zmniejszenie jest najbardziej zauważalne w godzinach poza szczytem, gdy ruch człowieka jest niski, ale ruch botów pozostaje stały. Przed implementacją middleware'u serwer utrzymywał podstawowe wykorzystanie CPU nawet o trzeciej rano, ponieważ boty nie śpią. Po implementacji wykorzystanie poza szczytem spada do bliska zera, dając serwerowi przestrzeń dla legytymnego ruchu w godzinach szczytu.

Czasy odpowiedzi dla legytymnych odwiedzających poprawiają się w wyniku bezpośredniej redukcji obciążenia serwera. Serwer WWW obsługujący pięćset żądań na sekundę, z czego trzysta to fałszywe boty, ma mniej zdolności dostępnych dla dwustu rzeczywistych odwiedzających niż serwer obsługujący tylko dwieście żądań na sekundę, z których wszystkie są legalne. Middleware nie tylko oszczędza zasoby na zablokowanych żądaniach. Poprawia jakość usługi dla każdego żądania, które przechodzi, ponieważ serwer ma więcej zdolności dostępnych dla rzeczywistej pracy.

Obciążenie bazy danych zmniejsza się proporcjonalnie. Jeśli aplikacja wysyła zapytanie do bazy danych dla każdego żądania strony, blokowanie trzystu fałszywych żądań na sekundę eliminuje trzysta niepotrzebnych zapytań do bazy danych na sekundę. W przypadku aplikacji ze złożonymi zapytaniami lub ograniczonymi połączeniami do bazy danych ta redukcja może być różnicą między stabilną operacją a okresowym przeciążeniem. Middleware chroni cały stos, od serwera WWW przez warstwę aplikacji do bazy danych, zatrzymując niechciany ruch zanim dotrze do któregokolwiek z nich.