Vuoteen 2025 mennessä digitaalinen maisema on muuttunut: CAPTCHA ei ole enää luotettava portinvartija, joka se kerran oli. Samaan aikaan kun tekoälypohjaiset botit ratkaisevat CAPTCHA-tehtäviä lähes täydellisellä tarkkuudella, todelliset käyttäjät turhautuvat ja usein hylkäävät sivustot, kun heitä haastetaan. Viimeaikaiset tutkimukset osoittavat, että botit läpäisevät kuva- ja tekstipohjaiset CAPTCHA:t 96–100 %:n ajasta—paljon paremmin kuin todelliset ihmiset ja laskien lomakkeiden konversioita jopa 20 %. Mutta ongelma ulottuu paljon syvemmälle kuin mikään vanhentunut pulma.
Nykyään automaattinen liikenne hallitsee verkkoa. Tajusin tämän henkilökohtaisesti. Vuonna 2024 arvioitiin, että lähes puolet kaikesta verkkotoiminnasta oli bottien tuottamaa, ja jopa 37 % luokiteltiin suorastaan haitalliseksi. Jopa sivustot, joilla on aktiivisia torjuntatoimia, raportoivat edelleen 10–20 % jatkuvaa bottitoimintaa. Todellisuus on karu: perinteiset ratkaisut kuten CAPTCHA ja IP-estolistat ovat lähes voimattomia koordinoitujen, nopeasti kehittyvien bottiverkkojen edessä, jotka voivat jäljitellä oikeita käyttäjiä, kierrättää tuoreita IP-osoitteita ja jopa käyttää mobiililaitteita suurhyökkäyksiin.
Verkkosivustojen omistajille ja verkkoyrityksille vaikutus on tuhoisa. Bottitulvat voivat lamauttaa palvelinresursseja, hidastaa sivujen lataamisen ryömintään ja pilata käyttökokemuksen. Mutta vaikutukset leviävät laajemmalle—Googlen sijoitukset laskevat, kun sivun suorituskyky heikkenee, mainostulot haihtuvat liikenteen laadun laskiessa ja suhteet mainoskumppaneihin happanevat, kun tekaistut vierailut hukuttavat analytiikan.
Koin tämän kriisin itse. Kaikki alkoi mainostoimiston syytöksestä: he väittivät, että 90 % sivustoni liikenteestä oli tekaistua. Heidän mainosten toimitukseen upotettu seurantakoodinsa paljasti bottimäärät, jotka ylittivät paitsi heidän suodattimensa myös palvelimeni. Puhumme yli miljoonasta bottivierailusta päivässä—liikennettä, joka oli näkymätöntä Google Analyticsille mutta katastrofaalista kulissien takana. Mitä aluksi luulin olevan aitoja käyttäjiä, olivatkin todellisuudessa osa armotonta automatisoitujen iskujen aaltoa, joka tulvi infrastruktuurini ja uhkasi koko projektini elinkelpoisuutta.
Tämä ei ole vain tarina pahantekijöistä hyödyntämässä heikkouksia—se on siitä, kuinka modernin verkon arkkitehtuuri on piiritettynä. Koodin optimoinnit ja palvelinpäivitykset eivät riittäneet. Haasteesta tuli asevarustelu, ja sivustoni oli jäänyt ristituleen. Näin bottitulva eteni, melkein tuhoten kaiken, mitä olin rakentanut—ja askeleet, jotka otin taistellakseni vastaan.
Tarina bottien liikenteestäni: 3 miljoonan sivustosta puoleen miljoonaan
Kaikki alkoi, kun mainostoimisto syytti minua 90 %:n vale-liikenteestä, olen jo sanonut sen, mutta: he olivat asentaneet seuranta-koodin sivustolleni mainosten toimittamiseksi, ja bottien määrä oli heillekin ongelma—se ylitti heidän suodattimensa ja lisäsi palvelimen kuormitusta. Puhumme yli miljoonasta bottivierailusta päivässä.
Aluksi olin raivoissani. Google Analyticsissa näin 100 000 puhdasta päivittäistä käyntiä. Oikeita käyttäjiä, ajattelin. Mutta heidän huolensa koski Analyticsin ulkopuolista liikennettä. Tämä näkymätön osuus iskuista aiheutti kaaosta palvelimen kuormituksessa. Tuolloin projektini pyöri Laravel 5.3:ssa jaetussa hostingissa, ja uskoin suorituskyvyn pullonkaulan olevan vanhassa koodipohjassa. Kirjoitin kaiken uudelleen Laravel 10:ssä erinomaisella optimoinnilla, mukaan lukien miljoonien tietokantamerkintöjen päivittäinen analyysi.
Silti se viivästyi. Yhteinen hostingini ei pystynyt käsittelemään sitä. Sivujen lataus hidastui, ja oikea liikenne väheni—kuukausittain menetin noin 150 000 käyntiä. Kolmesta miljoonasta kuukausittaisesta käynnistä menetin lopulta yli puolet.
Olin päivittänyt tehokkaaseen VPS:ään, jossa oli 16 CPU-ydintä ja 32GB RAM, odottaen tämän ratkaisevan kaiken. Mutta parannetusta infrastruktuurista ja uudelleen koodatusta Laravel 10 -taustasta huolimatta ongelma jatkui. Itse asiassa asiat pahenivat—botit muuttuivat aggressiivisemmiksi, lisäsivät hyökkäysvolyymiä ja -tiheyttä. Kävi selväksi, että mikään koodin optimointi tai laitteiston skaalaus ei voinut korjata ongelmaa, joka johtui perustavalla tavalla hallitsemattomasta, haitallisesta bottiliikenteestä.
Mutta se ei ollut kaikki. Syvemmälle kaivautuessani huomasin, että mittakaava oli vielä suurempi: yli 2 miljoonaa verkkosivuston indeksointia päivässä, erillään noin 1,5 miljoonasta päivittäisestä bottivierailusta. Ja silti, sivuston kaupallistettava, seurattava osa (se, josta mainostoimistot välittivät) toi vain 100 000 näyttökertaa päivässä. Siinä ongelma kärjistyi. Työskentelin mainostoimiston kanssa, joka luotti puhtaaseen, ihmisten liikenteeseen. Heidän piti löytää tapoja suodattaa botit nopeasti, tai heidän analytiikka- ja mainospalvelujärjestelmänsä ylikuormittuisivat. Syytökset, infrastruktuurin ylikuormitus ja tulojen epäsuhta—ne kaikki olivat sidoksissa tähän näkymättömään, armottomaan bottien tulvaan.
Ensimmäinen liikkeeni oli luoda mukautettu CAPTCHA, pyrkien näyttämään boteille tyhjän sivun, kun oikeat käyttäjät pääsivät läpi. Valitettavasti se kostautui. Haitalliset botit eivät hidastuneet—ne kiihdyttivät. CAPTCHAsta tuli haaste, jota ne aggressiivisesti yrittivät voittaa, kaksinkertaistaen kuormituksen.
Seuraavaksi tuli massiivinen esto .htaccessin kautta. Se toimi—muutaman päivän ajan. Sitten bottiverkostot sopeutuivat, uusia IP-osoitteita ilmestyi, ja .htaccess muuttui turvonneeksi ja hitaaksi. Isäntäpalveluntarjoajani astui mukaan, auttaen estämään kokonaisia aliverkkoja tilapäisesti, mutta ongelma palasi viikoittain.
Lopulta käännyin Cloudflaren puoleen. Tämä oli merkittävin muutos. Vaikka ei täydellinen, se mahdollisti yli 1,5 miljoonan bottipyynnön suodattamisen 24 tunnin sisällä. Latasin verkon estot suoraan heidän palomuuriinsa. Tuloksena? 1,5 miljoonasta bottiosumasta vain 20 CAPTCHA-haastetta laukesi päivittäin—todiste siitä, että Cloudflaren reunatunnistus toimi paremmin kuin mikään muu kokeilemani.
Pysyäkseni bottien edellä, rakensin oman sisäisen lokijärjestelmäni. Se tallentaa jokaisen yksittäisen pyynnön IP-osoitteen ja User-Agent-merkkijonon avulla ja tallentaa ne tietokantaan. Taustalla ajoitettu tehtävä suoritetaan joka minuutti keräämään tietoja. Kun se havaitsee epäilyttävää toimintaa—kuten suuren määrän pyyntöjä yhdeltä verkolta tai IP-alueelta—se laukaisee automaattisen sähköposti-ilmoituksen. Tuo sähköposti sisältää luettelon IP-osoitteista ja aliverkoista, jotka ovat valmiita lisättäväksi Cloudflareen estämistä varten.
Olen edelleen Cloudflaren ilmaisella suunnitelmalla, mutta jo se tarjoaa riittävästi hallintaa manuaalisten palomuurisääntöjen toteuttamiseen. Tämä ennakoiva lähestymistapa antaa minun havaita ja vastata bottitulviin ennen kuin ne ylikuormittavat järjestelmän. Apache-tasolla yritin alun perin käyttää .htaccessia liikenteen estämiseen suoraan, mutta tämä menetelmä tuotti väheneviä tuloksia. Kun sääntöjä kertyi lisää, sivuston suorituskyky heikkeni, mikä teki selväksi, että palvelintasoinen esto ei ollut kestävää ilman CDN:ää tai reuna-kerroksen tukea.
Kuinka tehdä kirjautumisjärjestelmä + CloudFlare-suojaus?
Miksi ei nopeusrajoitusta tai maantieteellistä estoa? Koska ne eivät toimi minun tapauksessani. Useimmat näistä boteista tekevät vain yhden pyynnön per IP—mutta he tekevät sen käyttämällä satoja tai jopa tuhansia IP-osoitteita saman verkon sisällä. Tämä tarkoittaa, että IP-osoitteiden perusteella tapahtuva nopeusrajoitus ei auta paljoa; tilavuus on jaettu, ei keskitetty. Entä niiden havaitseminen User-Agentin avulla? Hyödytöntä. Jotkut botit ovat riittävän älykkäitä jäljittelemään Googlebotia tai muita laillisia indeksoijia, joten et voi luottaa pelkästään otsikoihin. Entä maantieteellinen suodatus? Myöskään ei tehokas. Sivustoni on monikielinen ja vastaanottaa liikennettä monista maista suunnitelmallisesti. Nämä tulvaverkot tietävät sen ja kierrättävät IP-osoitteita ympäri maailmaa. Ehkä he kaapivat minua, koska sivustollani on arvokasta sisältöä—mutta en voi vain lukita sitä rekisteröintiseinän taakse. Se pilaisi käyttäjäkokemuksen. Joten tarvitsin jotain älykkäämpää kuin tavalliset ratkaisut.
Katso koodini, MYSQL-kyselyt ja suositukset alla. (Laravel 10 + MYSQL)
