Egy Szerver Middleware, amely Megáll a Hamis Crawlerek Előtt, mielőtt Elérnék az Alkalmazást

A webalkalmazás kéréskezelési folyamata egy elegáns dolog. A kérés érkezik a webkiszolgálóra, áthalad a middleware-ek egy halmaza között, eléri a kontrollerhez, és visszaad egy válaszokat. A halmaz minden middleware-jének lehetősége van a kérést megvizsgálni, módosítani, továbbítani vagy teljesen elutasítani. Ez az architektúra tökéletes a bot-detektálás megvalósítására, mivel az ellenőrzés megtörténik, mielőtt a kérés érintene az alkalmazáslogikát. Egy hamis crawler, amely azt állítja, hogy Googlebot, azonosításra kerül és blokkolódik a middleware rétegben, és a kontroller soha nem is érzékeli a kérés létezését. Nincs pazarlott CPU-ciklus az oldal renderelésére. Nincs adatbázislekérdezés végrehajtva. Nincs gyorsítótár-bejegyzés kitöltve. A hamis bot megáll az ajtónál, és a szerver-erőforrások, amelyeket felhasználtak volna, megmaradnak az igazi látogatók számára.

A middleware létrehozásának motivációja egy konkrét és költséges problémából eredt. Egy nagy alkalmazás sávszélességet és szerver-erőforrásokat fogyasztott olyan mértékben, amely nem felelt meg a tényleges felhasználói bázisnak. A hozzáférési naplók rengeteg kérést tártak fel a Googlebot, Bingbot és különféle más jogos crawlereknek ható felhasználói ügynöktől. A vizsgálat megerősítette, hogy ezen kérések többsége hamis volt, a felhőszolgáltató szolgáltatók helyéről származó, nem a keresőmotorokból, amelyeknek állítottak maguk. Minden hamis kérés ugyanannyi szerver-erőforrást fogyasztott, mint egy igazi: ugyanaz a PHP-végrehajtási idő, ugyanazok az adatbázislekérdezések, ugyanaz a memóriaallokáció, ugyanaz a sávszélesség a válaszhoz. Szaporítva több ezer hamis kérés óránként, a költség jelentős volt. A middleware megoldás célja volt ennek a pazarlásnak a kiküszöbölése azzal, hogy fogta a hamis crawlereket, mielőtt fogyasztottak volna az alkalmazás-erőforrásokat.

A megvalósítás egy egyenes mintát követel, amelyet bármely backend fejlesztő adaptálhat. A middleware minden bejövő kérést elfog, ellenőrzi, hogy a felhasználói ügynök sztringje illeszkedik-e egy ismert keresőmotor crawler mintához, és ha igen, a kérés IP-címét a crawler ismert infrastruktúrájával szemben ellenőrzi a bot-detektálás API segítségével. A crawlereknek ható, de az ellenőrzésben hibás kéréseket 403 válasszal blokkolják. A verifikációban sikerülő kérések, vagy amelyek nem állítják maguknak, hogy crawlerek, normálisan folytatódnak a middleware halmaz között. Az egész vizsgálat minimális latenciát ad, mivel az ellenőrzési eredmények IP-cím szerint vannak gyorsítótárazva, ami azt jelenti, hogy minden egyedi IP-t csak egyszer ellenőriznek.

A Blokkolás Logikája a Middleware Rétegben

Annak a kiválasztásnak, hogy a middleware rétegben blokkoljunk, nem a webkiszolgáló szintjén (Nginx vagy Apache) vagy az alkalmazási szintjén (a kontrollerek között), szándékos architekturális döntés, amely konkrét kompromisszumokkal jár. A webkiszolgáló szintjén történő blokkolás a szerver-erőforrás-fogyasztás szempontjából a legtöbb hatékony lehetőség, mert a kérés soha nem éri el a PHP-t. Azonban a webkiszolgáló bot-detektálás konfigurációja általában statikus IP-feketelistákat vagy egyszerű felhasználói ügynök illesztéseket tartalmaz, amelyek közül egyik sem biztosítja a dinamikus, API-vezérelt ellenőrzést, amely szükséges az igazi crawlerek és hamisak közötti pontos megkülönböztetéshez. Egy millió IP-cím statikus feketelistájának fenntartása gyakorlatilag lehetetlen, és az egyedüli felhasználói ügynök illesztés nem tud azonosságot igazolni, mivel a felhasználói ügynökök triviálisan meghamisíthatók.

