Veebirakenduse tulemüüris olevad alalised tuvastused

Informatec Digital » Ressursid » Veebirakenduste tulemüüride alaline tuvastamine

Veebiturvalisus ei seisne enam ainult viirusetõrjetarkvara installimises ja parima lootmises. Tänapäeval on veebirakendused ja API-d peaaegu iga ettevõtte keskmes , muutes need rünnakute peamiseks sihtmärgiks. Alates veebipoodidest kuni digitaalse panganduse ja SaaS-platvormideni töötab kõik HTTP ja HTTPS-i kaudu – just siin tulevadki mängu veebirakenduste tulemüürid.

Kaasaegne WAF teeb enamat kui lihtsalt liikluse filtreerimist: see pakub veebirakenduse tulemüüris pidevat tuvastust , kohandab oma reegleid reaalajas, integreerub teiste kaitsekihtidega ja aitab järgida eeskirju, nagu PCI DSS või GDPR. Peamine on täielikult mõista, mida see teeb, kuidas see töötab, millised mudelid on olemas ja kuidas seda rakendada ilma jõudlust või kasutajakogemust kahjustamata.

Mis on WAF ja miks see tänapäeval nii oluline on?

Veebirakenduse tulemüür (WAF) on spetsiaalne turvamehhanism OSI mudeli 7. kihis, mis on loodud jälgima, filtreerima ja blokeerima veebirakendusse või API-sse sisenevat ja sealt väljuvat HTTP- ja HTTPS-liiklust. Erinevalt traditsioonilisest tulemüürist, mis kaitseb kogu võrku (3. ja 4. kiht), asub WAF kliendi ja rakenduse vahel ning mõistab veebipäringute konteksti.

Selle peamine ülesanne on peatada rünnakud, mis kasutavad ära rakenduse enda haavatavusi : SQL-süstid, saidiülene skriptimine (XSS), saidiülene päringute võltsimine (CSRF), autentimise kuritarvitamine, jõhkra jõu katsed, krüptograafiliste või juurdepääsukontrolli vigade ärakasutamine jne. Paljud neist ohtudest on kantud kuulsasse OWASP-i kümne parima hulka, mis on aastakümneid hiljem endiselt valdkonna etalon.

Seda tüüpi tulemüüri saab pakkuda füüsilise seadmena, serveritesse installitud tarkvarana või pilveteenusena . Olenemata mudelist on idee sama: kontrollida iga HTTP/HTTPS-päringut, võrrelda seda turvapoliitikate komplektiga ja millisekundites otsustada, kas lubada, blokeerida või klienti vaidlustada (näiteks captcha või JavaScripti väljakutse abil).

Keskkonnas, kus rakendusi avaldatakse kiiresti, kasutades avatud lähtekoodiga komponente ja pidevaid juurutusi, on tavaline, et haavatavused on tootmiskeskkonnas olemas enne, kui neid saab parandada . Sellisel juhul toimib WAF "turvapadjana": see ei paranda koodi, kuid see aitab ära hoida rünnakuid, mis seda ära kasutavad.

Peamised ohud, mida veebirakenduse tulemüür blokeerib

Hästi konfigureeritud WAF suudab leevendada laia valikut rünnakuid rakenduste ja API-de vastu . Mõned kõige levinumad on:

• SQL-süstimine (SQLi)Ründaja üritab vormidesse või parameetritesse sisestada SQL-käske, et andmebaasist andmeid lugeda, muuta või kustutada.
• Saidideülene skriptimine (XSS)See hõlmab pahatahtlike skriptide sisestamist veebilehtedele, et käivitada koodi teiste kasutajate brauserites.
• Saidiülene päringu võltsimine (CSRF)Kasutajat petetakse saatma soovimatuid päringuid rakendusele, kuhu ta on juba sisse logitud.
• Jõurünnakud ja volituste täitmineParoole või kasutajanime/parooli kombinatsioone testitakse seni, kuni need õnnestuvad, tavaliselt massiliselt ja automatiseeritud viisil.
• Puhvri ületäitumine ja serveri haavatavuste ärakasutamineanomaalsed sisestusmustrid, mis püüavad rakenduse loogikat või mälu rikkuda.
• Rakendustaseme DDoS: uputada konkreetseid URL-e või lõpp-punkte taotlustega rakenduse ressursside ammendamiseks.

