🥇Flow-protokoll som verktyg för säkerhetsövervakning av interna nätverk

När det gäller säkerhetsövervakning av interna företags- eller myndighetsnätverk, så får många en association till informationsläckagekontroll och implementering av DLP-lösningar. Men om man försöker precisera frågan och frågar hur ni upptäcker attacker i det interna nätverket, så blir svaret vanligtvis en hänvisning till intrångsdetekteringssystem (IDS). Det som för 10-20 år sedan var det enda alternativet, blir idag en anomali. Det finns ett mer effektivt, och på vissa sätt det enda möjliga alternativet för övervakning av det interna nätverket – att använda flow-protokoll, som ursprungligen var avsedda för att hitta nätverksproblem (troubleshooting), men som med tiden har utvecklats till ett mycket intressant säkerhetsverktyg. I denna artikel kommer vi att diskutera vilka flow-protokoll som finns, vilka som bäst hjälper att upptäcka nätverksattacker, var det är bäst att implementera flow-övervakning, vad man bör tänka på vid implementeringen av ett sådant system, och till och med hur allt detta kan köras på inhemsk utrustning.

Jag kommer inte att stanna vid frågan "Varför behövs säkerhetsövervakning av den interna infrastrukturen?" Svaret på den frågan verkar väl klart. Men om ni ändå skulle vilja försäkra er om att detta idag är oumbärligt, titta på en kort video som visar hur man på 17 olika sätt kan tränga in i ett företagsnätverk skyddat av en brandvägg. Därför kan vi anta att vi förstår att intern övervakning är nödvändig och det kvarstår bara att förstå hur man kan organisera den.

Jag skulle framhäva tre nyckelkällor för datainsamling för övervakning av infrastrukturen på nätverksnivå:

"rå" trafik som vi fångar upp och skickar för analys till vissa analysystem,
händelser från nätverksenheter genom vilka trafiken passerar,
information om trafiken, erhållen genom ett av flow-protokollen.

Capturing raw traffic är det mest populära alternativet bland säkerhetsexperter, eftersom det historiskt sett är det äldsta. Vanliga nätverkssystem för att upptäcka attacker (det första kommersiella systemet för att upptäcka attacker var NetRanger från företaget Wheel Group, som köptes av Cisco 1998) ägnade sig just åt att fånga paket (och senare även sessioner) där specifika signaturer ("avgörande regler" enligt FSTEC:s terminologi) som signalerade attacker letades efter. Självklart kan man analysera rå trafik inte bara med hjälp av IDS, utan också med andra verktyg (som Wireshark, tcpdump eller NBAR2-funktionaliteten i Cisco IOS), men de brukar sakna den kunskapsbas som skiljer ett säkerhetsverktyg från ett vanligt IT-verktyg.

Så, system för att upptäcka attacker. Den äldsta och mest populära metoden för att upptäcka nätverksattacker, som fungerar ganska bra vid perimetern (oavsett om det är företags-, datacenter- eller segmenteringsperimeter), men som faller kort i moderna switchade och programvarudefinierade nätverk. I ett nätverk byggt på vanliga switchar blir infrastrukturen för sensorer som upptäcker attacker för stor — du måste installera en sensor för varje anslutning till en nod vars attacker du vill övervaka. Självklart skulle varje tillverkare vara glad att sälja dig hundratals och tusentals sensorer, men jag tror att din budget inte klarar av sådana utgifter. Jag kan säga att även hos Cisco (där vi utvecklar NGIPS) har vi inte kunnat åstadkomma detta, även om det skulle se ut som prissättningen inte borde vara en fråga för oss — det är ju vår egen lösning. Dessutom uppstår frågan, hur ska sensorn anslutas i detta arrangemang? I ett avbrott? Och om själva sensorn går sönder? Kräva att en bypass-modul ska finnas i sensorn? Använda tap-splittrar? Allt detta gör lösningen dyrare och omöjliggör den för företag av alla storlekar.

