--- title: "Akamai WAF și Bot Manager: din modul de alertă în blocare efectivă" description: "De ce Akamai App & API Protector și Bot Manager rămân ani de zile în alertă și monitorizare, și cum se ajunge la blocare fără să afectați clienții." url: "https://nixit.ro/resurse/akamai-waf-bot-manager-blocare/" lang: "ro-RO" --- # Akamai WAF și Bot Manager: din modul de alertă în blocare efectivă În multe companii care folosesc Akamai, protecția aplicațiilor există mai mult pe factură decât în fața aplicației. App & API Protector rulează în modul de alertă, Bot Manager în modul de monitorizare, contractul se reînnoiește anual, iar nimeni nu vrea să fie cel care a activat blocarea și a oprit plățile online într-o zi aglomerată. Trecerea la blocare efectivă ține mai puțin de o anumită setare și mai mult de ordinea pașilor și de dovezile strânse înainte de fiecare. Mai jos este succesiunea pe care o urmăm ca arhitecți de securitate Akamai. ## Pentru cine contează în România Băncile, unde autentificarea în internet banking este ținta principală a încercărilor automate. Magazinele online, la care testarea cardurilor furate și atacurile asupra conturilor cresc odată cu campaniile de reduceri. Operatorii de pariuri și jocuri online, ale căror conturi și bonusuri sunt atacate sistematic. Platformele de bilete, unde boții cumpără locurile în primele minute ale unei vânzări. Și marketplace-urile, ale căror prețuri sunt extrase constant de concurență. Pentru entitățile aflate sub incidența NIS2, prin Ordonanța de urgență nr. 155/2024, protecția aplicațiilor expuse public face parte din măsurile de gestionare a riscurilor, iar o politică WAF care doar alertează este greu de prezentat drept măsură aplicată. ## Întâi configurația de securitate O configurație de securitate este formată din politici asociate unor nume de domeniu și căi, iar primul pas este de obicei să aflăm de ce sunt atâtea. Politici separate dintr-un motiv care nu mai există, excepții scrise în timpul unui incident și uitate apoi, reguli proprii care dublează o regulă administrată: fiecare se justifică sau se elimină înainte ca ceva să treacă în blocare. O configurație pe care nu o poate explica nimeni nu va fi acceptată de nimeni pentru blocare. ## App & API Protector, pe grupuri de atac Adaptive Security Engine evaluează cererile și menține regulile actualizate, ceea ce elimină cea mai obositoare parte a administrării unui WAF. Nu decide însă ce alarme false sunt acceptabile; pentru asta e nevoie în continuare de cineva care citește alertele. Pornim de la alertele din Web Security Analytics sau din SIEM, urmărim fiecare alertă recurentă până la parametrul, antetul sau calea care o produce și scriem excepția exact acolo. O regulă dezactivată pentru tot site-ul ca să nu mai fie declanșată de un singur câmp de formular este cea mai frecventă slăbiciune pe care o găsim în configurațiile moștenite. Când alertele unui grup de atac sunt înțelese, grupul trece în blocare, este urmărit o perioadă și abia apoi urmează următorul. Versiunile noi ale setului de reguli rulează întâi în evaluare, în paralel cu politica activă. În jurul regulilor administrate stau controalele specifice aplicației: limitări de rată pe autentificare, căutare, resetarea parolei și API-urile de prețuri; liste de clienți pentru parteneri, servicii de monitorizare și propriile scanere; restricții geografice doar acolo unde există un motiv real; definiții de API, astfel încât cererile să fie verificate față de ce acceptă efectiv API-ul. Companiile care folosesc încă Kona Site Defender câștigă de obicei cel mai mult din trecerea la App & API Protector, în primul rând pentru că Adaptive Security Engine ține regulile la zi fără întreținere manuală. Migrarea este cea mai sigură atunci când noua politică rulează întâi în evaluare pe traficul real și se păstrează doar excepțiile care mai au un motiv să existe. ## Boții cunoscuți, rezolvați primii Traficul automatizat nu este o singură problemă. Motoarele de căutare și serviciile de monitorizare trebuie lăsate să treacă, iar directorul de boți cunoscuți din Bot Manager îi acoperă pe cei mai mulți. Partenerii, agregatoarele și propriile verificări de disponibilitate primesc categorii proprii, cu o acțiune explicită; orice rămâne neclasificat va părea un atac în cel mai prost moment. Cererile care se prezintă drept motor de căutare, dar vin din altă rețea, sunt imposturi și pot fi blocate direct, de obicei prima acțiune de blocare și una dintre cele mai sigure. ## Endpoint-uri protejate, nu tot site-ul Automatizările care contează se concentrează acolo unde are loc o tranzacție: autentificare, creare de cont, plată, căutare. Le definim ca endpoint-uri protejate, astfel încât cererile să treacă prin toate metodele de detecție, inclusiv reputația clientului, detecția browserelor care se dau drept altceva, anomaliile HTTP și detecția activă prin scriptul inserat în pagină. Aplicațiile mobile, care nu pot rula scriptul, au nevoie de SDK-ul dedicat. Reacția se alege pentru fiecare endpoint. O provocare se potrivește la autentificare, unde o persoană o rezolvă o dată. Încetinirea costă timp atacatorului la plată fără să îi arate unde este limita. Conținutul alternativ este alegerea mai bună pentru cei care extrag date, care altfel își schimbă metodele în câteva ore. Blocarea directă rămâne pentru situațiile fără echivoc, iar acțiunile condiționate permit ca reacția să devină mai strictă pe măsură ce crește scorul. ## Credential stuffing pe pagina de autentificare Atacurile de tip credential stuffing pornesc de la o observație simplă: o parte importantă dintre utilizatori folosesc aceeași parolă pe mai multe site-uri. Listele de adrese și parole scurse din alte servicii circulă liber, iar atacatorul nu ghicește nimic. Le încearcă pe toate pe pagina dumneavoastră de autentificare și păstrează combinațiile care funcționează. Efectul se vede în conturi golite de puncte, bonusuri sau bani, într-o încărcare a sistemului de autentificare fără legătură cu traficul real și, după fiecare val, în solicitările la suport ale clienților care nu mai pot intra în cont. Atacurile vechi erau ușor de recunoscut: multe încercări de la aceeași adresă IP, într-un interval scurt, oprite de o limitare de rată pe adresă. Cele actuale sunt construite tocmai ca să ocolească această regulă. Traficul trece prin rețele de proxy-uri rezidențiale, astfel încât fiecare încercare pare să vină de la un alt abonat de internet din România, instrumentele folosesc browsere fără interfață sau biblioteci care imită amprenta unui browser real, iar ritmul rămâne sub pragurile obișnuite. Privit cerere cu cerere, traficul arată aproape normal. Diferența apare doar când se adună mai multe semnale: amprenta nu corespunde browserului declarat, antetele HTTP au o ordine pe care niciun browser real nu o produce, scriptul de detecție nu rulează sau rulează într-un mediu fără nimic omenesc, iar rata de eșec a autentificărilor este cu mult peste cea a utilizatorilor reali. Exact aceste semnale le evaluează Bot Manager pe endpoint-ul de autentificare, înainte ca cererea să ajungă la aplicație. Reacția potrivită acolo este de obicei o provocare, care devine blocare pe măsură ce crește scorul. Limitările de rată din App & API Protector pe autentificare și pe resetarea parolei rămân utile: nu mai opresc singure un atac distribuit, dar limitează daunele când ceva trece de detecție. ## Ce nu face Bot Manager Bot Manager decide dacă o cerere vine de la o automatizare, nu dacă persoana care se autentifică cu parola corectă este titularul contului. Când combinațiile valide sunt încercate manual, sau de oameni plătiți pentru asta, problema iese din zona boților. Akamai Account Protector evaluează riscul fiecărei autentificări în raport cu istoricul contului, autentificarea multifactor face ca parola singură să nu mai fie suficientă pentru operațiunile sensibile, aplicația poate cere o verificare suplimentară într-un context neobișnuit, iar verificarea parolelor noi față de listele de parole compromise reduce exact rezerva din care se alimentează aceste atacuri. ## Ce să măsurați Fiecare modificare trebuie să vină cu întrebarea la care răspunde. După provocarea automatizărilor la autentificare, au scăzut încercările eșuate pe oră, în timp ce autentificările reușite au rămas la fel? După conținutul alternativ pe căutare, a scăzut extragerea de date sau doar s-a mutat pe altă cale? Pentru credential stuffing, urmăriți raportul dintre autentificările reușite și cele eșuate, pe oră și pe sursă, numărul de conturi distincte încercate dintr-un anumit tip de trafic și resetările de parolă cerute după un vârf de eșecuri. Când evenimentele de securitate de la Akamai ajung în același SIEM cu jurnalele aplicației, aceste corelații se fac în minute, nu după ce clienții au început să sune. ## Fiecare modificare, reversibilă Fiecare modificare urmează același drum: inventarul configurației și o măsurătoare a traficului normal, modificarea scrisă în Terraform și revizuită, activarea pe rețeaua de staging, apoi promovarea în producție, cu versiunea anterioară gata de restaurat în câteva minute. Evenimentele de securitate ajung în SIEM, iar reglajul se revizuiește săptămânal până la stabilizarea politicii. Facem această muncă pe Akamai, și echivalentul ei pe Cloudflare, CloudFront și Fastly, în cadrul serviciului de [management CDN și securitate la margine](/servicii/management-cdn/).