Ekuilibri midis regjistrimit dhe bllokimit në WAF

Informatec Digital » Burime » Balancimi i Regjistrimit dhe Bllokimit në WAF

Gjetja e ekuilibrit të duhur midis regjistrimit dhe bllokimit në një WAF është bërë një nga problemet më të zakonshme për ekipet e sigurisë dhe operacioneve. Një firewall i aplikacionit web mund të ndalojë sulme shumë serioze, por nëse konfigurohet shumë agresivisht, ai mund të bllokojë blerjet legjitime, aksesin ose thirrjet API. Nëse konfigurohet shumë lirshëm, ai përfundon duke qenë pothuajse thjesht dekorativ. Çelësi është të rregulloni me kujdes kur të regjistroheni, kur të numëroni, kur të lejoni dhe kur të bllokoni.

Në këtë artikull, do të shqyrtojmë se si ta arrijmë këtë ekuilibër duke përdorur aftësitë moderne WAF (listat e lejimeve, rregullat e bazuara në frekuencë, mënyrat e të mësuarit, integrimin SIEM, të mësuarit automatik, etj.), të mbështetura nga shembuj konkretë nga AWS WAF, ModSecurity, WAF-të e bazuara në cloud dhe zgjidhjet lokale . Do të shihni se si të kufizoni pozitivët e rremë pa ulur nivelin e mbrojtjes, si të organizoni politikat sipas aplikacionit dhe si të përdorni regjistrimin si një aleat, jo si një burim të vazhdueshëm dhe të pakontrollueshëm zhurme.

Çfarë është një WAF dhe pse është kaq i rëndësishëm regjistrimi?

Një firewall i aplikacionit web vepron si një shtresë inteligjente midis përdoruesit dhe serverit , duke analizuar trafikun HTTP/HTTPS në kohë reale. Ndryshe nga një firewall tradicional i rrjetit, i cili monitoron portet dhe IP-të, një WAF shkon më thellë: URL-të, parametrat, trupat e kërkesave, titujt, cookie-t, metodat HTTP dhe më shumë.

Misioni i tij është të zbulojë dhe ndalojë sulmet tipike të Shtresës 7 : injektimi SQL, XSS, LFI/RFI, sulmet kundër kontrollit të aksesit, abuzimi me API-të, scraping agresiv, forca brutale dhe madje edhe disa modele DDoS në nivel aplikacioni. Për ta bërë këtë, ai mbështetet në grupe rregullash, nënshkrimesh dhe politikash sigurie që përditësohen vazhdimisht.

Regjistrimi është ana tjetër e medaljes. Çdo vendim i WAF-it - lejo, blloko ose vetëm numëro - mund të shoqërohet nga një ngjarje e detajuar në regjistra . Këto regjistra lejojnë:

• Hetoni incidentet: rindërtoni çfarë ndodhi dhe si u bë një përpjekje për të shfrytëzuar një dobësi.
• Rregullo rregullat: zbulon pozitivet e rreme duke parë se cilat kërkesa legjitime po bllokon WAF.
• Përmbush rregulloretdemonstrojnë se ekzistojnë kontrolle aktive (PCI DSS, GDPR, auditime të brendshme, etj.).
• Ushqyerja e një SIEMlidh sulmet e aplikacioneve me ngjarjet e rrjetit, sistemit, identitetit etj.

Problemi është se një WAF i akorduar dobët mund të mbushë regjistrat me mijëra ngjarje të parëndësishme , duke e bërë të pamundur gjetjen e asaj që është e rëndësishme dhe, për më tepër, duke shkaktuar refuzime të pajustifikuara të trafikut të ligjshëm. Këtu hyn në lojë arti i të luajturit me mënyrat e regjistrimit, numërimit dhe bllokimit.

Modelet e sigurisë në WAF: listat e bllokimit, listat e lejimit dhe një qasje hibride

Shumica e WAF-ve moderne kombinojnë disa qasje filtrimi, të cilat ndikojnë drejtpërdrejt në mënyrën se si regjistrohen dhe bllokohen kërkesat . Në përgjithësi, mund të identifikojmë dy filozofi klasike, plus një model hibrid shumë të zakonshëm.

