En servermellomvare som stopper falske krypere før de når applikasjonen din

Forespørselspipeline i en nettapplikasjon er en elegant ting. En forespørsel ankommer webserveren, passerer gjennom en stabel mellomvare, når en kontroller og returnerer et svar. Hver mellomvare i stabelen har muligheten til å inspisere forespørselen, endre den, sende den videre eller avvise den helt. Denne arkitekturen er perfekt for implementering av botdeteksjon fordi verifiseringen skjer før forespørselen berører noen applikasjonslogikk. En falsk krypere som hevder å være Googlebot blir identifisert og blokkert i mellomvarelaget, og kontrolleren vet aldri at forespørselen eksisterte. Ingen CPU-sykluser bortkastet på gjengivelse av en side. Ingen databasespørringer utført. Ingen cache-oppføringer fylt. Den falske boten stoppes ved døren, og serverressursene som ville ha blitt forbrukt bevares for legitime besøkende.

Motivasjonen for å bygge denne mellomvaren kom fra et konkret og kostbart problem. En stor applikasjon forbrukte båndbredde og serverressurser med hastigheter som ikke var i samsvar med sin faktiske brukerbase. Tilgangsloggene avslørte massive mengder forespørsler fra brukaragenter som hevdet å være Googlebot, Bingbot og ulike andre legitime krypere. Undersøkelsen bekreftet at flertallet av disse var falske, fra skyleverandører i stedet for søkemotorene de hevdet å være fra. Hver falsk forespørsel forbrukte samme serverressurser som en ekte: samme PHP-utførelsestid, samme databasespørringer, samme minneallokering, samme båndbredde for svaret. Multiplisert over tusenvis av falske forespørsler per time var kostnaden betydelig. Mellomvareløsningen var designet for å eliminere dette sløsingen ved å fange falske krypere før de forbrukte noen applikasjonsressurser i det hele tatt.

Implementeringen følger et enkelt mønster som enhver backend-utvikler kan tilpasse. Mellomvaren avskjærer hver innkommende forespørsel, sjekker om brukeragenten samsvarer med et kjent mønster for søkemotorkrypere, og hvis det gjør det, verifiserer forespørselens IP-adresse mot krypernes kjente infrastruktur ved hjelp av botdeteksjons-API. Forespørsler som hevder å være krypere men ikke verifiseres, blir blokkert med et 403-svar. Forespørsler som verifiseres eller som ikke hevder å være krypere i det hele tatt, fortsetter gjennom mellomvarestabelen normalt. Hele kontrollen legger til minimal latens fordi verifikasjonsresultatene blir bufret per IP-adresse, noe som betyr at hver unike IP blir verifisert bare en gang.

Beslutningslogikken bak blokkering på mellomvarenivået

Valget av å blokkere på mellomvarenivået i stedet for på webservernivået (Nginx eller Apache) eller på applikasjonsnivået (innenfor kontrollere) er en bevisst arkitektonisk beslutning med spesifikke avveininger. Blokkering på webservernivået er det mest effektive alternativet når det gjelder ressursforbruk fordi forespørselen aldri når PHP i det hele tatt. Webserverkonfigurasjonen for botdeteksjon innebærer imidlertid typisk statiske IP-svartelister eller enkelt brukeragentmatching, hvorav ingen gir den dynamiske API-drevne verifiseringen som trengs for nøyaktig å skille ekte krypere fra falske. Vedlikehold av en statisk svarteliste med millioner av IP-adresser er upraktisk, og brukeragentmatching alene kan ikke verifisere identitet fordi brukaragenter lett kan forfalskes.

Blokkering på applikasjonsnivået, innenfor kontrollere eller tjenesteklasser, er det mest fleksible alternativet, men det minst effektive. Når forespørselen når en kontroller, har mellomvarestabelen allerede blitt utført, ruten har blitt løst, og potensielt dyre operasjoner som øktinitialisering og autentisering har allerede skjedd. Blokkering på dette punktet sparer kontrollerkjøringstiden, men sløser bort alt som skjedde før det. For høytrafikapplikasjoner hvor falske botforespørsler teller i tusenvis per time, legger dette sløsingen seg opp.

Mellomvarelaget sitter på det optimale punktet i pipelinen. Det kjører før øktbehandling, før autentisering, før rutespesifikk mellomvare, og helt sikkert før noen kontrollørlogikk. Men det har tilgang til hele forespørselsobjektet, inkludert hodeder, IP-adresser og spørringsparametrer, noe som betyr at det kan utføre sofistikert verifikasjonslogikk i stedet for enkelt mønstermatching. Mellomvaren kan ringe en ekstern API, bufre resultater, bruke betinget logikk basert på den påståtte identiteten, og logge verifikasjonsresultater for analyse. Denne kombinasjonen av effektivitet og fleksibilitet gjør mellomvaren til det naturlige hjemmet for botdeteksjon i en nettapplikasjon.