Du kan försöka "hänga" sensorn på SPAN/RSPAN/ERSPAN-porten och rikta trafik från nödvändiga portar på switchen till den. Detta alternativ delvis avhjälper problemet som beskrevs i föregående stycke, men ställer ett annat - SPAN-porten kan inte ta emot all trafik som riktas till den - den har inte tillräcklig kapacitet. Du blir tvungen att offra något. Antingen lämna vissa noder utan övervakning (då måste du först prioritera dem) eller rikta inte all trafik från noden, utan endast viss typ. I alla fall riskerar vi att missa vissa attacker. Dessutom kan SPAN-porten vara upptagen av andra behov. I slutändan måste vi ompröva den befintliga nätverksarkitekturen och eventuellt göra justeringar för att maximalt täcka ditt nätverk med det antal sensorer du har (och samordna detta med IT).

Och om ditt nätverk använder asymmetriska rutter? Och om du har implementerat eller planerar att implementera SDN? Och om du behöver övervaka virtualiserade maskiner eller containrar vars trafik överhuvudtaget inte når den fysiska switchen? Dessa frågor ogillas av tillverkare av traditionella IDS, eftersom de inte vet hur de ska svara på dem. Kanske kommer de att försöka intala dig att alla dessa trendiga teknologier är en hype och att du inte behöver dem. Kanske kommer de att prata om behovet av att börja i liten skala. Eller så kanske de säger att du måste installera en kraftfull maskin i nätverkscentret och rikta all trafik dit med hjälp av lastbalanserare. Vilken variant de än föreslår, måste du själv tydligt förstå hur väl den passar för dig. Och först därefter fatta beslut om tillvägagångssättet för övervakning av nätverksinfrastrukturens informationssäkerhet. Återvände till paketfångst, jag vill säga att denna metod fortfarande är mycket populär och viktig, men dess huvudsakliga syfte är gränskontroll; gränser mellan din organisation och internet, gränser mellan datacentret och resten av nätverket, gränser mellan automatiserade styrsystem och företagssegmentet. På dessa ställen har klassiska IDS/IPS fortfarande rätt att existera och klarar uppgiften bra.

Låt oss gå vidare till det andra alternativet. Analysen av händelser som kommer från nätverksenheter kan också användas för att upptäcka attacker, men inte som en primär mekanism, eftersom det bara kan detektera en liten klass av intrång. Dessutom är det något reaktivt — attacken måste först inträffa, och sedan måste den registreras av nätverksenheten, som på något sätt kommer att signalera ett problem med informationssäkerheten. Det finns flera sätt att göra detta. Det kan vara syslog, RMON eller SNMP. De två sista protokollen för nätverksövervakning tillämpas inom ramen för informationssäkerhet endast om vi behöver upptäcka en DoS-attack mot själva nätverksutrustningen, eftersom vi med RMON och SNMP kan, till exempel, övervaka belastningen på enhetens centrala processor eller dess gränssnitt. Detta är en av de mest "kostnadseffektiva" (syslog eller SNMP finns hos alla), men också den mest ineffektiva metoden för att övervaka informationssäkerheten i den interna infrastrukturen — många attacker är helt enkelt dolda för den. Självklart bör man inte försumma detta och analysen av syslog hjälper dig att i tid identifiera förändringar i konfigurationen av själva enheten, dess kompromiss, men för att upptäcka attacker i hela nätverket är den inte särskilt lämplig.

Det tredje alternativet är analys av trafikinformation som passerar genom enheten, som stöder en av flera flow-protokoll. I detta fall, oavsett protokoll, består infrastrukturen för arbete med flöden alltid av tre komponenter:

Generering eller export av flöde. Denna roll tilldelas vanligtvis till en router, switch eller annan nätverksenhet som, genom att släppa genom sig nätverkstrafik, möjliggör att extrahera nyckelparametrar som sedan överförs till insamlingsmodulen. Till exempel, hos Cisco stöds protokollet Netflow inte bara på routrar och switchar, inklusive virtuella och industriella, utan också på trådlösa kontroller, brandväggar och till och med servrar.
Insamling av flöde. Med tanke på att det i moderna nätverk vanligtvis finns mer än en nätverksenhet, uppstår behovet av att samla in och konsolidera flöden, vilket löses med hjälp av så kallade samlare som bearbetar de mottagna flödena och sedan överför dem för analys.
Flow-analys. Analysatorn tar på sig den huvudsakliga kognitiva uppgiften och tillämpar olika algoritmer på flöden för att dra slutsatser. Till exempel kan en sådan analysator inom IT-funktionen identifiera flaskhalsar i nätverket eller analysera trafikbelastningsprofilen för vidare optimering av nätverket. För informationssäkerhet kan en sådan analysator upptäcka dataläckage, spridning av skadlig kod eller DoS-attacker.