Një WAF i bazuar në listën e bllokimeve ndjek një model sigurie negative. Parimi i tij thelbësor është: "Unë lejoj gjithçka përveç asaj që e di se është keqdashëse". Funksionon duke përdorur nënshkrime të sulmeve të njohura (injektim SQL, XSS, modele bot-esh, etj.) dhe rregulla që përcaktojnë se çfarë konsiderohet e dyshimtë. Është më e lehtë për t'u vendosur fillimisht, por mbështetja vetëm në këtë model rrezikon të lejojë që vektorë ose variante të reja sulmi të kalojnë pa u zbuluar.

Një WAF me një listë lejimesh funksionon në të kundërt: "bllokoni gjithçka përveç asaj që lejohet shprehimisht". Bazohet në një model sigurie pozitive. Pranohet vetëm trafiku që i përshtatet sjelljes së përcaktuar legjitime - rrugët, metodat, parametrat, formatet, madhësitë, etj. Është shumë më i sigurt, por kërkon rregullime të konsiderueshme dhe mund të gjenerojë pozitivë të rremë fillimisht nëse nuk përgatitet siç duhet.

Për shkak të avantazheve dhe disavantazheve të secilës qasje, një model hibrid që kombinon listat e lejimeve dhe listat e bllokimit po bëhet gjithnjë e më i zakonshëm . Në këtë skenar, përcaktohen profilet e trafikut të pritur (për shembull, çfarë përbën një hyrje normale ose kërkesë pagese) dhe nënshkrimet dhe heuristikat aplikohen njëkohësisht për të zbuluar modelet tipike keqdashëse. Për qëllime regjistrimi, kjo qasje hibride lejon:

• Shëno si ngjarje me rrezik të lartë që shkel listën e artikujve të lejuar.
• Trajto si alarme me përparësi të mesme/të ulët modelet e përgjithshme të listës së bllokimeve.
• Përdorni modalitetin "numëro" për të parë se çfarë do të shkelte një rregull përpara se të aktivizoni bllokun.

WAF në rrjet, në host dhe në cloud: ndikimi në regjistrimin dhe bllokimin

Modeli i vendosjes WAF ndikon shumë në mënyrën se si trajtohet regjistrimi dhe bllokimi i trafikut. Regjistrimi i kërkesave në një pajisje rrjeti nuk është i njëjtë me regjistrimin e tyre në një agjent brenda serverit ose në një shërbim të menaxhuar në cloud.

Një WAF i bazuar në rrjet zakonisht vendoset si një pajisje fizike ose virtuale brenda infrastrukturës, midis internetit dhe aplikacioneve. Kjo është qasja klasike e përdorur nga prodhues si F5. Ofron avantazhin e performancës së lartë dhe kontrollit të detajuar , por konfigurimi dhe menaxhimi mund të jenë kompleksë. Regjistrimi zakonisht dërgohet në syslog ose në një SIEM qendror, dhe është e rëndësishme të filtrohet me kujdes ajo që ruhet për të shmangur mbingarkesën e mjeteve të ruajtjes dhe analizës, si dhe për të diagnostikuar problemet në rrjetet IP dhe DNS.

WAF -et e bazuara në host funksionojnë në të njëjtët servera (ose kontejnerë) ku ndodhet aplikacioni, zakonisht si modul ose agjent (për shembull, ModSecurity i integruar në Nginx ose Apache; kombinimi i tij me forcimin e Linux duke përdorur SELinux përmirëson gjendjen e sigurisë). Ky model lejon një kontekst më të madh të aplikacionit dhe rregulla shumë specifike për shërbim, me koston e konsumimit të burimeve lokale dhe kërkimit të një menaxhimi më të shpërndarë të regjistrave. Regjistrat mund të ruhen në skedarë lokalë dhe më pas të përcillen ose të integrohen me shërbime të centralizuara të regjistrimit.

WAF -të e bazuara në cloud (Cloudflare, Akamai, Imperva Cloud, AWS WAF, etj.) integrohen me balancuesit e ngarkesës, CDN-të ose rrjetet virtuale. Ofruesit zakonisht ofrojnë panele dhe eksport të regjistrave në S3, BigQuery, remote syslogs ose SIEM. Ato janë përgjithësisht më të lehta për t'u konfiguruar, por ju duhet t'i përshtatni politikat tuaja të regjistrimit sipas modelit të ofruesit: llojet e ngjarjeve, periudhat e ruajtjes, filtrat e ashpërsisë, etj.

