Kalbant apie vidinio įmonės ar padalinio tinklo saugumo stebėjimą, daugelis tai sieja su informacijos nutekėjimo kontrole ir DLP sprendimų diegimu. Ir jei bandysite patikslinti klausimą ir paklausti, kaip aptinkate atakas vidiniame tinkle, atsakymas, kaip taisyklė, bus įsilaužimo aptikimo sistemų (IDS) paminėjimas. O tai, kas buvo vienintelė galimybė prieš 10–20 metų, šiandien tampa anachronizmu. Yra efektyvesnis, o kai kur ir vienintelis galimas vidinio tinklo stebėjimo variantas – naudojant srauto protokolus, kurie iš pradžių buvo skirti tinklo problemų paieškai (trikčių šalinimui), tačiau laikui bėgant transformavosi į labai įdomią saugos priemonę. Pakalbėsime apie tai, kokie srauto protokolai yra ir kurie geriau aptinka tinklo atakas, kur geriausia įdiegti srauto stebėjimą, į ką atkreipti dėmesį diegiant tokią schemą ir net kaip visa tai „pakelti“ ant buitinės įrangos. šio straipsnio taikymo srityje.
Prie klausimo „Kodėl reikalinga vidinė infrastruktūros saugumo stebėsena“ nesigilinsiu? Atrodo, kad atsakymas aiškus. Bet jei vis dėlto norėtumėte dar kartą įsitikinti, kad šiandien negalite gyventi be jo, trumpas vaizdo įrašas apie tai, kaip 17 būdų galite įsiskverbti į užkarda apsaugotą įmonės tinklą. Todėl manysime, kad suprantame, kad vidinė stebėsena yra būtinas dalykas ir beliks tik suprasti, kaip ją galima organizuoti.
Norėčiau pabrėžti tris pagrindinius duomenų šaltinius infrastruktūros stebėjimui tinklo lygiu:
- „neapdorotas“ srautas, kurį fiksuojame ir pateikiame analizei tam tikroms analizės sistemoms,
- įvykiai iš tinklo įrenginių, per kuriuos vyksta srautas,
- eismo informacija, gauta per vieną iš srauto protokolų.
Neapdoroto srauto fiksavimas yra populiariausias pasirinkimas tarp saugumo specialistų, nes jis istoriškai atsirado ir buvo pirmasis. Įprastos tinklo įsibrovimų aptikimo sistemos (pirmoji komercinė įsibrovimų aptikimo sistema buvo NetRanger iš Wheel Group, kurią 1998 m. įsigijo Cisco) buvo tiksliai užfiksuojamos paketų (ir vėlesnių seansų), kuriuose buvo ieškoma tam tikrų parašų („lemiamos taisyklės“). FSTEC terminija), signalizacijos atakos. Žinoma, neapdorotą srautą galite analizuoti ne tik naudodami IDS, bet ir kitus įrankius (pavyzdžiui, „Wireshark“, „tcpdum“ ar „Cisco IOS“ NBAR2 funkcionalumą), tačiau jiems dažniausiai trūksta žinių bazės, kuri atskirtų informacijos saugos įrankį nuo įprasto. IT įrankis.
Taigi, atakų aptikimo sistemos. Seniausias ir populiariausias tinklo atakų aptikimo metodas, kuris gerai atlieka savo darbą perimetru (nesvarbu, kas – įmonės, duomenų centro, segmento ir pan.), tačiau sugenda šiuolaikiniuose komutuojamuose ir programinės įrangos apibrėžtuose tinkluose. Įprastų jungiklių pagrindu sukurto tinklo atveju atakų aptikimo jutiklių infrastruktūra tampa per didelė – kiekvienoje jungtyje prie mazgo, kuriame norite stebėti atakas, turėsite įdiegti jutiklį. Bet kuris gamintojas, žinoma, mielai parduos jums šimtus ir tūkstančius jutiklių, bet manau, kad jūsų biudžetas nepajėgs padengti tokių išlaidų. Galiu pasakyti, kad net Cisco (o mes esame NGIPS kūrėjai) negalėjome to padaryti, nors atrodo, kad kainos klausimas yra prieš mus. Neturėčiau pakęsti – tai mūsų pačių sprendimas. Be to, kyla klausimas, kaip prijungti jutiklį šioje versijoje? Į tarpą? Ką daryti, jei pats jutiklis sugenda? Ar reikia jutiklio apėjimo modulio? Naudoti skirstytuvus (bakstelėti)? Visa tai brangina sprendimą ir daro jį neįperkamą bet kokio dydžio įmonei.
Galite pabandyti „pakabinti“ jutiklį ant SPAN/RSPAN/ERSPAN prievado ir nukreipti srautą iš reikiamų komutatoriaus prievadų į jį. Ši parinktis iš dalies pašalina ankstesnėje pastraipoje aprašytą problemą, tačiau iškelia kitą – SPAN prievadas negali priimti absoliučiai viso srauto, kuris bus siunčiamas į jį – jam neužteks pralaidumo. Teks kai ką paaukoti. Arba palikite kai kuriuos mazgus be stebėjimo (tada pirmiausia turite jiems nustatyti prioritetus), arba siųskite ne visą srautą iš mazgo, o tik tam tikro tipo. Bet kokiu atveju kai kurias atakas galime praleisti. Be to, SPAN prievadas gali būti naudojamas kitiems poreikiams. Dėl to turėsime peržiūrėti esamą tinklo topologiją ir galbūt ją pakoreguoti, kad jūsų tinklas būtų maksimaliai padengtas turimų jutiklių skaičiumi (ir suderinti tai su IT).
Ką daryti, jei jūsų tinklas naudoja asimetrinius maršrutus? Ką daryti, jei įdiegėte arba planuojate įdiegti SDN? Ką daryti, jei reikia stebėti virtualizuotas mašinas ar konteinerius, kurių srautas visai nepasiekia fizinio jungiklio? Tai klausimai, kurių nemėgsta tradiciniai IDS pardavėjai, nes jie nežino, kaip į juos atsakyti. Galbūt jie jus įtikins, kad visos šios madingos technologijos yra ažiotažas ir jums to nereikia. Galbūt jie kalbės apie būtinybę pradėti nuo mažo. O gal jie pasakys, kad tinklo centre reikia pastatyti galingą kūlimo įrenginį ir nukreipti visą srautą į jį naudojant balansuotojus. Kad ir koks būtų jums pasiūlytas variantas, turite aiškiai suprasti, kaip jis jums tinka. Ir tik po to priimkite sprendimą dėl tinklo infrastruktūros informacijos saugumo stebėjimo metodo pasirinkimo. Grįžtant prie paketų fiksavimo, noriu pasakyti, kad šis būdas ir toliau yra labai populiarus ir svarbus, tačiau pagrindinis jo tikslas – sienų kontrolė; ribos tarp jūsų organizacijos ir interneto, ribos tarp duomenų centro ir likusio tinklo, ribos tarp procesų valdymo sistemos ir įmonės segmento. Šiose vietose klasikiniai IDS/IPS vis dar turi teisę egzistuoti ir puikiai susidoroti su savo užduotimis.
Pereikime prie antrojo varianto. Įvykių iš tinklo įrenginių analizė taip pat gali būti naudojama atakų aptikimo tikslais, bet ne kaip pagrindinis mechanizmas, nes leidžia aptikti tik nedidelę įsibrovimų klasę. Be to, tai būdinga tam tikram reaktyvumui – pirmiausia turi įvykti ataka, tada ją turi įrašyti tinklo įrenginys, kuris vienaip ar kitaip signalizuos apie informacijos saugumo problemą. Yra keletas tokių būdų. Tai gali būti syslog, RMON arba SNMP. Paskutiniai du tinklo stebėjimo protokolai informacijos saugumo kontekste naudojami tik tuo atveju, jei reikia aptikti DoS ataką prieš pačią tinklo įrangą, nes naudojant RMON ir SNMP galima, pavyzdžiui, stebėti įrenginio centrinio įrenginio apkrovą. procesorius ar jo sąsajos. Tai yra vienas iš „pigiausių“ (visi turi syslog arba SNMP), bet ir pats neveiksmingiausias iš visų vidinės infrastruktūros informacijos saugumo stebėjimo metodų - daugelis atakų nuo jo tiesiog paslėpti. Žinoma, jų nereikėtų pamiršti, o ta pati syslog analizė padeda laiku nustatyti paties įrenginio konfigūracijos pokyčius, jo kompromitavimą, tačiau aptikti viso tinklo atakas ji nelabai tinka.
Trečia galimybė – analizuoti informaciją apie srautą, einantį per įrenginį, kuris palaiko vieną iš kelių srauto protokolų. Šiuo atveju, nepaisant protokolo, sriegimo infrastruktūra būtinai susideda iš trijų komponentų:
- Srauto generavimas arba eksportas. Šis vaidmuo dažniausiai priskiriamas maršrutizatoriui, jungikliui ar kitam tinklo įrenginiui, kuris, per save perduodamas tinklo srautą, leidžia iš jo išgauti pagrindinius parametrus, kurie vėliau perduodami į surinkimo modulį. Pavyzdžiui, „Cisco“ palaiko „Netflow“ protokolą ne tik maršrutizatoriuose ir komutatoriuose, įskaitant virtualius ir pramoninius, bet ir belaidžiuose valdikliuose, ugniasienėse ir net serveriuose.
- Kolekcijos srautas. Atsižvelgiant į tai, kad šiuolaikiniame tinkle dažniausiai yra daugiau nei vienas tinklo įrenginys, iškyla srautų surinkimo ir konsolidavimo problema, kuri sprendžiama naudojant vadinamuosius kolektorius, kurie apdoroja gautus srautus, o vėliau perduoda juos analizei.
- Srauto analizė Analizatorius imasi pagrindinės intelektualinės užduoties ir, taikydamas srautams įvairius algoritmus, daro tam tikras išvadas. Pavyzdžiui, kaip IT funkcijos dalis, toks analizatorius gali nustatyti tinklo kliūtis arba analizuoti srauto apkrovos profilį tolesniam tinklo optimizavimui. O informacijos saugumui toks analizatorius gali aptikti duomenų nutekėjimą, kenkėjiško kodo plitimą ar DoS atakas.
Nemanykite, kad ši trijų pakopų architektūra yra per sudėtinga – pagal ją veikia ir visi kiti variantai (išskyrus galbūt su SNMP ir RMON veikiančias tinklo stebėjimo sistemas). Analizei turime duomenų generatorių, kuris gali būti tinklo įrenginys arba atskiras jutiklis. Turime signalizacijos surinkimo sistemą ir valdymo sistemą visai stebėjimo infrastruktūrai. Paskutiniai du komponentai gali būti sujungti viename mazge, tačiau daugiau ar mažiau dideliuose tinkluose jie paprastai yra paskirstomi mažiausiai dviejuose įrenginiuose, kad būtų užtikrintas mastelio keitimas ir patikimumas.
Skirtingai nuo paketų analizės, kuri yra pagrįsta kiekvieno paketo ir seansų, iš kurių jis susideda, antraštės ir kūno duomenų tyrimu, srauto analizė remiasi metaduomenų apie tinklo srautą rinkimu. Kada, kiek, iš kur ir kur, kaip... į šiuos klausimus atsako tinklo telemetrijos analizė naudojant įvairius srauto protokolus. Iš pradžių jie buvo naudojami statistiniams duomenims analizuoti ir IT problemoms tinkle surasti, tačiau vėliau, tobulėjant analitiniams mechanizmams, atsirado galimybė juos saugumo sumetimais pritaikyti tai pačiai telemetrijai. Dar kartą verta paminėti, kad srauto analizė nepakeičia ir nepakeičia paketų fiksavimo. Kiekvienas iš šių metodų turi savo taikymo sritį. Tačiau šio straipsnio kontekste būtent srautų analizė geriausiai tinka vidinei infrastruktūrai stebėti. Turite tinklo įrenginius (nesvarbu, ar jie veikia pagal programinės įrangos apibrėžtą paradigmą, ar pagal statines taisykles), kurių ataka negali apeiti. Jis gali apeiti klasikinį IDS jutiklį, tačiau tinklo įrenginys, palaikantis srauto protokolą, negali. Tai yra šio metodo pranašumas.
Kita vertus, jei reikia įrodymų teisėsaugai ar savo incidentų tyrimo komandai, neapsieisite be paketų fiksavimo – tinklo telemetrija nėra duomenų srauto kopija, kurią būtų galima panaudoti renkant įrodymus; ji reikalinga norint greitai aptikti ir priimti sprendimus informacijos saugumo srityje. Kita vertus, naudodamiesi telemetrijos analize, galite „rašyti“ ne visą tinklo srautą (jei ką, Cisco užsiima duomenų centrais :-), o tik tai, kas yra susijusi su ataka. Šiuo atžvilgiu telemetrijos analizės įrankiai puikiai papildys tradicinius paketų fiksavimo mechanizmus, suteikdami komandas atrankiniam fiksavimui ir saugojimui. Priešingu atveju turėsite turėti milžinišką saugojimo infrastruktūrą.
Įsivaizduokime tinklą, veikiantį 250 Mbit/sek greičiu. Jei norite išsaugoti visą šį kiekį, jums reikės 31 MB saugyklos vienai sekundei srauto perdavimo, 1,8 GB vienai minutei, 108 GB vienai valandai ir 2,6 TB vienai dienai. Norint saugoti kasdienius duomenis iš tinklo, kurio pralaidumas yra 10 Gbit/s, jums reikės 108 TB saugyklos vietos. Tačiau kai kurie reguliatoriai reikalauja saugoti saugos duomenis metų metus... Įrašymas pagal pareikalavimą, kurį padeda įgyvendinti srauto analizė, padeda sumažinti šias vertes dydžiu. Beje, jei kalbame apie įrašytų tinklo telemetrijos duomenų apimties ir visiško duomenų fiksavimo santykį, tada jis yra maždaug nuo 1 iki 500. Esant toms pačioms aukščiau nurodytoms vertėms, išsaugomas visas dienos srauto nuorašas. bus atitinkamai 5 ir 216 GB (galite net įrašyti į įprastą „flash drive“).
Jei neapdorotų tinklo duomenų analizės įrankiams jų fiksavimo metodas yra beveik vienodas kiekvienam pardavėjui, tai srauto analizės atveju situacija yra kitokia. Yra keletas srauto protokolų parinkčių, kurių skirtumus reikia žinoti saugumo kontekste. Populiariausias yra „Cisco“ sukurtas „Netflow“ protokolas. Yra keletas šio protokolo versijų, kurios skiriasi savo galimybėmis ir įrašytos eismo informacijos kiekiu. Dabartinė versija yra devinta (Netflow v9), kurios pagrindu buvo sukurtas pramonės standartas Netflow v10, dar žinomas kaip IPFIX. Šiandien dauguma tinklo pardavėjų savo įrangoje palaiko Netflow arba IPFIX. Tačiau yra ir įvairių kitų srauto protokolų variantų – sFlow, jFlow, cFlow, rFlow, NetStream ir kt., iš kurių sFlow yra populiariausias. Būtent šį tipą dažniausiai palaiko vietiniai tinklo įrangos gamintojai dėl jo įgyvendinimo paprastumo. Kokie yra pagrindiniai skirtumai tarp „Netflow“, kuris tapo de facto standartu, ir „sFlow“? Išskirčiau keletą pagrindinių. Pirma, „Netflow“ turi vartotojo pritaikomus laukus, o ne fiksuotus „sFlow“ laukus. Ir antra, ir tai mūsų atveju yra svarbiausia, sFlow renka vadinamąją atrankinę telemetriją; priešingai nei neatrinktas Netflow ir IPFIX. Kuo jie skiriasi?
Įsivaizduokite, kad nuspręsite perskaityti knygą "“ mano kolegų – Gary McIntyre’o, Josepho Munitzo ir Nademo Alfardano (dalį knygos galite atsisiųsti iš nuorodos). Turite tris galimybes pasiekti savo tikslą – perskaityti visą knygą, perskaityti ją, sustoti ties kas 10 ar 20 puslapių arba pabandyti rasti pagrindinių sąvokų atpasakojimą tinklaraštyje ar paslaugoje, pvz., „SmartReading“. Taigi, neatrinkta telemetrija nuskaito kiekvieną tinklo srauto „puslapį“, tai yra, analizuoja kiekvieno paketo metaduomenis. Atrankinė telemetrija yra selektyvus srauto tyrimas, tikintis, kad pasirinktuose pavyzdžiuose bus tai, ko jums reikia. Priklausomai nuo kanalo greičio, atrinktos telemetrijos bus siunčiamos analizei kas 64, 200, 500, 1000, 2000 ar net 10000 XNUMX paketus.
Informacijos saugumo stebėjimo kontekste tai reiškia, kad atrinkta telemetrija puikiai tinka aptikti DDoS atakas, nuskaityti ir skleisti kenksmingą kodą, tačiau gali praleisti atomines ar kelių paketų atakas, kurios nebuvo įtrauktos į analizei išsiųstą pavyzdį. Neatrinkta telemetrija neturi tokių trūkumų. Dėl to aptiktų atakų diapazonas yra daug platesnis. Čia pateikiamas trumpas įvykių, kuriuos galima aptikti naudojant tinklo telemetrijos analizės įrankius, sąrašas.
Žinoma, kai kurie atvirojo kodo „Netflow“ analizatoriai neleis jums to padaryti, nes jo pagrindinė užduotis yra rinkti telemetriją ir atlikti pagrindinę jos analizę IT požiūriu. Informacijos saugumo grėsmių, pagrįstų srautu, atpažinimui būtina analizatorių aprūpinti įvairiais varikliais ir algoritmais, kurie nustatys kibernetinio saugumo problemas pagal standartinius ar pritaikytus Netflow laukus, praturtins standartinius duomenis išoriniais duomenimis iš įvairių Threat Intelligence šaltinių ir kt.
Todėl, jei turite pasirinkimą, pasirinkite Netflow arba IPFIX. Bet net jei jūsų įranga veikia tik su „sFlow“, kaip ir vietiniai gamintojai, net ir šiuo atveju galite gauti naudos iš jos saugumo kontekste.
2019 metų vasarą išanalizavau Rusijos tinklo techninės įrangos gamintojų galimybes ir visos jos, išskyrus NSG, Polygon ir Craftway, paskelbė apie sFlow palaikymą (bent jau Zelax, Natex, Eltex, QTech, Rusteleteh).
Kitas klausimas, su kuriuo susidursite, yra tai, kur įdiegti srauto palaikymą saugumo tikslais? Tiesą sakant, klausimas užduotas ne visai teisingai. Šiuolaikinė įranga beveik visada palaiko srauto protokolus. Todėl klausimą performuluočiau kitaip – kur saugumo požiūriu efektyviausia rinkti telemetriją? Atsakymas bus gana akivaizdus – prieigos lygyje, kur matysite 100% viso srauto, kur turėsite išsamią informaciją apie hostus (MAC, VLAN, sąsajos ID), kur galėsite net stebėti P2P srautą tarp hostų, kurie yra labai svarbus skenuojant kenkėjiško kodo aptikimą ir platinimą. Pagrindiniame lygyje galite tiesiog nematyti dalies srauto, tačiau perimetro lygyje matysite ketvirtadalį viso tinklo srauto. Bet jei dėl kokių nors priežasčių jūsų tinkle yra svetimų įrenginių, leidžiančių užpuolikams „įeiti ir išeiti“ neapeinant perimetro, tada telemetrijos analizė iš jo nieko neduos. Todėl, siekiant maksimalios aprėpties, rekomenduojama įjungti telemetrijos rinkimą prieigos lygiu. Tuo pačiu verta paminėti, kad net jei kalbame apie virtualizaciją ar konteinerius, srauto palaikymas taip pat dažnai randamas šiuolaikiniuose virtualiuose komutatoriuose, kurie leidžia valdyti srautą ir ten.
Bet kadangi aš iškėliau temą, turiu atsakyti į klausimą: o jeigu įranga, fizinė ar virtuali, nepalaiko srauto protokolų? O gal jo įtraukimas yra draudžiamas (pavyzdžiui, pramonės segmentuose, siekiant užtikrinti patikimumą)? O gal jį įjungus apkraunamas didelis CPU (tai atsitinka senesnėje aparatinėje įrangoje)? Norėdami išspręsti šią problemą, yra specializuoti virtualūs jutikliai (srauto jutikliai), kurie iš esmės yra įprasti skirstytuvai, kurie perduoda srautą per save ir transliuoja jį srauto forma į surinkimo modulį. Tiesa, šiuo atveju gauname visas problemas, apie kurias kalbėjome aukščiau, susijusių su paketų fiksavimo įrankiais. Tai yra, jūs turite suprasti ne tik srautų analizės technologijos pranašumus, bet ir jos apribojimus.
Kitas dalykas, kurį svarbu atsiminti kalbant apie srautų analizės įrankius. Jei įprastoms saugumo įvykių generavimo priemonėms naudojame EPS metriką (įvykis per sekundę), tai šis rodiklis netaikomas telemetrinei analizei; jis pakeičiamas FPS (srauto per sekundę). Kaip ir EPS atveju, jo negalima apskaičiuoti iš anksto, tačiau galite įvertinti apytikslį gijų skaičių, kurį sukuria konkretus įrenginys, priklausomai nuo jo užduoties. Internete galite rasti lenteles su apytikslėmis skirtingų tipų įmonės įrenginių ir sąlygų reikšmėmis, kurios leis įvertinti, kokių licencijų jums reikia analizės įrankiams ir kokia bus jų architektūra? Faktas yra tas, kad IDS jutiklį riboja tam tikras pralaidumas, kurį jis gali „traukti“, o srauto kolektorius turi savo apribojimus, kuriuos reikia suprasti. Todėl dideliuose, geografiškai paskirstytuose tinkluose dažniausiai yra keli kolektoriai. Kai aprašiau , jau nurodžiau mūsų kolektorių skaičių – jų yra 21. Ir tai skirta tinklui, išsibarsčiusiam penkiuose žemynuose ir turinčiam apie pusę milijono aktyvių įrenginių).
Mes naudojame savo sprendimą kaip Netflow stebėjimo sistemą , kuri yra specialiai orientuota į saugumo problemų sprendimą. Jame yra daug įmontuotų variklių, skirtų anomaliai, įtartinai ir aiškiai kenkėjiškai veiklai aptikti, kas leidžia aptikti įvairiausias įvairias grėsmes – nuo šifravimo iki informacijos nutekėjimo, nuo kenksmingo kodo plitimo iki sukčiavimo. Kaip ir dauguma srauto analizatorių, „Stealthwatch“ sukurtas pagal trijų lygių schemą (generatorius – kolektorius – analizatorius), tačiau jis papildytas keletu įdomių savybių, kurios yra svarbios nagrinėjamos medžiagos kontekste. Pirma, jis integruojamas su paketų fiksavimo sprendimais (pvz., Cisco Security Packet Analyzer), kuris leidžia įrašyti pasirinktas tinklo sesijas, kad vėliau būtų galima atlikti išsamų tyrimą ir analizę. Antra, specialiai saugumo užduotims išplėsti, sukūrėme specialų nvzFlow protokolą, leidžiantį „transliuoti“ galinių mazgų (serverių, darbo stočių ir kt.) taikomųjų programų veiklą į telemetriją ir perduoti kolektoriui tolesnei analizei. Jei pradinėje versijoje „Stealthwatch“ tinklo lygiu veikia su bet kokiu srauto protokolu (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream), tai nvzFlow palaikymas leidžia koreliuoti duomenis ir mazgo lygiu. padidinti visos sistemos efektyvumą ir matyti daugiau atakų nei įprasti tinklo srautų analizatoriai.
Akivaizdu, kad kalbant apie „Netflow“ analizės sistemas saugumo požiūriu, rinka neapsiriboja vienu „Cisco“ sprendimu. Galite naudoti tiek komercinius, tiek nemokamus ar dalijimosi programinės įrangos sprendimus. Gana keista, jei Cisco tinklaraštyje kaip pavyzdžius pateikiu konkurentų sprendimus, todėl pasakysiu keletą žodžių apie tai, kaip tinklo telemetrija gali būti analizuojama naudojant du populiarius, panašaus pavadinimo, bet vis tiek skirtingus įrankius - SiLK ir ELK.
SiLK yra srauto analizės įrankių rinkinys (Internet-Level Knowledge sistema), sukurtas Amerikos CERT/CC ir kuris šiandieninio straipsnio kontekste palaiko Netflow (5-oji ir 9-oji, populiariausios versijos), IPFIX. ir sFlow bei įvairių paslaugų (rwfilter, rwcount, rwflowpack ir kt.) pagalba atlikti įvairias tinklo telemetrijos operacijas, siekiant aptikti joje neteisėtų veiksmų požymius. Tačiau reikia atkreipti dėmesį į keletą svarbių dalykų. SiLK yra komandų eilutės įrankis, kuris atlieka analizę tinkle, įvesdamas tokias komandas (didesnių nei 200 baitų ICMP paketų aptikimas):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nelabai patogus. Galite naudoti iSiLK GUI, bet tai labai nepalengvins jūsų gyvenimo, tik išspręs vizualizacijos funkciją, o ne pakeis analitiko. Ir tai yra antras punktas. Skirtingai nuo komercinių sprendimų, kurie jau turi tvirtą analitinę bazę, anomalijų aptikimo algoritmus, atitinkamą darbo eigą ir pan., SiLK atveju visa tai turėsite atlikti patys, o tai iš jūsų pareikalaus kiek kitokių kompetencijų nei naudojant jau paruoštą naudojami įrankiai. Tai nėra nei gerai, nei blogai – tai yra beveik bet kurio nemokamo įrankio, kuris daro prielaidą, kad žinote, ką daryti, ir tai tik padės jums (komercinės priemonės mažiau priklauso nuo naudotojų kompetencijų, nors jie taip pat mano kad analitikai suprastų bent tinklo tyrimų ir stebėjimo pagrindus). Bet grįžkime prie SiLK. Analitiko darbo ciklas su juo atrodo taip:
- Hipotezės formulavimas. Turime suprasti, ko ieškosime tinklo telemetrijos viduje, žinoti unikalius požymius, pagal kuriuos nustatysime tam tikras anomalijas ar grėsmes.
- Modelio kūrimas. Suformulavus hipotezę, ją programuojame naudodami tuos pačius Python, shell ar kitus įrankius, neįtrauktus į SiLK.
- Testavimas. Dabar ateina eilė patikrinti mūsų hipotezės teisingumą, kuri patvirtinama arba paneigiama naudojant SiLK programas, prasidedančias „rw“, „set“, „bag“.
- Realių duomenų analizė. Pramoninėje veikloje SiLK padeda mums kažką identifikuoti ir analitikas turi atsakyti į klausimus „Ar radome tai, ko tikėjomės?“, „Ar tai atitinka mūsų hipotezę?“, „Kaip sumažinti klaidingų teigiamų rezultatų skaičių?“, „Kaip pagerinti pripažinimo lygį? » ir taip toliau.
- Tobulinimas. Paskutiniame etape tobuliname tai, kas buvo padaryta anksčiau – kuriame šablonus, tobuliname ir optimizuojame kodą, performuluojame ir patiksliname hipotezę ir pan.
Šis ciklas bus taikomas ir „Cisco Stealthwatch“, tik paskutinis maksimaliai automatizuoja šiuos penkis žingsnius, sumažindamas analitikų klaidų skaičių ir padidindamas incidentų aptikimo efektyvumą. Pavyzdžiui, SiLK galite praturtinti tinklo statistiką išoriniais duomenimis apie kenkėjiškus IP naudodami ranka rašytus scenarijus, o Cisco Stealthwatch tai yra integruota funkcija, kuri iš karto parodo aliarmą, jei tinklo sraute yra sąveika su IP adresais iš juodojo sąrašo.
Jei srauto analizės programinės įrangos „mokamoje“ piramidėje pakilsite aukščiau, tada po visiškai nemokamos SiLK atsiras „shareware“ ELK, susidedanti iš trijų pagrindinių komponentų - „Elasticsearch“ (indeksavimas, paieška ir duomenų analizė), „Logstash“ (duomenų įvestis / išvestis). ) ir Kibana (vizualizacija). Skirtingai nuo SiLK, kur viską reikia rašyti pačiam, ELK jau turi daug paruoštų bibliotekų/modulių (kai kurios mokamos, kitos ne), kurios automatizuoja tinklo telemetrijos analizę. Pavyzdžiui, GeoIP filtras Logstash leidžia susieti stebimus IP adresus su jų geografine vieta (Stealthwatch turi šią integruotą funkciją).
ELK taip pat turi gana didelę bendruomenę, kuri papildo trūkstamus šio stebėjimo sprendimo komponentus. Pavyzdžiui, norėdami dirbti su Netflow, IPFIX ir sFlow, galite naudoti modulį , jei nesate patenkinti „Logstash Netflow“ moduliu, kuris palaiko tik „Netflow“.
Nors ELK užtikrina didesnį srauto rinkimo ir paieškos jame efektyvumą, šiuo metu ELK trūksta turtingos įmontuotos analizės, leidžiančios aptikti tinklo telemetrijos anomalijas ir grėsmes. Tai yra, vadovaudamiesi aukščiau aprašytu gyvavimo ciklu, turėsite savarankiškai apibūdinti pažeidimo modelius ir tada naudoti juos kovos sistemoje (ten nėra įmontuotų modelių).
Žinoma, yra ir įmantresnių ELK plėtinių, kuriuose jau yra keletas modelių tinklo telemetrijos anomalijų aptikimui, tačiau tokie plėtiniai kainuoja ir kyla klausimas, ar žaidimas vertas žvakės – parašykite panašų modelį patys, nusipirkite jo įgyvendinimą. savo stebėjimo įrankiui arba įsigykite paruoštą tinklo srauto analizės klasės sprendimą.
Apskritai nenoriu veltis į diskusijas, kad geriau išleisti pinigus ir nusipirkti paruoštą tinklo telemetrijos anomalijų ir grėsmių stebėjimo sprendimą (pavyzdžiui, „Cisco Stealthwatch“) arba pačiam išsiaiškinti ir pritaikyti tą patį. SiLK, ELK arba nfdump arba OSU srauto įrankiai kiekvienai naujai grėsmei (kalbu apie paskutines dvi iš jų Paskutinį kartą)? Kiekvienas pasirenka pats ir kiekvienas turi savų motyvų, kodėl pasirenka bet kurį iš dviejų variantų. Tik norėjau parodyti, kad tinklo telemetrija yra labai svarbi priemonė, užtikrinanti jūsų vidinės infrastruktūros tinklo saugumą, todėl neturėtumėte to pamiršti, kad nepatektumėte į įmonių, kurių pavadinimas žiniasklaidoje minimas kartu su epitetais, sąrašą. įsilaužė“, „neatitinka informacijos saugumo reikalavimų“, „negalvoja apie savo ir klientų duomenų saugumą“.
Apibendrinant norėčiau išvardinti pagrindinius patarimus, kurių turėtumėte laikytis kurdami savo vidinės infrastruktūros informacijos saugos stebėjimą:
- Neapsiribokite tik perimetru! Naudokite (ir pasirinkite) tinklo infrastruktūrą ne tik srautui perkelti iš taško A į tašką B, bet ir spręsti kibernetinio saugumo problemas.
- Išstudijuokite esamus informacijos saugos stebėjimo mechanizmus savo tinklo įrangoje ir naudokite juos.
- Vidiniam stebėjimui pirmenybę teikite telemetrinei analizei – ji leidžia aptikti iki 80–90% visų tinklo informacijos saugumo incidentų, tuo pačiu daryti tai, kas neįmanoma fiksuojant tinklo paketus ir sutaupant vietos visiems informacijos saugos įvykiams saugoti.
- Norėdami stebėti srautus, naudokite Netflow v9 arba IPFIX – jie suteikia daugiau informacijos saugumo kontekste ir leidžia stebėti ne tik IPv4, bet ir IPv6, MPLS ir kt.
- Naudokite neatrinktą srauto protokolą – jis suteikia daugiau informacijos grėsmėms aptikti. Pavyzdžiui, Netflow arba IPFIX.
- Patikrinkite tinklo įrangos apkrovą – ji taip pat gali neatlaikyti srauto protokolo. Tada apsvarstykite galimybę naudoti virtualius jutiklius arba „Netflow Generation Appliance“.
- Įdiekite kontrolę pirmiausia prieigos lygiu – tai suteiks galimybę matyti 100% viso srauto.
- Jei neturite pasirinkimo ir naudojate rusišką tinklo įrangą, pasirinkite tokią, kuri palaiko srauto protokolus arba turi SPAN/RSPAN prievadus.
- Sujunkite įsibrovimų / atakų aptikimo / prevencijos sistemas pakraščiuose ir srautų analizės sistemas vidiniame tinkle (įskaitant debesis).
Dėl paskutinio patarimo norėčiau pateikti iliustraciją, kurią jau pateikiau anksčiau. Matote, kad jei anksčiau Cisco informacijos saugos tarnyba beveik visiškai savo informacijos saugos stebėjimo sistemą kūrė remdamasi įsibrovimų aptikimo sistemomis ir parašo metodais, tai dabar jos sudaro tik 20% incidentų. Dar 20% tenka srautų analizės sistemoms, o tai rodo, kad šie sprendimai nėra užgaida, o tikras įrankis šiuolaikinės įmonės informacijos saugos tarnybų veikloje. Be to, jų įgyvendinimui turite svarbiausią dalyką – tinklo infrastruktūrą, į kurią investicijas galima dar labiau apsaugoti tinklui priskiriant informacijos saugumo stebėjimo funkcijas.
Reagavimo į tinklo srautuose nustatytas anomalijas ar grėsmes temos specialiai neliečiau, bet manau, kad jau dabar aišku, kad stebėjimas neturėtų baigtis vien tik grėsmės aptikimu. Po jo turėtų būti atsakymas, pageidautina automatiniu arba automatiniu režimu. Bet tai atskiro straipsnio tema.
Papildoma Informacija:
PS. Jei jums lengviau išgirsti viską, kas buvo parašyta aukščiau, galite žiūrėti valandos trukmės pristatymą, kuris buvo šios pastabos pagrindas.
Šaltinis: www.habr.com