Det är inte rimligt att tänka att en sådan trelagersarkitektur är för komplicerad — alla andra alternativ (med undantag för vissa nätverksmonitoreringssystem som använder SNMP och RMON) fungerar också enligt denna. Vi har en datagenerator för analys, vilken utgörs av en nätverksenhet eller en separat sensor. Vi har ett system för insamling av larm och ett system för hantering av hela övervakningsinfrastrukturen. De senaste två komponenterna kan slås samman inom en enhet, men i större nätverk är de vanligtvis spridda över minst två enheter för att säkerställa skalbarhet och tillförlitlighet.

Till skillnad från paketanalys, som baseras på att studera rubriken och kroppen av varje paket och de sessioner som dessa består av, bygger flödesanalys på att samla in metadata om nätverkstrafik. När, hur mycket, varifrån och vart, hur... dessa frågor besvaras av nätverks telemetrianalys med hjälp av olika flow-protokoll. De användes ursprungligen för att analysera statistik och identifiera IT-problem i nätverket, men med tiden, i takt med att analysmekanismer utvecklades, blev det möjligt att tillämpa dem också på denna telemetri för säkerhetsändamål. Här bör det återigen understrykas att flödesanalys inte ersätter eller utesluter paketupptagning. Varje metod har sitt eget användningsområde. Men i kontexten av denna artikel passar flödesanalys bäst för övervakning av intern infrastruktur. Ni har nätverksenheter (och det spelar ingen roll om de arbetar i en mjukvarudefinierad paradigm eller enligt statiska regler) som attacken inte kan kringgå. En klassisk IDS-sensor kan attacken undvika, men en nätverksenhet som stöder flow-protokoll kan inte. Detta är fördelen med denna metod.

Å andra sidan, om du behöver bevis för brottsbekämpande myndigheter eller din egen incidentutredningsgrupp, kan du inte undvika paketfångst — nättelemetri är inte en kopia av den trafik som kan användas vid insamling av bevis; det behövs för snabb upptäckte och beslut inom informationssäkerhet. Genom att använda telemetrianalys kan du "spela in" inte hela nätverkstrafiken (om det nu är så, så sysslar Cisco och datacenter med det :-), utan bara den som är involverad i attacken. Verktyg för telemetrianalys kompletterar traditionella paketfångstmetoder väl, vilket ger ett team möjlighet till selektiv fångst och lagring. Annars kommer du att behöva ha en kolossal lagringsinfrastruktur.

Låt oss tänka oss ett nätverk som arbetar med en hastighet av 250 Mbit/s. Om du vill spara hela den volymen, kommer du att behöva 31 Mb lagring för en sekunds trafiköverföring, 1,8 Gb för en minut, 108 Gb för en timme, och 2,6 Tb för ett dygn. För lagring av dagsdata från ett nätverk med en bandbredd på 10 Gbit/s behöver du 108 Tb lagring. Och vissa regleringsmyndigheter kräver ju att data om säkerhet ska lagras i åratal... Inspelning "vid behov", som du får hjälp med att genomföra genom strömanalys, hjälper dig att minska dessa värden med flera ordningar. För övrigt, när det kommer till förhållandet mellan mängden inspelad data från nättelemetri och fullständig datafångst, är det ungefär 1 till 500. För ovanstående värden kommer lagringen av den fullständiga avkodningen av all daglig trafik att uppgå till 5 respektive 216 Gb (det kan till och med spelas in på ett vanligt USB-minne).

Om metoderna för att analysera råa nätverksdata är nästan desamma mellan olika leverantörer, är situationen en annan vid analys av flöden. Det finns flera alternativ för flow-protokoll, vars skillnader är viktiga att känna till särskilt i säkerhetskontexten. Det mest populära är Netflow-protokollet, utvecklat av Cisco. Det finns flera versioner av detta protokoll, som skiljer sig åt i sina funktioner och mängden information som registreras om trafiken. Den nuvarande versionen är nionde (Netflow v9), på vilken den industriella standarden Netflow v10, även känd som IPFIX, har utvecklats. Idag stöder de flesta nätverksleverantörer antingen Netflow eller IPFIX i sin utrustning. Men det finns även flera andra alternativ för flow-protokoll – sFlow, jFlow, cFlow, rFlow, NetStream med mera, där sFlow är det mest populära. Det stöds oftast av inhemska tillverkare av nätverksutrustning på grund av dess enkelhet vid implementering. Vad är de viktigaste skillnaderna mellan Netflow, som blivit en de facto-standard, och sFlow? Några centrala punkter skulle jag nämna. För det första har Netflow användardefinierade fält, till skillnad från de fasta fälten i sFlow. För det andra, och detta är det mest avgörande i vårt fall, samlar sFlow så kallad samplad telemetri, till skillnad från osamplad telemetri hos Netflow och IPFIX. Vad är då skillnaden mellan dem?

