Een servermiddleware die valse crawlers stopt voordat ze uw toepassing bereiken

De aanvraagpijplijn in een webtoepassing is een elegant systeem. Een aanvraag arriveert bij de webserver, gaat door een stack van middleware, bereikt een controller en retourneert een respons. Elke middleware in de stack heeft de mogelijkheid om de aanvraag te inspecteren, aan te passen, door te geven of volledig af te wijzen. Deze architectuur is perfect voor het implementeren van botdetectie, omdat de verificatie plaatsvindt voordat de aanvraag enige toepassingslogica aanraakt. Een valse crawler die zich voordoet als Googlebot wordt in de middleware-laag geïdentificeerd en geblokkeerd, en de controller weet niet eens dat de aanvraag bestond. Geen CPU-cycli verspild aan het renderen van een pagina. Geen databasequery's uitgevoerd. Geen cache-items opgeslagen. De valse bot wordt tegen de deur tegengehouden, en de serverresources die zouden zijn verbruikt, blijven behouden voor legitieme bezoekers.

De motivatie voor het bouwen van deze middleware kwam voort uit een concreet en kostbaar probleem. Een grote toepassing consumeerde bandbreedte en serverresources in hoeveelheden die niet overeenkwamen met de werkelijke gebruikersbasis. De toegangslogboeken toonden enorme hoeveelheden aanvragen van user agents die zich voordoen als Googlebot, Bingbot en verschillende andere legitieme crawlers. Onderzoek bevestigde dat de meerderheid daarvan valse waren, afkomstig van cloudhosting-providers in plaats van de zoekmachines waarvan zij beweerden af te stammen. Elke valse aanvraag verbruikte dezelfde serverresources als een echte: dezelfde PHP-uitvoeringstijd, dezelfde databasequery's, dezelfde geheugentoewijzing, dezelfde bandbreedte voor de respons. Vermenigvuldigd over duizenden valse aanvragen per uur, was de kostprijs substantieel. De middleware-oplossing was ontworpen om deze verspilling uit te elimineren door valse crawlers op te vangen voordat zij enige toepassingsresources zouden verbruiken.

De implementatie volgt een eenvoudig patroon dat elke backend-ontwikkelaar kan aanpassen. De middleware onderschept elke inkomende aanvraag, controleert of de user agent-string overeenkomt met een patroon van een bekende zoekmachinecrawler, en als dit het geval is, verifieert de middleware het IP-adres van de aanvraag tegen de bekende infrastructuur van de crawler met behulp van de botdetectie-API. Aanvragen die zich voordoen als crawlers maar verificatie niet doorstaan, worden geblokkeerd met een 403-respons. Aanvragen die verificatie doorstaan, of die zich niet voordoen als crawlers, gaan normaal door de middleware-stack. De gehele controle voegt minimale latentie toe, omdat de verificatieresultaten per IP-adres in cache zijn opgeslagen, wat betekent dat elk uniek IP slechts eenmaal wordt geverifieerd.

De beslissingslogica achter blokkering op de middleware-laag

Het kiezen om op de middleware-laag in plaats van op webserver-niveau (Nginx of Apache) of op toepassingsniveau (binnen controllers) te blokkeren, is een doelbewuste architectuurkeuze met specifieke afwegingen. Blokkering op webserver-niveau is de meest efficiënte optie in termen van resourceverbruik, omdat de aanvraag PHP helemaal niet bereikt. Webserver-configuratie voor botdetectie omvat echter meestal statische IP-blacklists of eenvoudige user agent-overeenkomsten, waarvan geen enkele de dynamische, API-gestuurde verificatie biedt die nodig is om echte crawlers nauwkeurig van neppe's te onderscheiden. Het onderhouden van een statische blacklist van miljoenen IP-adressen is onpraktisch, en user agent-matching alleen kan identiteit niet verifiëren omdat user agents triviale te vervalsen zijn.

Blokkering op toepassingsniveau, binnen controllers of serviceklassen, is de meest flexibele optie maar de minst efficiënte. Op het moment dat de aanvraag een controller bereikt, is de middleware-stack al uitgevoerd, is de route al opgelost, en zijn mogelijk dure bewerkingen zoals sessie-initialisatie en verificatie al voorbij. Blokkering op dit moment bespaart uitvoeringstijd van de controller maar verspilt alles wat ervoor gebeurde. Voor high-traffic-toepassingen waarbij valse bot-aanvragen duizenden per uur bedragen, tellen deze verspilde voorbewerkingen op.