Lisaks hõlmavad tänapäevased WAF-id võimeid pahatahtliku botiliikluse (agressiivne kraapimine, automatiseeritud sisselogimised, hulgiostud jne) tuvastamiseks ja peatamiseks, kasutades selliseid tehnikaid nagu JavaScripti verifitseerimine, CAPTCHA, käitumisanalüüs või seadme tuvastamine.

Kuidas töötab pidevalt sisse lülitatud tuvastus WAF-is

WAF-i sisemine toimimine põhineb sügaval HTTP/HTTPS-i liikluse kontrollimise mootoril ja poliitikate või reeglite komplektil. Iga päringut analüüsitakse mitmel tasandil, et määrata selle sihtkoht:

Ühelt poolt on olemas eelnevalt määratletud reeglid , mis põhinevad sageli standardsetel komplektidel, näiteks OWASP ModSecurity Core reeglistikul või selle patenteeritud ekvivalentidel. Need reeglid hõlmavad teadaolevaid rünnakusignatuure (tüüpilised SQL-süstimise, XSS-i, teekonna läbimise jne mustrid).

Teisest küljest tugineb pidevalt sisse lülitatud tuvastamine keerukamatele analüüsimeetoditele :

• Regulaarsed väljendid kahtlaste mustrite leidmiseks parameetrites, päistes, sisudes ja radades.
• Riskihindamise mudelid mis määravad „ohu skoori“, kombineerides igast päringust mitu signaali.
• SmartParse keerukate struktuuride (JSON, XML, kodeeritud kasulikud koormused) abil, et tuvastada rünnakuid, mis on varjatud legitiimsete andmete hulka.
• käitumise analüüs ja ajaloolise liikluse korrelatsioon, et eristada normaalset käitumist peenematest rünnakumustritest.

Kõige selle abil saab WAF reaalajas poliitikaid rakendada: lubada, blokeerida, logida või päringuid vaidlustada . Lisaks salvestab see sündmusi üksikasjalikesse logidesse, mis saab seejärel saata SIEM- või SOAR-platvormile korrelatsiooniks, auditeerimiseks ja automaatseks vastamiseks.

Põhipunkt on see, et tuvastused ei ole staatilised. Tõhusa WAF-i reeglid ja signatuurid on pidevalt uuendatud , et kohaneda uute haavatavuste ja kõrvalehoidumistehnikatega, ning paljud neist sisaldavad masinõpet ja pilvepõhist ohuinfot, et täiustada tuvastamist ilma pideva käsitsi sekkumiseta.

Turvamudelid: must nimekiri, valge nimekiri ja hübriid

Rakenduse tulemüüri käitumist saab määratleda kolme peamise turvalähenemisviisi järgi:

• Negatiivne turvamudel (must nimekiri)Vaikimisi on taotlused lubatud, välja arvatud need, mis vastavad pahatahtlikeks liigitatud signatuuridele või mustritele.
• Positiivne turvamudel (valge nimekiri)Kõik, mis pole otseselt lubatud, blokeeritakse; läbi lastakse ainult need päringud, mis vastavad väga spetsiifilisele "hea liikluse" profiilile.
• HübriidmudelMõlemad lähenemisviisid on kombineeritud, rakendades kriitilistele toimingutele valgeid nimekirju ja ülejäänud liiklusele musti nimekirju.