Föreställ dig att du har bestämt dig för att läsa boken “Security Operations Center: Building, Operating, and Maintaining your SOC” av mina kollegor – Gary McIntyre, Joseph Muniz och Nadeem alfar dan (via länken kan du ladda ner en del av boken). Du har tre alternativ för att uppnå ditt mål – läsa boken i sin helhet, snabbt ögna igenom den med stopp på var tionde eller tjugonde sida, eller försöka hitta en sammanfattning av de viktigaste koncepten på någon blogg eller tjänst som SmartReading. Så osamplad telemetri handlar om att läsa varje “sida” av nätverkstrafik, det vill säga att analysera metadata för varje paket. Samplad telemetri innebär att endast en del av trafiken studeras i hopp om att det i de utvalda urvalen finns det du behöver. Beroende på hastigheten på länken kommer samplad telemetri att ge var 64:e, 200:e, 500:e, 1000:e, 2000:e eller till och med 10000:e paket för analys.

I kontexten av övervakning av IT-säkerhet innebär detta att provtagningsbaserad telemetri är väl lämpad för att upptäcka DDoS-attacker, skanning, spridning av skadlig kod, men kan missa atomära eller flerpaketsattacker som inte kommit med i provet som skickades för analys. Den osamplingbaserade telemetrin har inte dessa nackdelar, och med dess hjälp är spektrumet av upptäckta attacker mycket bredare. Här är en kort lista över händelser som kan upptäckas med hjälp av verktyg för analys av nätverks telemetri.

Självklart kommer ingen open source Netflow-analysator att tillåta detta, eftersom dess huvudsakliga uppgift är att samla in telemetri och genomföra en grundläggande analys ur IT-perspektiv. För att upptäcka IT-säkerhetshot baserat på flow måste analysatorn utrustas med olika motorer och algoritmer som ska identifiera cybersäkerhetsproblem baserat på standard- eller användardefinierade fält i Netflow, berika standarddata med externa uppgifter från olika källor till Threat Intelligence, osv.

Därför, om du har valet, bör du välja Netflow eller IPFIX. Men även om din utrustning bara arbetar med sFlow, som hos inhemska producenter, kan du även i detta fall dra nytta av det ur säkerhetsperspektiv.

Under sommaren 2019 gjorde jag en analys av möjligheterna som finns hos ryska tillverkare av nätverksutrustning och alla, med undantag för NSG, Poligon och Kraftvey, angav att de stödjer sFlow (minst Zhelax, Natex, Eltex, QTech, Rusteltec).

Den nästa frågan som du kommer att ställa dig är var stöd för flow ska implementeras för säkerhetsändamål? Faktum är att frågan är lite felställd. På modern utrustning finns stöd för flowprotokoll nästan alltid. Därför skulle jag omformulera frågan till var det är mest effektivt att samla telemetri ur säkerhetssynpunkt? Svaret är ganska uppenbart – på åtkomstnivå, där du ser 100 % av all trafik, där du har detaljerad information om värdar (MAC, VLAN, gränssnitts-ID), där du till och med kan spåra P2P-trafik mellan värdar, vilket är kritiskt för att upptäcka skanning och spridning av skadlig kod. På kärnnivå kan du helt enkelt missa en del av trafiken, och på perimeter kan du max se en fjärdedel av all din nätverkstrafik. Men om det av någon anledning har dykt upp obehöriga enheter i ditt nätverk som tillåter angripare att "komma in och ut" utan att gå via perimetern, kommer analys av telemetrin därifrån inte att ge dig något. Därför rekommenderas det för maximal täckning att aktivera insamlingen av telemetri just på åtkomstnivå. Det är värt att nämna att även om vi pratar om virtualisering eller containrar så finns det ofta stöd för flow i moderna virtuella switchar, vilket möjliggör trafikövervakning där också.

