Botiliiklus on muutunud ettevõtete veebilehtede, e-poodide ja kliendiportaalide jaoks üha tavalisemaks probleemiks. Sageli paistab see välja aeglase lehe, hangunud ostukorvi, rämpsvormide või korduvate sisselogimiskatsetena. Tegelik põhjus ei pruugi olla arendusviga, vaid automatiseeritud liiklus, mis koormab süsteemi, kogub andmeid või otsib nõrku kohti.
Kujutage ette olukorda.
Ettevõtte e-pood muutub esmaspäeva hommikul aeglaseks. Selle tulemusel annavad kliendid müügiosakonnale märku, et tootelehed ei avane, ostukorv hangub ja tellimust ei saa lõpuni vormistada. Turunduskampaaniat ei toimu, uudiskirja pole saadetud ja külastajate arv ei paista esmapilgul märgatavalt kasvanud.
Seetõttu on esimene reaktsioon on sageli lihtne: “Midagi on arenduses valesti.”
Mõnikord ongi põhjus rakenduse tehnilises pooles. Kuid üha sagedamini ei põhjusta koormust mitte päris kasutajad ega kehv kood, vaid automatiseeritud botid. Need võivad külastada veebilehte suure hulga päringutega, proovida kontodele sisse murda, koguda andmeid või otsida süsteemist nõrkusi.
See ei ole enam ainult suurte rahvusvaheliste ettevõtete probleem. Botiliiklus puudutab järjest rohkem ka tavalisi Eesti ettevõtteid: e-poode, tootmisettevõtteid, teenusepakkujaid, kinnisvaraportaale, logistikalahendusi ja äriklientidele mõeldud iseteeninduskeskkondi.
Botiprobleem ei pruugi tähendada, et veebileht on maas. Sageli avaldub see aegluses, katkestustes, rämpspäringutes, kasvavates kuludes ja kehvemas kliendikogemuses.
Mis on bot?
Bot on tarkvaraline programm, mis teeb internetis automaatselt tegevusi, mida inimene muidu teeks käsitsi. Bot võib avada veebilehti, täita vorme, teha otsinguid, koguda infot, proovida paroole või saata päringuid rakenduse taustasüsteemidele.
Kõik botid ei ole pahatahtlikud.
Näiteks otsingumootorite botid indekseerivad veebilehti, et ettevõtte sisu oleks Google’is leitav. Google selgitab oma dokumentatsioonis täpsemalt, kuidas otsingurobotid veebilehti leiavad ja indekseerivad.
Samuti on olemas monitooringuteenused, mis kontrollivad automaatselt, kas veebileht töötab. Sellised botid on ettevõtte jaoks kasulikud ja vajalikud.
Probleem tekib siis, kui botte kasutatakse ettevõtte süsteemide koormamiseks, andmete varastamiseks, turvanõrkuste otsimiseks või äriprotsesside häirimiseks.
Kuidas botiprobleem päriselus välja näeb?
Näiteks e-pood märkab, et tootelehed muutuvad tööpäeva keskel aeglaseks. Müük väheneb, kuid serveri koormus kasvab. Esialgu kahtlustatakse, et probleem on e-poe platvormis või viimases arenduses. Logide analüüs näitab aga, et suur osa liiklusest tuleb korduvate päringutena samadele kategooria- ja tootelehtedele.
Päris kliendid nii ei käitu. Tõenäoline põhjus on automaatne hinnainfo või tooteandmete kogumine.
Teine näide: B2B kliendiportaalis toimub öösel tuhandeid sisselogimiskatseid. Kasutatakse päris e-posti aadresse ja erinevaid paroole. See võib viidata olukorrale, kus botid proovivad mujal lekkinud paroole kasutada teie süsteemis.
Kolmas levinud olukord on kontaktivormide rämps. Müügimeeskond hakkab saama kümneid või sadu võltspäringuid, mis sisaldavad suvalisi nimesid, kahtlaseid linke või automaatselt genereeritud teksti. Selle tulemusel kulub aega rämpsu sorteerimisele ja päris kliendipäringud võivad jääda müra sisse.
Kõigi nende näidete puhul ei ole probleem ainult tehniline. See mõjutab müüki, kliendikogemust, tööaega ja usaldust.
Milliseid probleeme pahatahtlikud botid tekitavad?
Botirünnak ei tähenda alati seda, et veebileht täielikult maha võetakse. Sageli on mõju vaiksem, kuid äriliselt väga kulukas.
Näiteks võivad botid:
- tekitada veebilehele või rakendusele ebaharilikult suure koormuse;
- muuta lehe aeglaseks päris klientide jaoks;
- proovida sisse logida varastatud kasutajanimede ja paroolidega;
- koguda äritundlikku infot, näiteks hindu, tooteandmeid või saadavust;
- täita vorme võltsandmetega;
- luua massiliselt võltskontosid;
- koormata API-liideseid ja taustasüsteeme;
- otsida automaatselt teadaolevaid turvanõrkusi;
- suurendada serveri-, pilve- või majutuskulusid.
Äri vaates ei ole probleem ainult tehniline. Kui klient ei saa tellimust esitada, broneeringut teha või iseteenindusse sisse logida, mõjutab see müüki, kliendikogemust ja usaldust.
Botiliikluse mõju ei piirdu IT-ga. Kui digikanal ei tööta usaldusväärselt, muutub tehniline probleem kiiresti äriprobleemiks.
Miks botirünnakud on sagenenud?
Botiliikluse kasvul on mitu põhjust.
Esiteks on automatiseerimine muutunud odavaks ja kättesaadavaks. Tööriistad, millega saab massiliselt päringuid teha, paroole proovida või veebilehtedelt andmeid koguda, ei ole enam keerulised ega kallid.
Teiseks on kurjategijatel rohkem motivatsiooni. Ettevõtete veebikeskkondades liigub väärtuslik info: kliendiandmed, hinnad, varud, tellimused, lepingutingimused ja kasutajakontod. Kui süsteem on avalikus internetis, on see automaatselt ka botivõrgustike huviorbiidis.
Kolmandaks on ettevõtete digitaalsed teenused muutunud ärikriitiliseks. Kui varem oli veebileht sageli turunduskanal, siis täna võib see olla müügikanal, klienditeeninduskanal või oluline osa tarneahelast. See teeb veebisüsteemide häirimise mõjukamaks.
Neljandaks kasutatakse rünnakutes järjest enam hajutatud taristut: pilveteenuseid, nakatunud seadmeid, proxy-võrke ja automaatseid skripte. See teeb ründeliikluse eristamise päris kasutajatest keerulisemaks.
Tavaline koormus või botikoormus: kuidas neil vahet teha?
Kõrge koormus ei tähenda alati rünnakut. Kui ettevõttel toimub kampaania, uudiskirja väljasaatmine, hooajaline müügiperiood või uus tooteesitlus, võib liikluse kasv olla täiesti loomulik.
Botikoormuse puhul on erinevus selles, et liiklus ei käitu nagu tavaline klient.
Tüüpilised märgid võivad olla:
- väga palju korduvaid päringuid samadele aadressidele;
- ebaloomulikult kiire tegevus, mida inimene käsitsi teha ei jõuaks;
- palju sisselogimiskatseid lühikese aja jooksul;
- päringud kindlatele lehtedele, näiteks otsingule, sisselogimisele või API otspunktidele;
- liiklus ebatavalistest riikidest või IP-vahemikest;
- serverikoormus kasvab, kuid müük või päringute arv ei kasva;
- vormidesse tekib rämpsandmeid.
Näiteks kui kampaania ajal kasvab nii külastatavus kui ka müük, on see tõenäoliselt normaalne koormus. Kui aga serveri koormus kasvab mitu korda, kuid müügis, päringutes ega kliendikäitumises kasvu ei ole, tasub kontrollida, kas osa liiklusest on automatiseeritud.
Levinud eksiarvamus: “Kui leht on aeglane, peab arendaja selle ära parandama”
Aeglane veebileht ei ole alati arendusviga. Mõnikord on tegelik probleem liiklus, mida ettevõte ei ole ise soovinud ega tekitanud.
Aeglane või ülekoormatud veebileht vajab kindlasti tehnilist analüüsi. Kuid botiliikluse puhul on oluline mõista vastutuse piire.
Arendaja saab ja peab ehitama süsteemi mõistlikult turvaliseks, optimeerituks ja hallatavaks. See tähendab korralikku arhitektuuri, kvaliteetset koodi, logimist, ligipääsude kontrolli, jõudlusteste ja vajadusel kaitsemeetmete soovitamist.
Samas ei saa ükski arenduspartner garanteerida, et avalikus internetis asuvat süsteemi ei tabaks kunagi pahatahtlik liiklus. Botirünnakud sõltuvad paljudest teguritest: majutuskeskkonnast, võrgu- ja turvateenustest, CDN-ist, tulemüüridest, ligipääsupoliitikatest, äririskidest ning sellest, milliseid kaitsemeetmeid ettevõte on otsustanud kasutusele võtta.
Teisisõnu: arendaja vastutab selle eest, et süsteem oleks mõistlikult hästi ehitatud ja kokkulepitud nõuetele vastav. Kuid botirünnakute täielik vältimine ei ole ainult arendusküsimus. See on kombinatsioon arendusest, küberturbest, taristust, monitooringust ja ärilistest riskivalikutest.
Hea partner aitab neid riske selgitada ja maandada, mitte ei luba, et internetis olevaid ohte ei eksisteeri.
Kuidas botiliiklust ära tunda?
Botiliiklus ei paista alati välja suure rünnakuna. Sageli algab see väikestest märkidest, mida võib esmapilgul pidada tavaliseks tehniliseks probleemiks.
Tüüpilised märgid on näiteks:
- veebileht muutub aeglaseks ilma nähtava põhjuseta;
- serveri koormus kasvab, kuigi müük või päringute arv ei kasva;
- logides on palju korduvaid päringuid samadele aadressidele;
- sisselogimiskatseid tehakse ebaharilikult palju;
- vormidesse tekib rämpsandmeid;
- API-de kasutus kasvab järsult;
- liiklus tuleb ebatavalistest riikidest või IP-vahemikest;
- analüütika näitab käitumist, mis ei sarnane tavakasutajale.
Üksik märk ei tähenda veel tingimata botirünnakut. Oluline on vaadata tervikut: serverilogisid, rakenduse logisid, kasutajate käitumist, taristu koormust ja ärilisi näitajaid.
Näiteks kui kampaania ajal kasvab nii külastatavus kui ka müük, võib tegemist olla tavapärase koormusega. Kui aga koormus kasvab mitu korda, kuid müügis, päringutes ega tavakasutajate käitumises muutust ei ole, tasub kontrollida, kas osa liiklusest on automatiseeritud.
Mida teha, kui kahtlustate botiliiklust?
Kui veebileht, e-pood või portaal muutub ootamatult aeglaseks, ei tasu alustada oletustest. Esimene eesmärk on aru saada, kas probleem on rakenduses, taristus, integratsioonides või liikluses.
Praktiline kontroll võiks alata neist sammudest:
- Kontrollige mõju ulatust. Kas probleem puudutab kõiki kasutajaid või ainult teatud piirkonda, seadet, brauserit või teenust?
- Vaadake koormusnäitajaid. Kas serveri, andmebaasi, API-de või rakenduse koormus on järsult kasvanud?
- Võrrelge koormust äriliste näitajatega. Kui koormus kasvab, aga müük, päringud või tavakülastused mitte, võib liiklus olla ebaloomulik.
- Analüüsige logisid. Otsige korduvaid päringuid samadelt IP-aadressidelt, samadele URL-idele või kindlatele API otspunktidele.
- Kontrollige sisselogimisi ja vormiesitusi. Ebatavaliselt palju sisselogimiskatseid või rämpsvorme võib viidata automatiseeritud tegevusele.
- Kaasake arenduspartner ja majutusteenuse pakkuja. Arenduspartner näeb rakenduse käitumist, majutusteenuse pakkuja aga võrgu- ja serveritaseme koormust.
Kõige olulisem on mitte teha kiireid järeldusi ilma andmeteta. Aeglane veebileht võib olla rakenduse, andmebaasi, taristu, integratsiooni või pahatahtliku liikluse probleem. Enne lahenduse valimist tuleb põhjus tuvastada.
Kuidas botirünnakute mõju vähendada?
Botiliiklust ei saa täielikult välistada, kuid selle mõju saab oluliselt vähendada. Selleks on vaja kombinatsiooni arenduslikest, taristu- ja turvameetmetest.
1. Monitooring ja logimine
Ilma nähtavuseta ei saa probleemi juhtida. Ettevõttel peaks olema ülevaade, kui palju päringuid süsteem saab, kust need tulevad, millised teenused on kõige suurema koormuse all ja millal tekivad kõrvalekalded.
Hea monitooring aitab eristada, kas probleem on rakenduse jõudluses, serveriressursis, andmebaasis, API-des või pahatahtlikus liikluses.
2. Rate limiting ehk päringute piiramine
Kõik kasutajad ei pea saama teha piiramatult päringuid. Näiteks sisselogimine, otsingud, vormide esitamine ja API-kutsed peaksid olema kontrollitud.
Kui üks IP-aadress või kasutaja teeb liiga palju päringuid lühikese aja jooksul, saab süsteem teda aeglustada, ajutiselt blokeerida või suunata täiendavasse kontrolli.
3. WAF ja botikaitse
Web Application Firewall ehk veebirakenduse tulemüür aitab filtreerida pahatahtlikku liiklust enne, kui see jõuab rakenduseni. Paljudel juhtudel kasutatakse WAF-i koos CDN- ja botikaitse teenustega, mis suudavad tuvastada tuntud ründemustreid, kahtlast liiklust ja automatiseeritud päringuid.
See ei asenda kvaliteetset arendust, kuid vähendab oluliselt riski, et iga päring jõuab otse ettevõtte süsteemi koormama.
4. CAPTCHA ja täiendavad kontrollid
CAPTCHA ja muud täiendavad kontrollid võivad aidata vormide, sisselogimiste ja registreerimiste kaitsel, kuid neid tuleb kasutada mõistlikult. Kui iga kliendi tegevus tehakse ebamugavaks, kannatab kasutajakogemus.
Parem lähenemine on riskipõhine: täiendavat kontrolli küsitakse siis, kui käitumine erineb tavapärasest.
5. Tugevam autentimine
Kui süsteemis on kasutajakontod, tuleb pöörata tähelepanu paroolipoliitikale, kaheastmelisele autentimisele, sisselogimiskatsete piirangutele ja varastatud paroolide kasutamise tuvastamisele.
Paljud rünnakud ei alga keerulisest häkkimisest, vaid automaatsest katsetamisest: kas mõni kasutaja on kasutanud sama parooli ka mujal.
6. Vahemälu ja jõudluse optimeerimine
Kõik päringud ei pea koormama andmebaasi või ärikriitilisi teenuseid. Õigesti seadistatud vahemälu, CDN, andmebaasi optimeerimine ja rakenduse arhitektuur aitavad vähendada koormust ka siis, kui liiklus ajutiselt kasvab.
See ei kõrvalda pahatahtlikku liiklust, kuid muudab süsteemi vastupidavamaks.
7. Selged tegevusplaan
Kui botirünnak toimub, ei ole õige aeg hakata arutama, kellele helistada või milliseid ligipääse vaja on.
Ettevõttel peaks olema eelnevalt kokku lepitud tegevusplaan: kes jälgib, kes otsustab, kes suhtleb teenusepakkujatega ja millised meetmed saab kiiresti aktiveerida.
Millest peaks ettevõte alustama?
Hea esimene samm on tänase olukorra hindamine.
Ettevõte peaks endalt küsima:
- Kas meil on ülevaade veebilehe ja rakenduste liiklusest?
- Kas kriitilised vormid, sisselogimised ja API-d on piirangutega kaitstud?
- Kas kasutame WAF-i või botikaitset?
- Kas serveri- ja rakenduslogid on kättesaadavad ning analüüsitavad?
- Kas meil on kokkulepe, kuidas reageerime koormusrünnaku või pahatahtliku liikluse korral?
- Kas arenduspartner, majutusteenuse pakkuja ja ettevõtte IT vastutusalad on selgelt kokku lepitud?
Need küsimused aitavad vältida olukorda, kus probleem avastatakse alles siis, kui kliendid juba kaebavad.
Kokkuvõte
Botid on muutunud tavaliseks osaks internetiliiklusest. Osa neist on kasulikud, kuid pahatahtlikud botid võivad mõjutada ettevõtte müüki, kliendikogemust, andmete turvalisust ja tegevuskulusid.
Seetõttu ei peaks botikaitset käsitlema ainult tehnilise lisana, vaid osana ärikriitiliste digikanalite juhtimisest. Küsimus ei ole selles, kas ettevõte on piisavalt suur, et botte huvitada. Küsimus on selles, kui oluline on ettevõtte jaoks see, et tema digitaalsed teenused töötaksid usaldusväärselt ka ebatavalise koormuse korral.
Acty roll
Acty aitab ettevõtetel hinnata veebirakenduste ja ärisüsteemide vastupidavust, tuvastada nõrku kohti ning kavandada praktilisi kaitsemeetmeid. Eesmärk ei ole lihtsalt “botte blokeerida”, vaid tagada, et ettevõtte digitaalsed teenused toetaksid äri ka siis, kui internetiliiklus ei ole alati heatahtlik.