Zgjedhja e një modeli ose tjetrit nuk është vetëm një vendim teknik, por edhe një çështje se si dëshironi të balanconi regjistrimin dhe bllokimin: një shërbim i menaxhuar nga cloud-i thjeshton shumë aspekte, por mund të dëshironi kontroll absolut mbi vendin ku ruhen regjistrimet për shkak të politikave të pajtueshmërisë ose konfidencialitetit, gjë që ju shtyn drejt modeleve lokale ose hibride.

Kushtet, rregullat dhe ACL-të në internet: si vendos WAF nëse do të bllokojë, lejojë apo vetëm do të regjistrojë

Pavarësisht prodhuesit, të gjitha WAF-et moderne bazohen në konceptin e kushteve, rregullave dhe politikave të aksesit . Të kuptuarit e kësaj është çelësi për përdorimin me sukses të mënyrave të numërimit, regjistrimit dhe kyçjes në prodhim.

Kushtet përshkruajnë se cila pjesë e kërkesës inspektohet: IP-ja e burimit, titujt specifikë HTTP (Host, User-Agent, Accept, Content-Type…), parametrat e pyetjes, trupi i kërkesës, cookie-t, metoda HTTP, vendi i origjinës, etj. Për shembull, në AWS WAF Classic mund të përcaktoni një kusht IP me deri në 10.000 adresa ose diapazone, ose një kusht përputhjeje vargu në një pjesë të URL-së.

Rregullat kombinojnë një ose më shumë kushte dhe caktojnë një qëllim: të lejojë, të bllokojë ose të numërojë. Kur një rregull ka kushte të shumëfishta, ato zakonisht vlerësohen me një DHE logjike : të gjitha kushtet duhet të përmbushen që rregulli të aktivizohet. Një rregull normal pa kushte, në praktikë, nuk përputhet me asgjë dhe veprimi i tij nuk aktivizohet kurrë.

Shumë WAF, përfshirë AWS WAF, kanë gjithashtu rregulla të bazuara në shpejtësi . Këto rregulla numërojnë kërkesat që vijnë nga një adresë IP (ose grup adresash IP që plotësojnë kushte të caktuara) gjatë një dritareje kohore, për shembull, pesë minuta. Nëse tejkalohet një prag - le të themi, 1.000 kërkesa në pesë minuta - rregulli hyn në fuqi: bllokimi ose thjesht numërimi. Kjo është shumë e dobishme për:

• kontroll forcë brutale mbi format e hyrjes.
• Kufizoni ngacmimet agresive ose botët e paedukatë.
• Zbutja e llojeve të caktuara të sulmeve DDoS në nivelin e aplikacionit.

Niveli tjetër është Web ACL (Lista e Kontrollit të Qasjes) . Këtu, rregullat grupohen dhe përcaktohen një renditje vlerësimi dhe një veprim i parazgjedhur (ALLOW ose BLOCK). Një kërkesë kalon nëpër rregullat sipas radhës; nëse përputhet me një, veprimi i saj zbatohet dhe vlerësimi i pjesës tjetër ndalet. Nëse nuk përputhet me asnjë rregull, zbatohet veprimi i parazgjedhur i përcaktuar në ACL.

Për sa i përket balancimit të regjistrimit dhe bllokimit, ACL është vendi ku vendosni nëse dëshironi që sistemi të jetë lejues si parazgjedhje (LEJO dhe bllokon vetëm nga rregulla specifike) apo shumë kufizues (BLOKO përveç në raste të jashtëzakonshme). Për më tepër, shumë zgjidhje ju lejojnë të vendosni rregulla në modalitetin "numërim" brenda ACL-së, në mënyrë që ato të regjistrojnë përputhjet, por të mos bllokojnë trafikun - ideale për fazën e akordimit.

Listat e bardha dhe ulja e zhurmës në regjistra

Listat e lejimeve janë një mjet themelor për të zvogëluar pozitivët e rremë dhe zhurmën në regjistër . Ideja është e thjeshtë: në kontekste të caktuara, ju i thoni WAF-it të mos zbatojë një direktivë ose një sërë rregullash për trafik specifik që e keni kategorizuar tashmë si të besueshëm ose që e dini se është jashtë normës, por legjitim.