Men eftersom jag tog upp ämnet, måste jag svara på frågan: vad händer om utrustningen, antingen fysisk eller virtuell, ändå inte stöder flowprotokoll? Eller om dess aktivering är förbjuden (t.ex. i industriella segment för att säkerställa tillförlitlighet)? Eller om dess aktivering leder till hög belastning på centralprocessorn (vilket kan hända på gammal utrustning)? För att lösa detta problem finns det specialiserade virtuella sensorer (flow sensor) som i grunden är vanliga grenare som passerar trafik genom sig och sänder den i form av flow till insamlingsmodulen. Men i det här fallet får vi hela hög med problem som vi tidigare diskuterat i förhållande till paketfångstverktyg. Det vill säga, man måste förstå inte bara fördelarna med flödesanalystekniken, utan även dess begränsningar.

En annan aspekt att komma ihåg när man talar om analyssystem för flöden är att, om vi för vanliga säkerhetshändelsegeneratorer använder måttet EPS (event per second, händelser per sekund), så är detta mått inte applicerbart på analys av telemetri; det ersätts av FPS (flow per second, flöden per sekund). Precis som med EPS kan man inte beräkna detta i förväg, men man kan uppskatta det ungefärliga antalet flöden som en viss enhet genererar beroende på dess uppgift. På internet kan du hitta tabeller med ungefärliga värden för olika typer av företagsenheter och villkor som gör att du kan uppskatta vilka licenser som behövs för analysverktyg och vilken arkitektur som kommer att vara nödvändig. Faktum är att IDS-sensorn är begränsad av en viss bandbredd som den kan "hantera", och flödeskollektorn har också sina begränsningar som man måste förstå. Därför har stora, geografiskt distribuerade nätverk vanligtvis flera kollektorer. När jag beskrev hur nätverket inom Cisco övervakas, nämnde jag redan antalet av våra kollektorer – de är 21. Och detta för ett nätverk som är spritt över fem kontinenten och har omkring en halv miljon aktiva enheter).

Som övervakningssystem för Netflow använder vi vår egen lösning Cisco Stealthwatch, vilket är speciellt utformat för att lösa säkerhetsproblem. Det har många inbyggda motorer för att upptäcka anomal, misstänksam och uppenbart skadlig aktivitet, vilket möjliggör detektion av ett brett spektrum av olika hot — från kryptovaluta-mining till informationsläckor, från spridning av skadlig kod till bedrägeri. Precis som de flesta strömanalysatorer är Stealthwatch uppbyggd enligt ett tre-nivå-schema (generator — insamlare — analysator), men den har även flera intressanta funktioner som är viktiga i detta sammanhang. För det första integreras det med paketfångstlösningar (t.ex. Cisco Security Packet Analyzer), vilket möjliggör inspelning av utvalda nätverkssessioner för djupare utredning och analys. För det andra, för att utvidga säkerhetsuppgifterna, har vi utvecklat ett speciellt protokoll, nvzFlow, som gör det möjligt att “sända” aktivitet från applikationer på ändpunkter (servrar, arbetsstationer och liknande) till telemetri och överföra det till insamlaren för vidare analys. Om Stealthwatch i sin ursprungliga version fungerar med vilket flow-protokoll som helst (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) på nätverksnivå, möjliggör stödet för nvzFlow korrelation av data även på nodnivå, vilket därmed ökar effektiviteten för hela systemet och ger en bättre översikt över attacker än vanliga nätverksströmanalysatorer.

Det är uppenbart att när man pratar om Netflow-analysystem ur säkerhetssynpunkt, så är marknaden inte begränsad till enbart Cisco-lösningen. Du kan använda både kommersiella och gratis eller delegerat gratis alternativ. Det är lite konstigt om jag i Cisco-bloggen skulle nämna exempel på konkurrenters lösningar, så jag ska säga några ord om hur nätverks telemetri kan analyseras med hjälp av två populära, liknande namngivna, men ändå olika verktyg — SiLK och ELK.

