2025-re a digitális környezet megváltozott: a CAPTCHA már nem a megbízható kapuőr, ami egykor volt. Miközben az AI-vezérelt botok szinte tökéletes pontossággal oldják meg a CAPTCHA feladványokat, a valódi felhasználók frusztráltak, és gyakran elhagyják az oldalakat, amikor kihívás elé állítják őket. Friss tanulmányok azt mutatják, hogy a botok ma már 96–100%-os sikerrel teljesítik a kép- és szöveges CAPTCHA-kat — messze felülmúlva a valódi emberek sikerességi arányát, és akár 20%-kal csökkentve az űrlapkonverziókat. De a probléma sokkal mélyebbre nyúlik, mint bármilyen elavult feladatány.
Ma az automatizált forgalom uralja a webet. Ezt személyesen is megtapasztaltam. 2024-ben a becslések szerint az összes online aktivitás közel fele botok által generált volt, amelynek akár 37%-a egyértelműen rosszindulatúnak minősült. Még az aktív védekezéssel rendelkező oldalak is 10–20%-os folyamatos bot-aktivitásról számolnak be. A valóság kíméletlen: a hagyományos megoldások, mint a CAPTCHA és az IP-feketelista, szinte tehetetlenné váltak a koordinált, gyorsan fejlődő botnetek ellen, amelyek képesek valódi felhasználókat utánozni, friss IP-címeket váltogatni, és még mobil eszközöket is kihasználni nagyszabású támadásokhoz.
A weboldal-tulajdonosok és online vállalkozások számára a hatás pusztító. A bot-áradatok megbéníthatják a szerver erőforrásait, csigalassúvá tehetik az oldalak betöltését, és tönkretehetik a felhasználói élményt. De a hatások tovább gyűrűznek — a Google rangsorolás csökken, ahogy az oldal teljesítménye romlik, a hirdetési bevételek elpárolognak, ahogy a forgalom minősége csökken, és a hirdetési partnerekkel való kapcsolatok megromlanak, amikor a hamis látogatások elárasztják az analitikájukat.
Ezt a válságot saját bőrömön tapasztaltam meg. Minden egy hirdetési ügynökség vádaskodásával kezdődött: azt állították, hogy az oldalam forgalmának 90%-a hamis. A hirdetések kiszolgálására beágyazott nyomkövető kódjuk olyan bot-mennyiséget tárt fel, amely nemcsak a szűrőiket, hanem a szerveremet is túlterhelte. Napi több mint egymillió bot-látogatásról beszélünk — olyan forgalomról, amely a Google Analytics számára láthatatlan volt, de a háttérben katasztrofális. Amit eredetileg valódi felhasználóknak hittem, az valójában egy könyörtelen automatizált találat-hullám része volt, amely elárasztotta az infrastruktúrámat és veszélyeztette az egész projektem életképességét.
Ez nem csupán egy történet arról, hogy rosszindulatú szereplők kihasználják a gyengeségeket — arról szól, hogyan van ostrom alatt a modern web egész architektúrája. A kódoptimalizálások és a szerver-fejlesztések nem voltak elegendőek. A kihívás fegyverkezési versennyé vált, az oldalam a kereszttűzben. Íme, hogyan bontakozott ki a bot-áradat, majdnem mindent elpusztítva, amit felépítettem — és a lépések, amelyeket a visszavágásért tettem.
A bot forgalom történetem: 3 milliós weboldalból fél milliós
Minden egy hirdetési ügynökséggel kezdődött, amely megvádolt, hogy a forgalmam 90%-a hamis, ezt már mondtam, de: ők egy nyomkövető kódot helyeztek el az oldalamon a hirdetések kiszolgálására, és a bot-mennyiség számukra is problémát jelentett — túlterhelte a szűrőiket és felfújta a szerver terhelését. Napi több mint egymillió bot-látogatásról beszélünk.
Eleinte fel voltam háborodva. A Google Analytics-ben napi 100 000 tiszta látogatást láttam. Valódi felhasználók, gondoltam. De az ő aggodalmuk az Analytics-en kívüli forgalomra vonatkozott. A találatok láthatatlan rétege pusztítást végzett a szerver terhelésében. Akkoriban a projektem Laravel 5.3-on futott megosztott tárhelyen, és azt hittem, a teljesítmény szűk keresztmetszete a régi kódbázis. Mindent újraírtam Laravel 10-ben kiváló optimalizálással, beleértve a napi több millió adatbázis-rekord elemzését.
Ennek ellenére lassú volt. A megosztott tárhelyem nem bírta. Az oldalak betöltése csigalassú volt, és a valódi forgalom csökkent — hónapról hónapra körülbelül 150 000 látogatást veszítettem. A havi 3 millió látogatásból végül több mint a felét elveszítettem.
Frissítettem egy erős VPS-re 16 CPU maggal és 32GB RAM-mal, azt várva, hogy ez mindent megold. De még a javított infrastruktúrával és az újrakódolt Laravel 10 backenddel is fennmaradt a probléma. Sőt, a dolgok rosszabbodtak — a botok agresszívebbek lettek, növelve a támadások mennyiségét és gyakoriságát. Világossá vált, hogy sem kódoptimalizálás, sem hardver-skálázás nem tudja megoldani azt a problémát, ami alapvetően az ellenőrizhetetlen, rosszindulatú bot-forgalomról szól.
De ez még nem volt minden. Mélyebbre ásva rájöttem, hogy a léptékek még nagyobbak: napi több mint 2 millió weboldal-bejárás, elkülönítve a napi körülbelül 1,5 millió bot-látogatástól. És mégis, az oldal monetizálható, nyomon követhető része (amelyre az ügynökségek figyeltek) mindössze napi 100 000 megjelenítést hozott. Itt eszkalálódott a probléma. Egy hirdetési ügynökséggel dolgoztam, amely tiszta, emberi forgalomra támaszkodott. Nekik gyorsan kellett megtalálniuk a módot a botok kiszűrésére, különben az analitikai és hirdetéskiszolgáló rendszereik túlterhelődtek volna. A vádaskodások, az infrastruktúra túlterhelése és a bevételi eltérések — mind ehhez a láthatatlan, könyörtelen bot-áradathoz kötődtek.
Az első lépésem egy egyedi CAPTCHA létrehozása volt, amelynek célja az volt, hogy a botoknak üres oldalt mutasson, míg a valódi felhasználók áthaladjanak. Sajnos ez visszaütött. A rosszindulatú botok nem lassultak le — fokoztak. A CAPTCHA kihívássá vált, amelyet agresszíven próbáltak legyőzni, megduplázva a terhelést.
Ezután jött a tömeges blokkolás .htaccess-szel. Működött — néhány napig. Aztán a bot-hálózatok alkalmazkodtak, új IP-k jelentek meg, és a .htaccess felduzzadt és lassú lett. A tárhelyszolgáltatóm beavatkozott, segítve teljes alhálózatok ideiglenes blokkolásában, de a probléma hetente visszatért.
Végül a Cloudflare-hez fordultam. Ez volt a legjelentősebb változás. Bár nem volt tökéletes, lehetővé tette, hogy 24 órán belül több mint 1,5 millió bot-kérést szűrjek ki. Hálózati blokkokat töltöttem fel közvetlenül a tűzfalukba. Az eredmény? Az 1,5 millió bot-találatból naponta mindössze 20 CAPTCHA-kihívás indult el — bizonyítva, hogy a Cloudflare éldetektálása jobban működött, mint bármi más, amit kipróbáltam.
Hogy a botok előtt maradjak, építettem egy saját belső naplózó rendszert. Ez minden egyes kérést rögzít IP-cím és User-Agent karakterlánc alapján, adatbázisban tárolva. A háttérben egy ütemezett feladat fut percenként az adatok összesítésére. Amikor gyanús aktivitást észlel — például nagy mennyiségű kérést egyetlen hálózatról vagy IP-tartományból — automatikus e-mail értesítést indít. Az e-mail tartalmazza a blokkolásra kész IP-k és alhálózatok listáját a Cloudflare-hez.
Még mindig a Cloudflare ingyenes csomagján vagyok, de még ez is elegendő kontrollt biztosít a manuális tűzfalszabályok megvalósításához. Ez a proaktív megközelítés lehetővé teszi, hogy a bot-áradatokat még azelőtt észleljem és reagáljak rájuk, mielőtt túlterhelnék a rendszert. Apache szinten eredetileg a .htaccess-t próbáltam használni a forgalom közvetlen blokkolására, de ennek a módszernek csökkenő hozama volt. Ahogy egyre több szabály halmozódott fel, az oldal teljesítménye romlott, egyértelművé téve, hogy a szerver szintű blokkolás CDN vagy élréteg támogatás nélkül nem fenntartható.
Hogyan készítsünk bejelentkezési rendszert + CloudFlare védelmet?
Miért nem sebességkorlátozás vagy geo-blokkolás? Mert az én esetemben nem működnek. A legtöbb ilyen bot csak egyetlen kérést küld IP-nként — de ezt több száz vagy akár több ezer IP-vel teszik ugyanazon hálózaton belül. Ez azt jelenti, hogy az IP-nkénti sebességkorlátozás nem sokat segít; a mennyiség elosztott, nem koncentrált. Mi a helyzet a User-Agent alapú felismeréssel? Használhatatlan. Egyes botok elég okosak ahhoz, hogy utánozzák a Googlebot-ot vagy más legitim bejárókat, tehát nem bízhatsz meg egyedül a fejlécekben. Mi a helyzet a geolokációs szűréssel? Szintén nem hatékony. Az oldalam többnyelvű, és szándékosan sok országból fogad forgalmat. Ezek az áradat-hálózatok tudják ezt, és világszerte váltogatják az IP-ket. Lehet, hogy azért bejárnak, mert az oldalamnak értékes tartalma van — de nem zárkóztathatom egyszerűen regisztrációs fal mögé. Ez tönkretenné a felhasználói élményt. Tehát valami okosabbra volt szükségem a szokásos megoldásoknál.
Nézd meg a kódomat, a MYSQL lekérdezéseket és az ajánlásokat alább. (Laravel 10 + MYSQL)