Për shembull, në AWS WAF mund të krijoni rregulla të listës së lejimeve në mënyrë që nëse një kërkesë vjen nga një adresë ose diapazon specifik IP , ose nëse përputhet me një model URL dhe metodë HTTP të njohur, të mos zbatohen inspektime të caktuara të nënshkrimit. Kjo ndihmon për të:

• Parandaloni API-të e brendshme që përdorin modele "të çuditshme" gjeneron pozitivë të rremë të vazhdueshëm.
• Zvogëloni vonesën e shkaktuar nga inspektimi i thellë në trafikun që tashmë e konsideroni të besueshëm.
• Zvogëloni vëllimin e të dhënave të panevojshme në regjistrat WAF.

Në platforma si ModSecurity, qasja e rekomanduar nuk është modifikimi i rregullave standarde (p.sh., OWASP Core Rule Set), por krijimi i përjashtimeve specifike sipas ID-së së rregullit për parametra, shtigje ose përdorues të caktuar. Kjo ju lejon të ruani mbrojtjen e përgjithshme pa krijuar dobësi të mëdha duke çaktivizuar të gjitha rregullat në të gjithë faqen.

Çelësi është që listat e lejimeve të jenë kirurgjikale , jo një qasje gjithëpërfshirëse. Është shumë më mirë të përjashtohet një kombinim specifik (rregulli X + parametri Y në URL-në Z) sesa të çaktivizohet rregulli X globalisht. Në këtë mënyrë, regjistrimi mbetet i dobishëm dhe nuk krijoni pika të verbëra të panevojshme.

Rregullat dhe kufizimet e protokollit: kur të bllokohet, kur të paralajmërohet

Shumë WAF përfshijnë një sërë rregullash të pastrimit të protokollit HTTP që veprojnë si një filtër i parë për trafikun e keqformuar ose të dyshimtë . Këto rregulla kontrollojnë titujt, metodat, madhësitë e argumenteve etj. të kërkuara, dhe janë një burim i shpeshtë si i mbrojtjes së mirë ashtu edhe i pozitivëve të rremë nëse nuk kuptohen siç duhet.

Disa shembuj shumë të zakonshëm:

• Mungon koka e pranimit (Mungon koka e pranimit): Kjo nuk është rreptësisht një shkelje e RFC-së, por shumë kërkesa pa këtë kokë vijnë nga mjete të automatizuara ose skripte të shkruara dobët. Mund të ndikojë në API-të e personalizuara ose klientët që nuk e dërgojnë atë. Në shumë mjedise, regjistrimi dhe numërimi preferohen më shumë sesa bllokimi i plotë.
• Mungon koka e strehuesitSipas standardeve HTTP/1.1, koka e Host është e detyrueshme. WAF-të gjithashtu kanë nevojë për të përcaktuar se cilën politikë duhet të aplikojnë. Bllokimi këtu është zakonisht i arsyeshëm, por mund të gjenerojë pozitive të rreme gjatë testimit ose për shkak të trafikut të brendshëm të konfiguruar gabimisht; këshillohet të monitorohen regjistrat përpara se të aktivizohet bllokimi i rreptë.
• Mungon koka e agjentit të përdoruesitKy rregull përpiqet të frenojë botët rudimentare dhe trafikun e paidentifikuar. Problemi është se shumë API të ligjshme mund të mos dërgojnë një Agjent Përdoruesi. Qasja më e arsyeshme është zakonisht të regjistroheni dhe, nëse zbulohet një API i qëndrueshëm dhe i ligjshëm, shtoni IP-në ose modelin e tyre në një listë të lejuar.
• Validimi GET/HEAD me trupinEdhe pse RFC nuk e ndalon rreptësisht dërgimin e trupit me kërkesa GET ose HEAD, kjo nuk është praktikë e zakonshme dhe mund të tregojë përpjekje për shmangie. Në shumë raste, hapi i parë është të regjistrohen të gjitha këto kërkesa dhe, nëse gjenden anomali të dyshimta, të vazhdohet me bllokimin e tyre.
• Mungon Lloji i Përmbajtjes me trupNëse ka një trup por jo Lloj Përmbajtjeje, ky është një tregues i qartë i përdorimit të papërshtatshëm të protokollit ose një përpjekje për të shmangur analizën. Në këto raste, një qasje më agresive bllokimi zakonisht ka kuptim, veçanërisht në mjediset me internet.