SiLK — ett verktyg (System for Internet-Level Knowledge) för trafikanalys, utvecklat av den amerikanska CERT/CC, som i kontexten av dagens artikel stöder Netflow (versioner 5 och 9, de mest populära), IPFIX och sFlow. Genom olika verktyg (rwfilter, rwcount, rwflowpack, med flera) kan det utföra olika operationer på nättelemetri för att upptäcka tecken på obehöriga aktiviteter. Men det finns ett par viktiga punkter att notera. SiLK är ett kommandoradsverktyg, och för att utföra operativ analys måste kommandon ges i formatet (detektering av ICMP-paket större än 200 byte):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

det är inte särskilt bekvämt. Du kan använda det grafiska gränssnittet iSiLK, men det kommer inte att göra ditt liv lättare, då det endast fungerar som visualisering och inte som en ersättning för analytikern. Och det är den andra punkten. Till skillnad från kommersiella lösningar som redan innehåller en solid analytisk bas, algoritmer för att upptäcka avvikelser och korresponderande arbetsflöden, måste du i fallet med SiLK själv gå igenom hela processen, vilket kräver lite andra kompetenser än vad som behövs för att använda ett redan klart verktyg. Detta är varken bra eller dåligt — det är en egenskap hos nästan alla gratisverktyg, som förutsätter att du vet vad du gör, medan de endast hjälper dig med det (kommersiella verktyg är mindre beroende av användarnas kompetens, även om de också antar att analytikerna åtminstone förstår grunderna i nätverksundersökningar och övervakning). Men låt oss återgå till SiLK. En analytikers arbetscykel med det ser ut på följande sätt:

Formulering av hypotesen. Vi måste förstå vad vi ska leta efter inom nättelemetrin, veta de unika attributen genom vilka vi ska identifiera olika avvikelser eller hot.
Bygga modellen. Efter att ha formulerat hypotesen programmerar vi den med hjälp av Python, shell, eller andra verktyg som inte ingår i SiLK.
Testning. Nu är det dags att kontrollera om vår hypotes är korrekt, vilken bekräftas eller förkastas med hjälp av SiLK-verktyg som börjar med 'rw', 'set', 'bag'.
Analys av verkliga data. I industriell användning hjälper SiLK oss att identifiera något, och analytikern måste svara på frågorna "Har vi funnit det vi förväntade oss?", "Stämmer detta med vår hypotes?", "Hur kan vi minska antalet falska positiva?", "Hur kan vi förbättra igenkänningen?" och så vidare.
Förbättring. I det slutliga steget förbättrar vi det som tidigare har skapats – vi skapar mallar, förbättrar och optimerar koden, omformulerar och preciserar hypotesen m.m.

Denna cykel kommer även att tillämpas på Cisco Stealthwatch, men den senare automatiserar dessa fem steg maximalt, vilket minskar analytikerns fel och ökar snabbheten i incidentupptäckten. Till exempel kan du i SiLK berika nätverksstatistiken med externa data om skadliga IP-adresser med hjälp av självskrivna skript, medan det i Cisco Stealthwatch är en inbyggd funktion som omedelbart visar en varningssignal om det i nätverkstrafiken förekommer interaktion med IP-adresser från svartlistan.

Om man går högre upp i "betalningspyramiden" för programvara för flowanalys kommer SiLK, som är helt gratis, att följas av det villkorligt gratis ELK, som består av tre nyckelkomponenter – Elasticsearch (indexering, sökning och datanalys), Logstash (data in/ut) och Kibana (visualisering). Till skillnad från SiLK, där allt måste skrivas själv, har ELK redan många färdiga bibliotek/moduler (vissa betalda, vissa gratis) som automatiserar analysen av nätverkstelemetri. Till exempel tillåter GeoIP-filtret i Logstash att koppla de observerade IP-adresserna till deras geografiska plats (vilket i Stealthwatch är en inbyggd funktion).

ELK har också en ganska stor gemenskap som skriver till de saknade komponenterna för denna övervakningslösning. Till exempel, för att arbeta med Netflow, IPFIX och sFlow kan du använda modulen elastiflow, om du inte är nöjd med Logstash Netflow-modulen som endast stöder Netflow.

Genom att ge mer snabbhet för insamling av flow och sökning i det, saknar ELK för närvarande rik inbyggd analys för upptäckten av anomalier och hot inom nätverkstelemetri. Det innebär att, enligt den ovan beskrivna livscykeln, att du själv måste definiera avvikelsemodeller och sedan använda dem i det skarpa systemet (det finns ingen inbyggd modeller där).

