{"id":55733,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","title":{"rendered":"Web Application Firewalli evolutsioon: v\u00f5rgu t\u00f5kked pilvep\u00f5histe s\u00fcsteemide kaitseks masin\u00f5ppe abil","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Meie eelnevas artiklis pilveteemal arutasime, kuidas kaitsta IT-ressursse avalikus pilves ning miks traditsioonilised viiruset\u00f5rjed ei sobi nende eesm\u00e4rkide saavutamiseks. Selles postituses j\u00e4tkame pilveteabe turvalisuse teemat ja r\u00e4\u00e4gime WAFi arengust ning sellest, mida on parem valida: riistvara, tarkvara v\u00f5i pilv. olen r\u00e4\u00e4kinud<\/a><\/noindex>Mis on WAF\u00a0<\/b><\/p>\n

\"Web
\n<\/p>\n

\u00dcle 75% h\u00e4kkerite r\u00fcnnakutest on suunatud veebirakenduste ja veebisaitide haavatavustele: sellised r\u00fcnnakud j\u00e4\u00e4vad tavaliselt m\u00e4rkamatuks infos\u00fcsteemide 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\u00f5tte v\u00f5rku.<\/h3>\n

\nVeebirakenduste tulem\u00fc\u00fcr (WAF) on kaitsekest, mis blokeerib r\u00fcnnakud veebirakendustele: SQL-s\u00fcstekoodid, XSS, kaugk\u00e4ivitamine, bruteforce ja autentimise ringide v\u00e4ltimine (auth bypass). Sealhulgas r\u00fcnnakud, mis kasutavad zero-day haavatavusi. Rakenduste tulem\u00fc\u00fcrid tagavad kaitse, j\u00e4lgides veebilehtede sisu, sealhulgas HTML, DHTML ja CSS, ning filtreerides potentsiaalselt kahjulikke HTTP\/HTTPS p\u00e4ringuid.<\/p>\n

Millised olid esimesed lahendused?
\n<\/a><\/noindex><\/p>\n

Esimesed katsed luua veebirakenduste tulem\u00fc\u00fcre tehti juba 90ndate alguses. On teada v\u00e4hemalt kolmest insenerist, kes t\u00f6\u00f6tasid selle ala nimel. Esiteks, Purdue \u00dclikooli arvutiteaduse professor Gene Spafford. Ta kirjeldas rakendustulem\u00fc\u00fcri arhitektuuri, kasutades proksi-mudelit ning avaldas selle 1991. aastal raamatus<\/h3>\n

\n\u201ePraktiline UNIX-i turvalisus\u201c Teiseks ja kolmandaks olid Bell Labs'i infoturbe spetsialistid William Cheswick ja Marcus Ranum. Nad arendasid v\u00e4lja \u00fche esimestest rakendustulem\u00fc\u00fcride protot\u00fc\u00fcpidest. Selle levitamisega tegeles DEC, toote nimega SEAL (Secure External Access Link).<\/a><\/noindex>.<\/p>\n

Kuid SEAL ei olnud t\u00e4ie\u00f5iguslik WAF-lahendus. See oli klassikaline v\u00f5rgutulem\u00fc\u00fcr, millel oli laiendatud funktsionaalsus \u2013 v\u00f5imalus blokeerida r\u00fcnnakud FTP ja RSH-le. Seet\u00f5ttu peetakse t\u00e4na esimeseks WAF-lahenduseks Perfecto Technologies'i tootet, hiljem tuntud kui Sanctum. 1999. aastal <\/p>\n

l\u00f5id nad s\u00fcsteemi AppShield. Sel ajal tegeles Perfecto Technologies IT-lahenduste arendamisega e-kaubanduse jaoks ning nende uue toote sihtr\u00fchmaks olid veebipoed. AppShield suutis anal\u00fc\u00fcsida HTTP-p\u00e4ringuid ja blokeerida r\u00fcnnakud d\u00fcnaamiliste infos\u00fcsteemi poliitikate alusel. esituse<\/a><\/noindex> Umbes sama ajal kui AppShield (2002. aastal) ilmus esimesed avatud l\u00e4htekoodiga WAF. Selleks sai<\/p>\n

Umbes sama aja AppShieldiga (2002. aastal) ilmus ka esimene avatud l\u00e4htekoodiga WAF. Sellega sai. ModSecurity<\/a><\/noindex>). ModSecurity blokeerib r\u00fcnnakud rakendustele, tuginedes standardsest regulaarsete v\u00e4ljendite (signatuuride) komplektile \u2013 t\u00f6\u00f6riistadele p\u00e4ringute kontrollimiseks mustri j\u00e4rgi \u2013 GitHubi hoidla<\/a><\/noindex>OWASP Core Rule Set L\u00f5ppkokkuv\u00f5ttes \u00f5nnestus arendajatel saavutada oma eesm\u00e4rk \u2013 turule hakkasid ilmuma uued WAF-lahendused, sealhulgas need, mis on \u00fcles ehitatud ModSecurity alusel.<\/a><\/noindex>.<\/p>\n