Az alkalmazási szintjén történő blokkolás, a kontrollerek vagy a szervizklasszok között, a legflexibilisebb lehetőség, de a legkevésbé hatékony. Amikor a kérés eléri a kontrollerhez, a middleware halmaz már végzett, az útvonal feloldódott, és potenciálisan költséges műveletek, mint a munkamenet-inicializálás és a hitelesítés már megtörténtek. A blokkolás ezen a ponton mentesít a kontroller végrehajtási idejétől, de pazarlja mindent, ami megtörtént előtte. A nagy forgalmú alkalmazások számára, ahol a hamis bot kérések naponta ezreiben vannak, ez a pazarolt előfeldolgozás felhalmozódik.

A middleware réteg az optimális pontban ül a folyamatban. Ez a munkamenet kezelése előtt, hitelesítés előtt, útvonal-specifikus middleware előtt, és biztosan a kontroller logika előtt végzett. De van hozzáférése a teljes kérés objektumhoz, beleértve a fejléceket, IP-címeket és lekérdezési paramétereket, ami azt jelenti, hogy egy kifinomult ellenőrzési logikát hajthat végre, nem pedig egyszerű mintaillesztést. A middleware meghívhat egy külső API-t, gyorsítótárazhat eredményeket, kondíciós logikát alkalmazhat az állított identitás alapján, és naplózhat ellenőrzési kimeneteleseket az elemzéshez. Ez a hatékonyság és a rugalmasság kombinációja teszi a middleware-t a bot-detektálás természetes otthonává egy webalkalmazásban.

A gyorsítótár stratégia különösen fontos a teljesítmény szempontjából. Gyorsítótárazás nélkül, minden kérés egy állított crawlertől API hívást igényelne az IP-cím ellenőrzéséhez. Még egy gyors API-val is, ez latenciát adna minden kéréshez. A megoldás az ellenőrzési eredmények gyorsítótárazása IP-cím szerint, több óra vagy akár egy teljes nap élettartamával. A keresőmotor crawlerek stabil IP-tartományokból működnek, amelyek ritkán változnak, így egy gyorsítótárolt ellenőrzési eredmény hosszú ideig érvényes marad. Amikor egy kérés egy állított Googlebottól érkezik, a middleware először a gyorsítótárat ellenőrzi. Ha az IP egy ellenőrzött jogos lett az gyorsítótár időszakán belül, a kérés azonnal át van engedve. Ha az IP-t egy ellenőrzés során hamisnak találták, azonnal blokkolódik. Csak az első idő IP-címei igényelnek egy tényleges API hívást, és ezt követően az eredményt a gyorsítótárból szolgálják ki elhanyagolható latencia költségével.

Mi Történik a Blokkolódott Kérésekkel

Egy hamis crawler blokkolása nem egyszerűen az, hogy egy 403 választ adunk vissza és továbblépünk. A blokkolódás döntésének és kontextusának naplózódnia kell az elemzéshez. Minden blokkolódott kérés egy adatpont az őt figyelmezteti, hogy ki próbál hozzáférni az oldalhoz, mit állít magáról, és honnan jön. Idővel ez a napló olyan mintákat tár fel, amelyek az alaposabb biztonsági döntéseket tájékoztatnak. Talán egy konkrét ASN a hamis crawlerek aránytalan részéért felelős. Talán a hamis Googlebot kérések bizonyos napi időpontban megemelkednek. Talán egy konkrét URL útvonal több hamis crawlert vonz, mint mások, ami azt sugallja, hogy a botok konkrét tartalmat céloznak.