Bufferstrategi er særlig viktig for ytelse. Uten bufring ville hver forespørsel fra en påstått krypere kreve et API-kall for å verifisere IP-adressen. Selv med et raskt API, ville dette legge til latens for hver forespørsel. Løsningen er å bufre verifikasjonsresultater nøklet av IP-adresse, med en tid-til-live på flere timer eller til og med en full dag. Søkemotorkrypere opererer fra stabile IP-områder som endres sjelden, så et bufret verifikasjonsresultat forblir gyldig i utvidede perioder. Når en forespørsel ankommer fra en påstått Googlebot, sjekker mellomvaren først bufferen. Hvis IP-en ble verifisert som legitim innenfor bufferperioden, tillates forespørselen gjennom umiddelbart. Hvis IP-en ble verifisert som falsk, blir den blokkert umiddelbart. Bare førsteganger IP-adresser krever et faktisk API-kall, og etter det innledende anropet serveres resultatet fra buffer med ubetydelig latenskostnad.

Hva som skjer med forespørslene som blir blokkert

Blokkering av en falsk krypere er ikke bare et spørsmål om å returnere et 403-svar og gå videre. Blokkeringsbeslutningen og dens kontekst bør logges for analyse. Hver blokkert forespørsel representerer et datapunkt om hvem som forsøker å få tilgang til nettstedet, hva de later til å være, og hvor de kommer fra. Over tid avslører denne loggen mønstre som informerer bredere sikkerhetsbeslutninger. Kanskje en spesifikk ASN er ansvarlig for en uforholdsmessig stor andel falske krypere. Kanskje falske Googlebot-forespørsler øker på bestemte tidspunkter på dagen. Kanskje en bestemt URL-sti tiltrekker seg flere falske krypere enn andre, noe som antyder at boten målretter spesifikt innhold.

Svaret på en blokkert forespørsel kan også være mer nyansert enn en blindstiende 403. Noen implementeringer returnerer en 429 (For mange forespørsler) for å skjule at boten er blitt identifisert, noe som gjør det vanskeligere for botoperatøren å justere sin tilnærming. Andre returnerer 200 med en tom kropp, som sløser minimal båndbredde mens det forhindrer at boten vet at den har blitt oppdaget. Mer aggressive tilnærminger returnerer et 403 med en melding som indikerer at krypererverifisering mislyktes, som er transparent, men gir botoperatører informasjon om oppdagelsesmekanismen. Valget avhenger av nettstedoperatørens filosofi om transparens versus operasjonell sikkerhet.

For bots som hevder å være krypere, men som egentlig er legitime tjenester som tilfeldigvis bruker søkemotorkryperes brukagenter feil, kan blokkeringen være mer forstyrrende enn tiltenkt. Noen SEO-overvåkingsverktøy bruker for eksempel Googlebot-lignende brukagenter for å simulere hvordan Google ser en side. Disse verktøyene vil ikke verifiseres fordi de ikke er Google, selv om formålet deres er legitimt fra nettstedoperatørens perspektiv. Mellomvaren kan imøtekomme dette ved å vedlikeholde en hviteliste over kjente IP-områder for betrodde tredjeparts tjenester, eller ved å bruke verifisering bare på spesifikke brukeragentmønstre samtidig som andre ignoreres. Fleksibiliteten til mellomvaren tillater denne slags nyansert politikk uten å kreve endringer i webserverkonfigurasjonen eller programkoden.

Synkron versus asynkron verifisering

Spørsmålet om hvorvidt bots skal verifiseres synkront eller asynkront påvirker både effektiviteten av blokkeringen og ytelsespåvirkningen på applikasjonen. Synkron verifisering betyr at mellomvaren pauser forespørselen, ringer verifikasjonens API, venter på svaret, og tillater eller blokkerer deretter forespørselen basert på resultatet. Denne tilnærmingen gir umiddelbar blokkering, men legger til latens for den første forespørselen fra hver IP-adresse. Med bufring påvirker latensen bare den første forespørselen, men for høytrafikapplikasjoner kan selv denne tilfeldige forsinkelsen være uakseptabel.

