Serverski Middleware Koji Zaustavlja Lažne Web Crawlere Pre Nego Što Dostignu Vašu Aplikaciju

Tok zahteva u veb aplikaciji je elegantna stvar. Zahtev stigne na veb server, prolazi kroz stack middleware-a, dostiže kontroler i vraća odgovor. Svaki middleware u stacku ima mogućnost da pregleda zahtev, izmeni ga, prosleđuje ga dalje ili ga odbije u potpunosti. Ova arhitektura je idealna za implementaciju detekcije botova jer se verifikacija dešava pre nego što zahtev dotakne bilo koju logiku aplikacije. Lažan crawler koji se predstavlja kao Googlebot biva identifikovan i blokiran u middleware sloju, a kontroler čak ne zna da je zahtev postojao. Nema rasipanja CPU ciklusa na renderovanje stranice. Nema upita bazi podataka. Nema popunjavanja keš stavki. Lažan bot je zaustavljen na vratima, a serverski resursi koji bi bili potrošeni su čuvani za legitimne posjetioce.

Motivacija za gradnju ovog middleware-a potekla je iz konkretnog i skupog problema. Velika aplikacija je trošila bandwidth i serverske resurse po stopama koje nisu korelirale sa njenom stvarnom bazom korisnika. Pristupni logovi su pokazali ogromne količine zahteva od user agenata koji se predstavljaju kao Googlebot, Bingbot i razni drugi legitimni crawleri. Istraga je potvrdila da je većina njih bila lažna, potiču iz cloud hosting provajdera umesto iz search engine-a koje su predstavljale. Svaki lažan zahtev je konzumirao iste serverske resurse kao pravi: isto PHP vrijeme izvršavanja, iste baze podataka upite, istu alokaciju memorije, istu bandwidth za odgovor. Množeno sa hiljade lažnih zahteva po satu, trošak je bio ozbiljan. Middleware rješenje je osmišljeno da eliminiše ovo rasipanje hvatanjem lažnih crawlera pre nego što konzumiraju bilo kakve resurse aplikacije.

Implementacija slijedi jednostavan obrazac koji svaki backend developer može da prilagodi. Middleware presreće svaki dolazni zahtev, provjerava da li string user agenta odgovara poznatom obrascu search engine crawlera, i ako je tako, verifikuje IP adresu zahteva protiv poznatih infrastruktura crawlera koristeći API za detekciju botova. Zahtevi koji se predstavljaju kao crawleri ali ne uspijevaju verifikaciju su blokirani sa 403 odgovorom. Zahtevi koji prolaze verifikaciju, ili koji se uopšte ne predstavljaju kao crawleri, nastavljaju kroz middleware stack normalno. Cijela provjera dodaje minimalnu latenciju jer su rezultati verifikacije keširani po IP adresi, što znači da je svaka jedinstvena IP adresa verificirana samo jednom.

Logika Odluke Iza Blokiranja na Middleware Sloju

Odabir da se blokira na middleware sloju umjesto na veb server nivou (Nginx ili Apache) ili na nivou aplikacije (u kontrolerima) je namjerna arhitektonska odluka sa specifičnim kompromisima. Blokiranje na veb server nivou je najefikasnija opcija u smislu potrošnje resursa jer zahtev nikad ne dostiže PHP. Međutim, konfiguracija veb servera za detekciju botova obično uključuje statične blacklist IP adrese ili jednostavno podudaranje user agenta, ni jedno od čega ne pruža dinamičku, API-vođenu verifikaciju potrebnu za točnu razliku između prvih crawlera i lažnjaka. Održavanje statičke blacklist-e miliona IP adresa je nepraktično, a samom user agentu se jednostavno može falsificirati.

Blokiranje na nivou aplikacije, unutar kontrolera ili service klasa, je najfleksibilnija opcija ali najmanje efikasna. Do vremena kada zahtev dospeva do kontrolera, middleware stack se već izvršio, ruta je razrešena i potencijalno skupo operacije kao inicijalizacija sesije i autentifikacija su već se desile. Blokiranje u ovoj točki štedu vrijeme izvršavanja kontrolera ali rasipa sve što se desilo prije toga. Za high-traffic aplikacije gdje fake bot zahtevi broje hiljade po satu, ovo rasipanje preprocessing-a se sabire.

Middleware sloj sjedí u optimalnoj točki u pipeline-u. Izvršava se pre rukovanja sesijom, pre autentifikacije, pre middleware-a specifičnog za rutu, i sigurno pre bilo koje logike kontrolera. Ali ima pristup kompletnom objektu zahteva, uključujući zaglavlje, IP adrese i query parametre, što znači da može izvoditi sofisticiraniju logiku verifikacije umjesto jednostavnog podudaranja uzorka. Middleware može pozvati eksterni API, keširanu rezultate, primijeniti uslovna logika na osnovu tvrdnje identiteta i zabilježiti rezultate verifikacije za analizu. Ova kombinacija efikasnosti i fleksibilnosti čini middleware prirodnim domom za detekciju botova u veb aplikaciji.

