Meie eelnevas artiklis pilveteemal arutasime, kuidas kaitsta IT-ressursse avalikus pilves ning miks traditsioonilised viirusetõrjed ei sobi nende eesmärkide saavutamiseks. Selles postituses jätkame pilveteabe turvalisuse teemat ja räägime WAFi arengust ning sellest, mida on parem valida: riistvara, tarkvara või pilv. Mis on WAF

Üle 75% häkkerite rünnakutest on suunatud veebirakenduste ja veebisaitide haavatavustele: sellised rünnakud jäävad tavaliselt märkamatuks infosüsteemide infrastruktuuri ja -teenuste jaoks. Veebirakenduste haavatavused toovad endaga kaasa konto ja isikuandmete, paroolide ning krediitkaardinumbrite kompromiteerimise ja pettuse riskid. Lisaks teenivad veebisaidi haavatavused sissetungijate jaoks sisenemisena ettevõtte võrku.
Veebirakenduste tulemüür (WAF) on kaitsekest, mis blokeerib rünnakud veebirakendustele: SQL-süstekoodid, XSS, kaugkäivitamine, bruteforce ja autentimise ringide vältimine (auth bypass). Sealhulgas rünnakud, mis kasutavad zero-day haavatavusi. Rakenduste tulemüürid tagavad kaitse, jälgides veebilehtede sisu, sealhulgas HTML, DHTML ja CSS, ning filtreerides potentsiaalselt kahjulikke HTTP/HTTPS päringuid.
Millised olid esimesed lahendused?
Esimesed katsed luua veebirakenduste tulemüüre tehti juba 90ndate alguses. On teada vähemalt kolmest insenerist, kes töötasid selle ala nimel. Esiteks, Purdue Ülikooli arvutiteaduse professor Gene Spafford. Ta kirjeldas rakendustulemüüri arhitektuuri, kasutades proksi-mudelit ning avaldas selle 1991. aastal raamatus
„Praktiline UNIX-i turvalisus“ .
Kuid SEAL ei olnud täieõiguslik WAF-lahendus. See oli klassikaline võrgutulemüür, millel oli laiendatud funktsionaalsus – võimalus blokeerida rünnakud FTP ja RSH-le. Seetõttu peetakse täna esimeseks WAF-lahenduseks Perfecto Technologies'i tootet, hiljem tuntud kui Sanctum. 1999. aastal
lõid nad süsteemi AppShield. Sel ajal tegeles Perfecto Technologies IT-lahenduste arendamisega e-kaubanduse jaoks ning nende uue toote sihtrühmaks olid veebipoed. AppShield suutis analüüsida HTTP-päringuid ja blokeerida rünnakud dünaamiliste infosüsteemi poliitikate alusel. Umbes sama ajal kui AppShield (2002. aastal) ilmus esimesed avatud lähtekoodiga WAF. Selleks sai
Umbes sama aja AppShieldiga (2002. aastal) ilmus ka esimene avatud lähtekoodiga WAF. Sellega sai. ). ModSecurity blokeerib rünnakud rakendustele, tuginedes standardsest regulaarsete väljendite (signatuuride) komplektile – tööriistadele päringute kontrollimiseks mustri järgi – OWASP Core Rule Set .
Kolm põlvkonda – juba ajalugu
Tavaks on eristada kolme WAF-süsteemide põlvkonda, mis on arenenud tehnoloogia arenguga.
Esimene põlvkond
. Töötas regulaarsete väljendite (või grammatikate) alusel. Sellesse kuulub ka ModSecurity. Süsteemi pakkuja uurib rakenduste rünnakute tüüpe ja loob mustreid, mis kirjeldavad seaduslikke ja potentsiaalselt kahjulikke päringuid. WAF kontrollib neid loendeid ja otsustab, mida konkreetses olukorras teha – blokeerida liiklus või mitte.Regulaarsete väljendite alusel avastamise näiteks on juba mainitud projekt
Core Rule Set , mis on samuti avatud lähtekoodiga. Regulaarsete väljenditega süsteemidel on mitmeid puudusi, sealhulgas see, et uue haavatavuse tuvastamisel peab administraator looma lisareegleid käsitsi. Suure IT-infrastruktuuri puhul võib reeglite hulk ulatuda mitme tuhande piirini. Sellise regulaarsete väljendite hulga haldamine on üsna keeruline, rääkimata sellest, et nende kontrollimine võib vähendada võrgu jõudlust. , mis on samuti avatud lähtekoodiga. Regulaarsetel väljenditel on mitmeid puudusi, sealhulgas see, et uue haavatavuse avastamisel peab administraator käsitsi looma täiendavaid reegleid. Suure IT-infrastruktuuri puhul võib reeglite arv olla mitu tuhat. Nii paljude regulaarsete väljendite haldamine on üsna keeruline, rääkimata sellest, et nende kontrollimine võib halvendada võrgu jõudlust.
Lisaks on regulaarsete väljendite valehäirete tase üsna kõrge. Kuulus lingvist Noam Chomsky pakkus välja grammatikate klassifitseerimise, jagades need nelja tingimuslikku keerukuse taset. Selle klassifitseerimise kohaselt on regulaarsete väljenditega võimalik kirjeldada ainult tulemüüri reegleid, mis ei eelda kõrvalekaldeid mallist. See tähendab, et pahatahtlikud võivad kergesti petta esimese põlvkonna WAFi. Üks meetod selle vastu võitlemiseks on lisada rakendustele suunatud päringutesse erimärke, mis ei mõjuta kahjulike andmete loogikat, kuid rikuvad allkirjareeglit.

