- Efektyvus WAF apjungia blokuojamųjų sąrašų modelius, leidžiamųjų sąrašų modelius ir dažnumu pagrįstas taisykles, kad nuspręstų, kada registruoti, skaičiuoti ar blokuoti.
- Klaidingai teigiamų rezultatų koregavimas naudojant baltuosius sąrašus, išimtis ir modeliavimo režimus yra labai svarbus siekiant išvengti poveikio teisėtam srautui.
- Politikos segmentavimas pagal programą ar paslaugą, kartu su integracija su SIEM ir automatizavimu, leidžia pasiekti realistišką pusiausvyrą tarp saugumo ir veikimo.
- Evoliucija link WAAP platformų išplečia apsaugą iki API, pagerina įrašų kontekstą ir palengvina tikslesnius blokavimo sprendimus.
Tinkamo balanso tarp registravimo ir blokavimo radimas WAF sistemoje tapo vienu iš dažniausių saugumo ir operacijų komandų galvos skausmų. Žiniatinklio programų užkarda gali sustabdyti labai rimtas atakas, tačiau pernelyg agresyviai sukonfigūruota ji gali blokuoti teisėtus pirkimus, prieigą ar API iškvietimus. Pernelyg laisvai sukonfigūruota, ji tampa beveik vien dekoratyvia. Svarbiausia – atidžiai koreguoti, kada registruoti, kada skaičiuoti, kada leisti ir kada blokuoti.
Šiame straipsnyje mes išsamiai aptarsime, kaip pasiekti šią pusiausvyrą naudojant modernias WAF galimybes (leidžiamųjų sąrašus, dažnumu pagrįstas taisykles, mokymosi režimus, SIEM integraciją, mašininį mokymąsi ir kt.), remiantis konkrečiais AWS WAF, „ModSecurity“, debesijos pagrindu veikiančių WAF ir vietinių sprendimų pavyzdžiais . Sužinosite, kaip apriboti klaidingai teigiamus rezultatus nesumažinant apsaugos lygio, kaip tvarkyti politikas pagal programą ir kaip naudoti registravimą kaip sąjungininką, o ne kaip nuolatinį, nevaldomą triukšmo šaltinį.
Kas yra WAF ir kodėl registracija tokia svarbi?
Žiniatinklio programų užkarda veikia kaip intelektualus sluoksnis tarp vartotojo ir serverio , realiuoju laiku analizuojant HTTP/HTTPS srautą. Skirtingai nuo tradicinės tinklo užkardos, kuri stebi prievadus ir IP adresus, WAF analizuoja giliau: URL, parametrus, užklausų tekstus, antraštes, slapukus, HTTP metodus ir kt.
Jo misija – aptikti ir sustabdyti tipines 7 lygio atakas : SQL injekciją, XSS, LFI/RFI, atakas prieš prieigos kontrolę, API piktnaudžiavimą, agresyvų duomenų išgavimą, „brute force“ ir net tam tikrus programos lygio DDoS modelius. Tam jis naudoja nuolat atnaujinamus taisyklių, parašų ir saugumo politikų rinkinius.
Žurnalavimas yra kita medalio pusė. Kiekvieną WAF sprendimą – leisti, blokuoti ar tik skaičiuoti – gali lydėti išsamus įvykis žurnaluose . Šie žurnalai leidžia:
- Ištirti incidentus: atkurti, kas įvyko ir kaip buvo bandoma išnaudoti pažeidžiamumą.
- Koreguoti taisykles: aptikti klaidingai teigiamus rezultatus matant, kurias teisėtas užklausas WAF blokuoja.
- Laikytis taisyklių: įrodyti, kad egzistuoja aktyvios kontrolės priemonės (PCI DSS, BDAR, vidaus auditai ir kt.).
- SIEM maitinimas: susieti programų atakas su tinklo, sistemos, tapatybės ir kt. įvykiais.
Problema ta, kad prastai suderintas WAF gali užpildyti žurnalus tūkstančiais nesusijusių įvykių , todėl neįmanoma rasti to, kas svarbu, ir, be to, gali būti nepagrįstai atmetamas teisėtas srautas. Štai čia ir prasideda žaidimo su registravimo, skaičiavimo ir blokavimo režimais menas.
WAF saugumo modeliai: blokuojamųjų sąrašai, leidžiamųjų sąrašai ir hibridinis metodas
Daugumoje šiuolaikinių WAF derinami keli filtravimo metodai, kurie tiesiogiai veikia užklausų registravimą ir blokavimą . Apskritai galime išskirti dvi klasikines filosofijas ir labai dažną hibridinį modelį.
Blokavimo sąrašu pagrįsta WAF taiko neigiamo saugumo modelį. Pagrindinis jo principas yra toks: „Leidžiu viską, išskyrus tai, ką žinau esant kenkėjiška“. Jis veikia naudodamas žinomų atakų (SQL injekcijos, XSS, robotų šablonų ir kt.) parašus ir taisykles, kurios apibrėžia, kas laikoma įtartinu. Iš pradžių jį lengviau diegti, tačiau pasikliaujant vien šiuo modeliu kyla rizika, kad nauji atakų vektoriai ar variantai praslys nepastebėti.
WAF su leidžiamųjų sąrašu veikia priešingai: „blokuoti viską, išskyrus tai, kas aiškiai leidžiama“. Jis pagrįstas teigiamu saugumo modeliu. Priimamas tik tas srautas, kuris atitinka apibrėžtą teisėtą elgseną – maršrutus, metodus, parametrus, formatus, dydžius ir kt. Tai daug saugiau, tačiau reikalauja didelių tikslinimų ir iš pradžių gali generuoti klaidingus teigiamus rezultatus, jei nėra tinkamai paruoštas.
Dėl kiekvieno metodo privalumų ir trūkumų vis labiau paplitęs hibridinis modelis, apjungiantis leidžiamuosius ir blokuojamuosius sąrašus . Šiame scenarijuje apibrėžiami numatomi srauto profiliai (pavyzdžiui, kas laikoma įprastu prisijungimu arba mokėjimo užklausa), o parašai ir euristika vienu metu taikomi tipiniams kenkėjiškiems modeliams aptikti. Registravimo tikslais šis hibridinis metodas leidžia:
- Pažymėti kaip didelės rizikos įvykis kas pažeidžia leidžiamų daiktų sąrašą.
- Elkitės kaip vidutinio / žemo prioriteto įspėjimai bendrieji blokuojamųjų sąrašų modeliai.
- Prieš aktyvuodami bloką, naudokite „skaičiavimo“ režimą, kad pamatytumėte, kas pažeistų taisyklę.
WAF tinkle, pagrindiniame kompiuteryje ir debesyje: poveikis registravimui ir užrakinimui
WAF diegimo modelis labai įtakoja, kaip tvarkomas srauto registravimas ir blokavimas. Užklausų registravimas tinklo įrenginyje nėra tas pats, kas jų registravimas agente serveryje ar valdomoje debesies paslaugoje.
Tinklo pagrindu veikiantis WAF paprastai diegiamas kaip fizinis arba virtualus įrenginys infrastruktūroje, tarp interneto ir programų. Tai klasikinis metodas, kurį naudoja tokie gamintojai kaip „F5“. Jis siūlo didelio našumo ir detalaus valdymo pranašumą , tačiau konfigūravimas ir valdymas gali būti sudėtingi. Žurnalai paprastai siunčiami į sistemos žurnalą arba centrinę SIEM sistemą, todėl svarbu atidžiai filtruoti, kas išsaugoma, kad nebūtų perkrauta saugykla ir analizės įrankiai, ir diagnozuoti problemas IP ir DNS tinkluose.
Pagrindinio kompiuterio pagrindu veikiančios WAF sistemos veikia tuose pačiuose serveriuose (arba konteineriuose), kuriuose yra programa, paprastai kaip modulis arba agentas (pavyzdžiui, „ModSecurity“ integruota į „Nginx“ arba „Apache“; derinant ją su „Linux“ apsaugos nuo sukietėjimo funkcija naudojant SELinux, pagerėja saugumo padėtis). Šis modelis leidžia pasiekti platesnį programos kontekstą ir nustatyti labai specifines taisykles kiekvienai paslaugai, tačiau tuo pačiu metu sunaudojant vietinius išteklius ir reikalaujant labiau paskirstyto žurnalų valdymo. Žurnalai gali būti saugomi vietiniuose failuose ir persiunčiami arba integruoti su centralizuotomis žurnalų tvarkymo paslaugomis.
Debesijos pagrindu veikiančios WAF sistemos („Cloudflare“, „Akamai“, „Imperva Cloud“, AWS WAF ir kt.) integruojasi su apkrovos balansavimo įrenginiais, CDN arba virtualiais tinklais. Teikėjai paprastai siūlo ataskaitų suvestines ir žurnalų eksportavimą į S3, „BigQuery“, nuotolinius sisteminius žurnalus arba SIEM. Paprastai jas lengviau nustatyti, tačiau turite pritaikyti savo žurnalavimo politiką prie teikėjo modelio: įvykių tipai, saugojimo laikotarpiai, svarbos filtrai ir kt.
Vieno ar kito modelio pasirinkimas yra ne tik techninis sprendimas, bet ir tai, kaip norite subalansuoti registravimą ir užrakinimą: debesyje valdoma paslauga supaprastina daugelį aspektų, tačiau dėl atitikties ar konfidencialumo politikos galite norėti absoliučios žurnalų saugojimo vietos kontrolės , todėl verta rinktis vietinius arba hibridinius modelius.
Sąlygos, taisyklės ir žiniatinklio ACL: kaip WAF nusprendžia, ar blokuoti, leisti, ar tik registruoti
Nepriklausomai nuo gamintojo, visi šiuolaikiniai WAF yra pagrįsti prieigos sąlygų, taisyklių ir politikų koncepcija . Šios sąvokos supratimas yra labai svarbus norint sėkmingai naudoti skaičiavimo, registravimo ir užrakinimo režimus gamyboje.
Sąlygos apibūdina , kuri užklausos dalis yra tikrinama: šaltinio IP, konkrečios HTTP antraštės (pagrindinis kompiuteris, vartotojo agentas, priėmimas, turinio tipas...), užklausos parametrai, užklausos tekstas, slapukai, HTTP metodas, kilmės šalis ir kt. Pavyzdžiui, „AWS WAF Classic“ galite apibrėžti IP sąlygą su iki 10 000 adresų ar diapazonų arba eilutės atitikimo sąlygą URL daliai.
Taisyklės sujungia vieną ar daugiau sąlygų ir priskiria ketinimą: leisti, blokuoti arba skaičiuoti. Kai taisyklė turi kelias sąlygas, jos paprastai įvertinamos loginiu operatoriumi IR : kad taisyklė būtų suaktyvinta, turi būti įvykdytos visos sąlygos. Įprasta taisyklė be sąlygų praktiškai nieko neatitinka ir jos veiksmas niekada nesuaktyvinamas.
Daugelis WAF, įskaitant AWS WAF, taip pat turi greičio pagrindu veikiančias taisykles . Šios taisyklės skaičiuoja užklausas, gaunamas iš IP adreso (arba IP adresų rinkinio, atitinkančio tam tikras sąlygas) per tam tikrą laiko tarpą, pavyzdžiui, penkias minutes. Jei viršijama riba, pvz., 1.000 užklausų per penkias minutes, taisyklė įsigalioja: blokuojama arba tiesiog skaičiuojama. Tai labai naudinga:
- valdymas brutali jėga prisijungimo formose.
- Apribokite agresyvų duomenų išgavimą ar nemandagius robotus.
- Tam tikrų tipų DDoS atakų mažinimas programų lygmeniu.
Kitas lygis yra žiniatinklio ACL (prieigos valdymo sąrašas) . Čia taisyklės yra sugrupuotos, apibrėžiama vertinimo tvarka ir numatytasis veiksmas (LEIDŽTI arba BLOKUOTI). Užklausa pereina taisykles eilės tvarka; jei ji atitinka vieną taisyklę, taikomas jos veiksmas, o likusių vertinimas sustabdomas. Jei ji neatitinka jokios taisyklės, taikomas numatytasis ACL apibrėžtas veiksmas.
Kalbant apie registravimo ir blokavimo balansavimą, ACL yra ta vieta, kur galite nuspręsti, ar norite, kad sistema pagal numatytuosius nustatymus būtų leidžianti (LEIDŽIAMA ir blokuojama tik pagal konkrečias taisykles) , ar labai ribojanti (BLOKUOTI, išskyrus išimtinius atvejus). Be to, daugelis sprendimų leidžia nustatyti taisykles „skaičiuojimo“ režimu ACL viduje, kad jos registruotų atitikmenis, bet neblokuotų srauto – tai idealiai tinka derinimo etapui.
Baltieji sąrašai ir triukšmo mažinimas žurnaluose
Leidžiamieji sąrašai yra pagrindinė priemonė, skirta sumažinti klaidingai teigiamus rezultatus ir triukšmą žurnale . Idėja paprasta: tam tikrais atvejais nurodote WAF netaikyti direktyvos ar taisyklių rinkinio konkrečiam srautui, kurį jau priskyrėte prie patikimų arba kurį žinote esant teisėtą, bet neatitinkantį normos.
Pavyzdžiui, AWS WAF galite sukurti leidžiamųjų sąrašų taisykles, kad jei užklausa gaunama iš konkretaus IP adreso ar diapazono arba jei ji atitinka žinomą URL šabloną ir HTTP metodą, tam tikri parašų patikrinimai nebūtų taikomi. Tai padeda:
- Neleiskite vidinėms API sąsajoms, kurios naudoja „keistus“ šablonus generuoti nuolatinius klaidingus teigiamus duomenis.
- Sumažinkite delsą, atsirandančią dėl išsamios patikimo srauto analizės.
- Sumažinkite nereikalingų įrašų kiekį WAF žurnaluose.
Tokiose platformose kaip „ModSecurity“ rekomenduojama nekeisti standartinių taisyklių (pvz., „OWASP Core Rule Set“), o kurti konkrečias išimtis pagal taisyklės ID tam tikriems parametrams, keliams ar vartotojams. Tai leidžia išlaikyti bendrą apsaugą nesukuriant didelių pažeidžiamumų, išjungiant ištisas taisykles visoje svetainėje.
Svarbiausia – leistinuosius sąrašus taikyti chirurginiu , o ne visuotiniu būdu. Geriau neįtraukti konkretaus derinio (taisyklę X + parametrą Y URL Z), nei išjungti taisyklę X visuotinai. Tokiu būdu registravimas išliks naudingas ir nesukursite nereikalingų aklųjų zonų.
Protokolo taisyklės ir apribojimai: kada blokuoti, kada įspėti
Daugelyje WAF yra HTTP protokolo valymo taisyklių rinkinys, kuris veikia kaip pirmasis filtras netinkamai suformuotam arba įtartinam srautui . Šios taisyklės tikrina reikiamas antraštes, metodus, argumentų dydžius ir kt. ir yra dažnas geros apsaugos bei klaidingai teigiamų rezultatų šaltinis, jei jos nėra tinkamai suprantamos.
Keletas labai dažnų pavyzdžių:
- Trūksta patvirtinimo antraštės (Trūksta „Accept“ antraštės): Tai nėra griežtai RFC pažeidimas, tačiau daug užklausų be šios antraštės gaunamos iš automatizuotų įrankių arba prastai parašytų scenarijų. Tai gali paveikti pasirinktines API sąsajas arba klientus, kurie jos nesiunčia. Daugelyje aplinkų registravimas ir skaičiavimas yra geresnis pasirinkimas nei visiškas blokavimas.
- Trūksta pagrindinio kompiuterio antraštėsPagal HTTP/1.1 standartus, pagrindinio kompiuterio antraštė yra privaloma. WAF sistemoms ji taip pat reikalinga, kad būtų galima nustatyti, kurią politiką taikyti. Blokavimas čia paprastai yra pagrįstas, tačiau testavimo metu arba dėl netinkamai sukonfigūruoto vidinio srauto gali būti klaidingai teigiamas; prieš įjungiant griežtą blokavimą, patartina stebėti žurnalus.
- Trūksta vartotojo agento antraštėsŠi taisyklė bando pažaboti elementarius robotus ir neidentifikuotą srautą. Problema ta, kad daugelis teisėtų API gali nesiųsti vartotojo agento. Protingiausias būdas paprastai yra registruoti ir, jei aptinkama nuosekli ir teisėta API, įtraukti jų IP adresą arba šabloną į leidžiamųjų sąrašą.
- GET/HEAD patvirtinimas su tekstuNors RFC griežtai nedraudžia siųsti teksto su GET arba HEAD užklausomis, tai nėra įprasta praktika ir gali rodyti bandymus apeiti užklausas. Daugeliu atvejų pirmas žingsnis yra užregistruoti visas šias užklausas ir, jei jos nustatomos kaip įtartinos anomalijos, jas blokuoti.
- Trūksta turinio tipo su tekstuJei yra tekstas, bet nėra turinio tipo (Content-Type), tai aiškiai rodo netinkamą protokolo naudojimą arba bandymą išvengti analizės. Tokiais atvejais paprastai prasmingas agresyvesnis blokavimo metodas, ypač interneto aplinkoje.
Be šių protokolo taisyklių, dažnai nustatomi argumentų apribojimai , siekiant apsaugoti nuo programų lygio perkrovų ir DoS atakų. Pavyzdžiui:
- Didžiausias argumentų skaičius vienai užklausai (pagal numatytuosius nustatymus, kai kuriuose WAF – 255).
- Didžiausias individualaus argumento ilgis (pavyzdžiui, 400 simbolių).
- Bendras visų argumentų dydis (pavyzdžiui, 64 000 baitų).
Šios vertės yra pagrįstos daugeliui programų, tačiau yra atvejų (sudėtingų formų įkėlimai, išplėstiniai filtrai, dideli JSON įkėlimai), kai pasitaiko klaidingai teigiamų rezultatų. Tokiais atvejais protingiausia pradėti nuo registravimo ir skaičiavimo , peržiūrėti, kurie galiniai taškai pažeidžia apribojimus, ir koreguoti tik tuos maršrutus, o ne panaikinti visus apribojimus visai svetainei.
Klaidingi teigiami rezultatai: kaip juos aptikti ir nenumirti bandant
Klaidingai teigiamas rezultatas yra teisėtas prašymas, kurį WAF identifikuoja kaip kenkėjišką ir blokuoja arba pažymi kaip ataką. Jų išvengti neįmanoma, ypač kai įjungti išsamūs taisyklių rinkiniai, pvz., OWASP CRS, tačiau juos galima profesionaliai valdyti, kad jie netaptų kasdieniu galvos skausmu.
Klaidingai teigiamų rezultatų aptikimas prasideda nuo kruopščios žurnalų peržiūros . Tai apima blokuojamų užklausų, jų suaktyvinimo ir konteksto, kuriame jos atsiranda, patikrinimą (URL, parametrai, naudotojas, kilmė ir kt.). Vizualiniai įrankiai ir ataskaitų suvestinės gali padėti nustatyti 403 klaidų padidėjimą arba neįprastus modelius.
Tiek debesijos paslaugų teikėjų, tiek „ModSecurity“ bendruomenės labai rekomenduojamas metodas yra naudoti modeliavimo arba skaičiavimo režimą . Šiuo režimu taisyklės, kurias norite išbandyti, registruoja kiekvieną atitikmenį, bet jų neblokuoja. Tai leidžia, pavyzdžiui, pamatyti, kiek teisėtų užklausų nauja SQLi taisyklė būtų užblokavusi, kol išdrįsote ją aktyvuoti gamybinėje aplinkoje.
Taip pat gera idėja išbandyti taisykles testavimo arba ikigamybinėje aplinkoje , kuri gauna realų arba imituojamą srautą. Tokios priemonės kaip OWASP ZAP arba srauto atkūrimo scenarijai gali padėti imituoti teisėtus modelius ir žinomas atakas, kad būtų galima patikrinti WAF elgesį.
Be to, labai svarbu atsižvelgti į klaidingai teigiamų rezultatų poveikį veiklai ir reputacijai: mokėjimų sutrikimai, vartotojų registracijos sutrikimai, kritiniai API iškvietimai, kurie nepavyksta be paaiškinimo – visa tai gali turėti tiesioginių nuostolių pajamoms ir prekės ženklo įvaizdžiui. Per didelis klaidingai teigiamų rezultatų skaičius taip pat apkrauna saugumo komandą įspėjimais, kurie nekuria pridėtinės vertės, todėl sunku nustatyti tikrus incidentus.
Strategijos taisyklėms koreguoti ir sumaniai naudoti registrą
Klaidingai teigiamų rezultatų valdymas nėra taisyklių išjungimas, kol „viskas veikia“, o WAF tikslus sureguliavimas chirurginiu tikslumu . Čia praverčia tokios gerosios praktikos:
Pirma, venkite taisyklių išjungimo visame pasaulyje. Pageidautina sukurti labai konkrečias išimtis : taisyklės ID neįtraukti tik į konkretų maršrutą, tam tikrus parametrus arba vidinį srautą. Tokiu būdu liksite apsaugoti likusioje programos dalyje ir tvarkysite naudingus žurnalus.
Antra, prieš blokuodami pasinaudokite skaičiavimo režimu . Naujų taisyklių aktyvavimas iš pradžių tik registravimo režimu leidžia įvertinti, kiek teisėtų užklausų būtų paveiktos. Tai galite papildyti SIEM įspėjimais, kad greitai aptiktumėte, ar taisyklė generuoja neįprastą atitikmenų kiekį.
Trečia, integruokite WAF su SIEM arba centralizuota registravimo platforma . Tai palengvina WAF įvykių koreliaciją su kitais rodikliais: neįprasta sistemos veikla, masinės autentifikacijos klaidomis, įtartinais konfigūracijos pakeitimais ir kt. Tai taip pat padeda nustatyti, kurias taisykles pirmiausia koreguoti, atsižvelgiant į įvykių sunkumą ir dažnumą.
Ketvirta, dokumentuokite kiekvieną pakeitimą: kuri taisyklė buvo patikslinta, kuriam galiniam taškui, kokiu pagrindu ir kokiais įrodymais. Tam gali būti naudinga peržiūrėti serverio vadovus . Ši dokumentacija ne tik padeda palaikyti vidaus kontrolę, bet ir yra neįkainojama atliekant saugumo auditus ir peržiūras, kai norite parodyti, kad kontrolės priemonės nėra išjungiamos lengvabūdiškai.
Automatizavimas, mašininis mokymasis ir adaptyvios taisyklės WAF
Augant programoms ir sudėtingėjant srautui, rankinis WAF valdymas tampa nerealus. Čia praverčia automatizavimas, pažangi žurnalų analizė ir, kai kuriais atvejais, mašininis mokymasis.
Pirma, integracija su SIEM leidžia kurti koreliacijos taisykles ir automatinius atsakymus : pavyzdžiui, jei IP adresų rinkinys pakartotinai suaktyvina injekcijos arba XSS taisykles, galite sugeneruoti automatinį veiksmą, kad tie IP adresai būtų įtraukti į laikiną blokuojamųjų sąrašą arba sustiprintas tikrinimo lygis.
Antra, kai kuriuose WAF yra mašininio mokymosi režimai , kurie stebi teisėtą srautą per nustatytą laikotarpį. Remdamiesi šiais duomenimis, jie siūlo arba koreguoja įprasto elgesio slenksčius, modelius ir profilius. Tai padeda sumažinti klaidingai teigiamų rezultatų skaičių, kai taisyklės perjungiamos į blokavimo režimą, ir aptikti vėlesnius srauto nukrypimus.
Moksliniuose ir laboratoriniuose tyrimuose prižiūrimo mokymosi metodai buvo naudojami modeliams, kurie atskiria teisėtą ir kenkėjišką srautą, apmokyti, tobulinant politikas, kurios vėliau naudojamos gamyboje. Nors tai nėra stebuklinga priemonė, šis metodas gali padėti atskleisti subtilius modelius , kurių klasikinės parašais pagrįstos taisyklės lengvai neaptinka.
Galiausiai, nuolatinis automatizuotas testavimas (naudojant tokius įrankius kaip OWASP ZAP, pasirinktinius scenarijus arba CI/CD srautus) leidžia patikrinti, ar WAF pakeitimai nesutrikdo kritinių funkcijų ir nepalieka akivaizdžių pažeidžiamumų. Integravus šiuos testus į diegimo ciklą, saugumas tampa natūralia kūrimo srauto dalimi, o ne paskutinės minutės pataisa.
Politikos kūrimas pagal programą ir juodieji sąrašai pagal paslaugą
Sudėtingose aplinkose, pavyzdžiui, prieglobos paslaugų teikėjo ar interneto paslaugų teikėjo, vienos WAF politikos nepakanka, ypač kai dalyvauja šešėlinė IT . Įprasta, kad už to paties apkrovos balansavimo įrenginio yra keli domenai arba programos, kurių kiekvienas turi skirtingus saugumo poreikius ir srauto profilius . Būtent čia labai svarbu sukurti konkrečioms paslaugoms skirtas politikas ir sąrašus.
Iliustracinis pavyzdys yra HTTP/S apkrovos balansavimo įrenginys, veikiantis kaip atvirkštinis tarpinis serveris kelioms svetainėms (pvz., www.company1.com ir www.company2.com), esančioms už vieno virtualaus IP adreso. Tokiu atveju WAF galima sukonfigūruoti taip, kad įvertintų pagrindinio kompiuterio antraštę ir šaltinio IP adresą, kai tik gaunama užklausa, dar prieš jai pasiekiant apkrovos balansavimo modulį.
Logika būtų maždaug tokia: WAF patikrina, ar SERVER_NAME (pagrindinio kompiuterio) ir kliento IP adreso derinys atitinka konkrečios svetainės juodąjį sąrašą. Jei IP adresas yra nurodytas kaip blokuojamas www.company2.com, bet ne www.company1.com, 403 Forbidden atsakymas siunčiamas tik pirmuoju atveju. „Švarus“ srautas tada perduodamas apkrovos balansavimo moduliui, kuris nusprendžia, kuri serverio dalis aptarnauja užklausą.
Tai leidžia, pavyzdžiui, tvarkyti konkrečiam domenui skirtus juoduosius sąrašus , o ne vieną bendrą sąrašą visam prieigos taškui. Registravimo lygmenyje kiekvienas atmetimas įrašomas į sistemos žurnalą su tokia informacija kaip taisyklės ID, atitinkanti sąlyga, URL, pagrindinis kompiuteris ir kliento IP adresas, o tai palengvina vėlesnę šių sąrašų analizę ir išplėtimą arba derinimą.
Šios istorijos moralas yra tas, kad kuo labiau segmentuotos jūsų politikos (pagal programą, aplinką, vartotojo tipą), tuo geriau galite rasti pusiausvyrą tarp registravimo ir blokavimo: galite būti labai griežti administraciniuose portaluose ir šiek tiek lankstesni informacinėse svetainėse, pavyzdžiui, visada žurnaluose pateikdami įrodymus, kodėl buvo priimtas kiekvienas sprendimas.
Už klasikinio WAF ribų: WAAP ir API apsauga
Grėsmių sritis nestovi vietoje. Šiandien daugelis programų yra sukurtos debesyje, naudoja mikropaslaugų architektūras ir nelegaliai veikia viešose bei privačiose API sąsajose , todėl tampa pagrindiniais užpuolikų taikiniais. Tradiciniai WAF išsivystė į platesnes platformas, žinomas kaip WAAP (žiniatinklio programų ir API apsauga) arba WAAS (žiniatinklio programų ir API saugumas).
Šie sprendimai ne tik automatiškai aptinka žiniatinklio programas, bet ir identifikuoja API galinius taškus , priima tokias specifikacijas kaip „OpenAPI“ arba „Swagger“ ir naudoja tą apibrėžimą užklausų atitikčiai patikrinti: numatomus duomenų tipus, leidžiamus parametrus, dydžio apribojimus ir kt. Priklausomai nuo galinio taško (pavyzdžiui, tokio, kuris tvarko labai jautrius duomenis), gali būti taikomas daug aukštesnis tikrinimo ir blokavimo lygis.
Registravimo lygmeniu WAAP linkęs generuoti kontekstinius įvykius : kuris tikslus API galinis taškas buvo užpultas, kokia operacija (GET, POST, PUT…), kuris vartotojas ar prieigos raktas buvo susijęs, kuri specifikacijos dalis buvo pažeista ir kt. Tai leidžia priimti tikslesnius blokavimo sprendimus, o ne pasikliauti vien bendrais naudingosios apkrovos modeliais.
Be to, daugelis WAAP įrankių apima programoms ir API pritaikytą DoS apsaugą, geolokacijos filtravimą, IP reputacijos valdymą, botų ir duomenų išgavimo aptikimą bei parinktis, leidžiančias pritaikyti įspėjimų lygius kiekvienai paslaugai. Vėlgi, svarbiausia yra turėti lankstumo nuspręsti, kur norite patikimesnio požiūrio ir kur teikti pirmenybę sklandžiam veikimui , neaukojant patikimos žurnalų duomenų bazės, skirtos bet kokiems incidentams tirti.
Apibendrinant, gerai suderintas WAF – nesvarbu, ar klasikinis, pagrįstas WAAP, ar integruotas į debesijos ekosistemą – tampa esminiu šiuolaikinių programų ir API gynybos komponentu, gebančiu derinti išsamų registravimą, intelektualų blokavimą ir nuolatinį prisitaikymą prie kintančio grėsmių kraštovaizdžio.