Det finns naturligtvis mer avancerade tillägg för ELK, som redan har vissa modeller för att upptäcka avvikelser i nätverkstelemetri, men sådana tillägg kostar pengar och då handlar det om huruvida det är värt att skriva en liknande modell själv, köpa dess implementation för sitt övervakningsverktyg eller köpa en färdig lösning inom Network Traffic Analysis.

Jag vill överhuvudtaget inte gå in på debatten om det är bättre att spendera pengar på att köpa en färdig lösning för övervakning av avvikelser och hot i nätverkstelemetri (till exempel Cisco Stealthwatch) eller att förstå det själv och justera SiLK, ELK eller nfdump eller OSU Flow Tools för varje nytt hot (jag pratar om de två senare?). om Var och en väljer för sig själv och alla har sina skäl att välja något av de två alternativen. Jag ville bara visa att nätverkstelemetri är ett mycket viktigt verktyg för att säkerställa nätverkssäkerheten i sin interna infrastruktur, och man bör inte bortse från det för att undvika att hamna på listan över företag vars namn nämns i media tillsammans med epitet som 'hackade', 'som inte följde säkerhetskraven', 'som inte tänker på säkerheten för sina egna och sina kunders data'.

För att sammanfatta vill jag lista de nyckeltips som man bör följa när man bygger övervakning av IT-säkerheten i sin interna infrastruktur:

Begränsa dig inte bara till perimeterna! Använd (och välj) ditt nätverksinfrastruktur inte bara för att överföra trafik från punkt A till punkt B, utan också för att hantera frågor kring cybersäkerhet.
Studera de existerande mekanismerna för övervakning av IT-säkerhet i din nätverksutrustning och implementera dem.
För intern övervakning, föredra att analysera telemetri — det gör det möjligt att upptäcka upp till 80-90% av alla nätverksincidenter relaterade till IT-säkerhet, vilket gör det som är omöjligt vid fångst av nätverkspaket och sparar lagringsutrymme för alla IT-säkerhetshändelser.
För övervakning av flöden, använd Netflow v9 eller IPFIX – de ger mer information i säkerhetskontext och möjliggör övervakning av inte bara IPv4, utan också IPv6, MPLS etc.
Använd ett osampling flow-protokoll – det ger mer information för att upptäcka hot. Till exempel, Netflow eller IPFIX.
Kontrollera belastningen på din nätverksutrustning – det kan hända att den inte klarar av att hantera flow-protokollet också. Överväg i så fall att använda virtuella sensorer eller Netflow Generation Appliance.
Implementera kontroll i första hand på åtkomstnivå – det ger dig möjlighet att se 100% av all trafik.
Om du inte har något val och använder rysk nätverksutrustning, välj den som stödjer flow-protokoll eller har SPAN/RSPAN-portar.
Kombinera system för upptäckta/preventiva intrång/attacker vid gränserna och system för flödesanalys i det interna nätverket (inklusive i molnen).

När det kommer till det sista rådet vill jag gärna ta upp en illustration som jag redan nämnt tidigare. Ni ser att om den tidigare säkerhetstjänsten från Cisco nästan helt byggde sitt övervakningssystem på system för intrångsdetektering och signaturmetoder, så står de nu för endast 20% av incidenterna. Ytterligare 20% går till flödesanalysystem, vilket visar att dessa lösningar inte är en lyx, utan ett verkligt verktyg i verksamheten för moderna säkerhetstjänster. Särskilt eftersom ni har det mest avgörande för deras implementering – nätverksinfrastrukturen, vars investeringar kan skyddas ytterligare genom att även tilldela nätverket funktioner för säkerhetsövervakning.

Jag avstod medvetet från att beröra ämnet för hur man reagerar på upptäckta anomalier eller hot i nätverksflöden, men jag tror det är tydligt att övervakning inte bör avslutas vid att bara upptäcka hot. Det ska följas av reaktion, helst automatiskt eller i automatiserad form. Men det är ett ämne för ett annat material.

Ytterligare information:

PS. Om det är lättare för dig att ta till dig allt som skrivits ovan genom att lyssna, kan du titta på en timmes presentation som låg till grund för denna anteckning.

Källa: habr.com

Flow-protokoll som ett verktyg för att övervaka säkerheten i det interna nätverket