Strategija keša je posebno važna za performanse. Bez keširanja, svaki zahtev od tvrdnjskog crawlera bi zahtijevao API poziv da verifikuje IP adresu. Čak i sa brzim API-jem, ovo bi dodalo latenciju svakom zahtjevu. Rješenje je keširati rezultate verifikacije ključane po IP adresi, sa time-to-live od nekoliko sati ili čak cijelog dana. Search engine crawleri rade iz stabilnih IP raspona koji se rijetko mijenjaju, tako da keširani rezultat verifikacije ostaje validan za produžene periode. Kada zahtev stigne od tvrdnjskog Googlebot-a, middleware prvo provjerava keš. Ako je IP bio verifikovan kao legitiman unutar perioda keša, zahtev je dozvoljen odmah. Ako je IP bio verifikovan kao lažan, blokiran je odmah. Samo prve IP adrese zahtijevaju pravi API poziv, a nakon toga, rezultat se poslužuje iz keša sa zanemarljivim latenciskim troškom.

Šta Se Dešava Sa Zahtjevima Koji Budu Blokirani

Blokiranje lažnog crawlera nije jednostavno pitanje vraćanja 403 odgovora i nastavka. Odluka o blokiranju i njen kontekst bi trebali biti zabilježeni za analizu. Svaki blokirani zahtev predstavlja podatnu točku o tome ko pokušava pristupiti mjestu, šta se predstavlja kao, i odakle dolazi. Tokom vremena, ova logika otkriva obrasce koji informiraju šire sigurnosne odluke. Možda specifican ASN je odgovoran za nerazmjernu amortizaciju lažnih crawlera. Možda lažni Googlebot zahtevi prikupljaju se u određenim vremenima dana. Možda specifičan URL putanja privlači više lažnih crawlera od ostalih, sugerirajući da botovi ciljaju specifičan sadržaj.

Odgovor na blokirani zahtev može biti i nuanciraniji od nepristojnog 403. Neki primjeri vraćaju 429 (Previše Zahtjeva) da bi sakrili činjenicu da je bot identifikovan, čineći teže za bot operatoru da prilagodi svoj pristup. Ostali vraćaju 200 sa praznom tijelom, što rasipa minimalnu bandwidth dok se sprečava bot od znanja da je otkrivena. Agresivniji pristupi vraćaju 403 sa porukom pokazujući da je verifikacija crawlera neuspješna, što je transparentno ali daje bot operatorima informacije o mehanizmu detekcije. Odabir zavisi od filozofije operatora mjesta o transparentnosti nasuprot operativnoj sigurnosti.

Za botove koji se predstavljaju kao crawleri ali su zapravo legitimne usluge koje jednostavno koriste search engine user agenate neispravno, blokiranje može biti disruptivnije nego namjerno. Neki SEO monitoring alati, na primjer, koriste Googlebot-like user agenate da simuliraju kako Google vidi stranicu. Ovi alati će neuspješnu verifikaciju jer nisu Google, čak iako je njihova namjera legitimna iz perspektive operatora mjesta. Middleware može da to akomodira održavanjem whitelist-e poznatih IP raspona za pouzdane treće-party usluge, ili primjenom verifikacije samo na specifične user agenate uzorke dok ignoriše druge. Fleksibilnost middleware pristupa dozvoljava ovu vrstu nuancirane politike bez zahtijevanja promjena u konfiguraciji veb servera ili u kodu aplikacije.

Sinhronog Nasuprot Asinhronog Verifikovanja

Pitanje da li verifikuvati botove sinhronog ili asinhronog utiče kako na efektivnost blokiranja tako i na uticaj performansi na aplikaciju. Sinhronizovana verifikacija znači da middleware pauzira zahtjev, poziva verifikacijski API, čeka odgovor, i zatim dozvoljava ili blokira zahtjev na osnovu rezultata. Ovaj pristup daje trenutno blokiranje ali dodaje latenciju prvom zahtjevu od svake IP adrese. Sa keširanjem, latencija samo utiče na prvi zahtjev, ali za high-traffic aplikacije čak i taj povremeni zadržaj može biti neprihvatljiv.