Teine põlvkond. Teise põlvkonna rakenduste tulekindlate tulemüüride loomise põhjus oli WAF-ide jõudlus- ja täpsusprobleemide lahendamine. Nendes süsteemides on rakendatud parserid, mille ülesanne on tuvastada kindlaid rünnakute tüüpe (nt HTML, JS jne). Need parserid töötavad spetsiaalsete tokenitega, mis kirjeldavad päringute tüüpe (nt variable, string, unknown, number). Potentsiaalselt kahjulikud tokeni järjestused kantakse eraldi loendisse, millega WAF-süsteem regulaarselt võrreldakse. Esmakordselt näidati seda lähenemist Black Hat 2012 konverentsil C/C++ vormis. , mis võimaldab tuvastada SQL-süstid.
Võrreldes esimese põlvkonna WAF-idega suudavad spetsialiseeritud parserid töötada kiiremini. Siiski ei lahendanud nad vanade kahjulike rünnakute ilmnemisel süsteemi käsitsi seadistamisega seotud raskusi.

Kolmas põlvkond. Kolmanda põlvkonna tuvastamise loogika areng seisneb masinõppe meetodite rakendamises, mis võimaldavad tuvastamise grammatikat maksimaalselt läheneda SQL/HTML/JS kaitstud süsteemide reaalsetele grammatikatele. See tuvastamisloogika suudab kohandada Turingi masinat rekursiivselt loetavate grammatikate katmiseks. Veelgi enam, varem oli kohandatava Turingi masina loomise ülesanne lahendamata, kuni esimesed uuringud närvivõrkude Turingi masinatest avalikustati.
Masinõpe pakub ainulaadset võimalust kohandada mis tahes grammatikat, et katta mistahes rünnakute tüüpe ilma signatuuride loendite käsitsi koostamise vajaduseta, mis oli vajalik esimese põlvkonna tuvastamisel, ja ilma uute tokeniseerijate/parserite väljatöötamiseta uute rünnakute, nagu Memcachedi, Redis'i, Cassandrat ja SSRF, suhtes, nagu seda nõudis teise põlvkonna metoodika.
Kombineerides kõik kolm tuvastusloogika põlvkonda, saame joonistada uue diagrammi, kus punase kontuuriga on esindatud kolmanda põlvkonna tuvastamine (joonis 3). See põlvkond hõlmab ühte lahendust, mida me rakendame pilves koos „Onseki”, veebirakenduste ja API adaptiivse kaitse platvormi arendajaga, Alarme.
Nüüd kasutatakse tuvastusloogikas rakenduselt tagasisidet automaatse seadistamise jaoks. Masinõppe raames kutsutakse seda tagasiside tsüklit „tugiseerimine”. Üldiselt on olemas üks või mitu sellist tugiseerimise tüüpi:
- Rakenduse vastuse käitumise analüüs (passiivne)
- Skaneerimine/fuzzer (aktiivne)
- Aruande failid/ühendused/intercept protseduurid (pärast fakti)
- Käsitsi (määrab superviisor)
Kokkuvõttes lahendab kolmanda põlvkonna tuvastusloogika ka olulise täpsusprobleemi. Nüüd on võimalik mitte ainult vältida valehäireid ja vale negatiive, vaid ka tuvastada aktsepteeritud tõeliselt negatiivseid tulemusi, näiteks SQL käskude kasutamise tuvastamine juhtpaneelil, veebilehe mallide laadimine, JavaScripti vigadega seotud AJAX päringud ja muud.

