En servermiddleware som stoppar falska crawlers innan de når din applikation

Förfråganpipelinen i en webbapplikation är en elegant sak. En förfrågan anländer till webbservern, passerar genom en stack av middleware, når en controller och returnerar ett svar. Varje middleware i stacken har möjligheten att inspektera förfrågan, modifiera den, skicka den vidare eller avvisa den helt. Denna arkitektur är perfekt för att implementera botdetektion eftersom verifieringen sker innan förfrågan berör någon applikationslogik. En falsk crawler som påstår sig vara Googlebot identifieras och blockeras i middlewarelayern, och controllern vet inte ens att förfrågan existerade. Ingen CPU-cykler slösas bort på sidrendering. Inga databasfrågor körs. Inga cacheposter fylls. Den falska boten stoppas vid dörren, och de serverresurser som skulle ha förbrukats sparas för legitima besökare.

Motiveringen för att bygga denna middleware kom från ett konkret och dyrt problem. En stor applikation förbrukade bandbredd och serverresurser i takt som inte motsvarade hennes faktiska användarbas. Åtkomstloggarna visade massiva mängder förfrågningar från användaragenter som påstod sig vara Googlebot, Bingbot och olika andra legitima crawlers. Utredning bekräftade att majoriteten av dessa var falska, som härrörde från molnhotellsleverantörer snarare än de sökmotorer de påstod sig representera. Varje falsk förfrågan förbrukade samma serverresurser som en riktig: samma PHP-körningstid, samma databasfrågor, samma minnesallokering, samma bandbredd för svaret. Multiplicerat över tusentals falska förfrågningar per timme var kostnaden betydande. Middlewarelösningen utformades för att eliminera detta slöse genom att fånga falska crawlers innan de förbrukade några applikationsresurser överhuvudtaget.

Implementeringen följer ett enkelt mönster som alla backend-utvecklare kan anpassa. Middlewaren avlyssnar varje inkommande förfrågan, kontrollerar om användaragentsträngen matchar ett känt sökmotorscrawlermönster, och om så är fallet, verifierar förfrågan IP-adress mot crawlerns kända infrastruktur med hjälp av botdetekterings-API:et. Förfrågningar som påstår sig vara crawlers men misslyckas verifiering blockeras med ett 403-svar. Förfrågningar som passerar verifiering, eller som inte påstår sig vara crawlers överhuvudtaget, fortsätter genom middlewarestacken normalt. Hela kontrollen lägger till minimal latens eftersom verifieringsresultaten cachelagras per IP-adress, vilket betyder att varje unik IP verifieras endast en gång.

Beslötslogiken bakom blockering vid middlewarelayern

Valet att blockera vid middlewarelayern snarare än på webbservernivå (Nginx eller Apache) eller på applikationsnivå (inom controllers) är ett avsiktligt arkitekturval med specifika kompromisser. Blockering på webbservernivå är det mest effektiva alternativet när det gäller resursförbrukning eftersom förfrågan aldrig når PHP överhuvudtaget. Webbserverkonfiguration för botdetektion involverar dock vanligtvis statiska IP-svartlistor eller enkel användaragentmatchning, varav ingen ger den dynamiska, API-driven verifiering som krävs för att noggrant skilja riktiga crawlers från falska. Att underhålla en statisk svartlista över miljontals IP-adresser är opraktisk, och användaragentmatchning ensam kan inte verifiera identitet eftersom användaragenter är trivialt förfalskningsbara.

Blockering på applikationsnivå, inom controllers eller serviceklasser, är det mest flexibla alternativet men det minst effektiva. Då förfrågan når en controller har middlewarestacken redan körts, rutten har lösts, och potentiellt dyra operationer som sessioninitialisering och autentisering har redan skett. Blockering vid denna tidpunkt sparar controllerkörningstiden men slösar på allt som hände före det. För högtrafik-applikationer där falska botförfrågningar räknas i tusentals per timme, denna slösade förbearbetning ökar.

Middlewarelayern sitter på den optimala punkten i pipelinen. Det körs före sessionhantering, före autentisering, före rutspecifik middleware och säkerligen före någon kontrollerlogik. Men det har åtkomst till det fullständiga förfrågobjektet, inklusive headers, IP-adresser och frågeparametrar, vilket betyder att det kan utföra sofistikerad verifieringslogik snarare än enkelmatchning. Middlewaren kan ringa ett externt API, cacheresultat, tillämpa villkorslogik baserat på det påstådda identiteten, och logga verifieringsresultat för analys. Denna kombination av effektivitet och flexibilitet gör middleware till det naturliga hemmet för botdetektion i en webbapplikation.