Asynkron verifisering tar en annen tilnærming. Den første forespørselen fra en ny IP tillates gjennom mens en verifiseringsjobb blir satt i kø i bakgrunnen. Når verifikasjonsresultatet kommer tilbake, blir det bufret, og alle påfølgende forespørsler fra denne IP-adressen håndteres i henhold til resultatet. Denne tilnærmingen legger til null latens for forespørselspipelinen, men tillater et lite antall innledende forespørsler fra falske bots å passere gjennom før verifiseringen er fullført. For de fleste applikasjoner er denne avveiningen akseptabel. En falsk bot som sender tre forespørsler før den blir blokkert, har forbrukt langt færre ressurser enn en som sender tusenvis av forespørsler ukontrollert.

Køsystemet gjør den asynkrone tilnærmingen enkel. Mellomvaren sender en verifiseringsjobb som ringer botdeteksjons-API, lagrer resultatet i bufferen, og avfyrer valgfritt en hendelse som andre deler av applikasjonen kan lytte til. Jobben kjøres på sekunder, noe som betyr at vinduet under hvilket uverifisert bottrafikk kan passere gjennom er ekstremt smalt. For applikasjoner som bruker et raskt minneinternt minne, er det bufrede resultatet tilgjengelig for alle applikasjonsforekomster umiddelbart, så selv i et lastsalansert miljø trenger verifiseringen å skje bare en gang per IP-adresse på tvers av alle servere.

En hybridtilnærming kombinerer det beste fra begge. Kjente botbrukagenter som samsvarer med mønstre med høy sikkerhet utløser synkron verifisering med bufrede resultater, og legger til minimal latens. Mønstre med lavere sikkerhet utløser asynkron verifisering, som tillater den første forespørselen gjennom mens verifiseringen kjøres i bakgrunnen. Denne lagdelte tilnærmingen optimaliserer for det vanlige tilfellet mens den håndterer kanttilfeller elegant. Mellomvarens posisjon i forespørselspipelinen gjør det til det ideelle stedet for å implementere denne logikken, fordi den har tilgang til all informasjonen som trengs for å ta rutingsbeslutningen og kjøres før noen dyr applikasjonslogikk.

Den målbare effekten av blokkering ved døren

Resultatene av implementering av botdeteksjonsmellomvare er synlige nesten umiddelbart i servermetrikker. Den mest dramatiske endringen er i båndbreddeforbruk. Falske krypere ber om komplette HTML-sider, inkludert alle eiendelene som refereres i svaret. Hver blokkert forespørsel sparer båndbredden som ville ha blitt brukt til å overføre det fullstendige svaret, som for innholdsrike sider kan være tiere eller hundrevis av kilobyte per forespørsel. Over tusenvis av blokkerte forespørsler per time samler båndbreddesparingene seg til meningsfulle kostnadsreduksjoner, spesielt for applikasjoner som ligger hos leverandører som belaster per gigabyte overføring.

CPU-utnyttelse synker fordi serveren ikke lenger utfører PHP-kode, kjører databasespørringer og gjengivelser maler for forespørsler som ikke gir verdi. Reduksjonen er mest merkbar i lavtrafikktider når menneskelig trafikk er lav, men bottrafikk forblir konstant. Før implementering av mellomvaren opprettholdt serveren en grunnleggende CPU-utnyttelse selv klokken tre om morgenen fordi bots sover ikke. Etter implementering faller lavtrafikuttnyttelsen til nesten null, noe som gir serveren råderom for legitim trafikk i spitsstunder.

Responstider for legitime besøkende forbedres som en direkte konsekvens av redusert serverbelastning. En webserver som håndterer fem hundre forespørsler per sekund, tre hundre av dem er falske bots, har mindre kapasitet tilgjengelig for de to hundrede virkelige besøkende enn en server som håndterer bare to hundrede forespørsler per sekund, alle av dem legitime. Mellomvaren sparer bare ikke ressurser på de blokkerte forespørslene. Det forbedrer kvaliteten på tjenesten for hver forespørsel som passerer gjennom, fordi serveren har mer kapasitet tilgjengelig for ekte arbeid.

Databasebelastning synker proporsjonalt. Hvis applikasjonen spør databasen for hver sideforespørsel, eliminerer blokkering av tre hundrede falske forespørsler per sekund tre hundrede unødvendige databasespørringer per sekund. For applikasjoner med komplekse spørringer eller begrenset databasetilkoblinger kan denne reduksjonen være forskjellen mellom stabil drift og periodisk overbelastning. Mellomvaren beskytter hele stabelen, fra webserveren gjennom applikasjonslaget til databasen, ved å stoppe uønsket trafikk før den når noen av dem.