Når det kommer til overvågning af sikkerheden i et internt virksomheds- eller afdelingsnetværk, forbinder mange det med informationslækagekontrol og implementering af DLP-løsninger. Og hvis du forsøger at finpudse spørgsmålet og spørge, hvordan du opdager angreb på det interne netværk, så vil svaret normalt være omtale af intrusion detection systems (IDS). Og det, der var den eneste mulighed for 10-20 år siden, er i dag ved at blive en anakronisme. Der er en mere effektiv, og nogle steder den eneste mulige mulighed for at overvåge det interne netværk - at bruge flow-protokoller, der oprindeligt er designet til at søge efter netværksproblemer (fejlfinding), men med tiden omdannet til et meget interessant sikkerhedsværktøj. Her vil vi tale om, hvad flowprotokoller er, og hvilke der hjælper med at opdage netværksangreb bedre, hvor det er bedst at implementere flowovervågning, hvad man skal kigge efter, når man implementerer en sådan ordning, og endda hvordan man "hæver" det hele på husholdningsudstyr , vil vi tale inden for rammerne af denne artikel.
Jeg vil ikke dvæle ved spørgsmålet "Hvorfor skal vi overvåge sikkerheden i den interne infrastruktur?" Svaret på det er lidt indlysende. Men hvis du alligevel gerne vil sikre dig igen, at du i dag ikke kan undvære det, en kort video med en historie om, hvordan du kan komme ind i et virksomhedsnetværk beskyttet af en firewall på 17 måder. Derfor vil vi antage, at vi forstår, at intern overvågning er en nødvendig ting, og det er kun tilbage at forstå, hvordan det kan organiseres.
Jeg vil fremhæve tre nøgledatakilder til infrastrukturovervågning på netværksniveau:
- "rå" trafik, som vi fanger og sender til analyse til nogle analysesystemer,
- hændelser fra netværksenheder, som trafikken passerer igennem,
- trafikinformation modtaget via en af flowprotokollerne.
Indfangning af rå trafik er den mest populære mulighed blandt sikkerhedsfolk, fordi den historisk dukkede op og var den allerførste. Konventionelle netværkssystemer til registrering af indtrængen (det allerførste kommercielle system til registrering af indtrængen var NetRanger fra Wheel Group, købt i 1998 af Cisco) var netop engageret i at fange pakker (og senere sessioner), hvor visse signaturer blev søgt ("afgørende regler" i FSTEC's terminologi), signalerende angreb. Selvfølgelig kan du analysere rå trafik ikke kun med IDS, men også med andre værktøjer (for eksempel Wireshark, tcpdum eller NBAR2-funktionaliteten i Cisco IOS), men de mangler normalt den videnbase, der adskiller et informationssikkerhedsværktøj fra en almindeligt it-værktøj.
Altså indbrudsdetektionssystemer. Den ældste og mest populære metode til at opdage netværksangreb, som gør et godt stykke arbejde i perimeteren (uanset hvad - virksomhed, datacenter, segment osv.), men fejler i moderne switchede og softwaredefinerede netværk. Hvis der er tale om et netværk bygget på basis af konventionelle switches, bliver infrastrukturen af indtrængningsdetektionssensorer for stor - du bliver nødt til at sætte en sensor på hver forbindelse til værten, som du vil overvåge angreb mod. Enhver producent vil selvfølgelig med glæde sælge dig hundredvis og tusindvis af sensorer, men jeg tror, dit budget ikke kan modstå sådanne udgifter. Jeg kan sige, at selv hos Cisco (og vi er udviklerne af NGIPS) kunne vi ikke gøre dette, selvom det ser ud til, at spørgsmålet om pris ligger foran os. bør ikke stå - det er vores egen beslutning. Derudover opstår spørgsmålet, hvordan man tilslutter sensoren i denne version? I et hul? Hvad hvis selve sensoren svigter? Kræver et bypass-modul i sensoren? Brug splittere (tryk)? Alt dette øger omkostningerne ved løsningen og gør den uoverkommelig for en virksomhed af enhver størrelse.
Du kan prøve at "hænge" sensoren på SPAN/RSPAN/ERSPAN-porten og dirigere trafik til den fra de nødvendige switch-porte. Denne mulighed fjerner delvist problemet beskrevet i det foregående afsnit, men udgør et andet - SPAN-porten kan ikke modtage absolut al den trafik, der vil blive sendt til den - den vil ikke have nok båndbredde. Villig til at ofre noget. Forlad enten nogle af noderne uden overvågning (så skal du først prioritere dem), eller send ikke al trafik fra noden, men kun en bestemt type. Under alle omstændigheder kan vi gå glip af nogle angreb. Derudover kan SPAN-porten optages til andre behov. Som følge heraf bliver vi nødt til at gennemgå den eksisterende netværkstopologi og eventuelt foretage justeringer af den for at dække dit netværk maksimalt med det antal sensorer du har (og koordinere dette med IT).
Hvad hvis dit netværk bruger asymmetriske ruter? Og hvis du har implementeret eller planlægger at implementere SDN? Men hvad nu hvis du skal overvåge virtualiserede maskiner eller containere, hvis trafik slet ikke når den fysiske switch? Det er spørgsmål, som traditionelle IDS-leverandører ikke kan lide, fordi de ikke ved, hvordan de skal besvare dem. Måske vil de overbevise dig om, at alle disse moderigtige teknologier er hype, og at du ikke har brug for det. Måske vil de tale om behovet for at starte i det små. Eller måske vil de sige, at du skal placere en kraftig tærskemaskine i midten af netværket og dirigere al trafik til den ved hjælp af belastningsbalancere. Uanset hvilken mulighed du bliver tilbudt, skal du selv klart forstå, hvordan det passer dig. Og først derefter træffe en beslutning om valget af tilgang til overvågning af informationssikkerheden i netværksinfrastrukturen. For at vende tilbage til pakkefangst, vil jeg sige, at denne metode fortsat er meget populær og vigtig, men dens hovedformål er grænsekontrol; grænserne mellem din organisation og internettet, grænserne mellem datacentret og resten af netværket, grænserne mellem processtyringssystemet og virksomhedssegmentet. Disse steder har klassiske IDS/IPS stadig ret til at eksistere og udføre et godt stykke arbejde med deres opgaver.
Lad os gå videre til den anden mulighed. Analyse af hændelser, der kommer fra netværksenheder, kan også bruges til indtrængningsformål, men ikke som hovedmekanismen, da den kun registrerer en lille klasse af indtrængen. Derudover er der en vis reaktivitet iboende - først skal der ske et angreb, derefter skal det rettes af en netværksenhed, som på den ene eller anden måde vil signalere et problem med informationssikkerheden. Der er flere sådanne metoder. Det kan være syslog, RMON eller SNMP. De sidste to protokoller til netværksovervågning i forbindelse med informationssikkerhed bruges kun, hvis vi skal detektere et DoS-angreb på selve netværksudstyret, da man ved hjælp af RMON og SNMP f.eks. kan overvåge belastningen på enhedens centrale processor eller dens grænseflader. Dette er en af de "billigste" (alle har syslog eller SNMP), men også den mest ineffektive af alle måder at overvåge informationssikkerheden i den interne infrastruktur på - mange angreb er simpelthen skjult for den. Selvfølgelig skal de ikke forsømmes, og den samme syslog-analyse hjælper dig med at identificere ændringer i selve enhedens konfiguration rettidigt, hvilket kompromitterer den, men den er ikke særlig velegnet til at opdage angreb på hele netværket.
Den tredje mulighed er at analysere information om trafik, der passerer gennem en enhed, der understøtter en af flere flow-protokoller. I dette tilfælde, uanset protokollen, består streaminginfrastrukturen nødvendigvis af tre komponenter:
- Genererings- eller eksportflow. Denne rolle tildeles normalt en router, switch eller anden netværksenhed, som ved at sende netværkstrafik gennem sig selv giver dig mulighed for at udtrække nøgleparametre fra den, som derefter overføres til samlingsmodulet. For eksempel understøttes Ciscos Netflow-protokol ikke kun på routere og switches, inklusive både virtuelle og industrielle, men også på trådløse controllere, firewalls og endda servere.
- indsamlingsflow. I betragtning af, at der normalt er mere end én netværksenhed i et moderne netværk, opstår problemet med at indsamle og konsolidere strømme, som løses ved hjælp af såkaldte samlere, der behandler de modtagne strømme og derefter sender dem til analyse.
- flowanalyse. Analysatoren påtager sig den intellektuelle hovedopgave og drager visse konklusioner ved at anvende forskellige algoritmer til strømmene. For eksempel inden for en IT-funktion kan en sådan analysator identificere netværksflaskehalse eller analysere trafikbelastningsprofilen for yderligere at optimere netværket. Og af hensyn til informationssikkerheden kan en sådan analysator opdage datalæk, spredning af ondsindet kode eller DoS-angreb.
Tro ikke, at sådan en trelagsarkitektur er for kompliceret - alle andre muligheder (med mulig undtagelse af netværksovervågningssystemer, der fungerer med SNMP og RMON) fungerer også efter den. Vi har en datagenerator til analyse, som er en netværksenhed eller en stand-alone sensor. Vi har et alarmindsamlingssystem og vi har et styringssystem for hele overvågningsinfrastrukturen. De sidste to komponenter kan kombineres inden for en enkelt node, men i mere eller mindre store netværk er de normalt spredt over mindst to enheder for at sikre skalerbarhed og pålidelighed.
I modsætning til pakkeanalyse, som er baseret på undersøgelsen af headeren og datakroppen for hver pakke og de sessioner, der består af dem, er flowanalyse afhængig af indsamlingen af metadata om netværkstrafik. Hvornår, hvor meget, hvorfra og hvor, hvordan ... det er spørgsmålene, som netværkstelemetrianalyse besvarer ved hjælp af forskellige flowprotokoller. Til at begynde med blev de brugt til at analysere statistik og søge efter it-problemer i netværket, men siden, som udviklingen af analytiske mekanismer, blev det muligt at anvende dem på den samme telemetri af sikkerhedsmæssige årsager. Det er værd at gentage her, at flowanalyse ikke erstatter eller erstatter pakkefangst. Hver af disse metoder har sit eget omfang. Men i forbindelse med denne artikel er det flowanalyse, der er bedst egnet til overvågning af intern infrastruktur. Du har netværksenheder (uanset om de fungerer i et softwaredefineret paradigme eller i henhold til statiske regler), som et angreb ikke kan omgå. Den kan omgå den klassiske IDS-sensor, men ikke en netværksenhed, der understøtter flow-protokollen. Dette er fordelen ved denne metode.
På den anden side, hvis du har brug for et bevisgrundlag for retshåndhævelse eller dit eget hændelsesefterforskningshold, kan du ikke undvære pakkefangst – netværkstelemetri er ikke en kopi af den trafik, der kan bruges til at indsamle beviser; det er nødvendigt for hurtig opdagelse og beslutningstagning inden for informationssikkerhed. På den anden side kan du ved hjælp af telemetrianalyse "skrive" ikke al netværkstrafik (hvis noget, Cisco er også involveret i datacentre :-), men kun den, der er involveret i angrebet. Telemetrianalyseværktøjer i denne henseende vil komplementere traditionelle pakkefangstmekanismer godt, hvilket giver en kommando til selektiv indfangning og lagring. Ellers bliver du nødt til at have en kolossal lagerinfrastruktur.
Forestil dig et netværk, der kører med 250 Mbps. Hvis du vil gemme hele denne mængde, skal du bruge 31 MB lagerplads til et sekunds trafikoverførsel, 1,8 GB i et minut, 108 GB i en time og 2,6 TB i en dag. For at gemme daglige data fra et netværk med en båndbredde på 10 Gb/s, skal du bruge 108 TB lagerplads. Men nogle regulatorer kræver, at du gemmer sikkerhedsdata i årevis ... On-demand-registreringen af flowanalysen hjælper dig med at reducere disse værdier i størrelsesordener. Forresten, hvis vi taler om forholdet mellem mængden af optagne data af netværkstelemetri og fuld datafangst, så er det cirka 1 til 500. For de samme værdier angivet ovenfor, lagring af en komplet dekryptering af al daglig trafik vil være henholdsvis 5 og 216 GB (du kan endda skrive til et almindeligt flashdrev ).
Hvis metoden til at indfange rå netværksdata til analyseværktøjer er næsten den samme fra leverandør til leverandør, så er situationen anderledes i tilfælde af strømanalyse. Der er flere varianter af flowprotokoller, hvor forskellene du skal kende i forbindelse med sikkerhed. Den mest populære er Netflow-protokollen udviklet af Cisco. Der er flere versioner af denne protokol, der adskiller sig i deres kapacitet og mængden af registreret information om trafik. Den nuværende version er den niende (Netflow v9), hvorfra industristandarden Netflow v10, også kendt som IPFIX, blev udviklet. I dag understøtter de fleste netværksleverandører Netflow eller IPFIX i deres udstyr. Men der er forskellige andre varianter af flowprotokoller - sFlow, jFlow, cFlow, rFlow, NetStream osv., hvoraf sFlow er den mest populære. Det er ham, der oftest understøttes af indenlandske producenter af netværksudstyr på grund af nem implementering. Hvad er de vigtigste forskelle mellem Netflow, som en de facto standard, og det samme sFlow? Jeg vil fremhæve et par vigtige. For det første har Netflow brugerkonfigurerbare felter i modsætning til faste felter i sFlow. Og for det andet, og det er det vigtigste i vores tilfælde, indsamler sFlow den såkaldte samplede telemetri; i modsætning til usamplet Netflow og IPFIX. Hvad er forskellen mellem dem?
Forestil dig, at du beslutter dig for at læse bogen "” mine kolleger Gary McIntyre, Joseph Munitz og Nadem Alfardan (du kan downloade en del af bogen fra linket). Du har tre muligheder for at nå dit mål – læs bogen i sin helhed, skum igennem den, stop på hver 10. eller 20. side, eller prøv at finde en genfortælling af nøglebegreber i en blog eller tjeneste som SmartReading. Så ikke-samplet telemetri er læsningen af hver "side" af netværkstrafik, det vil sige analysen af metadata for hver pakke. Sampled telemetri er en selektiv undersøgelse af trafik i håbet om, at de udvalgte prøver vil være, hvad du har brug for. Afhængigt af kanalhastigheden vil den samplede telemetri sende hver 64., 200., 500., 1000., 2000. eller endda 10000. pakke til analyse.
I forbindelse med informationssikkerhedsovervågning betyder det, at samplet telemetri er velegnet til at detektere DDoS-angreb, scanning, spredning af ondsindet kode, men det kan gå glip af atom- eller multipakkeangreb, som ikke er inkluderet i prøven sendt til analyse. Unswept telemetri har heller ingen sådanne mangler. at bruge rækken af opdagede angreb er meget bredere. Her er en lille liste over hændelser, der kan detekteres ved hjælp af netværkstelemetrianalyseværktøjer.
Selvfølgelig vil nogle open source Netflow-analysatorer ikke tillade dig at gøre dette, da dens hovedopgave er at indsamle telemetri og udføre grundlæggende analyse på det fra et IT-synspunkt. For at identificere IS-trusler baseret på flow er det nødvendigt at udstyre analysatoren med forskellige motorer og algoritmer, som vil identificere cybersikkerhedsproblemer baseret på standard- eller brugerdefinerede Netflow-felter, berige standarddata med eksterne data fra forskellige Threat Intelligence-kilder osv.
Derfor, hvis du har et valg, så stop det på Netflow eller IPFIX. Men selvom dit udstyr kun fungerer med sFlow, ligesom indenlandske producenter, så kan du selv i dette tilfælde drage fordel af det i en sikkerhedsmæssig sammenhæng.
I sommeren 2019 analyserede jeg de muligheder, som russiske netværksjernproducenter har, og alle, undtagen NSG, Polygon og Craftway, annoncerede støtte til sFlow (mindst Zelaks, Natex, Eltex, QTech, Rusteletech).
Det næste spørgsmål, der vil opstå før dig, er, hvor man skal implementere flowsupport af sikkerhedsmæssige årsager? Faktisk er spørgsmålet ikke stillet helt korrekt. På moderne udstyr er der næsten altid understøttelse af flowprotokoller. Derfor vil jeg omformulere spørgsmålet anderledes - hvor er den mest effektive måde at indsamle telemetri set fra et sikkerhedssynspunkt? Svaret vil være ret indlysende - på adgangsniveauet, hvor du vil se 100% af al trafik, hvor du vil have detaljerede oplysninger om værter (MAC, VLAN, interface ID), hvor du kan spore selv P2P-trafik mellem værter, som er afgørende for scanningsdetektering og distribution af skadelig kode. På kerneniveau kan du simpelthen ikke se noget af trafikken, men på perimeterniveau vil du godt se, hvis en fjerdedel af din netværkstrafik. Men hvis du af en eller anden grund har uvedkommende enheder på dit netværk, der tillader angribere at "gå ind og ud" uden om perimeteren, så vil det ikke give dig noget at analysere telemetrien fra det. For at opnå maksimal dækning anbefales det derfor at aktivere telemetriopsamling på adgangsniveauet. Samtidig er det værd at bemærke, at selvom vi taler om virtualisering eller containere, så understøtter moderne virtuelle switche også ofte flow, som giver dig mulighed for at styre trafikken der også.
Men siden jeg rejste emnet, så skal jeg svare på spørgsmålet, hvad nu hvis udstyret, fysisk eller virtuelt, trods alt ikke understøtter flowprotokoller? Eller er det forbudt (f.eks. i industrielle segmenter for at sikre pålidelighed)? Eller forårsager det højt CPU-brug at tænde det (dette sker på ældre hardware)? For at løse dette problem findes der specialiserede virtuelle sensorer (flowsensor), som i det væsentlige er almindelige splittere, der passerer trafik gennem sig selv og udsender den i form af et flow til opsamlingsmodulet. Sandt nok, i dette tilfælde får vi hele bunken af problemer, som vi talte om ovenfor i forhold til pakkefangstværktøjer. Det vil sige, at det er nødvendigt at forstå ikke kun fordelene ved flowanalyseteknologi, men også dens begrænsninger.
Endnu et punkt, som er vigtigt at huske, når man taler om flowanalyseværktøjer. Hvis vi anvender EPS (hændelse per sekund, hændelser per sekund) metrikken i forhold til de sædvanlige metoder til at generere sikkerhedshændelser, så er denne indikator ikke anvendelig til telemetrianalyse; den erstattes af FPS (flow per sekund, flow per sekund). Som i tilfældet med EPS kan det ikke beregnes på forhånd, men det er muligt at estimere det omtrentlige antal tråde, som en bestemt enhed genererer afhængigt af dens opgave. På internettet kan du finde tabeller med omtrentlige værdier for forskellige typer virksomhedsenheder og -betingelser, som giver dig mulighed for at vurdere, hvilken type licenser du har brug for til analyseværktøjer, og hvad vil deres arkitektur være? Faktum er, at IDS-sensoren er begrænset til en vis båndbredde, som den vil "trække ud", og flowkollektoren har sine egne begrænsninger, som skal forstås. Derfor er der i store, geografisk fordelte netværk normalt flere samlere. Da jeg beskrev , Jeg har allerede givet antallet af vores samlere - dem er der 21. Og dette er for et netværk spredt ud over fem kontinenter og tæller omkring en halv million aktive enheder).
Vi bruger vores egen løsning som et Netflow overvågningssystem , som er specifikt fokuseret på at løse sikkerhedsproblemer. Den har mange indbyggede motorer til at detektere unormal, mistænkelig og åbenlyst ondsindet aktivitet, som giver dig mulighed for at opdage en lang række forskellige trusler – fra kryptominering til informationslæk, fra distribution af ondsindet kode til svindel. Som de fleste flowanalysatorer er Stealthwatch bygget på et skema i tre niveauer (generator - opsamler - analysator), men det er suppleret med en række interessante funktioner, der er vigtige i forbindelse med det pågældende materiale. For det første integreres det med pakkeopsamlingsløsninger (såsom Cisco Security Packet Analyzer), som giver dig mulighed for at optage udvalgte netværkssessioner til senere dybdegående undersøgelse og analyse. For det andet, specifikt for at udvide sikkerhedsopgaverne, har vi udviklet en speciel nvzFlow-protokol, der giver dig mulighed for at "udsende" applikationsaktivitet på slutnoder (servere, arbejdsstationer osv.) til telemetri og overføre det til en samler for yderligere analyse. Hvis Stealthwatch i sin originale version fungerer med en hvilken som helst flowprotokol (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) på netværksniveau, så tillader nvzFlow-understøttelse data at blive korreleret også på nodeniveau. forbedrer den overordnede systemeffektivitet og ser flere angreb end konventionelle netværksflowanalysatorer.
Det er klart, at når man taler om Netflow analysesystemer ud fra et sikkerhedssynspunkt, er markedet ikke begrænset til en enkelt løsning fra Cisco. Du kan bruge både kommercielle og gratis eller shareware-løsninger. Det er ret mærkeligt, hvis jeg bruger konkurrenternes løsninger på Cisco-bloggen, så jeg vil sige et par ord om, hvordan netværkstelemetri kan analyseres ved hjælp af to populære, ens navn, men stadig forskellige værktøjer - SiLK og ELK.
SiLK er et sæt værktøjer (System for Internet-Level Knowledge) til trafikanalyse udviklet af det amerikanske CERT/CC, og som i forbindelse med dagens artikel understøtter Netflow (5. og 9., de mest populære versioner), IPFIX og sFlow og brug af forskellige hjælpeprogrammer (rwfilter, rwcount, rwflowpack osv.) til at udføre forskellige operationer på netværkstelemetri for at opdage tegn på uautoriserede handlinger i det. Men der er et par vigtige ting at bemærke. SiLK er et kommandolinjeværktøj og udfører onlineanalyse, alt imens du skriver en kommando af formen (detektering af ICMP-pakker større end 200 bytes):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ikke særlig behageligt. Du kan bruge iSiLK GUI, men det vil ikke gøre dit liv meget nemmere ved kun at løse visualiseringsfunktionen, ikke analytikererstatningen. Og dette er det andet punkt. I modsætning til kommercielle løsninger, som i forvejen har en solid analytisk base, anomalidetektionsalgoritmer svarende til workflow osv., skal du i SiLKs tilfælde gøre alt dette selv, hvilket vil kræve lidt andre kompetencer af dig end at bruge allerede klar -at bruge værktøjskasse. Dette er ikke godt og ikke dårligt - dette er en funktion af næsten ethvert gratis værktøj, der kommer fra det faktum, at du ved, hvad du skal gøre, og det vil kun hjælpe dig med dette (kommercielle værktøjer er mindre afhængige af dets brugeres kompetencer, selvom det også forudsætter, at analytikere forstår i det mindste det grundlæggende i at udføre netværksundersøgelser og overvågning). Men tilbage til SiLK. Analytikerens arbejdscyklus med det er som følger:
- Formulering af en hypotese. Vi skal forstå, hvad vi vil lede efter inden for netværkstelemetri, kende de unikke egenskaber, hvormed vi vil identificere visse anomalier eller trusler.
- Modelbygning. Efter at have formuleret en hypotese, programmerer vi den ved at bruge den samme Python, shell eller andre værktøjer, som ikke er inkluderet i SiLK.
- Afprøvning. Det er tid til at kontrollere rigtigheden af vores hypotese, som bekræftes eller afkræftes ved hjælp af SiLK-værktøjerne, der starter med 'rw', 'set', 'bag'.
- Reel dataanalyse. I kommerciel drift hjælper SiLK os med at identificere noget, og analytikeren skal svare på spørgsmålene "Fundet vi, hvad vi forventede?", "Svarer dette til vores hypotese?", "Hvordan vil det reducere antallet af falske positiver?", "Hvordan forbedrer man anerkendelsesniveauet?" og så videre.
- Forbedring. På den sidste fase forbedrer vi det, der blev gjort tidligere - vi opretter skabeloner, forbedrer og optimerer koden, omformulerer og forfiner hypotesen mv.
Denne cyklus vil være gældende for det samme Cisco Stealthwatch, kun de sidste fem trin automatiseres maksimalt, hvilket reducerer antallet af analytikerfejl og øger effektiviteten af hændelsesdetektion. For eksempel kan du i SiLK berige netværksstatistik med eksterne data om ondsindede IP'er ved hjælp af dine egne scripts, og i Cisco Stealthwatch er dette en indbygget funktion, der straks viser en alarm for dig, hvis der sker interaktion med sortlistede IP-adresser i netværket Trafik.
Hvis du går op i pyramiden af "betalt" flowanalysesoftware, så vil den helt gratis SiLK blive efterfulgt af en shareware ELK, bestående af tre nøglekomponenter - Elasticsearch (indeksering, søgning og analyse af data), Logstash (data input / output) og Kibana (visualisering). I modsætning til SiLK, hvor man selv skal skrive alt, har ELK allerede mange færdige biblioteker/moduler (nogle er betalt, nogle er ikke), der automatiserer analysen af netværkstelemetri. For eksempel giver GeoIP-filteret i Logstash dig mulighed for at binde de overvågede IP-adresser til deres geografiske placering (det samme Stealthwatch har denne indbyggede funktion).
ELK har også et ret stort community, der tilføjer de manglende komponenter til denne overvågningsløsning. For at arbejde med Netflow, IPFIX og sFlow kan du for eksempel bruge modulet hvis du ikke er tilfreds med Logstash Netflow-modulet, der kun understøtter Netflow.
For at give mere effektivitet i at indsamle flow og søge i det, mangler ELK i øjeblikket rig indbygget analyse til at detektere anomalier og trusler i netværkstelemetri. Det vil sige, at efter livscyklussen beskrevet ovenfor, skal du selvstændigt beskrive krænkelsesmodeller og derefter bruge det i kampsystemet (der er ingen indbyggede modeller).
Selvfølgelig er der mere sofistikerede udvidelser til ELK, som allerede indeholder nogle modeller til at detektere anomalier i netværkstelemetri, men sådanne udvidelser koster penge, og spørgsmålet er, om spillet er lyset værd - skriv selv en lignende model, køb dens implementering for dit overvågningsværktøj eller køb en nøglefærdig løsning af klassen Network Traffic Analysis.
Generelt ønsker jeg ikke at gå ind i kontroverser om, hvorvidt det er bedre at bruge penge og købe en færdig løsning til overvågning af uregelmæssigheder og trusler i netværkstelemetri (f.eks. Cisco Stealthwatch) eller finde ud af det på egen hånd og justere de samme SiLK, ELK eller nfdump eller OSU Flow Tools for hver ny trussel (jeg taler om de sidste to af dem sidste gang)? Alle vælger selv, og alle har deres egne motiver for at vælge en af de to muligheder. Jeg ville bare vise, at netværkstelemetri er et meget vigtigt værktøj til at sikre netværkssikkerheden i din interne infrastruktur, og du bør ikke forsømme det, for ikke at tilføje en virksomhed til listen, hvis navn er nævnt i medierne sammen med epiteterne "hacket", "ikke-kompatibel med krav til informationssikkerhed "," tænker ikke på sikkerheden af deres data og kundedata.
Sammenfattende vil jeg gerne liste de vigtigste tips, som du bør følge, når du bygger informationssikkerhedsovervågning af din interne infrastruktur:
- Begræns dig ikke til kun omkredsen! Brug (og vælg) netværksinfrastruktur ikke kun til at overføre trafik fra punkt A til punkt B, men også til at løse cybersikkerhedsproblemer.
- Undersøg de eksisterende informationssikkerhedsovervågningsmekanismer i dit netværksudstyr, og brug dem.
- For intern overvågning skal du foretrække telemetrianalyse - det giver dig mulighed for at opdage op til 80-90% af alle netværksinformationssikkerhedshændelser, mens du gør det, der er umuligt, når du fanger netværkspakker og sparer lagerplads til alle informationssikkerhedshændelser.
- For at overvåge flows, brug Netflow v9 eller IPFIX - de giver mere information i forbindelse med sikkerhed og giver dig mulighed for at overvåge ikke kun IPv4, men også IPv6, MPLS osv.
- Brug en uprøvet flowprotokol - den giver flere oplysninger til at opdage trusler. For eksempel Netflow eller IPFIX.
- Tjek belastningen af dit netværksudstyr - det kan muligvis ikke også håndtere behandlingen af flowprotokollen. Overvej derefter at bruge virtuelle sensorer eller en Netflow Generation Appliance.
- Implementer kontrol i første omgang på adgangsniveau - det vil give dig mulighed for at se 100 % af al trafik.
- Hvis du ikke har noget valg, og du bruger russisk netværksudstyr, så vælg et, der understøtter flowprotokoller eller har SPAN/RSPAN-porte.
- Kombiner indtrængen/angrebsdetektion/forebyggelse ved grænserne og flowanalysesystemer i det interne netværk (inklusive i skyerne).
Med hensyn til det sidste tip, vil jeg gerne give en illustration, som jeg allerede har givet før. Du kan se, at hvis tidligere Cisco IS-tjenesten næsten udelukkende byggede sit IS-overvågningssystem baseret på indtrængendetekteringssystemer og signaturmetoder, står de nu for kun 20 % af hændelserne. Yderligere 20% står for flowanalysesystemer, hvilket tyder på, at disse løsninger ikke er et indfald, men et reelt værktøj i aktiviteterne i informationssikkerhedstjenesterne i en moderne virksomhed. Desuden har du det vigtigste for deres implementering - netværksinfrastrukturen, investeringer i som kan yderligere beskyttes ved at tildele informationssikkerhedsovervågningsfunktioner til netværket.
Jeg har bevidst ikke berørt emnet om at reagere på uregelmæssigheder eller trusler, der er identificeret i netværksstrømme, men jeg mener, at det er klart, at overvågning ikke kun bør slutte med opdagelsen af en trussel. Det skal efterfølges af et svar og helst i automatisk eller automatiseret tilstand. Men dette er et emne for en separat artikel.
Yderligere information:
PS. Hvis det er nemmere for dig at lytte til alt, hvad der er skrevet ovenfor, så kan du se den timelange præsentation, der dannede grundlaget for denne note.
Kilde: www.habr.com