Cachestrategin är särskilt viktig för prestanda. Utan caching skulle varje förfrågan från en påstått crawler kräva ett API-anrop för att verifiera IP-adressen. Även med ett snabbt API skulle detta lägga till latens till varje förfrågan. Lösningen är att cacheresultaten verifieras nycklat av IP-adress, med en tid-till-live på flera timmar eller till och med en hel dag. Sökmotorcrawlers fungerar från stabila IP-intervall som förändras sällan, så ett cacheresultat från verifiering förblir giltigt under längre perioder. Då en förfrågan ankommer från en påstått Googlebot, kontrollerar middlewaren först cachen. Om IP-adressen verifierades som legitim inom cachperioden, tillåts förfrågan igenom omedelbar. Om IP-adressen verifierades som falsk blockeras den omedelbar. Endast första gångens IP-adresser kräver ett faktiskt API-anrop, och efter det inledande anropet serveras resultatet från cache vid försumbar latenskostnad.

Vad händer med de förfrågningar som blockeras

Att blockera en falsk crawler är inte helt enkelt att returnera ett 403-svar och gå vidare. Blockerbeslötet och dess sammanhang bör loggas för analys. Varje blockerad förfrågan representerar en datapunkt om vem som försöker få åtkomst till webbplatsen, vad de påstår sig vara, och var de kommer ifrån. Over tid avslöjar denna logg mönster som informerar bredare säkerhetsbeslut. Kanske är en specifik ASN ansvarig för en oproportionerlig andel av falska crawlers. Kanske ökar falska Googlebot-förfrågningar vid vissa tidpunkter på dagen. Kanske lockar en viss URL-väg mer falska crawlers än andra, vilket föreslår att botar är inriktade på specifikt innehål.

Svaret på en blockerad förfrågan kan också vara mer nyanserad än ett blankt 403. Några implementationer returnerar en 429 (För många förfrågningar) för att dölja det faktum att boten har identifierats, vilket gör det svårare för botoperatören att justera sitt tillvagagångssätt. Andra returnerar en 200 med en tom kropp, vilket slösar minimal bandbredd samtidigt som det förhindrar boten från att veta att den har upptäckts. Mer aggressiva tillvagagångssätt returnerar en 403 med ett meddelande som indikerar att crawlerverifiering misslyckades, vilket är transparent men ger botoperatörer information om detektionsmekanismen. Valet beror på webbplatsoperatörens filosofi om transparens kontra operativ säkerhet.

För botar som påstår sig vara crawlers men faktiskt är legitima tjänster som av misstag använder sökmotorcrawleruseragentstrings, kan blockeringen vara mer störande än avsiktlig. Vissa SEO-övervakningsverktyg, till exempel, använder Googlebot-liknande useragents för att simulera hur Google ser en sida. Dessa verktyg misslyckas verifiering eftersom de inte är Google, även om deras syfte är legitimt från webbplatsoperatörens perspektiv. Middlewaren kan anpassa detta genom att upprätthålla en vitlista över kända IP-intervall för betrodda tredjepartsservices, eller genom att tillämpa verifiering endast på specifika useragentmönster medan andra ignoreras. Flexibiliteten i middlewareapproachen möjliggör denna typ av nyanserad policy utan att kräva ändringar i webbserverkonfigurationen eller applikationskoden.

Synkron kontra asynkron verifiering

Frågan om huruvida man ska verifiera botar synkront eller asynkront påverkar både effektiviteten för blockeringen och prestandapåverkan på applikationen. Synkron verifiering betyder att middlewaren pausar förfrågan, anropar verifierings-API:et, väntar på svaret, och sedan antingen tillåter eller blockerar förfrågan baserat på resultatet. Denna metod ger omedelbar blockering men lägger till latens till den första förfrågan från varje IP-adress. Med caching påverkar latensen endast den första förfrågan, men för högtrafik-applikationer kan även denna enstaka fördröjning vara oacceptabel.