Përveç këtyre rregullave të protokollit, shpesh gjenden kufizime argumentesh për të mbrojtur kundër përmbytjeve në nivel aplikacioni dhe sulmeve DoS. Për shembull:

• Numri maksimal i argumenteve për kërkesë (si parazgjedhje, 255 në disa WAF).
• Gjatësia maksimale e një argumenti individual (për shembull, 400 karaktere).
• Madhësia totale e kombinuar e të gjitha argumenteve (për shembull, 64.000 bajt).

Këto vlera janë të arsyeshme për shumë aplikacione, por ka raste - ngarkime komplekse formularësh, filtra të avancuar, ngarkesa të mëdha JSON - ku ndodhin pozitive të rreme. Në këto skenarë, qasja më e kujdesshme është të fillohet duke regjistruar dhe numëruar , të rishikohet se cilat pika fundore po thyejnë kufijtë dhe të përshtatet vetëm për ato rrugë, në vend që të hiqen të gjitha kufijtë për të gjithë faqen.

Pozitivë të rremë: si t'i zbulojmë dhe të mos vdesim duke u përpjekur

Një pozitiv i rremë është një kërkesë legjitime që WAF e identifikon si keqdashëse dhe e bllokon ose e sinjalizon si sulm. Ato janë të pashmangshme, veçanërisht kur keni të aktivizuara grupe rregullash gjithëpërfshirëse si OWASP CRS, por ato mund të menaxhohen profesionalisht në mënyrë që të mos bëhen një dhimbje koke e përditshme.

Zbulimi i rezultateve pozitive të rreme fillon me një shqyrtim të kujdesshëm të regjistrave . Kjo përfshin shqyrtimin e kërkesave që po bllokohen, cili rregull i aktivizon ato dhe kontekstin në të cilin ndodhin (URL, parametrat, përdoruesi, origjina, etj.). Mjetet vizuale dhe panelet mund të ndihmojnë në identifikimin e rritjes së gabimeve 403 ose modeleve të pazakonta.

Një qasje shumë e rekomanduar, si nga ofruesit e cloud-it ashtu edhe nga komuniteti i ModSecurity, është përdorimi i një modaliteti simulimi ose numërimi . Në këtë modalitet, rregullat që dëshironi të testoni regjistrojnë çdo përputhje, por nuk i bllokojnë. Kjo ju lejon të shihni, për shembull, se sa kërkesa legjitime do të kishte bllokuar një rregull i ri SQLi përpara se të guxonit ta aktivizonit atë në prodhim.

Është gjithashtu një ide e mirë të testoni rregullat në një mjedis skenik ose para-prodhimi që merr trafik real ose të simuluar. Mjete si OWASP ZAP ose skriptet e riprodhimit të trafikut mund t'ju ndihmojnë të simuloni modele legjitime dhe sulme të njohura për të testuar sjelljen e WAF-it.

Për më tepër, është thelbësore të merret në konsideratë ndikimi operacional dhe reputacional i pozitivëve të rremë: ndërprerjet e pagesave, dështimet në regjistrimin e përdoruesve, thirrjet kritike të API-t që dështojnë pa shpjegim - të gjitha këto mund të kenë një kosto të drejtpërdrejtë në të ardhura dhe imazhin e markës. Një tepricë e pozitivëve të rremë gjithashtu e mbingarkon ekipin e sigurisë me alarme që nuk shtojnë vlerë, duke e bërë të vështirë identifikimin e incidenteve të vërteta.

Strategji për rregullimin e rregullave dhe përdorimin inteligjent të regjistrit

Menaxhimi i pozitivëve të rremë nuk ka të bëjë me çaktivizimin e rregullave derisa "gjithçka të funksionojë", por me rregullimin e hollësishëm të WAF-së me saktësi kirurgjikale . Këtu hyjnë në lojë praktikat e mira si më poshtë:

Së pari, shmangni çaktivizimin e rregullave globalisht. Është e preferueshme të krijoni përjashtime shumë specifike : përjashtoni ID-në e rregullit vetëm për një rrugë të caktuar, për parametra të caktuar ose për trafikun e brendshëm. Në këtë mënyrë, ju mbeteni të mbrojtur në pjesën tjetër të aplikacionit dhe mirëmbani regjistra të dobishëm.

