Kur bëhet fjalë për monitorimin e sigurisë së një rrjeti të brendshëm korporate ose departamenti, shumë e lidhin atë me kontrollin e rrjedhjeve të informacionit dhe zbatimin e zgjidhjeve DLP. Dhe nëse përpiqeni të sqaroni pyetjen dhe pyesni se si zbuloni sulmet në rrjetin e brendshëm, atëherë përgjigjja, si rregull, do të jetë një përmendje e sistemeve të zbulimit të ndërhyrjeve (IDS). Dhe ajo që ishte opsioni i vetëm 10-20 vjet më parë po bëhet një anakronizëm sot. Ekziston një opsion më efektiv, dhe në disa vende, i vetmi opsion i mundshëm për monitorimin e një rrjeti të brendshëm - përdorimi i protokolleve të rrjedhës, të cilat fillimisht ishin krijuar për të kërkuar problemet e rrjetit (zgjidhja e problemeve), por me kalimin e kohës u shndërruan në një mjet shumë interesant sigurie. Ne do të flasim për protokollet e rrjedhës dhe cilat janë më të mira në zbulimin e sulmeve në rrjet, ku është më mirë të zbatohet monitorimi i rrjedhës, çfarë të kërkoni kur vendosni një skemë të tillë dhe madje edhe si të "ngreni" të gjitha këto në pajisjet shtëpiake brenda objektit të këtij neni.
Nuk do tĂ« ndalem nĂ« pyetjen âPse nevojitet monitorimi i sigurisĂ« sĂ« infrastrukturĂ«s sĂ« brendshme?â PĂ«rgjigja duket se Ă«shtĂ« e qartĂ«. Por nĂ«se, megjithatĂ«, dĂ«shironi tĂ« siguroheni edhe njĂ« herĂ« qĂ« sot nuk mund tĂ« jetoni pa tĂ«, njĂ« video e shkurtĂ«r se si mund tĂ« depĂ«rtoni nĂ« njĂ« rrjet tĂ« korporatĂ«s tĂ« mbrojtur nga njĂ« mur zjarri nĂ« 17 mĂ«nyra. Prandaj, do tĂ« supozojmĂ« se e kuptojmĂ« se monitorimi i brendshĂ«m Ă«shtĂ« njĂ« gjĂ« e nevojshme dhe ajo qĂ« mbetet Ă«shtĂ« tĂ« kuptojmĂ« se si mund tĂ« organizohet.
Do të theksoja tre burime kryesore të të dhënave për monitorimin e infrastrukturës në nivel rrjeti:
- Trafiku "i papërpunuar" që ne kapim dhe dorëzojmë për analizë në sisteme të caktuara analizash,
- ngjarje nga pajisjet e rrjetit nëpër të cilat kalon trafiku,
- informacioni i trafikut të marrë nëpërmjet një prej protokolleve të rrjedhës.
Kapja e trafikut të papërpunuar është opsioni më i popullarizuar midis specialistëve të sigurisë, sepse historikisht u shfaq dhe ishte i pari. Sistemet konvencionale të zbulimit të ndërhyrjeve në rrjet (sistemi i parë komercial i zbulimit të ndërhyrjeve ishte NetRanger nga Wheel Group, i blerë në 1998 nga Cisco) ishin të angazhuar pikërisht në kapjen e paketave (dhe seancat e mëvonshme) në të cilat kërkoheshin disa nënshkrime ("rregulla vendimtare" në Terminologjia FSTEC), sulmet sinjalizuese. Sigurisht, ju mund të analizoni trafikun e papërpunuar jo vetëm duke përdorur IDS, por edhe duke përdorur mjete të tjera (për shembull, Wireshark, tcpdum ose funksionalitetin NBAR2 në Cisco IOS), por zakonisht atyre u mungon baza e njohurive që dallon një mjet sigurie informacioni nga një mjet i rregullt. mjet IT.
Pra, sistemet e zbulimit tĂ« sulmit. Metoda mĂ« e vjetĂ«r dhe mĂ« e popullarizuar e zbulimit tĂ« sulmeve nĂ« rrjet, e cila bĂ«n njĂ« punĂ« tĂ« mirĂ« nĂ« perimetĂ«r (pa marrĂ« parasysh se çfarĂ« - korporata, qendra e tĂ« dhĂ«nave, segmenti, etj.), por dĂ«shton nĂ« rrjetet moderne tĂ« komutuara dhe tĂ« pĂ«rcaktuara nga softueri. NĂ« rastin e njĂ« rrjeti tĂ« ndĂ«rtuar nĂ« bazĂ« tĂ« ndĂ«rprerĂ«sve konvencionalĂ«, infrastruktura e sensorĂ«ve tĂ« zbulimit tĂ« sulmit bĂ«het shumĂ« e madhe - do t'ju duhet tĂ« instaloni njĂ« sensor nĂ« secilĂ«n lidhje me nyjen nĂ« tĂ« cilĂ«n dĂ«shironi tĂ« monitoroni sulmet. Ădo prodhues, sigurisht, do tĂ« jetĂ« i lumtur t'ju shesĂ« qindra e mijĂ«ra sensorĂ«, por mendoj se buxheti juaj nuk mund tĂ« pĂ«rballojĂ« shpenzime tĂ« tilla. Mund tĂ« them qĂ« edhe nĂ« Cisco (dhe ne jemi zhvilluesit e NGIPS) nuk mund ta bĂ«nim kĂ«tĂ«, megjithĂ«se duket se çështja e çmimit Ă«shtĂ« para nesh. UnĂ« nuk duhet tĂ« qĂ«ndroj - Ă«shtĂ« vendimi ynĂ«. PĂ«r mĂ« tepĂ«r, lind pyetja, si ta lidhni sensorin nĂ« kĂ«tĂ« version? NĂ« hendek? Po nĂ«se vetĂ« sensori dĂ«shton? KĂ«rkohet njĂ« modul anashkalimi nĂ« sensor? PĂ«rdorni ndarĂ«s (trokitje e lehtĂ«)? E gjithĂ« kjo e bĂ«n zgjidhjen mĂ« tĂ« shtrenjtĂ« dhe e bĂ«n atĂ« tĂ« papĂ«rballueshme pĂ«r njĂ« kompani tĂ« çdo madhĂ«sie.
Mund të provoni të "varni" sensorin në një portë SPAN/RSPAN/ERSPAN dhe të drejtoni trafikun nga portat e kërkuara të kalimit në të. Ky opsion heq pjesërisht problemin e përshkruar në paragrafin e mëparshëm, por paraqet një tjetër - porti SPAN nuk mund të pranojë absolutisht të gjithë trafikun që do t'i dërgohet - nuk do të ketë gjerësi bande të mjaftueshme. Do t'ju duhet të sakrifikoni diçka. Ose lini disa nga nyjet pa monitorim (atëherë duhet t'i jepni përparësi atyre së pari), ose dërgoni jo të gjithë trafikun nga nyja, por vetëm një lloj të caktuar. Në çdo rast, mund të na mungojnë disa sulme. Përveç kësaj, porti SPAN mund të përdoret për nevoja të tjera. Si rezultat, ne do të duhet të rishikojmë topologjinë ekzistuese të rrjetit dhe ndoshta të bëjmë rregullime në të në mënyrë që të mbulojmë rrjetin tuaj në maksimum me numrin e sensorëve që keni (dhe ta koordinojmë këtë me IT).
Po sikur rrjeti juaj pĂ«rdor rrugĂ« asimetrike? Po sikur tĂ« keni zbatuar ose po planifikoni tĂ« zbatoni SDN? Po sikur tĂ« keni nevojĂ« tĂ« monitoroni makinat ose kontejnerĂ«t e virtualizuar, trafiku i tĂ« cilĂ«ve nuk arrin fare nĂ« çelĂ«sin fizik? KĂ«to janĂ« pyetje qĂ« shitĂ«sve tradicionalĂ« tĂ« IDS nuk u pĂ«lqejnĂ« sepse nuk dinĂ« t'u pĂ«rgjigjen atyre. Ndoshta ata do t'ju bindin se tĂ« gjitha kĂ«to teknologji nĂ« modĂ« janĂ« reklamĂ« dhe ju nuk keni nevojĂ« pĂ«r tĂ«. Ndoshta ata do tĂ« flasin pĂ«r nevojĂ«n pĂ«r tĂ« filluar pak. Ose ndoshta ata do tĂ« thonĂ« se duhet tĂ« vendosni njĂ« shirĂ«s tĂ« fuqishĂ«m nĂ« qendĂ«r tĂ« rrjetit dhe tĂ« drejtoni tĂ« gjithĂ« trafikun drejt tij duke pĂ«rdorur balancues. ĂfarĂ«do opsioni qĂ« ju ofrohet, duhet tĂ« kuptoni qartĂ« se si ju pĂ«rshtatet. Dhe vetĂ«m pas kĂ«saj merrni njĂ« vendim pĂ«r zgjedhjen e njĂ« qasjeje pĂ«r monitorimin e sigurisĂ« sĂ« informacionit tĂ« infrastrukturĂ«s sĂ« rrjetit. Pas kthimit nĂ« kapjen e paketave, dua tĂ« them qĂ« kjo metodĂ« vazhdon tĂ« jetĂ« shumĂ« e popullarizuar dhe e rĂ«ndĂ«sishme, por qĂ«llimi kryesor i saj Ă«shtĂ« kontrolli i kufirit; kufijtĂ« midis organizatĂ«s suaj dhe internetit, kufijtĂ« midis qendrĂ«s sĂ« tĂ« dhĂ«nave dhe pjesĂ«s tjetĂ«r tĂ« rrjetit, kufijtĂ« midis sistemit tĂ« kontrollit tĂ« procesit dhe segmentit tĂ« korporatĂ«s. NĂ« kĂ«to vende, ID -tĂ« klasike/IP -tĂ« ende kanĂ« tĂ« drejtĂ« tĂ« ekzistojnĂ« dhe tĂ« pĂ«rballojnĂ« mirĂ« me detyrat e tyre.
Le të kalojmë në opsionin e dytë. Analiza e ngjarjeve që vijnë nga pajisjet e rrjetit mund të përdoret gjithashtu për qëllime të zbulimit të sulmeve, por jo si mekanizmi kryesor, pasi lejon zbulimin e vetëm një klase të vogël ndërhyrjesh. Për më tepër, është e natyrshme në njëfarë reaktiviteti - fillimisht duhet të ndodhë sulmi, pastaj duhet të regjistrohet nga një pajisje rrjeti, e cila në një mënyrë ose në një tjetër do të sinjalizojë një problem me sigurinë e informacionit. Ka disa mënyra të tilla. Ky mund të jetë syslog, RMON ose SNMP. Dy protokollet e fundit për monitorimin e rrjetit në kontekstin e sigurisë së informacionit përdoren vetëm nëse duhet të zbulojmë një sulm DoS në vetë pajisjet e rrjetit, pasi duke përdorur RMON dhe SNMP është e mundur, për shembull, të monitorohet ngarkesa në qendrën e pajisjes. procesori ose ndërfaqet e tij. Kjo është një nga "më të lirat" (të gjithë kanë syslog ose SNMP), por edhe më joefektive nga të gjitha metodat e monitorimit të sigurisë së informacionit të infrastrukturës së brendshme - shumë sulme thjesht fshihen prej saj. Natyrisht, ato nuk duhen neglizhuar, dhe e njëjta analizë syslog ju ndihmon të identifikoni me kohë ndryshimet në konfigurimin e vetë pajisjes, komprometimin e tij, por nuk është shumë i përshtatshëm për zbulimin e sulmeve në të gjithë rrjetin.
Opsioni i tretë është të analizoni informacionin rreth trafikut që kalon përmes një pajisjeje që mbështet një nga disa protokolle të rrjedhës. Në këtë rast, pavarësisht nga protokolli, infrastruktura e filetimit përbëhet domosdoshmërisht nga tre komponentë:
- Gjenerimi ose eksporti i rrjedhës. Ky rol zakonisht i caktohet një router, ndërprerës ose pajisje tjetër rrjeti, e cila, duke kaluar trafikun e rrjetit përmes vetvetes, ju lejon të nxirrni parametrat kryesorë prej tij, të cilët më pas transmetohen në modulin e grumbullimit. Për shembull, Cisco mbështet protokollin Netflow jo vetëm në ruterat dhe çelsat, duke përfshirë ato virtuale dhe industriale, por edhe në kontrollorët me valë, muret e zjarrit dhe madje edhe serverët.
- Rrjedha e koleksionit. Duke marrë parasysh se një rrjet modern zakonisht ka më shumë se një pajisje rrjeti, lind problemi i grumbullimit dhe konsolidimit të flukseve, i cili zgjidhet duke përdorur të ashtuquajturat kolektorë, të cilët përpunojnë flukset e marra dhe më pas i transmetojnë ato për analizë.
- Analiza e rrjedhës Analizuesi merr përsipër detyrën kryesore intelektuale dhe, duke aplikuar algoritme të ndryshme në rrjedhat, nxjerr përfundime të caktuara. Për shembull, si pjesë e një funksioni IT, një analizues i tillë mund të identifikojë pengesat e rrjetit ose të analizojë profilin e ngarkesës së trafikut për optimizim të mëtejshëm të rrjetit. Dhe për sigurinë e informacionit, një analizues i tillë mund të zbulojë rrjedhjet e të dhënave, përhapjen e kodit me qëllim të keq ose sulmet DoS.
Mos mendoni se kjo arkitekturë me tre nivele është shumë e ndërlikuar - të gjitha opsionet e tjera (përveç, ndoshta, sistemet e monitorimit të rrjetit që punojnë me SNMP dhe RMON) gjithashtu funksionojnë sipas saj. Ne kemi një gjenerator të dhënash për analizë, i cili mund të jetë një pajisje rrjeti ose një sensor i pavarur. Ne kemi një sistem grumbullimi alarmi dhe një sistem menaxhimi për të gjithë infrastrukturën e monitorimit. Dy komponentët e fundit mund të kombinohen brenda një nyje të vetme, por në rrjete pak a shumë të mëdha ato zakonisht shpërndahen në të paktën dy pajisje për të siguruar shkallëzim dhe besueshmëri.
Ndryshe nga analiza e paketave, e cila bazohet në studimin e të dhënave të kokës dhe trupit të secilës paketë dhe seancat nga të cilat ajo përbëhet, analiza e rrjedhës mbështetet në mbledhjen e meta të dhënave rreth trafikut të rrjetit. Kur, sa, nga dhe ku, si... këto janë pyetjet që përgjigjet analiza e telemetrisë së rrjetit duke përdorur protokolle të ndryshme të rrjedhës. Fillimisht, ato u përdorën për të analizuar statistikat dhe për të gjetur probleme të TI-së në rrjet, por më pas, me zhvillimin e mekanizmave analitikë, u bë e mundur aplikimi i tyre në të njëjtën telemetri për qëllime sigurie. Vlen të përmendet përsëri se analiza e rrjedhës nuk zëvendëson ose zëvendëson kapjen e paketave. Secila prej këtyre metodave ka fushën e vet të aplikimit. Por në kontekstin e këtij artikulli, është analiza e rrjedhës që është më e përshtatshme për monitorimin e infrastrukturës së brendshme. Ju keni pajisje të rrjetit (pavarësisht nëse ato funksionojnë në një paradigmë të përcaktuar nga softveri ose sipas rregullave statike) që një sulm nuk mund të anashkalojë. Mund të anashkalojë një sensor klasik IDS, por një pajisje e rrjetit që mbështet protokollin e rrjedhës nuk mund. Ky është avantazhi i kësaj metode.
Nga ana tjetër, nëse keni nevojë për prova për zbatimin e ligjit ose ekipin tuaj të hetimit të incidentit, nuk mund të bëni pa kapjen e paketave - telemetria e rrjetit nuk është një kopje e trafikut që mund të përdoret për të mbledhur prova; është e nevojshme për zbulimin dhe vendimmarrjen e shpejtë në fushën e sigurisë së informacionit. Nga ana tjetër, duke përdorur analizën e telemetrisë, ju mund të "shkruani" jo të gjithë trafikun e rrjetit (nëse ka ndonjë gjë, Cisco merret me qendrat e të dhënave :-), por vetëm atë që përfshihet në sulm. Mjetet e analizës së telemetrisë në këtë drejtim do të plotësojnë mirë mekanizmat tradicionalë të kapjes së paketave, duke dhënë komanda për kapjen dhe ruajtjen selektive. Përndryshe, do t'ju duhet të keni një infrastrukturë kolosale magazinimi.
Le tĂ« imagjinojmĂ« njĂ« rrjet qĂ« funksionon me njĂ« shpejtĂ«si prej 250 Mbit/sek. NĂ«se dĂ«shironi tĂ« ruani gjithĂ« kĂ«tĂ« vĂ«llim, atĂ«herĂ« do t'ju nevojiten 31 MB hapĂ«sirĂ« ââruajtĂ«se pĂ«r njĂ« sekondĂ« transmetimi tĂ« trafikut, 1,8 GB pĂ«r njĂ« minutĂ«, 108 GB pĂ«r njĂ« orĂ« dhe 2,6 TB pĂ«r njĂ« ditĂ«. PĂ«r tĂ« ruajtur tĂ« dhĂ«nat ditore nga njĂ« rrjet me njĂ« gjerĂ«si brezi prej 10 Gbit/s, do t'ju duhet 108 TB hapĂ«sirĂ« ââruajtĂ«se. Por disa rregullatorĂ« kĂ«rkojnĂ« ruajtjen e tĂ« dhĂ«nave tĂ« sigurisĂ« pĂ«r vite me radhĂ«... Regjistrimi sipas kĂ«rkesĂ«s, tĂ« cilin analiza e rrjedhĂ«s ju ndihmon ta zbatoni, ndihmon nĂ« uljen e kĂ«tyre vlerave sipas rendit tĂ« madhĂ«sisĂ«. Nga rruga, nĂ«se flasim pĂ«r raportin e vĂ«llimit tĂ« tĂ« dhĂ«nave telemetrike tĂ« rrjetit tĂ« regjistruar dhe kapjen e plotĂ« tĂ« tĂ« dhĂ«nave, atĂ«herĂ« Ă«shtĂ« afĂ«rsisht 1 deri nĂ« 500. PĂ«r tĂ« njĂ«jtat vlera tĂ« dhĂ«na mĂ« sipĂ«r, ruajtja e njĂ« transkripti tĂ« plotĂ« tĂ« tĂ« gjithĂ« trafikut ditor do tĂ« jetĂ« pĂ«rkatĂ«sisht 5 dhe 216 GB (mund ta regjistroni edhe nĂ« njĂ« flash drive tĂ« rregullt).
NĂ«se pĂ«r mjetet pĂ«r analizimin e tĂ« dhĂ«nave tĂ« papĂ«rpunuara tĂ« rrjetit, metoda e kapjes sĂ« tyre Ă«shtĂ« pothuajse e njĂ«jtĂ« nga shitĂ«si nĂ« shitĂ«s, atĂ«herĂ« nĂ« rastin e analizĂ«s sĂ« rrjedhĂ«s situata Ă«shtĂ« e ndryshme. EkzistojnĂ« disa opsione pĂ«r protokollet e rrjedhĂ«s, ndryshimet nĂ« tĂ« cilat duhet tĂ« dini nĂ« kontekstin e sigurisĂ«. MĂ« i popullarizuari Ă«shtĂ« protokolli Netflow i zhvilluar nga Cisco. EkzistojnĂ« disa versione tĂ« kĂ«tij protokolli, qĂ« ndryshojnĂ« nĂ« aftĂ«sitĂ« e tyre dhe sasinĂ« e informacionit tĂ« trafikut tĂ« regjistruar. Versioni aktual Ă«shtĂ« i nĂ«nti (Netflow v9), mbi bazĂ«n e tĂ« cilit u zhvillua standardi i industrisĂ« Netflow v10, i njohur gjithashtu si IPFIX. Sot, shumica e shitĂ«sve tĂ« rrjetit mbĂ«shtesin Netflow ose IPFIX nĂ« pajisjet e tyre. Por ka opsione tĂ« tjera tĂ« ndryshme pĂ«r protokollet e rrjedhĂ«s - sFlow, jFlow, cFlow, rFlow, NetStream, etj., nga tĂ« cilat sFlow Ă«shtĂ« mĂ« i popullarizuari. ĂshtĂ« ky lloj qĂ« mĂ« sĂ« shpeshti mbĂ«shtetet nga prodhuesit vendas tĂ« pajisjeve tĂ« rrjetit pĂ«r shkak tĂ« lehtĂ«sisĂ« sĂ« zbatimit tĂ« tij. Cilat janĂ« ndryshimet kryesore midis Netflow, i cili Ă«shtĂ« bĂ«rĂ« njĂ« standard de fakto, dhe sFlow? Do tĂ« veçoja disa nga ato kryesore. SĂ« pari, Netflow ka fusha tĂ« personalizueshme nga pĂ«rdoruesi nĂ« krahasim me fushat fikse nĂ« sFlow. Dhe sĂ« dyti, dhe kjo Ă«shtĂ« gjĂ«ja mĂ« e rĂ«ndĂ«sishme nĂ« rastin tonĂ«, sFlow mbledh tĂ« ashtuquajturĂ«n telemetri tĂ« mostrĂ«s; nĂ« kontrast me atĂ« tĂ« pa kampionuar pĂ«r Netflow dhe IPFIX. Cili Ă«shtĂ« ndryshimi midis tyre?
Imagjinoni qĂ« vendosni tĂ« lexoni librin "â e kolegĂ«ve tĂ« mi - Gary McIntyre, Joseph Munitz dhe Nadem Alfardan (mund tĂ« shkarkoni njĂ« pjesĂ« tĂ« librit nga lidhja). Ju keni tre opsione pĂ«r tĂ« arritur qĂ«llimin tuaj - lexoni tĂ« gjithĂ« librin, kaloni nĂ«pĂ«r tĂ«, ndaloni nĂ« çdo faqe tĂ« 10-tĂ« ose tĂ« 20-tĂ«, ose pĂ«rpiquni tĂ« gjeni njĂ« ritregim tĂ« koncepteve kryesore nĂ« njĂ« blog ose shĂ«rbim si SmartReading. Pra, telemetria pa mostĂ«r po lexon çdo "faqe" tĂ« trafikut tĂ« rrjetit, domethĂ«nĂ«, duke analizuar metadatat pĂ«r secilĂ«n paketĂ«. Telemetria e mostrĂ«s Ă«shtĂ« studimi selektiv i trafikut me shpresĂ«n se mostrat e pĂ«rzgjedhura do tĂ« pĂ«rmbajnĂ« atĂ« qĂ« ju nevojitet. NĂ« varĂ«si tĂ« shpejtĂ«sisĂ« sĂ« kanalit, telemetria e mostrĂ«s do tĂ« dĂ«rgohet pĂ«r analizĂ« çdo paketĂ« tĂ« 64-tĂ«, tĂ« 200-tĂ«, tĂ« 500-tĂ«, tĂ« 1000-tĂ«, tĂ« 2000-tĂ« apo edhe tĂ« 10000-tĂ«.
Në kontekstin e monitorimit të sigurisë së informacionit, kjo do të thotë se telemetria e mostrës është e përshtatshme për zbulimin e sulmeve DDoS, skanimin dhe përhapjen e kodit me qëllim të keq, por mund të humbasë sulmet atomike ose me shumë paketa që nuk janë përfshirë në mostrën e dërguar për analizë. Telemetria e pangopur nuk ka disavantazhe të tilla. Me këtë, gama e sulmeve të zbuluara është shumë më e gjerë. Këtu është një listë e shkurtër e ngjarjeve që mund të zbulohen duke përdorur mjetet e analizës së telemetrisë së rrjetit.
Sigurisht, disa analizues Netflow me burim të hapur nuk do t'ju lejojnë ta bëni këtë, pasi detyra e tij kryesore është mbledhja e telemetrisë dhe kryerja e analizave themelore mbi të nga pikëpamja e IT. Për të identifikuar kërcënimet e sigurisë së informacionit bazuar në rrjedhën, është e nevojshme të pajisni analizuesin me motorë dhe algoritme të ndryshme, të cilët do të identifikojnë problemet e sigurisë kibernetike bazuar në fushat standarde ose të personalizuara të Netflow, do të pasurojnë të dhënat standarde me të dhëna të jashtme nga burime të ndryshme të Inteligjencës së Kërcënimit, etj.
Prandaj, nëse keni një zgjedhje, atëherë zgjidhni Netflow ose IPFIX. Por edhe nëse pajisjet tuaja funksionojnë vetëm me sFlow, si prodhuesit vendas, atëherë edhe në këtë rast mund të përfitoni prej saj në një kontekst sigurie.
Në verën e vitit 2019, unë analizova aftësitë që kanë prodhuesit rusë të pajisjeve të rrjetit dhe të gjithë, duke përjashtuar NSG, Polygon dhe Craftway, njoftuan mbështetje për sFlow (të paktën Zelax, Natex, Eltex, QTech, Rusteleteh).
Pyetja tjetër me të cilën do të përballeni është se ku të zbatoni mbështetjen e rrjedhës për qëllime sigurie? Në fakt, pyetja nuk është shtruar plotësisht në mënyrë korrekte. Pajisjet moderne pothuajse gjithmonë mbështesin protokollet e rrjedhës. Prandaj, do ta riformuloja pyetjen ndryshe - ku është më efektive mbledhja e telemetrisë nga pikëpamja e sigurisë? Përgjigja do të jetë mjaft e qartë - në nivelin e aksesit, ku do të shihni 100% të të gjithë trafikut, ku do të keni informacion të detajuar për hostet (MAC, VLAN, ID e ndërfaqes), ku madje mund të monitoroni trafikun P2P midis hosteve, të cilat është kritike për skanimin e zbulimit dhe shpërndarjes së kodit me qëllim të keq. Në nivelin bazë, thjesht mund të mos shihni një pjesë të trafikut, por në nivelin e perimetrit, do të shihni një të katërtën e të gjithë trafikut të rrjetit tuaj. Por nëse për ndonjë arsye keni pajisje të huaja në rrjetin tuaj që lejojnë sulmuesit të "hyjnë dhe dalin" pa anashkaluar perimetrin, atëherë analizimi i telemetrisë prej tij nuk do t'ju japë asgjë. Prandaj, për mbulim maksimal, rekomandohet të mundësohet grumbullimi i telemetrisë në nivelin e aksesit. Në të njëjtën kohë, vlen të përmendet se edhe nëse po flasim për virtualizim ose kontejnerë, mbështetja e rrjedhës shpesh gjendet gjithashtu në çelsat moderne virtuale, gjë që ju lejon të kontrolloni trafikun edhe atje.
Por meqenëse e ngrita temën, më duhet t'i përgjigjem pyetjes: po sikur pajisja, fizike apo virtuale, të mos mbështesë protokollet e rrjedhës? Apo është e ndaluar përfshirja e tij (për shembull, në segmentet industriale për të siguruar besueshmërinë)? Apo ndezja e tij çon në ngarkesë të lartë të CPU-së (kjo ndodh në pajisje të vjetra)? Për të zgjidhur këtë problem, ekzistojnë sensorë virtualë të specializuar (sensorë rrjedhjeje), të cilët në thelb janë ndarës të zakonshëm që kalojnë trafikun përmes vetes dhe e transmetojnë atë në formën e rrjedhës në modulin e grumbullimit. Vërtetë, në këtë rast marrim të gjitha problemet për të cilat folëm më lart në lidhje me mjetet e kapjes së paketave. Kjo do të thotë, ju duhet të kuptoni jo vetëm avantazhet e teknologjisë së analizës së rrjedhës, por edhe kufizimet e saj.
Një pikë tjetër që është e rëndësishme të mbani mend kur flisni për mjetet e analizës së rrjedhës. Nëse në lidhje me mjetet konvencionale të gjenerimit të ngjarjeve të sigurisë përdorim metrikën EPS (ngjarje për sekondë), atëherë ky tregues nuk është i zbatueshëm për analizën telemetrike; ai zëvendësohet nga FPS (rrjedhja për sekondë). Ashtu si në rastin e EPS, nuk mund të llogaritet paraprakisht, por mund të vlerësoni numrin e përafërt të fijeve që gjeneron një pajisje e veçantë në varësi të detyrës së saj. Ju mund të gjeni tabela në internet me vlera të përafërta për lloje të ndryshme të pajisjeve dhe kushteve të ndërmarrjes, të cilat do t'ju lejojnë të vlerësoni se cilat licenca ju nevojiten për mjetet e analizës dhe cila do të jetë arkitektura e tyre? Fakti është se sensori IDS është i kufizuar nga një gjerësi bande e caktuar që mund të "tërheqë", dhe kolektori i rrjedhës ka kufizimet e veta që duhen kuptuar. Prandaj, në rrjete të mëdha, të shpërndara gjeografikisht, zakonisht ka disa koleksionistë. Kur përshkrova , Unë kam dhënë tashmë numrin e koleksionistëve tanë - janë 21. Dhe kjo është për një rrjet të shpërndarë në pesë kontinente dhe që numëron rreth gjysmë milioni pajisje aktive).
Ne përdorim zgjidhjen tonë si një sistem monitorimi Netflow , e cila fokusohet në mënyrë specifike në zgjidhjen e problemeve të sigurisë. Ka shumë motorë të integruar për zbulimin e aktivitetit anormal, të dyshimtë dhe qartësisht me qëllim të keq, i cili ju lejon të zbuloni një gamë të gjerë kërcënimesh të ndryshme - nga kriptominimi deri te rrjedhjet e informacionit, nga përhapja e kodit me qëllim të keq deri te mashtrimi. Ashtu si shumica e analizuesve të rrjedhës, Stealthwatch është ndërtuar sipas një skeme me tre nivele (gjenerator - kolektor - analizues), por plotësohet me një numër karakteristikash interesante që janë të rëndësishme në kontekstin e materialit në shqyrtim. Së pari, ai integrohet me zgjidhjet e kapjes së paketave (siç është Cisco Security Packet Analyzer), i cili ju lejon të regjistroni sesionet e zgjedhura të rrjetit për hetim dhe analizë të mëvonshme të thelluar. Së dyti, posaçërisht për të zgjeruar detyrat e sigurisë, ne kemi zhvilluar një protokoll të veçantë nvzFlow, i cili ju lejon të "transmetoni" aktivitetin e aplikacioneve në nyjet fundore (serverët, stacionet e punës, etj.) në telemetri dhe ta transmetoni atë te kolektori për analiza të mëtejshme. Nëse në versionin e tij origjinal Stealthwatch punon me çdo protokoll rrjedhjeje (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) në nivel rrjeti, atëherë mbështetja nvzFlow lejon korrelacionin e të dhënave edhe në nivelin e nyjeve. duke rritur efikasitetin e të gjithë sistemit dhe duke parë më shumë sulme sesa analizuesit konvencionalë të rrjedhës së rrjetit.
ĂshtĂ« e qartĂ« se kur flasim pĂ«r sistemet e analizĂ«s Netflow nga pikĂ«pamja e sigurisĂ«, tregu nuk kufizohet nĂ« njĂ« zgjidhje tĂ« vetme nga Cisco. Ju mund tĂ« pĂ«rdorni zgjidhje komerciale dhe falas ose shareware. ĂshtĂ« mjaft e çuditshme nĂ«se citoj zgjidhjet e konkurrentĂ«ve si shembuj nĂ« blogun e Cisco-s, kĂ«shtu qĂ« do tĂ« them disa fjalĂ« se si mund tĂ« analizohet telemetria e rrjetit duke pĂ«rdorur dy mjete tĂ« njohura, tĂ« ngjashme nĂ« emĂ«r, por ende tĂ« ndryshme - SiLK dhe ELK.
SiLK është një grup mjetesh (Sistemi për Njohuri të Nivelit të Internetit) për analizën e trafikut, i zhvilluar nga CERT/CC Amerikan dhe që mbështet, në kontekstin e artikullit të sotëm, Netflow (versionet e 5-ta dhe të 9-ta më të njohura), IPFIX dhe sFlow dhe përdorimi i shërbimeve të ndryshme (rwfilter, rwcount, rwflowpack, etj.) për të kryer operacione të ndryshme në telemetrinë e rrjetit me qëllim zbulimin e shenjave të veprimeve të paautorizuara në të. Por ka disa pika të rëndësishme për t'u theksuar. SiLK është një mjet i linjës komanduese që kryen analiza on-line duke futur komanda si kjo (zbulimi i paketave ICMP më të mëdha se 200 bajt):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
jo shumë komode. Ju mund të përdorni ISILK GUI, por nuk do ta bëjë jetën tuaj shumë më të lehtë, duke zgjidhur vetëm funksionin e vizualizimit dhe duke mos zëvendësuar analistin. Dhe kjo është pika e dytë. Ndryshe nga zgjidhjet komerciale, të cilat tashmë kanë një bazë solide analitike, algoritme për zbulimin e anomalive, rrjedhën përkatëse të punës, etj., në rastin e SiLK-së do t'ju duhet t'i bëni të gjitha vetë, gjë që do të kërkojë kompetenca paksa më të ndryshme nga ju sesa nga përdorimi tashmë i gatshëm. mjetet e përdorimit. Kjo nuk është as e mirë as e keqe - kjo është një veçori e pothuajse çdo mjeti falas që supozon se ju dini çfarë të bëni dhe do t'ju ndihmojë vetëm me këtë (mjetet tregtare varen më pak nga kompetencat e përdoruesve të tij, megjithëse ata gjithashtu supozojnë që analistët i kuptojnë të paktën bazat e hetimeve dhe monitorimit të rrjetit). Por le të kthehemi te SILK. Cikli i punës i analistit me të duket kështu:
- Formulimi i një hipoteze. Ne duhet të kuptojmë se çfarë do të kërkojmë brenda telemetrisë së rrjetit, të dimë atributet unike me të cilat do të identifikojmë disa anomali ose kërcënime.
- Ndërtimi i një modeli. Pasi kemi formuluar një hipotezë, ne e programojmë atë duke përdorur të njëjtin Python, shell ose mjete të tjera që nuk përfshihen në SiLK.
- Duke testuar. ĂshtĂ« koha pĂ«r tĂ« kontrolluar korrektĂ«sinĂ« e hipotezĂ«s sonĂ«, e cila konfirmohet ose hidhet poshtĂ« duke pĂ«rdorur shĂ«rbimet SiLK duke filluar me 'rw', 'set', 'bag'.
- Analiza e të dhënave reale. Në funksionimin industrial, SiLK na ndihmon të identifikojmë diçka dhe analisti duhet t'i përgjigjet pyetjeve "A gjetëm atë që prisnim?", "A korrespondon kjo me hipotezën tonë?", "Si të zvogëlojmë numrin e pozitivëve të rremë?", "Si për të përmirësuar nivelin e njohjes? » e kështu me radhë.
- Përmirësimi. Në fazën përfundimtare, ne përmirësojmë atë që është bërë më parë - krijojmë shabllone, përmirësojmë dhe optimizojmë kodin, riformulojmë dhe sqarojmë hipotezën, etj.
Ky cikël do të jetë i zbatueshëm edhe për Cisco Stealthwatch, vetëm i fundit i automatizon këto pesë hapa në maksimum, duke reduktuar numrin e gabimeve të analistit dhe duke rritur efikasitetin e zbulimit të incidenteve. Për shembull, në SiLK mund të pasuroni statistikat e rrjetit me të dhëna të jashtme për IP-të me qëllim të keq duke përdorur skriptet e shkruara me dorë, dhe në Cisco Stealthwatch është një funksion i integruar që shfaq menjëherë një alarm nëse trafiku i rrjetit përmban ndërveprime me adresat IP nga lista e zezë.
Nëse shkoni më lart në piramidën "me pagesë" për softuerin e analizës së rrjedhës, atëherë pas SiLK absolutisht falas do të ketë një shareware ELK, i përbërë nga tre komponentë kryesorë - Elasticsearch (indeksimi, kërkimi dhe analiza e të dhënave), Logstash (hyrja/dalja e të dhënave ) dhe Kibana (vizualizimi). Ndryshe nga SiLK, ku duhet të shkruani gjithçka vetë, ELK tashmë ka shumë biblioteka/module të gatshme (disa me pagesë, disa jo) që automatizojnë analizën e telemetrisë së rrjetit. Për shembull, filtri GeoIP në Logstash ju lejon të lidhni adresat IP të monitoruara me vendndodhjen e tyre gjeografike (Stealthwatch e ka këtë veçori të integruar).
ELK gjithashtu ka një komunitet mjaft të madh që po plotëson komponentët që mungojnë për këtë zgjidhje monitorimi. Për shembull, për të punuar me Netflow, IPFIX dhe sFlow mund të përdorni modulin , nëse nuk jeni të kënaqur me Modulin Netflow Logstash, i cili mbështet vetëm Netflow.
Ndërsa jep më shumë efikasitet në mbledhjen e rrjedhës dhe kërkimin në të, ELK-së aktualisht i mungon analitika e pasur e integruar për zbulimin e anomalive dhe kërcënimeve në telemetrinë e rrjetit. Kjo do të thotë, duke ndjekur ciklin e jetës të përshkruar më sipër, do t'ju duhet të përshkruani në mënyrë të pavarur modelet e shkeljes dhe më pas ta përdorni atë në sistemin luftarak (nuk ka modele të integruara atje).
Ka, sigurisht, shtesa më të sofistikuara për ELK, të cilat tashmë përmbajnë disa modele për zbulimin e anomalive në telemetrinë e rrjetit, por zgjerime të tilla kushtojnë para dhe këtu pyetja është nëse loja ia vlen qiriri - shkruani vetë një model të ngjashëm, blini implementim për mjetin tuaj të monitorimit, ose blini zgjidhje të gatshme të klasës Analiza e Trafikut të Rrjetit.
NĂ« pĂ«rgjithĂ«si, nuk dua tĂ« futem nĂ« debatin se Ă«shtĂ« mĂ« mirĂ« tĂ« shpenzoni para dhe tĂ« blini njĂ« zgjidhje tĂ« gatshme pĂ«r monitorimin e anomalive dhe kĂ«rcĂ«nimeve nĂ« telemetrinĂ« e rrjetit (pĂ«r shembull, Cisco Stealthwatch) ose ta kuptoni vetĂ« dhe tĂ« personalizoni tĂ« njĂ«jtĂ«n gjĂ«. SiLK, ELK ose nfdump ose OSU Flow Tools pĂ«r çdo kĂ«rcĂ«nim tĂ« ri ( po flas pĂ«r dy tĂ« fundit prej tyre HerĂ«n e fundit)? Secili zgjedh vetĂ« dhe secili ka motivet e veta pĂ«r tĂ« zgjedhur njĂ«rĂ«n nga dy opsionet. Thjesht doja tĂ« tregoja se telemetria e rrjetit Ă«shtĂ« njĂ« mjet shumĂ« i rĂ«ndĂ«sishĂ«m pĂ«r tĂ« garantuar sigurinĂ« e rrjetit tĂ« infrastrukturĂ«s suaj tĂ« brendshme dhe nuk duhet ta neglizhoni atĂ«, pĂ«r tĂ« mos u futur nĂ« listĂ«n e kompanive emri i tĂ« cilave pĂ«rmendet nĂ« media bashkĂ« me epitetet â. hakuar", "jo nĂ« pĂ«rputhje me kĂ«rkesat e sigurisĂ« sĂ« informacionit" ", "duke mos menduar pĂ«r sigurinĂ« e tĂ« dhĂ«nave tĂ« tyre dhe tĂ« dhĂ«nave tĂ« klientit."
Për ta përmbledhur, do të doja të rendisja këshillat kryesore që duhet të ndiqni kur ndërtoni monitorimin e sigurisë së informacionit të infrastrukturës suaj të brendshme:
- Mos e kufizoni veten vetëm në perimetër! Përdorni (dhe zgjidhni) infrastrukturën e rrjetit jo vetëm për të lëvizur trafikun nga pika A në pikën B, por edhe për të adresuar çështjet e sigurisë kibernetike.
- Studioni mekanizmat ekzistues të monitorimit të sigurisë së informacionit në pajisjet e rrjetit tuaj dhe përdorni ato.
- PĂ«r monitorimin e brendshĂ«m, jepni pĂ«rparĂ«si analizĂ«s sĂ« telemetrisĂ« - ju lejon tĂ« zbuloni deri nĂ« 80-90% tĂ« tĂ« gjitha incidenteve tĂ« sigurisĂ« sĂ« informacionit nĂ« rrjet, duke bĂ«rĂ« atĂ« qĂ« Ă«shtĂ« e pamundur kur kapni paketat e rrjetit dhe kurseni hapĂ«sirĂ« ââpĂ«r ruajtjen e tĂ« gjitha ngjarjeve tĂ« sigurisĂ« sĂ« informacionit.
- Për të monitoruar flukset, përdorni Netflow v9 ose IPFIX - ato ofrojnë më shumë informacion në një kontekst sigurie dhe ju lejojnë të monitoroni jo vetëm IPv4, por edhe IPv6, MPLS, etj.
- Përdorni një protokoll rrjedhës pa mostër - ai ofron më shumë informacion për zbulimin e kërcënimeve. Për shembull, Netflow ose IPFIX.
- Kontrolloni ngarkesën në pajisjen tuaj të rrjetit - mund të mos jetë në gjendje të trajtojë gjithashtu protokollin e rrjedhës. Më pas merrni parasysh përdorimin e sensorëve virtualë ose Netflow Generation Appliance.
- Zbatoni kontrollin para së gjithash në nivelin e aksesit - kjo do t'ju japë mundësinë të shihni 100% të të gjithë trafikut.
- Nëse nuk keni zgjidhje dhe jeni duke përdorur pajisje të rrjetit rus, atëherë zgjidhni një që mbështet protokollet e rrjedhës ose ka porte SPAN/RSPAN.
- Kombinoni sistemet e zbulimit/parandalimit të ndërhyrjeve/sulmeve në skajet dhe sistemet e analizës së rrjedhës në rrjetin e brendshëm (duke përfshirë retë).
Sa i përket këshillës së fundit, do të doja të bëja një ilustrim që e kam dhënë më parë. Ju shikoni se nëse më parë shërbimi i sigurisë së informacionit Cisco pothuajse tërësisht e ndërtoi sistemin e tij të monitorimit të sigurisë së informacionit në bazë të sistemeve të zbulimit të ndërhyrjeve dhe metodave të nënshkrimit, tani ato përbëjnë vetëm 20% të incidenteve. Një tjetër 20% bie në sistemet e analizës së rrjedhës, gjë që sugjeron që këto zgjidhje nuk janë një trill, por një mjet i vërtetë në aktivitetet e shërbimeve të sigurisë së informacionit të një ndërmarrje moderne. Për më tepër, ju keni gjënë më të rëndësishme për zbatimin e tyre - infrastrukturën e rrjetit, investimet në të cilat mund të mbrohen më tej duke caktuar funksionet e monitorimit të sigurisë së informacionit në rrjet.
Konkretisht nuk e preka temën e reagimit ndaj anomalive apo kërcënimeve të evidentuara në flukset e rrjetit, por mendoj se tashmë është e qartë që monitorimi nuk duhet të përfundojë vetëm me zbulimin e një kërcënimi. Duhet të pasohet nga një përgjigje dhe mundësisht në një mënyrë automatike ose të automatizuar. Por kjo është një temë për një artikull të veçantë.
Informacione Shtese:
PS. Nëse është më e lehtë për ju të dëgjoni gjithçka që u shkrua më lart, atëherë mund të shikoni prezantimin njëorësh që formoi bazën e këtij shënimi.
Burimi: www.habr.com