![]()

Edasi vaatame erinevate WAF-i rakendamise tehnoloogilisi võimalusi.
Riistvara, tarkvara või pilv — mida valida?
Üks rakenduste tulemüüride lahendamise võimalus on „riistvara” lahendus. Need süsteemid on spetsialiseeritud arvutiseadmed, mille ettevõte paigaldab kohapeal oma andmekeskuses. See tähendab, et peab ostma enda riistvara ja maksma integreerijatele selle seadistamise ja häälestamise eest (kui ettevõttel pole oma IT-osakonda). Lisaks muutub iga riistvara aeg-ajalt vananenuks ja kasutuskõlbmatuks, mistõttu peavad tellijad arvestama riistvara uuendamise eelarvet.
Teine WAF-i rakendamise võimalus on tarkvaraline lahendamine. Lahendus installitakse mingi tarkvara täienduseks (nt ModSecurity seadistatakse Apache'i peale) ning töötab sama serveriga. Selliseid lahendusi saab tavaliselt paigaldada nii füüsilisele serverile kui ka pilve. Nende miinus on piiratud skaleeritavus ja müüja tugi.
Kolmas variant on WAF-i seadistamine pilvest. Sellised lahendused pakuvad pilveteenuse pakkujad kui tellimusteenust. Ettevõttel ei pea olema spetsiaalset riistvara ostma ega seadistama, need ülesanded lasuvad teenusepakkuja õlgadel. Oluline on see, et kaasaegne pilve WAF ei eelda ressursside migreerimist teenusepakkuja platvormile. Veebileht võib olla paigaldatud igal pool, isegi kohapeal.
Miks vaatavad paljud ettevõtted aina enam pilve WAF-i poole, räägime järgmises osas.
Mida suudab pilve WAF?
Tehnoloogiliste võimaluste seisukohalt:
- Uuenduste eest vastutab teenusepakkuja. WAF on tellimusel, seega jälgib teenusepakkuja uuenduste ja litsentside ajakohasust. Uuendused puudutavad nii tarkvara kui ka riistvara. Teenusepakkuja uuendab serveriparki ja hooldab seda. Ta vastutab ka koormuse tasakaalustamise ja varundamise eest. Kui WAF-serveris tekib rike, suunatakse liiklus kohe teisele masinale. Liikluse ratsionaalne jagamine aitab vältida olukordi, kus tulemüür satub fail open režiimi — ei suuda koormust taluda ja lõpetab päringute filtreerimise.
- Virtuaalne patchimine. Virtuaalsed patchid piiravad juurdepääsu kompromiteeritud rakenduse osadele, kuni arendaja uuenduse välja toob. Selle tulemusel saab pilveteenuse klient rahulikult oodata, kuni tarkvarapakkuja ametlikud "patchid" välja annab. Selle tegemine võimalikult kiiresti on tarkvarapakkuja prioriteet. Näiteks platvormil "Valarm" vastutab virtuaalse patchimise eest eraldi tarkvaramoodul. Administrator saab lisada kohandatud regulaaravaldisi pahatahtlike päringute blokeerimiseks. Süsteem võimaldab teatud päringuid lipuga "Isikuandmed" märgistada. Sel juhul nende parameetreid maskeeritakse ning need ei edastata mingil tingimusel tulemüüri tööpiirist välja.
- Sisseehitatud piiri- ja haavatavus-skanner. See võimaldab iseseisvalt määrata IT-infrastruktuuri võrgu piire, kasutades DNS-päringute ja WHOIS-protokolli andmeid. Pärast seda analüüsib WAF automaatselt sees olevaid teenuseid ja süsteeme (sooritab portide skannimist). Tulemüür suudab tuvastada kõik levinud haavatavuse tüübid — SQLi, XSS, XXE jne — ning tuvastada tarkvara konfiguratsioonivigu, näiteks volitamata juurdepääsu Git- ja BitBucket-repositoritele ning anonüümseid päringuid Elasticsearchi, Redis'i, MongoDB-sse.
- Rünnakuid jälgitakse pilve ressurssidega. Üldiselt on pilveteenuse pakkujatel suured arvutusvõimsused. See võimaldab ohtu analüüsida kõrge täpsuse ja kiirusena. Pilves paigaldatakse filtreerivate sõlmedega klaster, mille kaudu kogu liiklus läbib. Need sõlmed blokeerivad rünnakud veebirakendustele ja saadavad statistika analüüsi keskusesse. Seal kasutatakse masinõppe algoritme, et uuendada blokeerimise reegleid kõigi kaitstava rakenduse jaoks. Sellise skeemi rakendamine on näidatud joonisel 4. Sellised kohandatud turvareeglid vähendavad tulemüüri valehäirete arvu.

Nüüd mõningatest pilve WAF-i omadustest organisatsiooni ja halduse seisukohalt:
- Üleminek OpEx. Pilve WAF-i puhul on rakendamise maksumus null, kuna kogu riistvara ja litsentsid on juba teenusepakkuja poolt makstud, teenuse eest makstakse tellimuse alusel.
- Erinevad hinnaplaanid. Pilveteenuse kasutaja saab kiiresti lisavõimalusi sisse ja välja lülitada. Funktsioonide haldamine toimub keskse juhtpaneeli kaudu, mis on samuti kaitstud. Juhtimine toimub HTTPS kaudu ning lisaks on olemas ka kahefaktoriline autentimise mehhanism, mis põhineb TOTP (Time-based One-Time Password Algorithm) protokollil.
- Ühendamine DNS-i kaudu. Saate iseseisvalt muuta DNS-i ja seadistada marsruutimist võrgus. Nende ülesannete täitmiseks ei ole vaja eraldi spetsialiste välja koolitada. Üldiselt saab seadistamisel aidata teenusepakkuja tehniline tugi.
WAF-tehnoloogiad on läbinud evolutsiooni lihtsatest võrgu filterdustest, millel on empiirilised reeglid, kuni keerukate kaitsesüsteemide, milles on masinõppe algoritmid. Praegu omavad rakenduste tulemüürid suurt hulka funktsioone, mis olid 90ndatel raske saavutada. Suures osas on uue funktsionaalsuse lisamine olnud võimalik tänu pilvetehnoloogiatele. WAF-lahendused ja nende komponendid jätkavad arengut. Nagu ka teised infosüsteemide kaitse valdkonnad.
Teksti koostas Alexander Karpuzikov, pilveteenuse pakkuja #CloudMTS toote arenduse juht.
Allikas: habr.com