Asynkron verifiering tar ett annat tillvagagångssätt. Den första förfrågan från en ny IP tillåts igenom medan ett verifieringsjobb köas i bakgrunden. Då verifieringsresultatet kommer tillbaka cachelagras det, och alla efterföljande förfrågningar från denna IP hanteras enligt resultatet. Denna metod lägger noll latens till förfråganpipelinen men tillåter ett litet antal initiala förfrågningar från falska botar att passera igenom innan verifieringen slutförs. För de flesta applikationer är denna kompromiss acceptabel. En falsk bot som skickar tre förfrågningar innan den blockeras har förbrukat långt färre resurser än en som skickar tusentals oövervaakade förfrågningar.

Kösystemet gör det asynkrona tillvagagångssättet enkelt. Middlewaren skickar ett verifieringsjobb som anropar botdetekterings-API:et, lagrar resultatet i cachen, och valfritt utlöser en händelse som andra delar av applikationen kan lyssna på. Jobbet körs på några sekunder, vilket betyder att fönstret under vilket overifierad bottrafik kan passera igenom är extremt snävt. För applikationer som använder ett snabbt minne i cache, är det cachade resultatet tillgängligt för alla applikationsinstanser omedelbar, så även i en lastbalancerad miljö, behöver verifieringen endast ske en gång per IP-adress över alla servrar.

En hybridmetod kombinerar det bästa från båda. Kända bottyperagenter som matchar höga konfidensmönster utlöser synkron verifiering med cacheresultat, vilket lägger till minimal latens. Lägre konfidensmönster utlöser asynkron verifiering, vilket tillåter den första förfrågan igenom medan verifiering körs i bakgrunden. Denna nivåindelad metod optimerar för det vanliga fallet medan kantfall hanteras graciöst. Middlewarens position i förfråganpipelinen gör det till det ideala stället för att implementera denna logik, eftersom det har åtkomst till all information som behövs för att fatta routingbeslötet och körs före någon dyr applikationslogik.

Den mätbara påverkan av blockering vid dörren

Resultaten av att implementera botdetektionsmiddleware är synliga nästan omedelbar i servermätvärden. Den mest dramatiska förändringen är i bandbreddförbrukning. Falska crawlers begär fullständiga HTML-sidor, inklusive alla tillgångar som refereras i svaret. Varje blockerad förfrågan sparar bandbredden som skulle ha använts för att överföra det fullständiga svaret, vilket för innehållsrika sidor kan vara tiotals eller hundratals kilobyte per förfrågan. Över tusentals blockerade förfrågningar per timme, bandbreddsbesparingarna samlas till meningsfulla kostnadsreduktioner, särskilt för applikationer som är värdade på leverantörer som debiterar per gigabyte överföring.

CPU-användningen sjunker eftersom servern inte längre exekverar PHP-kod, kör databasfrågor och renderar mallar för förfrågningar som producerar inget värde. Minskningen är mest märkbar under lågtrafik-timmar när mänsklig trafik är låg men bottrafik förblir konstant. Före implementering av middlewaren, upprätthöll servern en baslinje-CPU-användning även klockan tre på morgonen eftersom botar inte sover. Efter implementering sjunker lågtrafik-användningen till nästan noll, vilket ger servern handlingsutrymme för legitim trafik under topptimmar.

Svarstiderna för legitima besökare förbättras som en direkt följd av minskad serverbelastning. En webbserver som hanterar fem hundra förfrågningar per sekund, trehundra av vilka är falska botar, har mindre kapacitet tillgänglig för de två hundra verkliga besökare än en server som hanterar bara två hundra förfrågningar per sekund, alla av vilka är legitima. Middlewaren sparar bara inte resurser på de blockerade förfrågningarna. Det förbättrar servicekvaliteten för varje förfrågan som passerar igenom, eftersom servern har mer kapacitet tillgänglig för verkligt arbete.

Databasbelastningen minskar proportionellt. Om applikationen frågar databasen för varje sidförfrågan, eliminerar blockering av tre hundra falska förfrågningar per sekund tre hundra onödiga databasfrågor per sekund. För applikationer med komplexa frågor eller begränsade databasanslutningar kan denna minskning vara skillnaden mellan stabil drift och periodisk överbelastning. Middlewaren skyddar hela stacken, från webbservern genom applikationslayern till databasen, genom att stoppa oönskad trafik innan den når någon av dem.