A blokkolódott kérésre adott válasz árnyaltabb is lehet, mint egy teljes 403. Néhány megvalósítás egy 429-et (Too Many Requests) ad vissza, hogy elrejtse azt a tényt, hogy a bot azonosításra került, ami megnehezíti a bot operátor megközelítésének módosítását. Mások egy 200-at adnak vissza egy üres testtel, amely minimális sávszélességet pazarol, miközben meggátolja, hogy a bot tudja, hogy fel lett fedezve. Az agresszívabb megközelítések egy 403-at adnak vissza a üzenettel, amely azt jelzi, hogy a crawler ellenőrzés meghiúsult, amely átlátható, de információt ad a bot operátoroknak az detektálódási mechanizmusról. A választás az oldal operátorjának filozófiájától függ az átláthatóság és az operatív biztonság között.

Azok a botak, amelyek crawlereknek állítják maguknak, de ténylegesen jogos szolgáltatások, amelyek véletlenül keresőmotor felhasználói ügynök sztringeket használnak helytelenül, a blokkolás szándéknál zavaróbb lehet. Néhány SEO-monitoring eszköz például Googlebot-szerű felhasználói ügynököket használ a Google szempontjából az oldalt szimulálni. Ezek az eszközök az ellenőrzésben meghiúsulnak, mert nem Google, még akkor is, ha céljaik az oldal operátora szempontjából jogosak. A middleware ezt úgy tud kezelni, hogy fenntart egy ismert IP-tartományok fehérlista a megbízott harmadik fél szolgáltatásokhoz, vagy az ellenőrzést csak konkrét felhasználói ügynök mintákra alkalmazza, míg másokat elhanyagol. A middleware megközelítés rugalmassága lehetővé teszi az ilyen árnyalt politikát az alkalmazás kódjának vagy a webkiszolgáló konfigurációjának módosítása nélkül.

Szinkron és Aszinkron Ellenőrzés

Az a kérdés, hogy a botok ellenőrzését szinkron vagy aszinkron módon végezzük-e, hatással van a blokkolás hatékonyságára és az alkalmazás teljesítményi hatására. A szinkron ellenőrzés azt jelenti, hogy a middleware szünetelteti a kérést, meghívja az ellenőrzés API-t, megvárja a választ, és azután az eredményen alapulva engedélyezi vagy blokkolódik a kérést. Ez a megközelítés azonnali blokkolást biztosít, de latenciát ad az első kéréshez minden IP-cím-hez. A gyorsítótárazással a latencia csak az első kérést érinti, de nagy forgalmú alkalmazások számára még ez az alkalmi késleltetés is elfogadhatatlan lehet.

Az aszinkron ellenőrzés egy másik megközelítést vesz. Az első kérés egy új IP-ből át van engedve, miközben egy ellenőrzési munka egy sorba van állítva a háttérben. Amikor az ellenőrzési eredmény visszaérkezik, a gyorsítótárba kerül, és az összes ezt követő kérés az IP-ből az eredménynek megfelelően kezelendő. Ez a megközelítés nulla latenciát ad a kérés folyamatához, de egy kis számú kezdeti kéréseket a hamis botokból ázz engedi, míg az ellenőrzés befejeződik. A legtöbb alkalmazás számára ez a kompromisszum elfogadható. Egy hamis bot, amely három kérést küld, mielőtt blokkolódik, jóval kevesebb erőforrást fogyasztott, mint az, amely ezreket küld szűrtelenül.

A sor rendszer egyenes teszi az aszinkron megközelítést. A middleware egy ellenőrzési munkát küld ki, amely meghívja a bot-detektálás API-t, a gyorsítótárba tárja az eredményt, és opcionálisan egy eseményt vált ki, amelyet az alkalmazás más részei figyelhetnek. A munka másodpercek alatt végzett, így az ablak, amelyen az ellenőrizetlen bot forgalom át tud jutni, rendkívül szűk. A gyors memóriabeli gyorsítótárat használó alkalmazások számára az eredmény azonnal elérhető az összes alkalmazási instancehez, így még egy terheléselosztott környezetben is az ellenőrzésnek csak egyszer kell megtörténnie IP-cím-ként az összes szerver között.