Valgesse nimekirja lisamine on üldiselt turvalisem, kuid ka nõudlikum seadistada , kuna see nõuab põhjalikku arusaamist sellest, mis on seaduslik liiklus. Musta nimekirja lisamine on algselt lihtsam, kuid see võib jätta lünki nullpäeva rünnakute või uudsete tehnikate jaoks. Seetõttu valivad paljud tänapäevased WAF-id hübriidlähenemise, mida saab rakenduse või lõpp-punkti järgi kohandada.

WAF-ide tüübid vastavalt nende juurutamisele

Sõltuvalt sellest, kuhu ja kuidas need on installitud, saame eristada mitut tüüpi veebirakenduste tulemüüre, millel kõigil on oma plussid ja miinused kulude, kontrolli, nähtavuse ja jõudluse osas :

• Võrgupõhised WAF-id (riistvara)füüsilised seadmed, mis paigutatakse võrguinfrastruktuuri interneti ja rakendusserverite vahele.
• Hostipõhised või tarkvarapõhised WAF-idNeed paigaldatakse otse sisse serverid, kus rakendus töötabvõi moodulina, mis on integreeritud rakenduse enda pinu.
• pilvepõhised WAF-idNeid pakub teenusena pilve- või serva-/CDN-teenuse pakkuja ning neid konfigureeritakse tavaliselt DNS-i või puhverserveri sätteid muutes.
• HübriidjuurutusedNad ühendavad kohalikke WAF-e (kohapealseid või hostitud) pilvepõhiste WAF-idega, et katta samaaegselt sega-, pärand- ja pilvepõhiseid keskkondi.

Võrguseadmed pakuvad väikest latentsusaega ja ulatuslikku kohalikku kontrolli , kuid nõuavad investeeringuid riistvarasse ja hooldusse. Host WAF-id pakuvad rakenduses detailset nähtavust, kuigi need tarbivad serveriressursse ja nõuavad rohkem haldust. Pilveteenused paistavad silma oma skaleeritavuse, kiire juurutamise ja hoolduse lihtsuse poolest, kuigi need ohverdavad osa sisemisest kontrollist ja mõnel juhul ka kõigi ohtude täieliku konteksti.

WAF versus teised turvasüsteemid: NGFW, IPS ja traditsioonilised tulemüürid

WAF-i rolli aetakse sageli segi teiste turvaseadmetega. Igal neist on arhitektuuris oma koht:

Traditsiooniline tulemüür määratleb sisemise ja välise võrgu vahelise perimeetri, kontrollides madalal tasemel porte, IP-aadresse ja protokolle. See ei mõista veebirakenduste loogikat ega vormide või URL-ide sisu.

Järgmise põlvkonna tulemüür (NGFW) laiendab seda klassikalist mudelit, lisades sügava pakettide kontrolli, kasutajate ja rakenduste kontrolli, viirusetõrje, pahavaratõrje ja ohuteabe integratsiooni. Mõned NGFW-d sisaldavad WAF-võimalusi, kuid nende fookus jääb peamiselt võrgule, samas kui WAF keskendub täielikult rakenduskihile.

Sissetungimise ennetamise süsteem (IPS) seevastu analüüsib kogu võrguliiklust kõigi protokollide kaudu, et tuvastada üldiseid rünnakumustreid. Tavaliselt tugineb see signatuuridele ja reeglitele, mis on vähem kontekstuaalsed kui veebirakenduse faabel (WAF) ega süvene alati nii sügavalt HTTP semantikasse ega rakenduse äriloogikasse.

Praktikas ühendab robustne arhitektuur NGFW, IPS ja WAF-i , millest igaüks on spetsialiseerunud oma kihile, edastades andmeid keskset SIEM-i, mis korreleerib sündmusi, genereerib hoiatusi ja võimaldab koordineeritud reageerimist ning ühendab need turvatööriistadega halduse automatiseerimiseks.

WAF-i juurutamise viisid rakenduse arhitektuuris

Lisaks lahenduse tüübile peate otsustama, kuidas WAF rakenduse liiklusvoogu integreeritakse. Kõige levinumad lähenemisviisid on:

• Läbipaistev sildWAF asub võrgus, lingitud samade portidega kui rakendus, ilma et kliendid või serverid seda otseselt "näeksid".
• Läbipaistev pöördproksiRakendused on WAF-ist teadlikud, kuid kliendile tundub, nagu nad suhtleksid otse rakendusega.
• Selgesõnaline pöördproksiKliendid teavad, et nad loovad ühenduse puhverserveriga, mis omakorda edastab päringud sisemistele serveritele.

Sillarežiimi on tavaliselt kõige lihtsam rakendada, kuna see nõuab vähem konfiguratsioonimuudatusi, kuid pakub rakenduse ja tulemüüri vahel vähem isolatsiooni . Erinevad pöördproksi maitsed pakuvad paremat rakenduste isolatsiooni, hõlbustavad TLS-i koormuse mahakandmist, võimaldavad krüptitud liikluse kontrollimist ja pakuvad suuremat paindlikkust täiustatud reeglite või koormuse tasakaalustamise loogika rakendamisel.

Veebirakenduse tulemüüri kasutamise peamised eelised

Hästi häälestatud WAF-i kasutuselevõtt pakub selgeid eeliseid nii tehnilisel kui ka ärilisel tasandil. Kõige olulisemate hulgas on:

• Täiustatud kaitse rakenduspõhiste rünnakute vastumida võrgu tulemüür või lihtne IPS ei suudaks sama täpsusega blokeerida.
• Andmelekke ja teenuse katkestuste ohu vähendamineotseste kulude (seisakud, päästeoperatsioonid, trahvid) ja kaudsete kulude (mainekahtumine, usalduse kaotus) vältimine.
• Abi regulatiivse vastavuse tagamiseleriti selliste nõuete puhul nagu PCI DSS, mis nõuavad internetipõhiste rakenduste kaitset ning tõendeid ohtude jälgimise ja blokeerimise kohta.
• Skaleeritavus ja paindlikkuseriti pilve- ja servamudelites, mis võimaldavad absorbeerida liikluspiike ja muutuvaid koormusi ilma kogu infrastruktuuri ümber kujundamata.

Paljud professionaalsed majutusteenuse pakkujad pakuvad oma platvormi integreeritud veebirakenduste foorumit (WAF). See lihtsustab protsessi, pakkudes veebisaidile või rakendusele automaatset kaitset süstimise, saidiülese skriptimise (XSS), põhiliste DDoS-rünnakute ja autentimise kuritarvitamise eest kohe algusest peale, ilma et meeskond peaks nullist keerulisi reegleid looma.

WAF-i rakendamise tegelikud väljakutsed ja kuidas nendega toime tulla

See, et WAF on võimas, ei tähenda, et kõik sujub. Selleks, et pidevalt sisse lülitatud tuvastused ei muutuks pidevaks nuhtluseks , tuleb meeles pidada mitmeid väljakutseid :

• Valepositiivsed tulemusedSee on klassikaline probleem. Halvasti häälestatud reegel võib blokeerida seadusliku liikluse, katkestada ostuvoo või takistada API-l ettenähtud viisil toimimist.
• Vajadus pidevate uuenduste järeleKui ettevõtteid ja poliitikat ei kaasajastata, jääb WAF uute rünnakutehnikate suhtes pimedaks.
• Konfiguratsiooni keerukusHeade reeglite määratlemine, logide mõistmine ja poliitikate kohandamine nõuab eriteadmisi.
• Mõju jõudluseleIga kontroll lisab koormust. Halb disain või vale asukoht võivad põhjustada suurt latentsusaega.
• Kõrvalehoidmise tehnikad ründajate poolt, kes fragmenteerivad pakette, kodeerivad kasulikku lasti kummalistel viisidel või kuritarvitavad protokolli iseärasusi, et kontrollidest mööda hiilida.