De middleware-laag zit op het optimale punt in de pijplijn. Het voert zich uit voordat sessieafhandeling, voordat verificatie, voordat middleware voor specifieke routes, en zeker voordat enige controller-logica. Maar het heeft toegang tot het volledige aanvraagobject, inclusief headers, IP-adressen en queryparameters, wat betekent dat het geavanceerde verificatielogica kan uitvoeren in plaats van eenvoudige patroonovereenkomsten. De middleware kan een externe API aanroepen, resultaten in cache opslaan, voorwaardelijke logica toepassen op basis van de geclaimde identiteit, en verificatieresultaten loggen voor analyse. Deze combinatie van efficiëntie en flexibiliteit maakt middleware tot het natuurlijke thuis voor botdetectie in een webtoepassing.

De cache-strategie is vooral belangrijk voor prestaties. Zonder caching zou elke aanvraag van een geclaimde crawler een API-aanroep vereisen om het IP-adres te verifiëren. Zelfs met een snelle API zou dit latentie aan elke aanvraag toevoegen. De oplossing is het cachen van verificatieresultaten op basis van IP-adres, met een time-to-live van enkele uren of zelfs een volledige dag. Zoekmachinecrawlers werken vanuit stabiele IP-bereiken die zelden veranderen, dus een in-cache-verificatieresultaat blijft voor langere periodes geldig. Wanneer een aanvraag van een geclaimde Googlebot aankomt, controleert de middleware eerst de cache. Als het IP als legitiem is geverifieerd binnen de cache-periode, wordt de aanvraag onmiddellijk doorgelaten. Als het IP als valse is geverifieerd, wordt het onmiddellijk geblokkeerd. Alleen IP-adressen voor het eerst vereisen een werkelijke API-aanroep, en daarna wordt het resultaat uit cache geserveerd tegen verwaarloosbare latentiekosten.

Wat gebeurt er met de aanvragen die worden geblokkeerd

Het blokkeren van een valse crawler is niet eenvoudigweg een zaak van het retourneren van een 403-respons en verdergaan. De blokkebeslissing en de context ervan moeten voor analyse worden geregistreerd. Elke geblokkeerde aanvraag vertegenwoordigt een gegevenspunt over wie de site probeert te bereiken, wat zij beweren te zijn, en van waar zij afkomstig zijn. Na verloop van tijd onthult dit logboek patronen die bredere veiligheidsbeslissingen informeren. Misschien is een specifieke ASN verantwoordelijk voor een onevenredig groot aandeel valse crawlers. Misschien stijgen valse Googlebot-aanvragen op bepaalde momenten van de dag. Misschien trekt een bepaalde URL-pad meer valse crawlers aan dan andere, wat suggereert dat bots specifieke content aanvallen.

De respons op een geblokkeerde aanvraag kan ook genuanceerder zijn dan een algemene 403. Sommige implementaties retourneren een 429 (Te veel aanvragen) om het feit te verbergen dat de bot is geïdentificeerd, waardoor het voor de botoperator moeilijker wordt om hun aanpak aan te passen. Anderen retourneren een 200 met een lege body, wat minimale bandbreedte verspilt terwijl voorkomen dat de bot weet dat het is gedetecteerd. Agressievere benaderingen retourneren een 403 met een bericht dat aangeeft dat crawlerverificatie is mislukt, wat transparant is maar botoperators informatie geeft over het detectiemechanisme. De keuze is afhankelijk van de filosofie van de site-operator over transparantie versus operationele veiligheid.

Voor bots die zich voordoen als crawlers maar eigenlijk legitieme services zijn die toevallig onjuist zoekmachine-user agent-strings gebruiken, kan de blokkering verstorender zijn dan beoogd. Sommige SEO-controletools gebruiken bijvoorbeeld Googlebot-achtige user agents om te simuleren hoe Google een pagina ziet. Deze tools zullen verificatie niet doorstaan, omdat zij niet Google zijn, ook al is hun doel legitiem vanuit het perspectief van de site-operator. De middleware kan hier rekening mee houden door een whitelist van bekende IP-bereiken voor vertrouwde externe services te onderhouden, of door verificatie toe te passen alleen op specifieke user agent-patronen terwijl andere worden genegeerd. De flexibiliteit van de middleware-benadering maakt dit soort genuanceerd beleid mogelijk zonder wijzigingen in de webserver-configuratie of de toepassingscode.

Synchrone versus asynchrone verificatie

De vraag of bots synchroon of asynchroon moeten worden geverifieerd, beïnvloedt zowel de effectiviteit van de blokkering als de prestatieimpact op de toepassing. Synchrone verificatie betekent dat de middleware de aanvraag pauzeert, de verificatie-API aanroept, wacht op de respons, en vervolgens de aanvraag op basis van het resultaat toestaat of blokkeert. Deze benadering biedt onmiddellijke blokkering maar voegt latentie toe aan de eerste aanvraag van elk IP-adres. Met caching beïnvloedt de latentie alleen de eerste aanvraag, maar voor high-traffic-toepassingen kan zelfs die occasionele vertraging onaanvaardbaar zijn.