Egy hibrid megközelítés az kettő legjobbjait egyesíti. Az ismert bot felhasználói ügynökök, amelyek magas megbízhatóságú mintáknak felelnek meg, szinkron ellenőrzést indítanak a gyorsítótárolt eredményekkel, minimális latenciát adnak. Az alacsonyabb megbízhatóságú minták aszinkron ellenőrzést indítanak, az első kérést át engedik, miközben az ellenőrzés a háttérben fut. Ez a rétegzett megközelítés optimalizál a gyakori esetre, miközben az élcsapatok kielégítik. A middleware pozíciója a kérés folyamatában teszi az ideális helyre ennek a logikának a megvalósítására, mivel hozzáférése van az összes szükséges információhoz az útvonalirányítódás döntéséhez, és végzett az alkalmazás bármely költséges logikája előtt.

A Blokkolás Ajtónál az Mérhető Hatása

A bot-detektálódás middleware implementálásának eredménye szinte azonnal látható a szerver metrikákban. A legdrámaibb változás a sávszélesség-fogyasztásban. A hamis crawlerek teljes HTML oldalakat kérnek, beleértve az összes, a válaszban hivatkozott eszközöket. Minden blokkolódott kérés mentesíti a sávszélességet, amely a teljes válasz továbbítására használódna, amely a tartalomhoz gazdagon oldalaknál több tíz vagy száz kilobájt lehet. Ezrek a blokkolódott kéréseken keresztül óránként, a sávszélesség megtakarítások egy értelmes költségcsökkentésbe felhalmozódnak, különösen az olyan szolgáltatóknál, amelyek gigabájtonként számláznak.

A CPU kihasználtsága csökken, mivel a szerver már nem végzett PHP kódot, adatbázis-lekérdezéseket és renderelési sablonokat az olyan kérésekhez, amelyek nem termelnek értéket. A csökkentés leginkább észrevehető az éjszakai órákban, amikor az emberi forgalom alacsony, de a bot forgalom állandó marad. A middleware implementálása előtt a szerver fenntartott egy alapvonal CPU kihasználtságot még három óra után is, mivel a botok nem alusznak. Után az implementálása, az éjszakai kihasználtsága közel nullára csökken, az alkalmazott szerver fejlécét az igazi forgalomhoz az oktatott órák alatt.

Az igazi látogatók számára az válaszidők javulnak a szerver terhelésének közvetlen következményeként. Egy webkiszolgáló, amely ötszáz kérést kezel másodpercenként, amelyből háromszáz hamis bot, kevesebb kapacitása van az igazi látogatóknál, mint egy szerver, amely csak kétszáz kérést kezel másodpercenként, amelyek az összes jogosak. A middleware nem csak megmentesz erőforrásokat a blokkolódott kéréseken. Az összes kéréshez az igazi munkához javít a szolgáltatás minőségét, mivel a szerver több kapacitása van az igazi munkához.

Az adatbázis-terhelés arányosan csökken. Ha az alkalmazás lekérdezi az adatbázist minden oldal kéréshez, a háromszáz hamis kérés blokkolása másodpercenként három száz szükségtelen adatbázis-lekérdezést kiküszöbölni másodpercenként. Az összetett lekérdezéseket vagy korlátozott adatbázis-kapcsolatokkal az alkalmazások számára ez a csökkentés lehet az a különbség az stabil működés között a az egy időszakos túlterhelés között. A middleware megvédi az egész veremborát, a webkiszolgálótól az alkalmazás rétegéig az adatbázisig, azzal, hogy az nem akart forgalmat megáll, mielőtt elérne egyikét sem.