Amikor egy belső vállalati vagy részleghálózat biztonságának felügyeletéről van szó, sokan az információszivárgások ellenőrzéséhez és a DLP-megoldások megvalósításához kötik. És ha megpróbálja tisztázni a kérdést, és megkérdezi, hogyan észleli a támadásokat a belső hálózaton, akkor a válasz általában a behatolásérzékelő rendszerek (IDS) említése lesz. És ami 10-20 évvel ezelőtt egyetlen lehetőség volt, az ma már anakronizmussá válik. Létezik egy hatékonyabb, helyenként az egyetlen lehetőség a belső hálózat felügyeletére - áramlási protokollok segítségével, melyeket eredetileg a hálózati problémák felkutatására (hibaelhárítás) terveztek, de idővel egy nagyon érdekes biztonsági eszközzé alakultak át. Beszélni fogunk arról, hogy milyen áramlási protokollok léteznek, és melyek azok, amelyek jobban észlelik a hálózati támadásokat, hol célszerű az áramlásfigyelést megvalósítani, mire kell figyelni egy ilyen séma telepítésekor, és még arról is, hogyan lehet mindezt a hazai berendezéseken „megemelni”. e cikk keretein belül.
Nem foglalkozom azzal a kérdéssel, hogy „Miért van szükség a belső infrastruktúra biztonsági ellenőrzésére?” A válasz egyértelműnek tűnik. De ha mégis szeretnél még egyszer megbizonyosodni arról, hogy ma már nem tudsz nélküle élni, egy rövid videó arról, hogyan lehet 17 módon behatolni a tűzfallal védett vállalati hálózatba. Ezért feltételezzük, hogy megértjük, hogy a belső ellenőrzés szükséges, és csak azt kell megérteni, hogyan lehet ezt megszervezni.
Három kulcsfontosságú adatforrást emelnék ki az infrastruktúra hálózati szintű felügyeletéhez:
- „nyers” forgalom, amelyet rögzítünk és elemzésre elküldünk bizonyos elemzőrendszereknek,
- események olyan hálózati eszközökről, amelyeken a forgalom áthalad,
- az egyik áramlási protokollon keresztül kapott forgalmi információk.
A nyers forgalom rögzítése a legnépszerűbb lehetőség a biztonsági szakemberek körében, mert történelmileg ez jelent meg és volt az első. A hagyományos hálózati behatolásérzékelő rendszerek (a legelső kereskedelmi behatolásérzékelő rendszer a Wheel Group NetRangere volt, amelyet 1998-ban vásárolt meg a Cisco) pontosan olyan csomagok (és későbbi munkamenetek) rögzítésével foglalkoztak, amelyekben bizonyos aláírásokat kerestek („döntő szabályok” FSTEC terminológia), jelzési támadások. A nyers forgalmat természetesen nemcsak IDS segítségével, hanem más eszközökkel is elemezhetjük (például Wireshark, tcpdum vagy a Cisco IOS NBAR2 funkciója), de ezekből általában hiányzik az a tudásbázis, amely megkülönbözteti az információbiztonsági eszközt a hagyományostól. informatikai eszköz.
Tehát támadásérzékelő rendszerek. A hálózati támadások észlelésének legrégebbi és legnépszerűbb módszere, amely jó munkát végez a peremen (mindegy, hogy mi legyen - vállalati, adatközpont, szegmens stb.), de a modern kapcsolt és szoftveres hálózatokban meghibásodik. Hagyományos switchekre épülő hálózat esetén a támadásérzékelő szenzorok infrastruktúrája túlságosan nagyra nő - minden egyes csatlakozásra szenzort kell telepítenie annak a csomópontnak, amelyen a támadásokat figyelni szeretné. Természetesen bármelyik gyártó szívesen elad Önnek több száz és ezer érzékelőt, de azt hiszem, a költségvetése nem tudja támogatni az ilyen kiadásokat. Azt mondhatom, hogy ezt még a Ciscónál (és mi vagyunk az NGIPS fejlesztői) sem tudtuk megtenni, bár úgy tűnik, az ár kérdése előttünk áll. Nem szabad kiállnom – ez a saját döntésünk. Ezenkívül felmerül a kérdés, hogyan kell csatlakoztatni az érzékelőt ebben a verzióban? A résbe? Mi van, ha maga az érzékelő meghibásodik? Szükség van bypass modulra az érzékelőben? Elosztókat használ (csap)? Mindez drágítja a megoldást, és megfizethetetlenné teszi bármilyen méretű cég számára.
Megpróbálhatja „akasztani” az érzékelőt egy SPAN/RSPAN/ERSPAN portra, és arra irányítani a forgalmat a szükséges kapcsolóportokról. Ez az opció részben eltávolítja az előző bekezdésben leírt problémát, de egy másikat vet fel - a SPAN port nem tudja teljesen fogadni a rá érkező forgalmat - nem lesz elég sávszélessége. Fel kell áldoznod valamit. Vagy hagyjon néhány csomópontot felügyelet nélkül (akkor először priorizálnia kell őket), vagy nem az összes forgalmat küldi el a csomópontról, hanem csak egy bizonyos típust. Mindenesetre kihagyunk néhány támadást. Ezenkívül a SPAN port más igényekre is használható. Ennek eredményeként át kell tekintenünk a meglévő hálózati topológiát, és esetleg módosítanunk kell rajta, hogy a lehető legtöbb érzékelővel lefedjük a hálózatot (és ezt egyeztetjük az IT-vel).
Mi van, ha a hálózat aszimmetrikus útvonalakat használ? Mi a teendő, ha már bevezette vagy tervezi megvalósítani az SDN-t? Mi van, ha olyan virtualizált gépeket vagy konténereket kell figyelnie, amelyek forgalma egyáltalán nem éri el a fizikai kapcsolót? Ezek olyan kérdések, amelyeket a hagyományos IDS-szállítók nem szeretnek, mert nem tudják, hogyan válaszoljanak rájuk. Talán meggyőzik Önt arról, hogy mindezek a divatos technológiák hype-ok, és nincs rá szüksége. Talán beszélni fognak arról, hogy kicsiben kell kezdeni. Vagy talán azt mondják, hogy egy erős cséplőt kell a hálózat közepére helyezni, és az összes forgalmat rá kell irányítani a kiegyenlítők segítségével. Bármilyen lehetőséget kínálnak is fel Önnek, világosan meg kell értenie, hogy az hogyan felel meg Önnek. És csak ezt követően döntsön a hálózati infrastruktúra információbiztonságának felügyeletére vonatkozó megközelítés kiválasztásáról. Visszatérve a csomagrögzítésre, szeretném elmondani, hogy ez a módszer továbbra is nagyon népszerű és fontos, de fő célja a határellenőrzés; határok a szervezete és az internet között, határok az adatközpont és a hálózat többi része között, határok a folyamatvezérlő rendszer és a vállalati szegmens között. Ezeken a helyeken a klasszikus IDS/IPS-nek továbbra is létjogosultsága van, és jól megbirkózik feladataival.
Térjünk át a második lehetőségre. A hálózati eszközökről érkező események elemzése támadásérzékelési célokra is használható, de nem fő mechanizmusként, mivel a behatolásoknak csak egy kis csoportját teszi lehetővé. Ezenkívül bizonyos reaktivitás velejárója - a támadásnak először meg kell történnie, majd azt egy hálózati eszköznek rögzítenie kell, ami valamilyen módon információbiztonsági problémát jelez. Több ilyen mód is létezik. Ez lehet syslog, RMON vagy SNMP. Az utolsó két protokollt az információbiztonsági hálózatfelügyeletre csak akkor használjuk, ha magának a hálózati berendezésnek a DoS-támadását kell észlelnünk, mivel az RMON és az SNMP használatával például megfigyelhető az eszköz központi terhelése. processzor vagy interfészei. Ez az egyik „legolcsóbb” (mindenkinek van syslogja vagy SNMP-je), ugyanakkor a leghatékonyabb a belső infrastruktúra információbiztonságának ellenőrzésére szolgáló összes módszer közül - sok támadás egyszerűen el van rejtve előle. Természetesen ezeket sem szabad elhanyagolni, és ugyanaz a syslog elemzés segít időben azonosítani magának az eszköznek a konfigurációjában bekövetkezett változásokat, annak kompromittálását, de nem túl alkalmas a teljes hálózatot ért támadások észlelésére.
A harmadik lehetőség a több áramlási protokoll egyikét támogató eszközön áthaladó forgalomra vonatkozó információk elemzése. Ebben az esetben, a protokolltól függetlenül, a szálfűző infrastruktúra szükségszerűen három összetevőből áll:
- Áramlás generálása vagy exportálása. Ez a szerepkör általában egy routerhez, switchhez vagy más hálózati eszközhöz van hozzárendelve, amely a hálózati forgalmat önmagán átvezetve lehetővé teszi a kulcsparaméterek kinyerését belőle, amelyek azután a gyűjtőmodulba kerülnek. Például a Cisco nem csak útválasztókon és kapcsolókon támogatja a Netflow protokollt, beleértve a virtuális és ipariakat is, hanem a vezeték nélküli vezérlőkön, tűzfalakon és még szervereken is.
- Gyűjteményfolyamat. Tekintettel arra, hogy egy modern hálózat általában egynél több hálózati eszközzel rendelkezik, felmerül az áramlások összegyűjtésének és konszolidálásának problémája, amelyet úgynevezett gyűjtők segítségével oldanak meg, amelyek feldolgozzák a kapott áramlásokat, majd továbbítják elemzésre.
- Áramláselemzés Az elemző felvállalja a fő intellektuális feladatot, és különféle algoritmusokat alkalmazva a folyamokra bizonyos következtetéseket von le. Például egy informatikai funkció részeként egy ilyen elemző képes azonosítani a hálózati szűk keresztmetszeteket vagy elemezni a forgalmi terhelési profilt a hálózat további optimalizálása érdekében. Az információbiztonság érdekében pedig egy ilyen elemző képes észlelni az adatszivárgásokat, a rosszindulatú kódok terjedését vagy a DoS támadásokat.
Ne gondolja, hogy ez a háromszintű architektúra túl bonyolult – minden más lehetőség (talán az SNMP-vel és RMON-nal működő hálózatfigyelő rendszerek kivételével) is ennek megfelelően működik. Az elemzéshez adatgenerátorral rendelkezünk, amely lehet hálózati eszköz vagy önálló szenzor. Rendelkezünk riasztásgyűjtő rendszerrel és felügyeleti rendszerrel a teljes felügyeleti infrastruktúra számára. Az utolsó két komponens kombinálható egyetlen csomóponton belül, de többé-kevésbé nagy hálózatokban általában legalább két eszköz között vannak szétszórva a skálázhatóság és a megbízhatóság biztosítása érdekében.
Ellentétben a csomagelemzéssel, amely az egyes csomagok fejléc- és törzsadatainak tanulmányozásán, valamint az abból álló munkamenetek vizsgálatán alapul, az áramláselemzés a hálózati forgalom metaadatainak gyűjtésén alapul. Mikor, mennyit, honnan és honnan, hogyan... ezekre a kérdésekre ad választ a hálózati telemetria különféle áramlási protokollokat alkalmazó elemzése. Kezdetben statisztikák elemzésére és informatikai problémák felkutatására használták a hálózaton, majd az elemzési mechanizmusok fejlődésével lehetővé vált, hogy biztonsági okokból ugyanazon a telemetrián alkalmazzák őket. Érdemes ismét megjegyezni, hogy az áramláselemzés nem helyettesíti vagy helyettesíti a csomagrögzítést. Ezen módszerek mindegyikének megvan a maga alkalmazási területe. Ennek a cikknek a keretében azonban az áramláselemzés a legalkalmasabb a belső infrastruktúra figyelésére. Vannak hálózati eszközei (akár szoftveresen definiált paradigmában, akár statikus szabályok szerint működnek), amelyeket egy támadás nem tud megkerülni. Ez képes megkerülni a klasszikus IDS-érzékelőt, de a áramlási protokollt támogató hálózati eszköz nem. Ez a módszer előnye.
Másrészt, ha bizonyítékra van szüksége a bűnüldöző szerveknek vagy a saját incidensnyomozó csapatának, nem nélkülözheti a csomagrögzítést – a hálózati telemetria nem a forgalom másolata, amely bizonyítékgyűjtésre használható; az információbiztonság területén a gyors észleléshez és döntéshozatalhoz szükséges. Másrészt a telemetriai elemzéssel nem az összes hálózati forgalmat lehet „írni” (ha van ilyen, a Cisco az adatközpontokkal foglalkozik :-) hanem csak azt, ami a támadásban érintett. A telemetriai elemző eszközök ebben a tekintetben jól kiegészítik a hagyományos csomagrögzítési mechanizmusokat, parancsokat adva a szelektív rögzítéshez és tároláshoz. Ellenkező esetben óriási tárolási infrastruktúrára lesz szüksége.
Képzeljünk el egy 250 Mbit/sec sebességgel működő hálózatot. Ha mindezt a kötetet tárolni szeretné, akkor 31 MB tárhelyre lesz szüksége egy másodperces forgalomátvitelhez, 1,8 GB-ra egy percre, 108 GB-ra egy órára, és 2,6 TB-ra egy napra. A 10 Gbit/s sávszélességű hálózat napi adatainak tárolásához 108 TB tárhelyre lesz szüksége. Egyes szabályozók azonban megkövetelik a biztonsági adatok évekig tartó tárolását... Az igény szerinti rögzítés, amelynek megvalósítását az áramláselemzés segíti, nagyságrendekkel csökkenti ezeket az értékeket. Egyébként, ha a rögzített hálózati telemetriai adatok mennyiségének és a teljes adatrögzítésnek az arányáról beszélünk, akkor ez körülbelül 1:500. A fent megadott értékekhez a teljes napi forgalom teljes átiratának tárolása 5 illetve 216 GB lesz (akár normál pendrive-ra is rögzítheted).
Ha a nyers hálózati adatok elemzésére szolgáló eszközök esetében a rögzítés módja szinte azonos szállítóról szállítóra, akkor az áramláselemzés esetében más a helyzet. A folyamatprotokollokhoz több lehetőség is kínálkozik, a különbségekről, amelyekről tudnia kell a biztonsággal összefüggésben. A legnépszerűbb a Cisco által kifejlesztett Netflow protokoll. Ennek a protokollnak több változata létezik, amelyek képességeikben és a rögzített forgalmi információk mennyiségében különböznek egymástól. A jelenlegi verzió a kilencedik (Netflow v9), amely alapján kifejlesztették az iparági szabványt, a Netflow v10-et, más néven IPFIX-et. Ma a legtöbb hálózati gyártó támogatja a Netflow-t vagy az IPFIX-et a berendezéseiben. De számos más lehetőség is létezik az áramlási protokollokhoz - sFlow, jFlow, cFlow, rFlow, NetStream stb., amelyek közül az sFlow a legnépszerűbb. Ezt a típust támogatják leggyakrabban a hazai hálózati berendezések gyártói a könnyű kivitelezés miatt. Melyek a fő különbségek a de facto szabvánnyá vált Netflow és az sFlow között? Néhány kulcsfontosságúat kiemelnék. Először is, a Netflow a felhasználó által testreszabható mezőkkel rendelkezik, szemben az sFlow rögzített mezőivel. Másodszor pedig, és ez esetünkben a legfontosabb, az sFlow úgynevezett mintavételezett telemetriát gyűjt; ellentétben a mintavétel nélküli Netflow és IPFIX rendszerrel. Mi a különbség köztük?
Képzeld el, hogy úgy döntesz, hogy elolvasod a könyvet "” kollégáim – Gary McIntyre, Joseph Munitz és Nadem Alfardan – közül (a könyv egy része letölthető a linkről). Három lehetőség közül választhat, hogy elérje célját – elolvassa az egész könyvet, lapozza át, minden 10. vagy 20. oldalon megállva, vagy próbálja megtalálni a kulcsfogalmak újramondását egy blogon vagy szolgáltatáson, például a SmartReadingen. Tehát a mintavétel nélküli telemetria a hálózati forgalom minden „oldalát” beolvassa, vagyis minden egyes csomag metaadatait elemzi. A mintavételes telemetria a forgalom szelektív tanulmányozása abban a reményben, hogy a kiválasztott minták tartalmazzák azt, amire szüksége van. A csatorna sebességétől függően a mintavételezett telemetria minden 64., 200., 500., 1000., 2000. vagy akár 10000. csomagonként kerül elküldésre.
Az információbiztonsági megfigyelés keretében ez azt jelenti, hogy a mintavételezett telemetria kiválóan alkalmas DDoS-támadások észlelésére, átvizsgálására és rosszindulatú kódok terjesztésére, de előfordulhat, hogy kimaradnak azok az atom- vagy többcsomagos támadások, amelyek nem szerepeltek az elemzésre küldött mintában. A mintavétel nélküli telemetriának nincsenek ilyen hátrányai. Ezzel sokkal szélesebb az észlelt támadások köre. Íme egy rövid lista a hálózati telemetriai elemző eszközökkel észlelhető eseményekről.
Természetesen néhány nyílt forráskódú Netflow analizátor ezt nem teszi lehetővé, mivel fő feladata a telemetria összegyűjtése és informatikai szempontból alapvető elemzése. Az információbiztonsági fenyegetések áramláson alapuló azonosításához az elemzőt különféle motorokkal és algoritmusokkal kell felszerelni, amelyek szabványos vagy egyedi Netflow mezők alapján azonosítják a kiberbiztonsági problémákat, gazdagítják a szabványos adatokat különböző fenyegetésintelligencia forrásokból származó külső adatokkal stb.
Ezért, ha van választása, válassza a Netflow vagy az IPFIX lehetőséget. De még akkor is, ha az Ön berendezése csak az sFlow-val működik, mint a hazai gyártók, még ebben az esetben is profitálhat belőle biztonsági szempontból.
2019 nyarán elemeztem az orosz hálózati hardvergyártók képességeit, és az NSG, a Polygon és a Craftway kivételével mindegyik bejelentette az sFlow támogatását (legalábbis Zelax, Natex, Eltex, QTech, Rusteleteh).
A következő kérdés, amellyel szembe kell néznie, az, hogy hol lehet biztonsági célból áramlástámogatást megvalósítani? Valójában a kérdés nincs teljesen helyesen feltéve. A modern berendezések szinte mindig támogatják az áramlási protokollokat. Ezért másképp fogalmaznám meg a kérdést - biztonsági szempontból hol a leghatékonyabb a telemetria gyűjtése? A válasz teljesen nyilvánvaló lesz - a hozzáférési szinten, ahol az összes forgalom 100%-át látni fogod, ahol részletes információkat kapsz a gazdagépekről (MAC, VLAN, interfész azonosító), ahol akár figyelni is tudod a gazdagépek közötti P2P forgalmat, ami kritikus fontosságú a rosszindulatú kódok észlelésében és terjesztésében. Az alapszinten előfordulhat, hogy egyszerűen nem látja a forgalom egy részét, de a kerületi szinten az összes hálózati forgalom negyedét fogja látni. De ha valamilyen oknál fogva olyan idegen eszközök vannak a hálózaton, amelyek lehetővé teszik a támadók számára, hogy „belépjenek és kilépjenek” a kerület megkerülése nélkül, akkor a telemetria elemzése nem ad semmit. Ezért a maximális lefedettség érdekében ajánlatos hozzáférési szinten engedélyezni a telemetriai adatgyűjtést. Ugyanakkor érdemes megjegyezni, hogy még ha virtualizációról vagy konténerekről is beszélünk, a modern virtuális kapcsolókban is gyakran megtalálható a flow-támogatás, amely lehetővé teszi a forgalom irányítását ott is.
De mivel felvetettem a témát, meg kell válaszolnom a kérdést: mi van akkor, ha a fizikai vagy virtuális berendezés nem támogatja az áramlási protokollokat? Vagy tilos a beépítése (például ipari szegmensekben a megbízhatóság biztosítása érdekében)? Vagy a bekapcsolása nagy CPU-terheléshez vezet (ez régebbi hardvereken történik)? Ennek a problémának a megoldására speciális virtuális érzékelők (áramlásérzékelők) léteznek, amelyek lényegében közönséges elosztók, amelyek átengedik a forgalmat magukon, és áramlás formájában sugározzák azt a gyűjtőmodulba. Igaz, ebben az esetben megkapjuk mindazokat a problémákat, amelyekről fentebb a csomagrögzítő eszközök kapcsán beszéltünk. Vagyis nemcsak az áramláselemzési technológia előnyeit kell megértenie, hanem korlátait is.
Egy másik pont, amelyet fontos megjegyezni, amikor az áramláselemző eszközökről beszélünk. Ha a biztonsági események generálásának hagyományos eszközeivel kapcsolatban az EPS metrikát (esemény per másodperc) használjuk, akkor ez a mutató nem alkalmazható a telemetriai elemzésre; FPS (flow per second) váltja fel. Az EPS-hez hasonlóan ezt sem lehet előre kiszámítani, de megbecsülhető, hogy az adott eszköz a feladatától függően hozzávetőlegesen hány szálat generál. Az interneten táblázatokat találhat hozzávetőleges értékekkel a különböző típusú vállalati eszközökhöz és feltételekhez, amelyek lehetővé teszik, hogy megbecsülje, milyen licencekre van szüksége az elemzőeszközökhöz, és milyen lesz az architektúrája? Az a tény, hogy az IDS érzékelőt egy bizonyos sávszélesség korlátozza, amelyet „húzhat”, és az áramlásgyűjtőnek megvannak a maga korlátai, amelyeket meg kell érteni. Ezért a nagy, földrajzilag elosztott hálózatokban általában több gyűjtő található. Amikor leírtam , már megadtam a gyűjtőink számát – 21 darab van. És ez egy öt kontinensen szétszórt, körülbelül félmillió aktív eszközt számláló hálózatra vonatkozik).
Netflow felügyeleti rendszerként saját megoldásunkat használjuk , amely kifejezetten a biztonsági problémák megoldására koncentrál. Számos beépített motorral rendelkezik a rendellenes, gyanús és egyértelműen rosszindulatú tevékenységek észlelésére, amelyek lehetővé teszik a különféle fenyegetések széles skálájának észlelését - a kriptominálástól az információszivárgásig, a rosszindulatú kódok terjedésétől a csalásig. A legtöbb áramláselemzőhöz hasonlóan a Stealthwatch is egy háromszintű séma szerint épül fel (generátor - kollektor - analizátor), de számos olyan érdekességgel van kiegészítve, amelyek fontosak a vizsgált anyaggal összefüggésben. Először is integrálható a csomagrögzítési megoldásokkal (például a Cisco Security Packet Analyzer), amely lehetővé teszi a kiválasztott hálózati munkamenetek rögzítését későbbi mélyreható vizsgálat és elemzés céljából. Másodszor, kifejezetten a biztonsági feladatok bővítése érdekében kifejlesztettünk egy speciális nvzFlow protokollt, amely lehetővé teszi a végcsomópontokon (szerverek, munkaállomások stb.) lévő alkalmazások tevékenységének telemetriába történő „sugárzását”, és a gyűjtőnek történő továbbítását további elemzés céljából. Ha eredeti verziójában a Stealthwatch bármilyen áramlási protokollal (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) működik hálózati szinten, akkor az nvzFlow támogatás csomóponti szinten is lehetővé teszi az adatkorrelációt, ezáltal. növeli a teljes rendszer hatékonyságát, és több támadást lát, mint a hagyományos hálózati áramláselemzők.
Nyilvánvaló, hogy ha a Netflow elemző rendszerekről beszélünk biztonsági szempontból, akkor a piac nem korlátozódik egyetlen Cisco megoldásra. Használhat kereskedelmi és ingyenes vagy shareware megoldásokat is. Elég furcsa, ha a versenytársak megoldásait idézem példaként a Cisco blogon, ezért ejtek néhány szót arról, hogyan lehet elemezni a hálózati telemetriát két népszerű, hasonló nevű, de mégis eltérő eszközzel - a SiLK-val és az ELK-val.
A SiLK az amerikai CERT/CC által kifejlesztett forgalomelemzési eszközkészlet (az Internet-szintű tudás rendszere), amely a mai cikk kapcsán támogatja a Netflow-t (5. és 9., a legnépszerűbb verzió), az IPFIX-et. és sFlow és különféle segédprogramok (rwfilter, rwcount, rwflowpack stb.) segítségével különféle műveleteket hajthat végre a hálózati telemetrián, hogy észlelje a benne lévő jogosulatlan műveletek jeleit. De néhány fontos szempontot meg kell jegyezni. A SiLK egy parancssori eszköz, amely on-line elemzést végez az ehhez hasonló parancsok beírásával (200 bájtnál nagyobb ICMP-csomagok észlelése):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nem túl kényelmes. Használhatja az iSiLK GUI-t, de nem könnyíti meg az életét, csak a vizualizációs funkciót oldja meg, és nem helyettesíti az elemzőt. És ez a második pont. Ellentétben a kereskedelmi megoldásokkal, amelyek már szilárd analitikai alappal, anomália észlelő algoritmusokkal, megfelelő munkafolyamattal stb. rendelkeznek, a SiLK esetében mindezt Önnek kell megtennie, ami kicsit más kompetenciákat igényel, mint a már kész használható eszközöket. Ez se nem jó, se nem rossz – ez szinte minden ingyenes eszköz jellemzője, amely feltételezi, hogy tudja, mit kell tennie, és csak ebben segít (a kereskedelmi eszközök kevésbé függenek a felhasználók kompetenciáitól, bár azt is feltételezik hogy az elemzők legalább a hálózati vizsgálatok és monitorozás alapjait megértsék). De térjünk vissza a SiLK-hoz. Az elemző munkaciklusa vele így néz ki:
- Hipotézis megfogalmazása. Meg kell értenünk, mit fogunk keresni a hálózati telemetrián belül, ismernünk kell azokat az egyedi attribútumokat, amelyek alapján azonosíthatunk bizonyos anomáliákat vagy fenyegetéseket.
- Modell építése. A hipotézis megfogalmazása után ugyanazzal a Python-nal, shell-el vagy más, a SiLK-ban nem szereplő eszközökkel programozzuk.
- Tesztelés. Most jön a sor, hogy ellenőrizzük hipotézisünk helyességét, amelyet az „rw”, „set”, „bag” kezdetű SiLK segédprogramok segítségével igazolunk vagy cáfolunk.
- Valós adatok elemzése. Ipari üzemben a SiLK segít azonosítani valamit, és az elemzőnek meg kell válaszolnia a „Megtaláltuk, amit vártunk?”, „Ez megfelel a hipotézisünknek?”, „Hogyan csökkenthető a hamis pozitív eredmények száma?”, „Hogyan” kérdésekre. az elismerés szintjének javítására? » stb.
- Javulás. Az utolsó szakaszban javítjuk a korábban tetteket - sablonokat készítünk, javítjuk és optimalizáljuk a kódot, újrafogalmazzuk és tisztázzuk a hipotézist, stb.
Ez a ciklus a Cisco Stealthwatch esetében is alkalmazható lesz, csak az utolsó automatizálja ezt az öt lépést maximálisan, csökkentve ezzel az elemzői hibák számát és növelve az incidensek észlelésének hatékonyságát. Például a SiLK-ban a rosszindulatú IP-címekre vonatkozó külső adatokkal gazdagíthatjuk a hálózati statisztikát kézzel írt szkriptek segítségével, a Cisco Stealthwatch-ban pedig egy beépített funkció, amely azonnal riasztást jelez, ha a hálózati forgalom interakciókat tartalmaz a tiltólistán szereplő IP-címekkel.
Ha feljebb lépsz a „fizetős” piramisban az áramláselemző szoftvereknél, akkor a teljesen ingyenes SiLK után egy shareware ELK lesz, amely három kulcskomponensből áll - Elasticsearch (indexelés, keresés és adatelemzés), Logstash (adatbevitel/kimenet). ) és Kibana (vizualizáció). A SiLK-kal ellentétben, ahol mindent magának kell megírnia, az ELK-nak már sok kész könyvtára/modulja van (egyik fizetős, van, amelyik nem), amelyek automatizálják a hálózati telemetria elemzését. Például a Logstash GeoIP-szűrője lehetővé teszi a megfigyelt IP-címek földrajzi helyükhöz való társítását (a Stealthwatch rendelkezik ezzel a beépített funkcióval).
Az ELK-nak is van egy meglehetősen nagy közössége, amely kiegészíti a hiányzó komponenseket ehhez a megfigyelési megoldáshoz. Például a Netflow, IPFIX és sFlow használatához használhatja a modult , ha nem elégedett a Logstash Netflow modullal, amely csak a Netflow-t támogatja.
Noha az ELK hatékonyabban gyűjti az áramlást és keres benne, jelenleg hiányzik a gazdag beépített analitika a hálózati telemetria anomáliáinak és fenyegetéseinek észlelésére. Vagyis a fent leírt életciklust követve önállóan le kell írnia a szabálysértési modelleket, majd használnia kell a harcrendszerben (ott nincsenek beépített modellek).
Természetesen vannak kifinomultabb bővítmények az ELK-hoz, amelyek már tartalmaznak néhány modellt a hálózati telemetria anomáliáinak észlelésére, de az ilyen bővítmények pénzbe kerülnek, és itt az a kérdés, hogy megéri-e a gyertyát a játék - írjon maga egy hasonló modellt, vegye meg implementációt felügyeleti eszközéhez, vagy vásárolja meg a Network Traffic Analysis osztály kész megoldását.
Általában nem akarok belemenni abba a vitába, hogy jobb pénzt költeni és kész megoldást vásárolni a hálózati telemetria anomáliáinak és fenyegetéseinek megfigyelésére (például Cisco Stealthwatch), vagy kitalálni és testre szabni. SiLK, ELK vagy nfdump vagy OSU Flow Tools minden új fenyegetéshez (az utolsó kettőről beszélek utoljára)? Mindenki maga választ, és mindenkinek megvan a maga indítéka, amiért a két lehetőség közül bármelyiket választja. Csak azt szerettem volna bemutatni, hogy a hálózati telemetria nagyon fontos eszköz a belső infrastruktúra hálózati biztonságának biztosításában, és nem szabad elhanyagolni, hogy ne csatlakozzon azon cégek listájához, amelyek nevét a médiában a jelzőkkel együtt említik. feltörték, "nem felelnek meg az információbiztonsági követelményeknek", "nem gondolnak adataik és vásárlói adataik biztonságára."
Összefoglalva szeretném felsorolni azokat a kulcsfontosságú tippeket, amelyeket érdemes követnie belső infrastruktúrája információbiztonsági felügyeletének kiépítése során:
- Ne korlátozza magát a kerületre! Használja (és válassza ki) a hálózati infrastruktúrát nemcsak a forgalom A pontból B pontba mozgatására, hanem a kiberbiztonsági problémák megoldására is.
- Tanulmányozza a meglévő információbiztonsági megfigyelési mechanizmusokat a hálózati berendezésében, és használja azokat.
- A belső felügyelethez előnyben részesítse a telemetriai elemzést - ez lehetővé teszi az összes hálózati információbiztonsági incidens akár 80-90%-ának észlelését, miközben megteszi azt, ami a hálózati csomagok rögzítésekor lehetetlen, és helyet takarít meg az összes információbiztonsági esemény tárolására.
- Az áramlások figyeléséhez használja a Netflow v9-et vagy az IPFIX-et – ezek több információt nyújtanak biztonsági kontextusban, és nem csak az IPv4, hanem az IPv6, MPLS stb. figyelését is lehetővé teszik.
- Használjon mintavételezés nélküli áramlási protokollt – ez több információt nyújt a fenyegetések észleléséhez. Például Netflow vagy IPFIX.
- Ellenőrizze a hálózati berendezés terhelését – előfordulhat, hogy nem tudja kezelni az áramlási protokollt is. Ezután fontolja meg virtuális érzékelők vagy Netflow Generation Appliance használatát.
- A vezérlést mindenekelőtt a hozzáférési szinten hajtsa végre – ez lehetőséget ad az összes forgalom 100%-ának megtekintésére.
- Ha nincs más választása, és orosz hálózati berendezést használ, akkor válasszon olyat, amelyik támogatja az áramlási protokollokat vagy rendelkezik SPAN/RSPAN portokkal.
- Kombinálja a behatolás-/támadás-észlelő/megelőző rendszereket a széleken és az áramláselemző rendszereket a belső hálózaton (beleértve a felhőket is).
Az utolsó tippet illetően egy olyan illusztrációt szeretnék adni, amelyet már korábban is adtam. Látható, hogy ha korábban a Cisco információbiztonsági szolgálat szinte teljes egészében behatolásérzékelő rendszerekre és aláírási módszerekre építette fel információbiztonsági megfigyelő rendszerét, akkor mára ezek az incidensek mindössze 20%-át teszik ki. További 20% esik az áramláselemző rendszerekre, ami azt sugallja, hogy ezek a megoldások nem szeszélyek, hanem valódi eszközök egy modern vállalat információbiztonsági szolgáltatásainak tevékenységében. Sőt, ezek megvalósításához Önnek a legfontosabb - a hálózati infrastruktúra, a beruházások tovább védhetők információbiztonsági felügyeleti funkciók hálózathoz rendelésével.
Kifejezetten nem érintettem a hálózati áramlásokban feltárt anomáliákra, fenyegetésekre való reagálás témáját, de azt gondolom, hogy az már most egyértelmű, hogy a monitorozásnak nem szabad csak a fenyegetés észlelésével véget érnie. Ezt válasznak kell követnie, lehetőleg automatikus vagy automatizált módban. De ez egy külön cikk témája.
További Információ:
PS. Ha könnyebben hall mindent, ami fent volt írva, akkor megtekintheti a jegyzet alapjául szolgáló egy órás előadást.
Forrás: will.com