Kolm p\u00f5lvkonda \u2013 juba ajalugu<\/p>\n

Tavaks on eristada kolme WAF-s\u00fcsteemide p\u00f5lvkonda, mis on arenenud tehnoloogia arenguga.<\/h3>\n

\nEsimene p\u00f5lvkond<\/p>\n

. T\u00f6\u00f6tas regulaarsete v\u00e4ljendite (v\u00f5i grammatikate) alusel. Sellesse kuulub ka ModSecurity. S\u00fcsteemi pakkuja uurib rakenduste r\u00fcnnakute t\u00fc\u00fcpe ja loob mustreid, mis kirjeldavad seaduslikke ja potentsiaalselt kahjulikke p\u00e4ringuid. WAF kontrollib neid loendeid ja otsustab, mida konkreetses olukorras teha \u2013 blokeerida liiklus v\u00f5i mitte.<\/b>Regulaarsete v\u00e4ljendite alusel avastamise n\u00e4iteks on juba mainitud projekt<\/p>\n

Core Rule Set avatud l\u00e4htekoodiga. Teine n\u00e4ide on<\/a><\/noindex> , mis on samuti avatud l\u00e4htekoodiga. Regulaarsete v\u00e4ljenditega s\u00fcsteemidel on mitmeid puudusi, sealhulgas see, et uue haavatavuse tuvastamisel peab administraator looma lisareegleid k\u00e4sitsi. Suure IT-infrastruktuuri puhul v\u00f5ib reeglite hulk ulatuda mitme tuhande piirini. Sellise regulaarsete v\u00e4ljendite hulga haldamine on \u00fcsna keeruline, r\u00e4\u00e4kimata sellest, et nende kontrollimine v\u00f5ib v\u00e4hendada v\u00f5rgu j\u00f5udlust. Samuti on regulaarsete v\u00e4ljendite puhul \u00fcsna k\u00f5rge valeh\u00e4irete m\u00e4\u00e4r. Kuulus lingvist Noam Chomsky pakkus v\u00e4lja grammatikate klassifitseerimise, milles jagas need neljaks tingimuslikuks keerukuse tasemeks. S\u00f5ltuvalt sellest klassifikatsioonist saab regulaarsete v\u00e4ljenditega kirjeldada ainult neid tulem\u00fc\u00fcri reegleid, mis ei eelda mustrist k\u00f5rvalekaldumist. See t\u00e4hendab, et r\u00fcndajad saavad kergesti \u201epetta\u201c esimese p\u00f5lvkonna WAF-i. \u00dcks meetod nende vastu v\u00f5itlemiseks on lisada rakenduste p\u00e4ringutesse spetsiaalseid s\u00fcmboleid, mis ei m\u00f5juta kahjulike andmete loogikat, kuid rikuvad signatuurireeglit.<\/a><\/noindex>, mis on samuti avatud l\u00e4htekoodiga. Regulaarsetel v\u00e4ljenditel on mitmeid puudusi, sealhulgas see, et uue haavatavuse avastamisel peab administraator k\u00e4sitsi looma t\u00e4iendavaid reegleid. Suure IT-infrastruktuuri puhul v\u00f5ib reeglite arv olla mitu tuhat. Nii paljude regulaarsete v\u00e4ljendite haldamine on \u00fcsna keeruline, r\u00e4\u00e4kimata sellest, et nende kontrollimine v\u00f5ib halvendada v\u00f5rgu j\u00f5udlust.<\/p>\n