Nende probleemide leevendamine hõlmab hea esialgse disaini ühendamist pideva hooldusega : jõudluskriteeriumide kehtestamist, mõõdikute (samaaegsed kasutajad, päringud sekundis, reageerimisajad) registreerimist, selgete rollide määratlemist (kes haldab reegleid, kes vaatab üle hoiatused, kui tihti poliitikaid üle vaadatakse) ning WAF-i integreerimist SOC-i, DevOpsi ja organisatsiooni jälgimisvahenditega.

Parimad tavad pideva tuvastuse maksimaalseks ärakasutamiseks

Selleks, et teie rakenduse tulemüür töötaks teie kasuks, mitte teie vastu, on soovitatav järgida mitmeid tavasid, mida paljud tootjad ja turvameeskonnad peavad oluliseks:

• Integreeri WAF olemasoleva infrastruktuuriga (CDN, koormuse tasakaalustajad, puhverserverid, SIEM, DDoS-lahendused, IPS) selle asemel, et seda vaadelda kui „isoleeritud kuupi“.
• Määrake jõudluse ja turvalisuse KPI-d algusest peale (valepositiivsete tulemuste määr, blokeeritud rünnakud, lisandunud latentsusaeg jne).
• Tutvustage konkreetseid WAF-i haldusrolle, kooskõlas arenduse, tegevuse ja SOC-iga, nii et reeglid arenevad koos rakendustega.
• Kasutage eelkonfigureeritud reeglite loendeid alusena, aga kohanda neid iga rakenduse jaoks: määratle erandid, konkreetsed valged nimekirjad ja kohandatud reeglid kriitiliste voogude jaoks.
• Integreerimine ürituste haldamise platvormidega (SIEM) WAF-logide korreleerimiseks teiste anduritega ja ülevaate saamiseks.
• Vaadake eeskirjad perioodiliselt üle, kaotades vananenud reeglid ning kohandades kiirusepiiranguid, seansi kontrolli ja kaitset robotite eest vastavalt kasutajate tegelikule käitumisele.

WAAP ja WAAS: WAF-i areng tänapäevaste rakenduste ja API-de jaoks

Pilvepõhiste arhitektuuride, mikroteenuste ja API-de levikuga kõikjal on klassikaline WAF jäänud alla ootuste. Seetõttu tekkis veebirakenduste ja API-de kaitse (WAAP) , mida sageli pakutakse veebirakenduste ja API-de turvalisuse (WAAS) teenusena ja mis läheb sammu edasi:

• Rakenduste ja API lõpp-punktide automaatne avastamineteenuste kaitsmata jätmise vältimine.
• API spetsifikatsioonide importimine (Swagger, OpenAPI jne), et kontrollida päringute vastavust määratletud lepingule.
• OWASP API spetsiifiline kaitse 10 parima jaoks ja äriloogika kuritarvitamise eest API-kõnedes.
• Integreeritud rakendustaseme bot ja DDoS-i leevendaminelisaks traditsioonilistele WAF-funktsioonidele.
• Võimalus rakendada iga lõpp-punkti kohta erinevaid poliitikaidmis muudab tundlike andmete haldajate töö palju keerulisemaks.

See lähenemisviis peegeldab praegust reaalsust: paljud haavatavused ei tulene enam tüüpilisest "klassikalisest" veebisaidist, vaid pigem halvasti dokumenteeritud API-dest, tähelepanuta jäetud lõpp-punktidest ja mitmes pilves avatud teenustest . Nende avastamise automatiseerimine ja kaitsmine samade pidevalt sisse lülitatud tuvastusvõimalustega on tagauste lahtijäämise vältimiseks ülioluline.

Üldiselt võimaldab hea arusaam sellest, mida WAF teeb, kuidas selle pidevad tuvastusmehhanismid toimivad, millised juurutusmudelid on olemas ja kuidas seda ülejäänud turvalisuse ökosüsteemiga integreerida, teil luua rakenduste ja API-de ümber palju tugevama kaitse, vähendades edukate rünnakute riski, ilma et see kahjustaks paindlikkust või kasutajakogemust.