Së dyti, përfitoni nga modaliteti i numërimit përpara se të bllokoni. Aktivizimi i rregullave të reja fillimisht vetëm në modalitetin e regjistrimit ju lejon të matni se sa kërkesa legjitime do të preken. Mund ta plotësoni këtë me alarme në SIEM për të zbuluar shpejt nëse një rregull po gjeneron një vëllim jonormal përputhjesh.

Së treti, integroni WAF-in me një SIEM ose një platformë të centralizuar regjistrimi . Kjo e bën më të lehtë lidhjen e ngjarjeve WAF me tregues të tjerë: aktivitet të pazakontë të sistemit, dështime të vërtetimit masiv, ndryshime të dyshimta të konfigurimit, etj. Gjithashtu ndihmon në përcaktimin e përparësive se cilat rregulla duhen përshtatur të parat bazuar në ashpërsinë dhe frekuencën e ngjarjeve.

Së katërti, dokumentoni çdo ndryshim: cili rregull është përmirësuar, për cilën pikë fundore, me çfarë justifikimi dhe me çfarë provash. Konsultimi i manualeve të serverit mund të jetë i dobishëm për këtë. Ky dokumentacion jo vetëm që ndihmon në ruajtjen e kontrollit të brendshëm, por është gjithashtu i paçmuar në auditimet dhe rishikimet e sigurisë, ku doni të tregoni se kontrollet nuk çaktivizohen lehtë.

Automatizimi, mësimi automatik dhe rregullat adaptive në WAF

Ndërsa aplikacionet rriten dhe trafiku bëhet më kompleks, menaxhimi manual i WAF-it bëhet jorealist. Këtu hyn në lojë automatizimi, analiza e avancuar e regjistrave dhe, në disa raste, mësimi automatik.

Së pari, integrimi me SIEM ju lejon të ndërtoni rregulla korrelacioni dhe përgjigje të automatizuara : për shembull, nëse një grup IP-sh aktivizon në mënyrë të përsëritur rregullat e injektimit ose XSS, mund të gjeneroni një veprim automatik për t'i shtuar ato IP në një listë bllokimi të përkohshme ose për të forcuar nivelin e inspektimit.

Së dyti, disa WAF përfshijnë mënyra të të mësuarit automatik që vëzhgojnë trafikun legjitim gjatë një periudhe të përcaktuar. Bazuar në këto të dhëna, ato propozojnë ose rregullojnë pragje, modele dhe profile të sjelljes normale. Kjo ndihmon në zvogëlimin e pozitivëve të rremë kur rregullat kalojnë në modalitetin e bllokimit dhe zbulojnë devijimet pasuese të trafikut.

Në mjediset kërkimore dhe laboratorike, teknikat e të mësuarit të mbikëqyrur janë përdorur për të trajnuar modele që dallojnë trafikun legjitim dhe atë keqdashës, duke rafinuar politikat që përdoren më pas në prodhim. Ndonëse nuk është një zgjidhje magjike, kjo qasje mund të ndihmojë në zbulimin e modeleve delikate që rregullat klasike të bazuara në nënshkrime nuk i zbulojnë lehtë.

Së fundmi, testimi i vazhdueshëm i automatizuar (duke përdorur mjete si OWASP ZAP, skripte të personalizuara ose tubacione CI/CD) ju lejon të vërtetoni që ndryshimet në WAF nuk prishin funksionalitetin kritik ose nuk lënë dobësi të dukshme. Integrimi i këtyre testeve në ciklin e implementimit e bën sigurinë një pjesë natyrale të rrjedhës së zhvillimit, në vend të një përditësimi të minutës së fundit.

Hartimi i politikave për çdo aplikim dhe listat e zeza për çdo shërbim

Në mjedise komplekse - për shembull, një ofrues hosting ose një ISP - një politikë e vetme WAF nuk është e mjaftueshme, veçanërisht kur përfshihet IT në hije . Është e zakonshme të kesh domene ose aplikacione të shumta pas të njëjtit balancues ngarkese, secila me nevoja të ndryshme sigurie dhe profile trafiku . Këtu bëhet thelbësore hartimi i politikave dhe listave specifike për shërbimin.