Lisaks on regulaarsete v\u00e4ljendite valeh\u00e4irete tase \u00fcsna k\u00f5rge. Kuulus lingvist Noam Chomsky pakkus v\u00e4lja grammatikate klassifitseerimise, jagades need nelja tingimuslikku keerukuse taset. Selle klassifitseerimise kohaselt on regulaarsete v\u00e4ljenditega v\u00f5imalik kirjeldada ainult tulem\u00fc\u00fcri reegleid, mis ei eelda k\u00f5rvalekaldeid mallist. See t\u00e4hendab, et pahatahtlikud v\u00f5ivad kergesti petta esimese p\u00f5lvkonna WAFi. \u00dcks meetod selle vastu v\u00f5itlemiseks on lisada rakendustele suunatud p\u00e4ringutesse erim\u00e4rke, mis ei m\u00f5juta kahjulike andmete loogikat, kuid rikuvad allkirjareeglit.<\/p>\n

\"Web
\n
\nTeine p\u00f5lvkond<\/b>. Teise p\u00f5lvkonna rakenduste tulekindlate tulem\u00fc\u00fcride loomise p\u00f5hjus oli WAF-ide j\u00f5udlus- ja t\u00e4psusprobleemide lahendamine. Nendes s\u00fcsteemides on rakendatud parserid, mille \u00fclesanne on tuvastada kindlaid r\u00fcnnakute t\u00fc\u00fcpe (nt HTML, JS jne). Need parserid t\u00f6\u00f6tavad spetsiaalsete tokenitega, mis kirjeldavad p\u00e4ringute t\u00fc\u00fcpe (nt variable, string, unknown, number). Potentsiaalselt kahjulikud tokeni j\u00e4rjestused kantakse eraldi loendisse, millega WAF-s\u00fcsteem regulaarselt v\u00f5rreldakse. Esmakordselt n\u00e4idati seda l\u00e4henemist Black Hat 2012 konverentsil C\/C++ vormis.\u00a0libinjection<\/a><\/noindex>, mis v\u00f5imaldab tuvastada SQL-s\u00fcstid.<\/p>\n

V\u00f5rreldes esimese p\u00f5lvkonna WAF-idega suudavad spetsialiseeritud parserid t\u00f6\u00f6tada kiiremini. Siiski ei lahendanud nad vanade kahjulike r\u00fcnnakute ilmnemisel s\u00fcsteemi k\u00e4sitsi seadistamisega seotud raskusi. <\/p>\n

\"Web
\n
\nKolmas p\u00f5lvkond<\/b>. Kolmanda p\u00f5lvkonna tuvastamise loogika areng seisneb masin\u00f5ppe meetodite rakendamises, mis v\u00f5imaldavad tuvastamise grammatikat maksimaalselt l\u00e4heneda SQL\/HTML\/JS kaitstud s\u00fcsteemide reaalsetele grammatikatele. See tuvastamisloogika suudab kohandada Turingi masinat rekursiivselt loetavate grammatikate katmiseks. Veelgi enam, varem oli kohandatava Turingi masina loomise \u00fclesanne lahendamata, kuni esimesed uuringud n\u00e4rviv\u00f5rkude Turingi masinatest avalikustati.<\/p>\n

Masin\u00f5pe pakub ainulaadset v\u00f5imalust kohandada mis tahes grammatikat, et katta mistahes r\u00fcnnakute t\u00fc\u00fcpe ilma signatuuride loendite k\u00e4sitsi koostamise vajaduseta, mis oli vajalik esimese p\u00f5lvkonna tuvastamisel, ja ilma uute tokeniseerijate\/parserite v\u00e4ljat\u00f6\u00f6tamiseta uute r\u00fcnnakute, nagu Memcachedi, Redis'i, Cassandrat ja SSRF, suhtes, nagu seda n\u00f5udis teise p\u00f5lvkonna metoodika. <\/p>\n

Kombineerides k\u00f5ik kolm tuvastusloogika p\u00f5lvkonda, saame joonistada uue diagrammi, kus punase kontuuriga on esindatud kolmanda p\u00f5lvkonna tuvastamine (joonis 3). See p\u00f5lvkond h\u00f5lmab \u00fchte lahendust, mida me rakendame pilves koos \u201eOnseki\u201d, veebirakenduste ja API adaptiivse kaitse platvormi arendajaga, Alarme. <\/p>\n

N\u00fc\u00fcd kasutatakse tuvastusloogikas rakenduselt tagasisidet automaatse seadistamise jaoks. Masin\u00f5ppe raames kutsutakse seda tagasiside ts\u00fcklit \u201etugiseerimine\u201d. \u00dcldiselt on olemas \u00fcks v\u00f5i mitu sellist tugiseerimise t\u00fc\u00fcpi:<\/p>\n