— egy kiberbiztonsági analitikai megoldás, amely átfogó fenyegetésfigyelést biztosít elosztott hálózatokban. A StealthWatch működése a NetFlow és IPFIX adatainak gyűjtésén alapul útválasztókból, kapcsolókból és egyéb hálózati eszközökből. Ennek eredményeként a hálózat érzékelővé válik, amely lehetővé teszi az adminisztrátor számára, hogy olyan területekre lásson be, amelyekhez a hagyományos hálózati védelmi módszerek, például a következő generációs tűzfal nem tudnak eljutni.
Korábbi cikkekben már írtam a StealthWatch-ról: , valamint . Most javaslom, hogy haladjunk tovább, és beszéljük meg, hogyan kell kezelni az alarmokat és vizsgálni a biztonsági eseményeket, amelyeket a megoldás generál. Hat példát fogok bemutatni, amelyek szerintem jó képet adnak a termék hasznosságáról.
Először is, érdemes megemlíteni, hogy a StealthWatch-ban bizonyos eloszlás van az algoritmusok és feedek között. Az elsőek különféle alarmok (értesítések), amelyek aktiválásakor gyanús dolgokat lehet felfedezni a hálózatban. A másodikak pedig biztonsági események. Ebben a cikkben 4 példát fogunk megvizsgálni az algoritmusok aktiválásáról és 2 példát a feedekről.
1. A legnagyobb interakciók elemzése a hálózaton belül
A StealthWatch beállításának kezdeti lépése a hosztok és hálózatok csoportonkénti meghatározása. A webes felületen a fül Configure > Host Group Management alatt a hálózatokat, hosztokat, szervereket megfelelő csoportokba kell sorolni. Saját csoportokat is létrehozhatunk. Érdemes megjegyezni, hogy a Cisco StealthWatch-ban a hosztok közötti interakciók elemzése nagyon kényelmes, mivel nemcsak a keresési szűrőket lehet menteni a folyamatok szerint, hanem magukat az eredményeket is.
Először is, a webes felületen érdemes belépni a Analyze > Flow Searchfülre. Ezután a következő paramétereket kell beállítani:
- Search Type — Top Conversations (a legnépszerűbb interakciók)
- Time Range — 24 hours (időintervallum, más is használható)
- Search Name — Top Conversations Inside-Inside (bármilyen érthető név)
- Subject — Host Groups → Inside Hosts (forrás — belső hosztok csoportja)
- Connection (meg lehet adni portokat, alkalmazásokat)
- Peer — Host Groups → Inside Hosts (cél — belső hosztok csoportja)
- Az Advanced Options részben további kollektort is meg lehet adni, ahonnan az adatokat vizsgálják, és a kimenet rendezését (byte-ok, folyamatok stb. szerint). Ezt alapértelmezettként fogom hagyni.
A gomb megnyomása után Keresés Megkapja a már rendszerezett interakciók listáját, amelyeket az átvitt adatmennyiség szerint soroltak.
A példámban a host 10.150.1.201 (szerver) egyetlen szál keretében továbbította 1,5 GB a forgalmat a host 10.150.1.200 (ügyfél) a következő protokollon mysql. A gomb Oszlopok kezelése lehetővé teszi, hogy további oszlopokat adjunk a megjelenített adatokhoz.
Ezután az adminisztrátor saját belátása szerint létrehozhat egy testreszabott szabályt, amely folyamatosan működik ezen interakciók során, és értesítést küld SNMP, email vagy Syslog útján.
2. A leglassabb kliens-szerver interakciók elemzése a hálózaton belül késleltetésekkel kapcsolatban
Címkék SRT (Szerver Válaszidő), RTT (Körutazási Idő) lehetővé teszi a szerverek és a hálózat általános késleltetéseinek meghatározását. Ez az eszköz különösen hasznos, amikor gyorsan kell megtalálni a felhasználók panaszainak okát, amikor egy alkalmazás lassan működik.
Megjegyzés: gyakorlatilag az összes Netflow exportáló nem képes SRT, RTT címkék küldésére, ezért gyakran ahhoz, hogy láthassuk ezeket az adatokat a FlowSensornál, be kell állítani a forgalom másolatának küldését a hálózati eszközökről. A FlowSensor viszont kiterjesztett IPFIX-et ad át a FlowCollector-nak.
Ezeket az elemzéseket könnyebb Java alkalmazásban végezni, mint például a StealthWatch, amelyet az adminisztrátor számítógépére telepítenek.
Jobb klikk a Belső hosztok elemre, majd lépjünk a Forgalmi táblázat.
elemre. Kattintsunk a Filter gombra és állítsuk be a szükséges paramétereket. Példaként:
- Dátum/idő — Az elmúlt 3 napra
- Teljesítmény — Átlagos körutazási idő >=50 ms
Az adatok megjelenítése után hozzá kell adni az érdeklődésünkre számot tartó RTT, SRT mezőket. Ehhez kattintsunk a képernyőn látható oszlopra, majd jobb klikkeljünk és válasszuk a Oszlopok kezelése. Ezután válasszuk ki az RTT, SRT paramétereket.
A kérés feldolgozása után az RTT átlag szerint szortíroztam, és láttam a leglassabb interakciókat.
A részletes információkhoz kattintson jobb gombbal az áramlatra, és válassza a Gyors nézet az áramlat számára.
Ez az információ azt mutatja, hogy a host 10.201.3.59 a következő csoportban Értékesítés és Marketing a DNS szerverhez NFS fordul továbbított 1 perc 23 másodpercen keresztül, és rendkívül rossz késleltetése van. A fülön meg lehet tudni, hogy melyik Netflow exportőrtől származik az információ. A fülön Interfaces több részletes információ található az interakcióról. adatok táblázatra történő továbbításához. Ezután meg kell tudni, hogy mely eszközök küldenek forgalmat a FlowSensornak, és a probléma valószínűleg ott rejlik.
Továbbá, a StealthWatch egyedi azzal, hogy végrehajtja a
deduplikációt. дедупликацию adatok (összevonja ugyanazokat az adatfolyamokat). Következésképpen szinte minden Netflow-eszközből gyűjthetünk, és nem kell aggódnunk a sok ismétlődő adat miatt. Éppen ellenkezőleg, ebben a rendszeren segít megérteni, hogy melyik hopnál vannak a legnagyobb késések.
3. HTTPS kriptográfiai protokollok auditálása
ETA (Encrypted Traffic Analytics) — a Cisco által kifejlesztett technológia, amely lehetővé teszi a rosszindulatú kapcsolatok észlelését titkosított forgalomban anélkül, hogy annak dekódolására lenne szükség. Ráadásul ez a technológia lehetővé teszi a HTTPS verziók és a csatlakozásoknál használt kriptográfiai protokollok "bontását". Ez a funkció különösen hasznos, ha a gyenge kriptóstandartokat alkalmazó hálózati csomópontokat szeretnénk észlelni.
Megjegyzés: először telepítenünk kell a StealthWatch network app-ot — ETA Kriptográfiai Audit.
Lépjünk a Irányítópultok → ETA Kriptográfiai Audit és választjuk ki azt a hosztcsoportot, amelyet elemezni szeretnénk. Az általános kép érdekében válasszunk Belső hosztok.
Megfigyelhetjük, hogy a TLS verzió és a megfelelő kriptóstandart jelenik meg. A megszokott séma szerint az oszlopban Actions lépjünk a View Flows menüpontra, és a keresés új fülön elindul.
A kimenetből látható, hogy a hoszt 198.19.20.136 12 órán keresztül HTTPS-t használt TLS 1.2-vel, ahol a titkosítási algoritmus és a hash-függvény AES-256 SHA-384 . Így az ETA lehetővé teszi a gyenge algoritmusok megtalálását a hálózatban.4. A hálózati anomáliák elemzése
A Cisco StealthWatch képes észlelni a forgalom anomáliáit a hálózatban, három eszközt használva:
Core Events (biztonsági események), Relationship Events (szegmensek közötti interakciós események és hálózati csomópontok) és viselkedéselemzés A viselkedéselemzés lehetővé teszi, hogy idővel egy adott hoszt vagy hosztcsoport viselkedési modelljét építsük fel. Minél több forgalom halad át a StealthWatch-on, annál pontosabbak lesznek az értesítések a segítségével. Kezdetben a rendszer sok téves riasztást generál, ezért a szabályokat érdemes "finomhangolni" kézzel. Javaslom, hogy az első néhány hétben ne figyeljünk ezekre az eseményekre, mivel a rendszer magától alkalmazkodik, vagy pedig tegyük őket kivételek közé..
Az alábbiakban egy előre beállított szabály példája található
Anomaly , amelyben a következő áll:az esemény riasztás nélkül fog működni, ha a hoszt az Inside Hosts csoportban kölcsönhatásba lép az Inside Hosts csoporttal, és 24 óra alatt a forgalom meghaladja a 10 megabájtot.
Példaként vegyük a riasztást Data Hoarding, ami azt jelenti, hogy egy forrás-/célhoszt anomálisan nagy mennyiségű adatot töltött le/újratöltött egy hosztcsoporttól vagy hosztból. Kattintsunk az eseményre, és mélyebbre merülünk az adatbázisban, ahol a riasztó hosztok szerepelnek. Ezután válasszuk ki a minket érdeklő hosztot az oszlopban. Data Hoarding.
Megjelenik egy esemény, amely arról tájékoztat, hogy 162k „pontot” észleltek, míg a politika 100k „pontot” engedélyez – ez a StealthWatch belső metrikái. Az oszlopban Actions kattintsunk View Flows.
Megfigyelhetjük, hogy ez a hoszt éjjel kapcsolatba lépett a következő hoszttal 10.201.3.47 a részlegből Értékesítés és marketing a DNS szerverhez HTTPS és letöltött 1,4 GB. Ez a példa lehet, hogy nem a legjobb, de a kapcsolatok észlelése akár több száz gigabájt esetén is pontosan így történik. Következésképpen a anomáliák további vizsgálata érdekes eredményekhez vezethet.
Megjegyzés: a SMC webes felületén az adatok a következő fülön találhatók Dashboardok csak az elmúlt hétre vonatkoznak, és a Monitor az elmúlt 2 hétre vonatkozik. Az régebbi események elemzéséhez és a jelentések generálásához az adminisztrátor számítógépén a Java konzollal kell dolgozni.
5. Belső hálózati szkennelések azonosítása
Most nézzünk meg néhány példát az informatikai biztonsági eseményekre. Ez a funkció inkább a biztonsági szakemberek számára érdekes.
Több előre beállított szkennelési eseménytípus található a StealthWatch-ban:
- Port Scan - a forrás sok állomás portját szkennel.
- Addr TCP scan - a forrás egész hálózatot szkennel egyetlen TCP porton, közben megváltoztatja a cél IP címet. Ezen idő alatt a forrás TCP Reset csomagokat kap vagy egyáltalán nem kap választ.
- Addr UDP scan - a forrás egész hálózatot szkennel egyetlen UDP porton, közben megváltoztatja a cél IP címet. Ezen idő alatt a forrás ICMP Port Unreachable csomagokat kap vagy egyáltalán nem kap választ.
- Ping Scan - a forrás ICMP kéréseket küld egy egész hálózatra a válaszok keresésének céljából.
- Stealth Scan TCP/UDP - a forrás ugyanazt a portját használta a célhoszt sok portjához való csatlakozáshoz egy időben.
Mivel a belső szkennerek egyszerűbb azonosításához létezik egy hálózati alkalmazás a StealthWatch - Látványértékelés. Kattintson a Dashboardok → Látványértékelés → Belső hálózati szkennerek menüpontra, ahol az elmúlt 2 hét biztonsági eseményei a szkennelésről láthatók.
A gomb megnyomásával Részletek, látható lesz a hálózatok vizsgálatának kezdete, a forgalmi trendek és a megfelelő riasztások.
Ezt követően "be lehet mélyedni" a hostba az előző képernyőn látható fülről, és megtekinthetjük a biztonsági eseményeket, valamint az elmúlt hét aktivitását ezzel a hosttal kapcsolatban.
Példaként elemezzük az eseményt Port Scan a hostból 10.201.3.149 Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata 10.201.0.72, a Műveletek > Kapcsolódó Áramlások. Elindul a keresés az áramlások között és releváns információk jelennek meg.
Ahogy látjuk, ez a host az egyik portjáról 51508/TCP 3 órája szkennelte a célszámítógépet a következő portokon: 22, 28, 42, 41, 36, 40 (TCP). Néhány mező nem jelenít meg információt, vagy azért, mert nem minden Netflow mező támogatott a Netflow exportálón.
6. Letöltött rosszindulatú programok elemzése a CTA segítségével
CTA (Cognitive Threat Analytics) — egy felhőalapú Cisco analitika, amely kiválóan integrálható a Cisco StealthWatch-szal, és lehetővé teszi a signature-mentes elemzés kiegészítését aláírásos elemzéssel. Ezáltal lehetővé válik a trójai vírusok, hálózati férgek, nulladik napi fenyegetések és más rosszindulatú programok és azok belső hálózati terjedésének észlelése. Az említett ETA technológia szintén lehetővé teszi az ilyen rosszindulatú kommunikációk elemzését titkosított forgalomban.
Már az első fülön a webes felületen található egy külön widget Cognitive Threat Analytics. A rövid összegzés összefoglalja a felhasználói hostokon észlelt fenyegetéseket: trójai, csaló szoftver, kényszerítő reklám szoftver. Az "Encrypted" szó jelzi az ETA működését. A hostra kattintva megjelenik minden információ, beleértve a biztonsági eseményeket és a CTA naplóit.
Minden CTA lépés felett állva részletes információk jelennek meg az interakcióról. A teljes elemzéshez érdemes rákattintani a Incidens Részletek Megtekintése, és egy külön konzolra jutsz Cognitive Threat Analytics.
A jobb felső sarokban a szűrő lehetővé teszi az események megjelenítését a kritikus szint szerint. Ha egy adott anomáliára állunk, az képernyő alján a megfelelő idővonalú naplók jelennek meg. Ezzel a kiberbiztonsági szakember pontosan megérti, hogy melyik fertőzött host melyik művelet után kezdett el bizonyos tevékenységeket folytatni.
Alább egy másik példa látható — egy banki trójai, amellyel a host megfertőződött. 198.19.30.36Ez a host interakcióba lépett a rosszindulatú domainekkel, és a naplók bemutatják az ilyen interakciók áramlásaira vonatkozó információkat.
Az egyik legjobb megoldás, amely lehet, hogy segíthet, az, hogy a hosztot karanténba helyezzük egy natív Cisco ISE segítségével a további kezelés és elemzés érdekében.
Zárás
A Cisco StealthWatch megoldás a hálózati monitoring termékek között az egyik vezető helyen áll, mind a hálózatelemzés, mind az információbiztonság területén. Ezzel az eszközzel észlelhetjük a hálózaton belüli illegitim interakciókat, az alkalmazások késleltetését, a legaktívabb felhasználókat, anomáliákat, kártevőket és APT-t. Továbbá, képesek vagyunk azonosítani a szkenneléseket, a penetrációs tesztelőket, elvégezni a HTTPS forgalom kriptoauditját. Még több használati esetet találhat a .
Ha szeretné ellenőrizni, hogy a hálózatán minden simán és hatékonyan működik-e, küldjön .
Hamarosan több technikai publikációt tervezünk különböző IB termékekről. Ha érdekli a téma, kövesse frissítéseinket csatornáinkon (, , , )!
Forrás: habr.com