Një shembull ilustrues është një balancues ngarkese HTTP/S që vepron si një ndërmjetës i kundërt për faqe të shumta (p.sh., www.company1.com dhe www.company2.com) pas një adrese të vetme IP virtuale. Në këtë skenar, WAF mund të konfigurohet për të vlerësuar kokën e Hostit dhe adresën IP të burimit sapo të mbërrijë kërkesa, madje edhe para se të arrijë në modulin e balancimit të ngarkesës.

Logjika do të ishte diçka e tillë: WAF kontrollon nëse kombinimi i SERVER_NAME (Host) dhe IP-së së klientit përputhet me një listë të zezë specifike për faqen. Nëse IP është e listuar si e bllokuar për www.company2.com, por jo për www.company1.com, një përgjigje 403 Forbidden dërgohet vetëm në rastin e parë. Trafiku "i pastër" i kalohet më pas modulit të balancimit të ngarkesës, i cili vendos se cili backend e shërben kërkesën.

Kjo lejon mirëmbajtjen, për shembull, të listave të zeza specifike për domenin , në vend të një liste të vetme globale për të gjithë pikën e aksesit. Në nivelin e regjistrimit, çdo refuzim regjistrohet në syslog me detaje të tilla si ID-ja e rregullit, kushti i përputhur, URL-ja, hosti dhe adresa IP e klientit, duke lehtësuar analizën pasuese dhe zgjerimin ose debugging-un e këtyre listave.

Morali i historisë është se sa më të segmentuara të jenë politikat tuaja (sipas aplikacionit, sipas mjedisit, sipas llojit të përdoruesit), aq më mirë mund të arrini ekuilibrin midis regjistrimit dhe bllokimit: mund të jeni shumë të rreptë në portalet administrative dhe disi më fleksibël në faqet e internetit informative, për shembull, gjithmonë me prova në regjistrime se pse është marrë secili vendim.

Përtej WAF klasik: Mbrojtja WAAP dhe API

Peizazhi i kërcënimeve nuk ka mbetur në vend. Sot, shumë aplikacione janë të orientuara drejt cloud-it, përdorin arkitektura mikroshërbimesh dhe ekspozojnë API-të publike dhe private , duke i bërë ato objektiva kryesore për sulmuesit. WAF-të tradicionale kanë evoluar në platforma më të gjera të njohura si WAAP (Mbrojtja e Aplikacioneve Web dhe API-ve) ose WAAS (Siguria e Aplikacioneve Web dhe API-ve).

Këto zgjidhje jo vetëm që zbulojnë automatikisht aplikacionet web, por gjithashtu identifikojnë pikat fundore të API-t , pranojnë specifikime si OpenAPI ose Swagger dhe e përdorin atë përkufizim për të kontrolluar përputhshmërinë e kërkesave: llojet e të dhënave të pritura, parametrat e lejuar, kufijtë e madhësisë, etj. Në varësi të pikës fundore (për shembull, një që trajton të dhëna shumë të ndjeshme), mund të zbatohet një nivel shumë më i lartë shqyrtimi dhe bllokimi.

Në nivelin e regjistrimit, WAAP tenton të gjenerojë ngjarje të pasura me kontekst : cila pikë fundore e saktë e API-t u sulmua, cili operacion (GET, POST, PUT…), cili përdorues ose token ishte i përfshirë, cila pjesë e specifikimit u shkel, etj. Kjo lejon vendime më të sakta bllokimi, në vend që të mbështetet vetëm në modelet gjenerike të ngarkesës.

Për më tepër, shumë mjete WAAP përfshijnë mbrojtje DoS specifike për aplikacionin dhe API-në, filtrim të gjeolokacionit, menaxhim të reputacionit të IP-së, zbulim të botëve dhe scraping-ut, dhe opsione për të personalizuar nivelet e alarmit për shërbim. Përsëri, ka të bëjë me fleksibilitetin për të vendosur se ku dëshironi një qasje më të fuqishme dhe ku dëshironi të përparësoni funksionimin e qetë , pa sakrifikuar një bazë të dhënash të fortë regjistrash për hetimin e çdo incidenti.

Të marra së bashku, një WAF i akorduar mirë - qoftë klasik, i bazuar në WAAP apo i integruar në një ekosistem cloud - bëhet një komponent thelbësor i mbrojtjes moderne të aplikacioneve dhe API-ve, i aftë të kombinojë regjistrimin e detajuar, bllokimin inteligjent dhe përshtatjen e vazhdueshme ndaj peizazhit në ndryshim të kërcënimeve.