Asinkrona verifikacija poduzima drugačiji pristup. Prvi zahtjev od nove IP adrese je dozvoljen kroz dok se verifikacijski posao stavlja u red čekanja. Kada se rezultat verifikacije vrati, on je keširuvan, i svi kasniji zahtjevi od tog IP-a se rukuju prema rezultatu. Ovaj pristup dodaje nula latencije zahtjevu pipeline-u ali dozvoljava mali broj inicijalnih zahtjeva od lažnih botova da prođe kroz pre nego što se verifikacija završi. Za većinu aplikacija, ovaj kompromis je prihvatljiv. Lažan bot koji pošalje tri zahtjeva pre nego što bude blokiran je konzumirao mnogo manje resursa od onog koji pošalje hiljade zahtjeva neozbiljan.

Red čekanja sistem čini asinkroni pristup jednostavnim. Middleware dispečira verifikacijski posao koji poziva API za detekciju botova, pohranjuje rezultat u keš, i opcionalno pokida događaj koji druge dijelove aplikacije mogu slušati. Posao se izvršava u sekundama, što znači da je prozor tijekom kojega neverifikovani bot saobraćaj može proći je ekstremno uzan. Za aplikacije koje koriste brzi in-memory keš, keširani rezultat je dostupan svim instancama aplikacije odmah, tako da čak i u load-balanced okruženju, verifikacija se trebala desiti samo jednom po IP adresi na svim serverima.

Hibridni pristup kombinuje najbolje od oba. Poznati bot user agenti koji odgovaraju visoko-pouzdanim obrascima triggeruju sinhronizovanu verifikaciju sa keširanim rezultatima, dodajući minimalnu latenciju. Nižu-pouzdane obrasce triggeru asinkroni verifikaciji, dozvoljavajući prvi zahtjev kroz dok se verifikacija dešava u pozadini. Ovaj slojeviti pristup optimizuje za čest slučaj dok rukuje granični slučajeve glatko. Pozicija middleware-a u zahtjevu pipeline-u čini ga idealnim mjestom za implementaciju ove logike, jer ima pristup svim informacijama potrebnim da se donese odluka rutiranja i izvršava pre bilo koje skupo logike aplikacije.

Mjerljiv Uticaj Blokiranja na Vratima

Rezultati implementacije bot detection middleware-a su vidljivi gotovo odmah u serverskim metrikama. Najdramatičnija promjena je u bandwidth konzumaciji. Lažni crawleri traže kompletan HTML stranice, uključujući sve sredstva koja se referenciraju u odgovoru. Svaki blokirani zahtjev štedi bandwidth koji bi bio korišten za prenošenje cijelog odgovora, koji za sadržaj-teške stranice može biti deseci ili stotine kilobajtova po zahtjevu. Preko hiljade blokiranih zahtjeva po satu, uštede u bandwidth akumuliraju se u smislene smanjenja troškova, posebno za aplikacije hostovane na provajderima koji naplaćuju po gigabajtu prijenosa.

CPU iskorišćenost pada jer server više ne izvršava PHP kod, ne trenira upite bazi podataka i ne renderuje template-e za zahtjeve koji proizvode nikakvu vrijednost. Smanjenje je najvidljivo tokom off-peak sati kada je saobraćaj čovjeka mali ali bot saobraćaj ostaje konstantan. Pre nego što se middleware implementira, server je održavao baseline CPU iskorišćenost čak i u tri ujutro jer botovi ne spavaju. Nakon implementacije, off-peak iskorišćenost pada blizu nule, dajući serveru prostor za legitiman saobraćaj tokom peak sati.

Vremenske izmjene za legitimne posjetioce se poboljšavaju kao direktna posljedica smanjenja opterećenja servera. Veb server koji rukuje pet stotina zahtjeva po sekundi, tri stotine od kojih su lažni botovi, ima manju kapacitetu dostupnu za dvije stotine stvarnih posjetilaca nego server koji rukuje samo dvije stotine zahtjeva po sekundi, svi od kojih su legitimni. Middleware ne samo štedi resurse na blokiranim zahtjevima. Poboljšava kvalitetu usluge za svaki zahtjev koji prolazi, jer server ima više kapaciteta dostupnog za stvarni rad.

Opterećenje baze podataka se smanjuje proporcionalno. Ako aplikacija upituje bazu podataka za svaki zahtjev stranice, blokiranje tri stotine lažnih zahtjeva po sekundi eliminiše tri stotine nepotrebnih upita bazi podataka po sekundi. Za aplikacije sa kompleksnim upitima ili ograničenim konekcijama baze podataka, ovo smanjenje može biti razlika između stabilne operacije i periodičnog preopterećenja. Middleware štiti čitav stack, od veb servera kroz aplikacijski sloj do baze podataka, zaustavljajući neželjeni saobraćaj pre nego što dosegne bilo koji od njih.