Kur flitet për monitorimin e sigurisë së një rrjeti të brendshëm korporativ ose institucionit, shumë fillojnë të mendojnë për kontrollin e rrjedhjes së informacionit dhe implementimin e zgjidhjeve DLP. Por nëse përpiqemi të saktësojmë pyetjen dhe të pyesim se si e zbuloni sulmet në rrjetin tuaj të brendshëm, përgjigjja zakonisht është përmendja e sistemeve të zbulimit të sulmeve (intrusion detection systems, IDS). Ajo që ishte opsioni i vetëm 10-20 vjet më parë, sot po bëhet një anahronizëm. Ka një variant më efektiv, dhe në disa raste dhe variantin e vetëm për monitorimin e rrjetit të brendshëm — përdorimin e protokolleve flow, të cilat fillimisht janë dizajnuar për të gjetur probleme rrjetesh (troubleshooting), por me kalimin e kohës janë transformuar në një mjet shumë interesant për sigurinë. Në këtë artikull do të flasim për se çfarë lloj protokollesh flow ekzistojnë dhe cilat nga ato ndihmojnë më shumë në zbulimin e sulmeve rrjetësore, ku është më mirë të implementohet monitorimi i flow, çfarë duhet të kemi parasysh gjatë implementimit të këtij skenari, dhe si mund ta realizojmë këtë në paisje tona vendase.
Nuk do të ndalem në pyetjen 'Përse është e nevojshme monitorimi i sigurisë së infrastrukturës së brendshme?' Përgjigjja për këtë duket e qartë. Por nëse akoma dëshironi të siguroheni se sot nuk ka asnjë formulë për ta anashkaluar këtë, një video e vogël që tregon se si mund të hyhet në një rrjet korporativ të mbrojtur nga një firewall në 17 mënyra. Prandaj, le të mendojmë se e kuptojmë që monitorimi i brendshëm është diçka e nevojshme dhe tani ka mbetur vetëm të kuptojmë se si mund ta organizojmë atë.
Unë do të veçoja tre burime kyçe të të dhënave për monitorimin e infrastrukturës në nivelin e rrjetit:
- trafiku 'i papërpunuar' që ne e kapim dhe i japim për analizë sistemeve të ndryshme të analizës,
- ngjarjet nga pajisjet rrjetësore përmes të cilave kalon trafiku,
- informacioni mbi trafikun që merret përmes një nga protokollet flow.
Kapja e trafikut të papërpunuar është opsioni më popullor për ekspertët e sigurisë, sepse historikisht ka lindur dhe ka qenë më i pari. Sistemet normale të zbulimit të sulmeve (sistemi i parë komercial i zbulimit të sulmeve ishte NetRanger nga Wheel Group, i blerë në vitin 1998 nga Cisco) ishin të fokusuar në kapjen e paketeve (dhe më vonë edhe seancave), në të cilat kërkoheshin disa nënshkrime (‘rregullat vendimtare’ në terminologjinë e FSTEK), që sinjalizuan për sulmet. Natyrisht, analiza e trafikut të papërpunuar mund të bëhet jo vetëm me IDS, por edhe me mjete të tjera (p.sh., Wireshark, tcpdump ose funksionalitetin NBAR2 në Cisco IOS), por zakonisht u mungon baza e njohurive që e ndan mjetin e sigurisë nga mjetet normale IT.
Pra, sistemet e zbulimit të sulmeve. Metoda më e vjetër dhe më popullore për zbuluar sulmet rrjetësore, e cila bën një punë të mirë në perimetrin (s’ka rëndësi cili — korporativ, QN, segmenti etj.), por dështon në rrjetet moderne të kaluara dhe ato që përcaktohen nga softueri. Në rastin e një rrjeti të ndërtuar mbi bazën e switcheve të zakonshme, infrastruktura e sensorëve të zbulimit të sulmeve bëhet tepër e madhe — do t’ju duhet të vendosni një sensor për çdo lidhje me nodin që dëshironi të monitoroni. Çdo prodhues, natyrisht, do të ishte i lumtur t'ju shiste qindra dhe mijëra sensorë, por mendoj se buxheti juaj nuk do të mbijetonte këto shpenzime. Mund të them se edhe në Cisco (dhe ne jemi zhvilluesit e NGIPS) nuk arritëm ta realizonim, ndonëse, duket, çështja e çmimit për ne nuk duhet të kishte rëndësi — përfundimisht, është zgjidhja jonë. Për më tepër, lind një pyetje, si do të lidhesh me sensorin në këtë variant? Në ndërprerje? Dhe nëse vetë sensori dështoj? A duhet të kërkohet ekzistenca e një moduli bypass në sensor? A duhet të përdoren ndarës (tap)? Të gjitha këto e rrisin çmimin e zgjidhjes dhe e bëjnë të pamundur për kompanitë e çdo madhësie.
Mund të provoni "të lidhni" sensorin në portin SPAN/RSPAN/ERSPAN dhe të drejtoni trafikun nga portet përkatëse të switchit në të. Kjo zgjidhje pjesërisht zgjidh problemin e përshkruar në paragrafin e mëparshëm, por sjell një tjetër — porti SPAN nuk mund të pranojë gjithë trafikun që do t’i drejtohet — nuk do të ketë mjaft kapacitet. Do të detyroheni të bëni disa sakrifica. Ose të lini disa pika pa monitorim (atëherë duhet të bëni një priorizim të tyre paraprakisht), ose të drejtoni vetëm një lloj të caktuar të trafikut nga pika. Në çdo rast, mund të humbasim disa sulme. Për më tepër, porti SPAN mund të jetë i zënë për nevoja të tjera. Në fund, do të duhet të rishikojmë topologjinë ekzistuese të rrjetit dhe ndoshta të bëjmë disa ndryshime për të mbuluar sa më shumë që të jetë e mundur rrjetin tuaj me numrin e sensorëve që keni (dhe ta koordinojmë këtë me IT-në).
Çfarë nëse rrjeti juaj përdor rute asimetrike? Çfarë nëse keni implementuar ose planifikoni të implementoni SDN? Çfarë nëse duhet të monitoroni makinat virtuale ose kontejnerët, trafiku i të cilëve nuk arrin në switchin fizik? Këto pyetje nuk i pëlqejnë prodhuesve të IDS traditaionale, sepse nuk dinë si t’u japin përgjigje. Ndoshta do t’ju shpjegojnë se të gjitha këto teknologji të modës janë vetëm një bujë dhe se nuk keni nevojë për to. Ndoshta do të flasin për nevojën për të filluar nga e para. Ose ndoshta do t’ju thonë se duhet të vendosni një makinë të fuqishme në qendër të rrjetit dhe të drejtoni gjithë trafikun në të përmes balancuesve. Cilado qoftë opsioni që ju ofrohet, duhet të kuptoni qartë se sa i përshtatet atë ju. Dhe vetëm pas kësaj, të merrni vendimin për qasjen ndaj monitorimit të infrastrukturës së sigurisë kibernetike. Duke u rikthyer te kapja e paketave, dua të theksoj se kjo metodë vazhdon të mbetet shumë popullore dhe e rëndësishme, por qëllimi i saj kryesor është kontrolli i kufijve; kufijve midis organizatës suaj dhe internetit, kufijve midis qendrës së të dhënave dhe rrjetit të mbetur, kufijve midis sistemit të kontrollit dhe segmentit tuaj korporativ. Në këto vende, IDS/IPS klasike ende kanë vend dhe bëjnë mjaft mirë punën e tyre.
Të kalojmë në opsionin e dytë. Analiza e ngjarjeve që vinë nga pajisjet rrjeti gjithashtu mund të përdoret për qëllime zbulimi të sulmeve, por jo si mekanizmi kryesor, pasi ajo lejon të identifikoni vetëm një klasë të vogël të ndërhyrjeve. Për më tepër, kjo metodë është paksa reaktive — sulmi duhet fillimisht të ndodhi, pastaj ai duhet të regjistrohet nga pajisja rrjetike, e cila në njëfarë mënyre do të sinjalizojë për një problem të sigurisë kibernetike. Ka disa mënyra për këtë. Mund të jetë syslog, RMON ose SNMP. Dy protokollet e fundit për monitorimin e rrjetit në kontekst të sigurisë kibernetike përdoren vetëm nëse na nevojitet të zbulojmë një sulm DoS ndaj vetë pajisjes rrjetike, pasi me ndihmën e RMON dhe SNMP mund të monitorojmë, për shembull, ngarkesën e procesorit të pajisjes ose të interface-ve të saj. Kjo është një nga mënyrat më të "lira" (syslog ose SNMP i ka çdo njeri), por gjithashtu më pak e efektshme nga të gjitha mënyrat për të monitoruar sigurinë kibernetike në infrastrukturën e brendshme — shumë sulme thjesht janë të fshehta për të. Sigurisht, nuk duhet t’i injoroni dhe analiza e syslog ndihmon për të identifikuar në kohë ndryshimet në konfiguracionin e pajisjes vetë, kompromitimin e saj, por zbuluar sulme për të gjithë rrjetin, ajo nuk është shumë e përshtatshme.
Opsioni i tretë — është analiza e informacionit mbi trafikun që kalon përmes një pajisjeje që mbështet një ose disa protokolle të flukseve. Në këtë rast, pavarësisht nga protokolli, infrastruktura e punës me flukse gjithmonë përbëhet nga tre komponente:
- Generimi ose eksporti i flukseve. Kjo rol zakonisht i atribuohet një routeri, switchi ose një pajisjeje tjetër rrjetike, e cila, duke kaluar trafikun rrjetor, mundëson nxjerrjen e parametrave kyç, të cilat më pas dërgohen në modulin e grumbullimit. Për shembull, te Cisco, protokolli Netflow mbështetet jo vetëm në routera dhe switch-e, përfshirë ato virtuale dhe industriale, por edhe në kontrolerët e pa tel, firewall-at dhe madje edhe në servera.
- Grumbullimi i flukseve. Duke e pasur parasysh se në rrjetet moderne zakonisht ka më shumë se një pajisje rrjetike, krijohet detyra e grumbullimit dhe konsolidimit të flukseve, që zgjidhet përmes ashtuquajturës kolektorëve, të cilët përpunojnë flukset e pranuara dhe më pas i dërgojnë ato për analizë.
- Analiza e flukseve. Analizatori merr përsipër detyrën kryesore intelektuale dhe, duke aplikuar algoritme të ndryshme në flukse, bën përfundime të ndryshme. Për shembull, brenda funksionit IT, një analizator i tillë mund të identifikojë ngushticat e rrjetit ose të analizojë profilin e ngarkesës së trafikut për optimizimin më të mirë të rrjetit. Në fushën e sigurisë, një analizator i tillë mund të zbulojë rrjedhjet e të dhënave, përhapjen e kodeve të dëmshme ose sulmet DoS.
Nuk duhet të mendoni se një arkitekturë tre-palëshe është shumë e komplikuar — të gjitha variantet e tjera (përveç, ndoshta, sistemeve të monitorimit të rrjetit që punojnë me SNMP dhe RMON) gjithashtu funksionojnë sipas saj. Ne kemi një gjenerator të dhënash për analizë, që është një pajisje rrjeti ose një sensor i shkëputur. Kemi një sistem për mbledhjen e sinjalizimeve dhe një sistem për menaxhimin e gjithë infrastrukturës së monitorimit. Këta dy komponentë të fundit mund të jenë të bashkuar në një nyje, por në rrjetet më të mëdha zakonisht janë të shpërndara në të paktën dy pajisje për të siguruar shkallëzim dhe besueshmëri.
Në krahasim me analizën e paketave, e cila bazohet në shqyrtimin e titujve dhe trupit të të dhënave të çdo pakete dhe sesioneve të përfshira, analiza e flukseve mbështetet në mbledhjen e metadatanave mbi trafikun rrjetor. Kur, sa, nga ku dhe ku, si... këto janë pyetje që përgjigjen nga analiza e telemetrisë rrjetore me ndihmën e protokolleve të ndryshme të flukseve. Fillimisht ato u përdorën për analizimin e statistikave dhe identifikimin e problemeve IT në rrjet, por më vonë, me zhvillimin e mekanizmave analitikë, u bë e mundur të aplikoheshin në të njëjtën telemetri për qëllime sigurie. Është e rëndësishme të theksohet se analiza e flukseve nuk zëvendëson dhe as anulon kapjen e paketave. Çdo nga këto metoda ka fushën e saj të aplikimit. Por në kontekstin e këtij artikulli, analiza e flukseve është më e përshtatshme për monitorimin e infrastrukturës së brendshme. Keni pajisje rrjeti (dhe nuk ka rëndësi nëse punojnë sipas një paradigme të përcaktuar nga software ose sipas rregullave statike) që sulmi nuk mund ta kalojë. Një sensor klasik IDS mund ta anashkalojë, por një pajisje rrjeti që mbështet protokollin e flukseve nuk mund ta bëjë këtë. Kjo është avantazhi i këtij metodi.
Nga ana tjetër, nëse keni nevojë për prova për organet e rendit ose grupin tuaj të hetimit të incidenteve, nuk mund të shmangni kapjen e paketave — telemetria rrjetore nuk është një kopje e trafikut që mund të përdoret për mbledhjen e provave; ajo nevojitet për zb discover e shpejtë dhe marrjen e vendimeve për sigurinë. Nga ana tjetër, duke përdorur analizën e telemetrisë, mund të "shkruani" jo të gjithë trafikun rrjetor (nëse ndodhet, Cisco dhe qendrat të dhënash merret me këtë :-), por vetëm atë që është në sulm. Mjetet e analizës së telemetrisë plotësojnë mirë mekanizmat tradicionale të kapjes së paketave, duke dhënë një komandë për kapjen dhe ruajtjen selektive. Ndryshe, do t'ju duhet një infrastrukture kolosale për ruajtje.
Le të imagjinojmë një rrjet që punon me një shpejtësi prej 250 Mbit/s. Nëse dëshironi të ruani gjithë këtë volum, do t'ju nevojitet një ruajtje prej 31 MB 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 kapacitet prej 10 Gbit/s, do t'ju nevojitet një ruajtje prej 108 TB. Disa rregullatorë kërkojnë ruajtjen e të dhënave për sigurinë për vite të tëra... Ruajta "në kërkesë", që ju ndihmon të realizoni analiza e flukseve, ndihmon në reduktimin e këtyre vlerave me një rend të madh. Për më tepër, nëse flisni për raportin e sasisë së të dhënave të regjistruara të telemetrisë rrjetore dhe kapjen e plotë të të dhënave, ai është rreth 1 ndaj 500. Për vlerat e lartpërmendura, ruajtja e dekodimit të plotë të gjithë trafikut ditor do të jetë respektivisht 5 dhe 216 GB (madje mund ta regjistroni edhe në një USB të zakonshme).
Nëse metoda e kapjes së të dhënave të papërpunuara të rrjetit pothuajse nuk ndryshon nga një ofrues në tjetrin për mjetet e analizës, situata është ndryshe kur bëhet fjalë për analizën e rrjedhave. Ekzistojnë disa lloje protokollesh të rrjedhave, për të cilat është thelbësore të njihni ndryshimet në kontekstin e sigurisë. Protokolli më i njohur është Netflow, i zhvilluar nga Cisco. Ekzistojnë disa versione të këtij protokolli, të cilat ndryshojnë sipas mundësive dhe sasisë së informacionit në lidhje me trafikun që regjistrohet. Versioni aktual është i nënti (Netflow v9), mbi të cilin është zhvilluar standardi industrial Netflow v10, i njohur gjithashtu si IPFIX. Sot, shumica e ofruesve të rrjeteve mbështesin pikërisht Netflow ose IPFIX në pajisjet e tyre. Megjithatë, ka edhe disa opsione të tjera për protokollet e rrjedhave — sFlow, jFlow, cFlow, rFlow, NetStream etj., ndër të cilët më i njohuri është sFlow. Ky i fundit shpesh mbështetet nga prodhuesit vendas të pajisjeve rrjet, për shkak të lehtësisë së implementimit. Cilat janë ndryshimet kryesore midis Netflow, i cili është bërë një standard de facto, dhe sFlow? Unë do të veçoja disa. Së pari, Netflow ka fusha të personalizuara nga përdoruesi, në krahasim me fushat fikse në sFlow. Së dyti, dhe kjo është më e rëndësishmja për ne, sFlow mbledh atë që quhet telemetri e sampëlluar; në kontrast me telemetrinë e mosmampëlluar në Netflow dhe IPFIX. Cila është diferenca midis tyre?
Imagjinoni se keni vendosur të njiheni me librin “” nga kolegët e mi — Gary Makintyre, Joseph Munizza dhe Nadem Alfardan (në lidhje, mund të shkarkoni një pjesë të librit). Keni tre mundësi për të arritur qëllimin e caktuar — të lexoni librin në tërësi, ta kaloni shpejt atë, duke u ndalur në çdo faqe të 10-të ose 20-të, ose të provoni të gjejni një përmbledhje të koncepteve kyçe në ndonjë blog ose shërbim si SmartReading. Kështu, telemetria e mosmampëlluar është leximi i çdo “faqe” të trafikut të rrjetit, dmth analiza e të dhënave meta për çdo paketë. Telemetria e sampëlluar është studimi i përzgjedhur i trafikut me shpresën se në mostrat e zgjedhura do të jetë ajo që ju nevojitet. Sipas shpejtësisë së kanalit, telemetria e sampëlluar do të dërgojë për analizë çdo 64-të, 200-të, 500-të, 1000-të, 2000-të ose madje 10000-të paketë.
Në kontekstin e monitorimit të sigurisë së informacionit, kjo do të thotë se telemetria e sampëlluar është e përshtatshme për zbule të sulmeve DDoS, skanime, shpërndarje të dëmtueseve, por mund të humbasë sulmet atomike ose shumëpaketëshe, të cilat nuk bien në mostrat e dërguara për analizë. Telemetria e mosmampëlluar nuk ka këto mangësi dhe me ndihmën e saj, spektri i sulmeve të zbulueshme është shumë më i gjerë. Ja një listë e vogël e ngjarjeve që mund të zbulohen përmes mjeteve të analizës së telemetrisë së rrjetit.
Natyrisht, ndonjë analizues Netflow me burim të hapur nuk do t'ju lejojë këtë, pasi detyra e tij kryesore është të mbledhë telemetrinë dhe të kryejë një analizë bazike nga perspektiva IT. Për të zbuluar kërcënimet e sigurisë së informacionit në bazë të rrjedhës, është e nevojshme të pajisni analizuesin me motorë dhe algoritmo që do të identifikojnë problemet e kibernetikës mbi bazën e fushave standarde ose të personalizuara të Netflow, duke pasuruar të dhënat standarde me informacione nga burime të ndryshme të Inteligjencës së Kërcënimit etj.
Prandaj, nëse keni një zgjedhje, ndaluni te Netflow ose IPFIX. Por madje edhe nëse pajisjet tuaja punojnë vetëm me sFlow, siç është rasti me prodhuesit vendas, madje në këtë rast mund të nxirrni përfitime nga kjo në kontekstin e sigurisë.
Në verën e vitit 2019, unë kam bërë një analizë të mundësive që kanë prodhuesit rusë të pajisjeve rrjet dhe të gjithë ata, përveç NSG, Poligon dhe Kraftway, deklaruan mbështetje për sFlow (të paktën, Zelax, Natex, Eltex, QTech, Rusteletech).
Pyetti pyetje tjetër që do t'ju shfaqet është: ku duhet të implementoni mbështetje për flow për qëllime sigurie? Në të vërtetë, pyetjeja është e formulua pak sa gabim. Në paisjet moderne, mbështetje për protokollet flow është pothuajse gjithmonë e pranishme. Prandaj, do ta riformuloja pyetjen ndryshe: ku është më efektive të mblidhni telemetrinë nga pikëpamja e sigurisë? Përgjigja është mjaft e qartë: në nivelin e aksesit, ku do të shihni 100% të gjithë trafikëve, ku do të keni informacion të detajuar për hostet (MAC, VLAN, ID e interfaces), ku do të mund të ndiqni madje trafikun P2P midis hosteve, që është kritik për zbulesën e skanimit dhe përhapjen e kodit të dëmshëm. Në nivelin e bërthamës, një pjesë e trafikut mund të mos e shihni, dhe në nivelin e perimetrin do të shihni ndoshta një të katërtën e gjithë trafikut tuaj rrjetor. Por nëse për ndonjë arsye, në rrjetin tuaj janë vendosur pajisje të huaja, duke lejuar sulmuesit të "hyjnë dhe dalin" duke anashkaluar perimetrin, atëherë analiza e telemetrisë nga ai do t'ju japë asgjë. Prandaj, për mbulimin maksimal, rekomandohet që të përfshihet mbledhja e telemetrisë pikërisht në nivelin e aksesit. Në këtë kuptim, duhet të theksohet se madje edhe kur flasim për virtualizimin ose kontejnerët, në switch-at virtual modern zakonisht ka mbështetje për flow, që lejon kontrollimin e trafikëve edhe atje.
Por, që ngaqë e ngrita temën, duhet t'i përgjigjem pyetjes: çfarë ndodh nëse paisja, fizike ose virtuale, nuk mbështet protokollet flow? Ose aktivizimi i saj ndalohet (për shembull, në segmentet industriale për të garantuar qëndrueshmërinë)? Ose aktivizimi i saj shkakton ngarkesë të lartë në procesorin e qendrës (në pajisje të vjetra ndodh kjo)? Për të zgjidhur këtë problem ekzistojnë sensorë të specializuar virtualë (flow sensor), të cilët në thelb janë thjesht ndarës që kalojnë trafik dhe e transmetojnë atë në formën e flow për modulin e mbledhjes. Megjithatë, në këtë rast ne përballeshim me gjithsej problemet, të cilat i diskutonim më parë në lidhje me mjetet e kapjes së paketave. Kështu, duhet të kuptoni jo vetëm përfitimet e teknologjisë për analizën e flukseve, por edhe kufizimet e saj.
Një tjetër moment i rëndësishëm që duhet mbajtur mend, kur flasim për mjetet e analizës së flukseve. Nëse në lidhje me mjetet e zakonshme të gjenerimit të ngjarjeve të sigurimit ne përdorim metrikën EPS (ngjarje për sekondë), atëherë për analizën e telemetrisë ky tregues nuk është i zbatueshëm; ai zëvendësohet me FPS (flow për sekondë). Ashtu si në rastin e EPS, nuk është e mundur ta llogarisni paraprakisht, por mund të vlerësoni numrin e përafërt të flukseve që gjeneron një pajisje e caktuar sipas detyrës së saj. Në Internet mund të gjeni tabela me vlera përafërsisht për lloje të ndryshme të pajisjeve korporative dhe kushteve, që do t'ju lejojë të flisni për licencat që ju nevojiten për mjetet e analizës dhe si do të jetë arkitektura e tyre. Problemi është se sensori IDS është i kufizuar në një kapacitet të caktuar kalimi që do të "përthithë" dhe gjithashtu mbledhësi i flukseve ka kufizimet e veta që duhet të kuptoni. Prandaj, në rrjetet e mëdha, të shpërndara territorialisht zakonisht ka disa mbledhës. Kur e përshkrova, , unë përmenda numrin e mbledhësve tanë - janë 21. Dhe kjo është për një rrjet, të shpërndarë mbi pesë kontinente dhe që ka rreth gjysmë milioni pajisje aktive).
Si sistem monitorimi Netflow ne përdorim zgjidhjen tonë , i cili është veçanërisht i orientuar drejt zgjidhjes së problemeve të sigurisë. Ai ka shumë motorë të integruar të zbulimit të aktiviteteve anomale, dyshuese dhe dukshëm shpërthyese, duke lejuar identifikimin e një gama të gjerë kërcënimesh - nga minimi i kriptove deri te rrjedhjet e informacionit, nga shpërndarja e kodeve keqja deri te mashtrimi. Ashtu si shumica e analizatorëve të rrjedhjeve, Stealthwatch është ndërtuar mbi një skemë me tre nivele (generator - kolektor - analizues), por është i plotësuar me një sërë karakteristikash interesante që janë të rëndësishme në kontekstin e materialeve të shqyrtuara. Së pari, ai integrohet me zgjidhjet e kapjes së paketave (p.sh., Cisco Security Packet Analyzer), duke lejuar regjistrimin e sesioneve të zgjedhura për hetim dhe analizë të thellë. Së dyti, për të zgjeruar detyrat e sigurisë, ne zhvilluam një protokoll të veçantë nvzFlow, i cili lejon 'transmetimin' e aktiviteteve të aplikacioneve në nyjet fundit (servera, stacione pune etj.) në telemetri dhe ta dërgojë atë në kolektor për analizë të mëtejshme. Në variantin e tij origjinal, Stealthwatch punon me çdo protokoll rrjedhjeje (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) në nivelin e rrjetit, ndërsa mbështetja për nvzFlow lejon korelacionin e të dhënave gjithashtu në nivelin e nyjës, duke rritur kështu efikasitetin e gjithë sistemit dhe duke parë më shumë sulme sesa analizatorët e zakonshëm të rrjedhjeve të rrjetit.
E qartë, kur flasim për sistemet e analizës së Netflow nga perspektiva e sigurisë, tregu nuk është i kufizuar vetëm në një zgjidhje nga Cisco. Ju mund të përdorni si zgjidhje komerciale ashtu edhe ato falas ose me kushte të caktuara. Më duket e çuditshme nëse unë në blogun e Cisco do t'i jap shembuj zgjidhjesh konkurrentësh, prandaj do të them disa fjalë se si telemetria e rrjetit mund të analizohët me dy mjete të njohura, që kanë emra të ngjashëm, por gjithsesi janë të ndryshme - SiLK dhe ELK.
SiLK është një grup mjetesh (the System for Internet-Level Knowledge) për analizën e trafikut, i zhvilluar nga CERT/CC në Amerikë dhe që mbështet, në kontekstin e këtij artikulli, Netflow (versionet më të njohura 5 dhe 9), IPFIX dhe sFlow, dhe me anë të utilitarianë të ndryshëm (rwfilter, rwcount, rwflowpack etj.) kryen operacione të ndryshme mbi telemetrinë e rrjetit me qëllim zbulimin e shenjave të veprimeve të paautorizuara. Por duhet të theksoj disa pika të rëndësishme. SiLK është një mjet linjë komande dhe të kryesh një analizë operative, gjithmonë duke futur komanda të tilla (zbulimi i paketave ICMP më të mëdha se 200 byte):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nuk është shumë e përshtatshme. Ju mund të përdorni ndërfaqen grafike iSiLK, por ajo nuk do t'ju lehtësojë jetën shumë, duke e zgjidhur vetëm funksionin e vizualizimit, jo zëvendësimin e analistit. Dhe kjo është pika tjetër. Ndryshe nga zgjidhjet komerciale, të cilat tashmë kanë një bazë të fortë analitike, algoritmet e zbulimit të anomalisë, përkatësitë e punës së rrjedhës etj., në rastin e SiLK, ju duhet t'i bëni të gjitha këto vetë, gjë që do t'ju kërkojë kompetenca të ndryshme nga përdorimi i mjeteve tashmë të gatshme për punë. Kjo nuk është e keqe dhe as e mirë - është një karakteristikë e pothuajse çdo instrumenti falas, i cili lë konceptin se ju e dini se çfarë të bëni, dhe ai vetëm ju ndihmon në këtë (instrumenti komercial është më pak varur nga kompetencat e përdoruesve, edhe pse gjithashtu supozon që analistët e kuptojnë të paktën bazat e zhvillimit të hetimeve në rrjet dhe monitorimin). Por le të kthehemi te SiLK. Cikli i punës i analistit me të duket si kjo:
- Formulimi i hipotezës. Duhet të kuptojmë se çfarë do të kërkojmë brenda telemetrisë së rrjetit, të dimë atributet unike sipas të cilave do të identifikojmë anomali ose kërcënime të caktuara.
- Ndërtimi i modelit. Pas formulimit të hipotezës, ne e programojmë atë me anë të Python, shell ose mjete të tjera që nuk janë pjesë e SiLK.
- Testimi. Arrin koha për të verifikuar saktësinë e hipotezës sonë, e cila konfirmohet ose hidhet poshtë me anë të mjeteve SiLK, të cilat fillojnë me 'rw', 'set', 'bag'.
- Analiza e të dhënave reale. Në përdorim industrial, SiLK na ndihmon të zbulojmë diçka dhe analisti duhet të përgjigjet në pyetje si 'A e gjetëm atë që supozonim?', 'A është kjo në përputhje me hipotezën tonë?', 'Si do ta ulë këtë numrin e rremeve?', 'Si të përmirësojmë nivelin e njohjes?' etj.
- Përmirësimi. Në fazën finale ne përmirësojmë atë që kemi bërë më parë - krijojmë shabllone, përmirësojmë dhe optimizojmë kodin, riprogramojmë dhe saktësojmë hipotezën etj.
Kyri i këtij procesi do të jetë po aq i aplikueshëm edhe për Cisco Stealthwatch, por ky i fundit automatizon këto pesë hapa në maksimum, duke ulur numrin e gabimeve të analistëve dhe duke rritur shpejtësinë e identifikimit të incidenteve. Për shembull, në SiLK, statistikën e rrjetit mund ta pasuroni me të dhëna të jashtme për IP-të e dëmshme duke përdorur skripte të shkruara nga vetë, ndërsa në Cisco Stealthwatch kjo është një funksion i ndërtuar që menjëherë ju tregon alarmin nëse në trafikun e rrjetit ka ndërveprim me adresa IP nga lista e zezë.
Nëse shkoni më lart në piramidën e softuerëve për analizimin e flukseve, pas SiLK krejtësisht falas, do të vijë ELK që është kushtuar pjesërisht, e përbërë nga tre komponente kryesore — Elasticsearch (indeksimi, kërkimi dhe analizimi i të dhënave), Logstash (input/output i të dhënave) dhe Kibana (vizualizimi). Ndryshe nga SiLK, ku duhet të shkruani gjithçka vetë, ELK ka shumë biblioteka/module të gatshme (disa janë me pagesë, disa jo) që automatizojnë analizimin e telemetrisë rrjetore. Për shembull, filtri GeoIP në Logstash lejon lidhjen e IP-ve të vëzhguara me vendndodhjen e tyre gjeografike (dhe kjo është një funksion i ndërtuar në Stealthwatch).
ELK gjithashtu ka një komunitet të konsiderueshëm që shkruan komponente të humbura për këtë zgjidhje monitorimi. Për shembull, për të punuar me Netflow, IPFIX dhe sFlow, mund të përdorni modul , nëse nuk jeni të kënaqur me Modulin Netflow të Logstash, i cili mbështet vetëm Netflow.
Duke ofruar më shumë shpejtësi në mbledhjen e flukseve dhe kërkimin në to, ELK aktualisht nuk ka një analizë të pasur të ndërtuar për identifikimin e anomaliave dhe kërcënimeve në telemetrinë rrjetore. Pra, duke ndjekur ciklin e jetës të përshkruar më lart, do të duhet të përshkruani vetë modelet e shkeljeve dhe pastaj t'i përdorni ato në sistemin e prodhimit (nuk ka modele të ndërtuara atje).
Natyrisht, ekzistojnë gjithashtu shtesa më të sofistikuara për ELK, në të cilat janë të ndërtuara disa modele të identifikimit të anomaliave në telemetrinë rrjetore, por këto shtesa kushtojnë para dhe këtu është një pyetje, a ia vlen të marrësh një model të ngjashëm vetë, ta blesh implementimin për mjetin tuaj të monitorimit ose të blesh një zgjidhje të gatshme të klasës Analizës së Trafikut Rrjet.
Në të vërtetë, nuk dua të hyj në polemikë mbi atë që është më mirë, të harxhosh para dhe të blesh një zgjidhje të gatshme për monitorimin e anomaliave dhe kërcënimeve në telemetrinë rrjetore (për shembull, Cisco Stealthwatch) ose të merresh vete dhe të zhvillosh modelet për çdo kërcënim të ri, duke përdorur SiLK, ELK ose nfdump ose OSU Flow Tools (po flas për dy të fundit nga këto herën e kaluar)? Çdo kush zgjedh për vete dhe çdo njeri ka motivet e tij për të zgjedhur ndonjë nga të dyja opsionet. Unë thjesht dëshiroja të tregoja se telemetria rrjetore është një mjet shumë i rëndësishëm për sigurimin e sigurisë së rrjetit të infrastrukturës tuaj të brendshme dhe nuk duhet ta injoroni atë, në mënyrë që të mos përfshiheni në listën e kompanive, emri i të cilave përmendet në media me epitete si "e sulmuar", "nuk ka përmbushur kërkesat për siguri", "nuk mendon për sigurinë e të dhënave të saj dhe të dhënave të klientëve."
Duke përmbledhur, do doja të rendis disa këshilla kyçe që duhet të ndiqni kur ndihmoni në ngritjen e monitorimit të sigurisë së informacionit në infrastrukturën tuaj të brendshme:
- Mos u kufizoni vetëm në perimetrin! Përdorni (dhe zgjidhni) infrastrukturën rrjetore jo vetëm për transferimin e trafikut nga pika A në pikën B, por edhe për zgjidhjen e çështjeve të sigurisë kibernetike.
- Hidhni një sy mekanizmave ekzistues të monitorimit të sigurisë në pajisjet tuaja rrjetore dhe angazhohuni me to.
- Për monitoringun e brendshëm preferoni analizimin e telemetrisë — kjo mundëson zbulimin e deri në 80-90% të të gjitha incidenteve të sigurisë rrjetore, duke bërë atë që është e pamundur me kapjen e paketimeve të rrjetit dhe duke kursyer hapësirën për ruajtjen e të gjitha ngjarjeve të sigurisë.
- Për monitorimin e flukseve përdorni Netflow v9 ose IPFIX – ata japin më shumë informacion në kontekstin e sigurisë dhe lejojnë monitorimin jo vetëm të IPv4, por edhe IPv6, MPLS etj.
- Përdorni një protokoll fluksi të pa-sampëlluar – ai ofron më shumë informacion për zbulimin e kërcënimeve. Për shembull, Netflow ose IPFIX.
- Kontrolloni ngarkesën e pajisjeve tuaja rrjetore – ndoshta ajo nuk do të jetë në gjendje të përballojë përpunimin e protokollit fluks. Atëherë, mendoni për përdorimin e sensorëve virtualë ose Netflow Generation Appliance.
- Implementoni kontrollin në nivele të qasjes si prioritet — kjo do t'ju japë mundësinë për të parë 100% të gjithë trafikut.
- Nëse nuk keni alternativë dhe përdorni pajisje rrjetore ruse, atëherë zgjidhni ato që mbështetin protokollet e fluksit ose kanë porta SPAN/RSPAN.
- Kombinoni sistemet e zbulimit/parandalimit të sulmeve në kufij dhe sistemet e analizës së flukseve në rrjetin e brendshëm (përfshirë edhe në çadrat).
Что касается последнего совета, то я бы хотел привести иллюстрацию, которую уже приводил раньше. Вы видите, что если раньше служба ИБ Cisco почти целиком выстраивала свою систему мониторинга ИБ на базе систем обнаружения вторжений и сигнатурных методов, то сейчас на их долю приходится всего 20% инцидентов. Еще 20% приходится на системы анализа потоков, что говорит о том, что эти решения — не блажь, а реальный инструмент в деятельности служб ИБ современного предприятия. Тем более, что у вас для их внедрения есть самое главное — сетевая инфраструктура, инвестиции в которую можно дополнительно защитить, возложив на сеть еще и функции мониторинга ИБ.
Я специально не стал касаться темы реагирования на выявленные в сетевых потоках аномалии или угрозы, но думаю, что и так понятно, что мониторинг не должен завершаться только обнаружением угрозы. За ним должно следовать реагирование и желательно в автоматическом или автоматизированном режиме. Но это уже тема отдельного материала.
Дополнительная информация:
ЗЫ. Если вам проще воспринимать на слух все, что было написано выше, то вы можете посмотреть часовую презентацию, которая легла в основу данной заметки.
Burimi: habr.com