Asynchrone verificatie hangt een ander benadering aan. De eerste aanvraag van een nieuw IP wordt doorgelaten terwijl een verificatietaak in de achtergrond in de wachtrij wordt geplaatst. Wanneer het verificatieresultaat terugkomt, wordt het in cache opgeslagen, en alle volgende aanvragen van dat IP worden volgens het resultaat afgehandeld. Deze benadering voegt nul latentie aan de aanvraagpijplijn toe, maar laat een klein aantal initiële aanvragen van valse bots door voordat de verificatie is voltooid. Voor de meeste toepassingen is deze afweging acceptabel. Een valse bot die drie aanvragen verstuurt voordat het wordt geblokkeerd, heeft veel minder resources verbruikt dan één die duizenden aanvragen zonder controle verstuurt.

Het wachtrijsysteem maakt de asynchrone benadering eenvoudig. De middleware stuurt een verificatietaak uit die de botdetectie-API aanroept, het resultaat in de cache opslaat, en optioneel een event afvaardigt dat andere delen van de toepassing kunnen luisteren. De taak wordt in seconden uitgevoerd, wat betekent dat het tijdvenster waarin onverifieerd bot-verkeer kan passeren, extreem nauw is. Voor toepassingen die een snelle in-memory cache gebruiken, is het in-cache-resultaat onmiddellijk beschikbaar voor alle toepassingsinstanties, dus zelfs in een load-balanced omgeving hoeft de verificatie slechts eenmaal per IP-adres over alle servers plaats te vinden.

Een hybride benadering combineert het beste van beide. Bekende bot-user agents die overeenkomen met hoog-betrouwbaarheidspatronen activeren synchrone verificatie met in-cache-resultaten, waardoor minimale latentie wordt toegevoegd. Lager-betrouwbaarheidspatronen activeren asynchrone verificatie, waardoor de eerste aanvraag wordt doorgelaten terwijl verificatie in de achtergrond wordt uitgevoerd. Deze gelaagde benadering optimaliseert voor het normale geval terwijl randgevallen elegant worden afgehandeld. De positie van de middleware in de aanvraagpijplijn maakt het het ideale plaats om deze logica te implementeren, omdat het alle informatie heeft die nodig is om de routeringsbeslissing te maken en zich voordoet voordat enige dure toepassingslogica.

De meetbare impact van blokkering aan de deur

De resultaten van het implementeren van botdetectie-middleware zijn bijna onmiddellijk zichtbaar in servermetrieken. De meest dramatische verandering is in bandbreedteverbruik. Valse crawlers vragen volledige HTML-pagina's aan, inclusief alle assets waarnaar in de respons wordt verwezen. Elke geblokkeerde aanvraag bespaart de bandbreedte die zou zijn gebruikt om de volledige respons te verzenden, wat voor content-zware pagina's tientallen of honderden kilobytes per aanvraag kan zijn. Over duizenden geblokkeerde aanvragen per uur accumuleert de bandbreedtebesparing tot betekenisvolle kostenreducties, vooral voor toepassingen die bij providers worden gehost die per gigabyte overdracht in rekening brengen.

CPU-gebruik daalt omdat de server niet langer PHP-code uitvoert, databasequery's uitvoert, en sjablonen voor aanvragen rendert die geen waarde opleveren. De reductie is het meest opvallend tijdens daluren wanneer menselijk verkeer laag is, maar bot-verkeer constant blijft. Voordat de middleware werd geïmplementeerd, handhaafde de server een baselinebasisgebruik zelfs om drie uur 's ochtends omdat bots niet slapen. Na implementatie daalt het daluren-gebruik bijna tot nul, wat de server ruimte geeft voor legitiem verkeer tijdens piekuren.

Responstijden voor legitieme bezoekers verbeteren als gevolg van verminderde serverbelasting. Een webserver die vijfhonderd aanvragen per seconde afhandelt, waarvan driehonderd valse bots, heeft minder capaciteit beschikbaar voor de tweehonderd echte bezoekers dan een server die slechts tweehonderd aanvragen per seconde afhandelt, waarvan allemaal legitiem. De middleware bespaart niet alleen resources op de geblokkeerde aanvragen. Het verbetert de servicekwaliteit voor elke aanvraag die erlangs gaat, omdat de server meer capaciteit beschikbaar heeft voor echt werk.

Databasebelasting neemt evenredig af. Als de toepassing de database bevraagt voor elke paginaaanvraag, elimineert het blokkeren van driehonderd valse aanvragen per seconde driehonderd onnodige databasequery's per seconde. Voor toepassingen met complexe query's of beperkte databaseverbindingen kan deze reductie het verschil zijn tussen stabiele werking en periodieke overbelasting. De middleware beschermt de gehele stack, van de webserver via de toepassingslaag tot de database, door ongewenst verkeer stop te zetten voordat het hen bereikt.