{"id":37437,"date":"2019-10-31T22:17:38","date_gmt":"2019-10-31T19:17:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\/"},"modified":"2019-10-31T22:17:38","modified_gmt":"2019-10-31T19:17:38","slug":"flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","title":{"rendered":"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>N\u00e5r det kommer til at overv\u00e5ge sikkerheden i et internt virksomheds- eller myndighedsnetv\u00e6rk, t\u00e6nker mange p\u00e5 kontrol af informationsl\u00e6ksager og implementering af DLP-l\u00f8sninger. Men hvis vi fors\u00f8ger at pr\u00e6cisere sp\u00f8rgsm\u00e5let og sp\u00f8rge, hvordan I opdager angreb i det interne netv\u00e6rk, vil svaret normalt v\u00e6re n\u00e6vnelsen af indtr\u00e6ngningsdetekteringssystemer (intrusion detection systems, IDS). Og det, der for 10-20 \u00e5r siden var den eneste mulighed, er i dag blevet en anakronisme. Der findes en mere effektiv, og visse steder endda den eneste mulige metode til at overv\u00e5ge det interne netv\u00e6rk \u2014 at bruge flow-protokoller, der oprindeligt var beregnet til at finde netv\u00e6rksproblemer (troubleshooting), men som med tiden har udviklet sig til et meget interessant sikkerhedsinstrument. I denne artikel vil vi tale om, hvilke flow-protokoller der findes, og hvilke der bedst hj\u00e6lper med at opdage netv\u00e6rksangreb, hvor monitorering af flow er bedst at implementere, hvad man skal v\u00e6re opm\u00e6rksom p\u00e5 ved ops\u00e6tning af et s\u00e5dant system, og hvordan man 'starter' det hele p\u00e5 indenlandsk udstyr.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Jeg vil ikke stoppe op ved sp\u00f8rgsm\u00e5let 'Hvorfor er overv\u00e5gning af den interne infrastruktur n\u00f8dvendig?' Svaret p\u00e5 det er tilsyneladende klart. Men hvis du stadig gerne vil sikre dig, at vi i dag ikke kan undv\u00e6re det, <noindex><a rel=\"nofollow\" href=\"https:\/\/gblogs.cisco.com\/ru\/17attackvectors\/\">se<\/a><\/noindex> en kort video, der forklarer, hvordan man kan tr\u00e6nge ind i et corporate netv\u00e6rk, der er beskyttet af en firewall, p\u00e5 17 forskellige m\u00e5der. S\u00e5 lad os antage, at vi forst\u00e5r, at intern overv\u00e5gning er n\u00f8dvendig, og nu skal vi blot finde ud af, hvordan vi kan organisere den.<\/p>\n<p>Jeg vil fremh\u00e6ve tre n\u00f8glekilder til data til overv\u00e5gning af infrastrukturen p\u00e5 netv\u00e6rksniveau:<\/p>\n<ul>\n<li>den 'r\u00e5' trafik, som vi opfanger og sender til analyse af visse analyse-systemer,<\/li>\n<li>nationale enheders h\u00e6ndelser, som trafikken passerer gennem,<\/li>\n<li>information om trafikken, der modtages via en af flow-protokollerne.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/09c7087593661d5b159ecc9e9ab39d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIndfangning af r\u00e5 trafik er den mest popul\u00e6re metode blandt sikkerhedseksperter, da den historisk set er den, der f\u00f8rst blev udviklet. De f\u00f8rste kommercielle netv\u00e6rksoverv\u00e5gningssystemer (den f\u00f8rste var NetRanger fra Wheel Group, k\u00f8bt af Cisco i 1998) besk\u00e6ftigede sig netop med at indfange pakker (og senere sessioner), hvor der blev s\u00f8gt efter specifikke signaturer (\u201dafg\u00f8rende regler\u201d i FSTEK-terminologi), der indikerede angreb. Selvf\u00f8lgelig kan r\u00e5 trafik analyseres ikke kun med IDS, men ogs\u00e5 ved hj\u00e6lp af andre v\u00e6rkt\u00f8jer (f.eks. Wireshark, tcpdump eller funktionaliteten NBAR2 i Cisco IOS), men disse har typisk ikke den vidensbase, der adskiller et informationssikkerhedsv\u00e6rkt\u00f8j fra et almindeligt IT-v\u00e6rkt\u00f8j.<\/p>\n<p>S\u00e5 lad os tale om angrebsdetekteringssystemer. Den \u00e6ldste og mest popul\u00e6re metode til detektion af netv\u00e6rksangreb, som g\u00f8r det ret godt p\u00e5 perimeteren (uanset hvilken - virksomhed, datacenter, segment osv.), men som halter bagud i moderne v\u00e6ksel- og softwaredefinerede netv\u00e6rk. I tilf\u00e6lde af et netv\u00e6rk bygget p\u00e5 standard switcher, bliver infrastrukturen af sensorer til angrebsdetektion for stor - du bliver n\u00f8dt til at installere en sensor p\u00e5 hver forbindelse til en node, hvis angreb du \u00f8nsker at overv\u00e5ge. Enhver fabrikant vil selvf\u00f8lgelig v\u00e6re glad for at s\u00e6lge dig hundreder og tusinder af sensorer, men jeg tror, at dit budget ikke kan klare s\u00e5danne udgifter. Jeg kan sige, at selv hos Cisco (hvor vi udvikler NGIPS) har vi ikke v\u00e6ret i stand til at g\u00f8re det, selvom det umiddelbart synes, at prisen ikke skulle v\u00e6re et problem \u2014 det er jo vores eget produkt. Derudover opst\u00e5r sp\u00f8rgsm\u00e5let, hvordan man skal tilslutte sensoren i en s\u00e5dan ops\u00e6tning? I brud? Hvad hvis selve sensoren g\u00e5r i stykker? Skal der v\u00e6re en bypass-modul i sensoren? Bruge tap-splittere? Alt dette \u00f8ger omkostningerne og g\u00f8r det uoverskueligt for virksomheder af enhver st\u00f8rrelse.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/4763c13237dbe9ffa38d62075939ffba.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDu kan fors\u00f8ge at \"h\u00e6fte\" sensoren til en SPAN\/RSPAN\/ERSPAN-port og dirigere trafik fra de n\u00f8dvendige porte p\u00e5 switchen til den. Denne l\u00f8sning l\u00f8ser delvist problemet beskrevet i det forrige afsnit, men skaber et andet \u2014 SPAN-porten kan ikke acceptere al den trafik, der dirigeres til den \u2014 den har ikke nok b\u00e5ndbredde. Du m\u00e5 ofre noget. Enten skal nogle noder v\u00e6re uden overv\u00e5gning (i s\u00e5 fald skal du f\u00f8rst prioritere dem), eller ogs\u00e5 skal du kun dirigere en bestemt type trafik fra noden og ikke al trafik. Uanset hvad kan vi misse nogle angreb. Desuden kan SPAN-porten v\u00e6re optaget til andre form\u00e5l. I sidste ende m\u00e5 vi genoverveje den eksisterende netv\u00e6rks-topologi og muligvis \u00e6ndre den for at maksimere d\u00e6kningen af dit netv\u00e6rk med det antal sensorer, du har (og koordinere det med IT).<\/p>\n<p>Men hvad hvis dit netv\u00e6rk bruger asymmetrisk routing? Hvad hvis du har implementeret eller planl\u00e6gger at implementere SDN? Hvad hvis du skal overv\u00e5ge virtualiserede maskiner eller containere, hvis trafik slet ikke n\u00e5r den fysiske switch? Disse sp\u00f8rgsm\u00e5l er producenterne af traditionelle IDS mindre glade for, fordi de ikke ved, hvordan de skal svare p\u00e5 dem. M\u00e5ske vil de fors\u00f8ge at overbevise dig om, at alle disse trendy teknologier er hype, og at du ikke har brug for dem. M\u00e5ske vil de tale om n\u00f8dvendigheden af at starte sm\u00e5t. Eller m\u00e5ske vil de sige, at du skal s\u00e6tte en kraftig maskine i midten af netv\u00e6rket og dirigere al trafikken til den ved hj\u00e6lp af load balancere. Uanset hvilket forslag du f\u00e5r, er det vigtigt, at du selv tydeligt forst\u00e5r, hvor godt det passer til dine behov. Og f\u00f8rst derefter tr\u00e6ffe beslutninger om, hvilken tilgang du skal v\u00e6lge til overv\u00e5gning af IT-sikkerheden i dit netv\u00e6rksinfrastruktur. N\u00e5r det g\u00e6lder pakkeoptagelse, vil jeg sige, at denne metode stadig er meget popul\u00e6r og vigtig, men dens prim\u00e6re form\u00e5l er gr\u00e6nsekontrol; gr\u00e6nserne mellem din organisation og Internettet, gr\u00e6nserne mellem datacenteret og resten af netv\u00e6rket, gr\u00e6nserne mellem automatisk kontrolsystem og det virksomhedsm\u00e6ssige segment. I disse omr\u00e5der har klassiske IDS\/IPS stadig en berettigelse og klarer sig godt med de opgaver, de f\u00e5r.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/7a5898e0aa9e3e9275dda3e2c7b75c5c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLad os g\u00e5 videre til den anden mulighed. Analyse af h\u00e6ndelser, der kommer fra netv\u00e6rksudstyr, kan ogs\u00e5 bruges til angrebsdetektering, men ikke som den prim\u00e6re mekanisme, da den kun kan detektere en lille klasse indbrud. Desuden har den en vis reaktivitet - et angreb skal f\u00f8rst finde sted, derefter skal det registreres af netv\u00e6rksudstyret, som p\u00e5 en eller anden m\u00e5de vil signalere om problemet med informationssikkerhed. Der er flere metoder til dette. Det kan v\u00e6re syslog, RMON eller SNMP. Sidstn\u00e6vnte to protokoller til netv\u00e6rksoverv\u00e5gning i forbindelse med informationssikkerhed anvendes kun, n\u00e5r vi har brug for at opdage en DoS-angreb p\u00e5 selve netv\u00e6rksudstyret, da RMON og SNMP kan bruges til at overv\u00e5ge belastningen p\u00e5 enhedens centrale processor eller dens interfaces. Dette er en af de mest \u201comkostningseffektive\u201d (syslog eller SNMP er tilg\u00e6ngelig for alle), men ogs\u00e5 den mest ineffektive metode til overv\u00e5gning af informationssikkerhed i den interne infrastruktur - mange angreb er simpelthen skjulte for den. Selvf\u00f8lgelig skal man ikke ignorere dem, og den samme syslog-analyse hj\u00e6lper dig med at identificere \u00e6ndringer i konfigurationen af selve enheden, kompromittering af den, men det er ikke s\u00e6rlig velegnet til at opdage angreb p\u00e5 hele netv\u00e6rket.<\/p>\n<p>Den tredje mulighed er at analysere information om trafikken, der passerer gennem en enhed, der underst\u00f8tter en af flere flow-protokoller. I dette tilf\u00e6lde, uanset protokollen, best\u00e5r infrastrukturen til arbejde med flows altid af tre komponenter:<\/p>\n<ul>\n<li>Generering eller eksport af flow. Denne rolle tildeles normalt en router, switch eller andet netv\u00e6rksudstyr, der, mens det passerer netv\u00e6rkstrafik, kan udtr\u00e6kke n\u00f8gleparametre, som derefter sendes til indsamlingen. For eksempel underst\u00f8tter Cisco-protokollen Netflow ikke kun routere og switche, herunder b\u00e5de virtuelle og industrielle, men ogs\u00e5 tr\u00e5dl\u00f8se controllere, firewall og endda servere.<\/li>\n<li>Indsamling af flow. Da der i moderne netv\u00e6rk typisk er mere end en netv\u00e6rksenhed, opst\u00e5r der en opgave med indsamling og konsolidering af flows, som l\u00f8ses ved hj\u00e6lp af s\u00e5kaldte collectorer, der behandler de modtagne flows og derefter sender dem til analyse.<\/li>\n<li>Flow-analyse. Analysev\u00e6rkt\u00f8jet tager den prim\u00e6re intellektuelle opgave og anvender forskellige algoritmer p\u00e5 str\u00f8mme for at drage visse konklusioner. For eksempel kan et s\u00e5dant analyseredskab inden for IT-funktionen identificere flaskehalse i netv\u00e6rket eller analysere trafikbelastningsprofilen for yderligere at optimere netv\u00e6rket. Og til informationsbeskyttelse kan et s\u00e5dant analyseredskab identificere datal\u00e6kager, spredning af malware eller DoS-angreb. <\/li>\n<\/ul>\n<p>Man skal ikke tro, at en s\u00e5dan tre-lags arkitektur er for kompleks \u2014 alle andre muligheder (undtagen m\u00e5ske netv\u00e6rksoverv\u00e5gningssystemer, der arbejder med SNMP og RMON) fungerer ogs\u00e5 i henhold til denne. Vi har en datagenerator til analyse, der fungerer som et netv\u00e6rksapparat eller en selvst\u00e6ndig sensor. Vi har et alarmsignalindsamlingssystem, og vi har et system til at styre hele overv\u00e5gningsinfrastrukturen. De sidste to komponenter kan sammenl\u00e6gges inden for en enkelt enhed, men i mere eller mindre store netv\u00e6rk er de normalt fordelt over mindst to enheder for at sikre skalerbarhed og p\u00e5lidelighed.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/65de74b0a7556606355f9b176ef7e19c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI mods\u00e6tning til pakkekanalanalyse, der er baseret p\u00e5 unders\u00f8gelse af header og indhold af hver pakke samt de sessioner, der best\u00e5r af dem, hviler flowanalysen p\u00e5 indsamling af metadata om netv\u00e6rkstrafik. Hvorn\u00e5r, hvor meget, hvorfra og til hvor, hvordan... det er sp\u00f8rgsm\u00e5l, som netv\u00e6rkstelemetrianalysen besvarer ved hj\u00e6lp af forskellige flow-protokoller. Oprindeligt blev de brugt til at analysere statistik og finde IT-problemer i netv\u00e6rket, men senere, efterh\u00e5nden som de analytiske mekanismer udviklede sig, blev det muligt at anvende dem p\u00e5 samme telemetri til sikkerhedsform\u00e5l. Her skal det endnu en gang bem\u00e6rkes, at flow-analyse ikke erstatter eller annullerer pakkefangst. Hver af disse metoder har sit anvendelsesomr\u00e5de. Men i konteksten af denne artikel er det netop flow-analyse, der bedst egner sig til overv\u00e5gning af den interne infrastruktur. Du har netv\u00e6rksenheder (og det er ligegyldigt, om de arbejder i en softwaredefineret paradigme eller i henhold til statiske regler), som en angreb ikke kan omg\u00e5. En classic IDS-sensor kan den omg\u00e5, men et netv\u00e6rksapparat, der underst\u00f8tter flow-protokollen, kan den ikke. Dette er fordelene ved denne metode. <\/p>\n<p>P\u00e5 den anden side, hvis du har brug for beviser til retsh\u00e5ndh\u00e6velse eller din egen efterforskningsgruppe for h\u00e6ndelser, kan du ikke undg\u00e5 at bruge pakkeoptagelse \u2014 netv\u00e6rkstelemtri er ikke en kopi af trafikken, der kan bruges ved indsamling af beviser; det er n\u00f8dvendigt for hurtig opdagelse og beslutningstagning inden for informationssikkerhed. P\u00e5 den anden side, ved at bruge telemetrianalyse, kan du \"skrive\" ikke al netv\u00e6rkstrafik (i \u00f8vrigt, Cisco og datacentre h\u00e5ndterer det :-), men kun den trafik, der er involveret i angrebet. V\u00e6rkt\u00f8jer til telemetrianalyse supplerer p\u00e5 dette omr\u00e5de godt de traditionelle pakkeoptagelsesmekanismer, hvilket giver mulighed for selektiv optagelse og opbevaring. Ellers skal du have en kolossal opbevaringsinfrastruktur.<\/p>\n<p>Lad os forestille os et netv\u00e6rk, der opererer med en hastighed p\u00e5 250 Mbit\/s. Hvis du \u00f8nsker at gemme hele dette volumen, har du brug for 31 MB opbevaring for et sekunds trafikoverf\u00f8rsel, 1,8 GB for et minut, 108 GB for en time, og 2,6 TB for en dag. For at gemme daglige data fra et netv\u00e6rk med en b\u00e5ndbredde p\u00e5 10 Gbit\/s, har du brug for 108 TB opbevaring. Og nogle tilsynsmyndigheder kr\u00e6ver, at data gemmes i \u00e5revis... Optagelse \"on demand\", som telemetrianalysen hj\u00e6lper med at realisere, hj\u00e6lper med at reducere disse v\u00e6rdier med flere st\u00f8rrelser. For \u00f8vrigt, n\u00e5r vi taler om forholdet mellem m\u00e6ngden af gemte data fra netv\u00e6rkstelemtri og den fulde dataoptagelse, er det cirka 1 til 500. For de samme n\u00e6vnte v\u00e6rdier ville lagringen af den fulde dekodning af al daglig trafik v\u00e6re henholdsvis 5 GB og 216 GB (det kan endda gemmes p\u00e5 et almindeligt USB-drev).<\/p>\n<p>Hvis metoden til at indsamle r\u00e5 netv\u00e6rksdata er n\u00e6sten ens fra leverand\u00f8r til leverand\u00f8r, er situationen en anden, n\u00e5r det kommer til str\u00f8m-analyse. Der findes flere varianter af flow-protokoller, som det er vigtigt at kende forskellene p\u00e5 i sikkerhedssammenh\u00e6ng. Den mest popul\u00e6re er Netflow-protokollen, udviklet af Cisco. Der findes flere versioner af denne protokol, som adskiller sig i deres muligheder og m\u00e6ngden af trafikdata, der registreres. Den aktuelle version er niende (Netflow v9), som danner grundlaget for industristandarden Netflow v10, ogs\u00e5 kendt som IPFIX. I dag underst\u00f8tter de fleste netv\u00e6rksleverand\u00f8rer enten Netflow eller IPFIX i deres udstyr. Men der er ogs\u00e5 forskellige andre varianter af flow-protokoller \u2014 sFlow, jFlow, cFlow, rFlow, NetStream osv., hvor sFlow er den mest popul\u00e6re. Det er netop sFlow, som oftest underst\u00f8ttes af indenlandske producenter af netv\u00e6rksudstyr p\u00e5 grund af den enkle implementering. Hvad er de vigtigste forskelle mellem Netflow, som er blevet de facto standard, og sFlow? Jeg ville fremh\u00e6ve flere n\u00f8gleforskelle. For det f\u00f8rste har Netflow brugerdefinerede felter, i mods\u00e6tning til de faste felter i sFlow. For det andet, som er det vigtigste i vores tilf\u00e6lde, indsamler sFlow det s\u00e5kaldte samplede telemetri; i mods\u00e6tning til det usamplede hos Netflow og IPFIX. Hvad er forskellen mellem dem?<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/96782b57ccaddd731d5084c127076d49.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nForestil dig, at du har besluttet at kigge n\u00e6rmere p\u00e5 bogen \u201c<noindex><a rel=\"nofollow\" href=\"http:\/\/www.ciscopress.com\/store\/security-operations-center-building-operating-and-maintaining-9780134052014\">Security Operations Center: Building, Operating, and Maintaining your SOC<\/a><\/noindex>\u201d af mine kolleger \u2014 Gary McIntyre, Joseph Muniz og Nadem AlFardan (du kan downloade en del af bogen via linket). Du har tre muligheder for at n\u00e5 dit m\u00e5l \u2014 l\u00e6se bogen helt, skimme den og stoppe ved hver 10. eller 20. side, eller fors\u00f8ge at finde en opsummering af de vigtigste koncepter i en blog eller tjeneste som SmartReading. Det usamplede telemetri er at l\u00e6se hver \u201cside\u201d af netv\u00e6rkstrafikken, det vil sige at analysere metadataene for hver pakke. Det samplede telemetri er en udvalgt unders\u00f8gelse af trafikken i h\u00e5bet om, at der i de udvalgte samples vil v\u00e6re det, du har brug for. Afh\u00e6ngigt af hastigheden p\u00e5 kanalen vil det samplede telemetri levere hver 64., 200., 500., 1000., 2000. eller endda 10000. pakke til analyse.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/28b798498a11a5e6f72ef847ea2dbaaa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI konteksten af overv\u00e5gning af IKT betyder det, at den sampled telemetri er velegnet til at opdage DDoS-angreb, scanninger, spredning af malware, men kan overse atomiske eller multi-paket angreb, der ikke er inkluderet i det sample, der blev sendt til analyse. Den unsampled telemetri har ikke s\u00e5danne ulemper, og med dens hj\u00e6lp er spektret af opdagede angreb langt bredere. Her er en kort liste over begivenheder, der kan opdages med hj\u00e6lp af analysev\u00e6rkt\u00f8jer til netv\u00e6rkstelemetri.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/be3a11d4826978d9c882074f22ee97c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNaturligvis, en eller anden open source Netflow-analysator vil ikke kunne g\u00f8re dette, da dens prim\u00e6re opgave er at indsamle telemetri og udf\u00f8re en grundl\u00e6ggende analyse set fra et IT-perspektiv. For at identificere trusler til IKT baseret p\u00e5 flow, skal analysatoren udstyres med forskellige motorer og algoritmer, som vil identificere cybersikkerhedsproblemer baseret p\u00e5 standard eller brugerdefinerede Netflow-felter, berige standarddata med eksterne data fra forskellige kilder til trussel efterretning osv.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/60e876dbfbdffd160e9899f87aa6303c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS\u00e5 hvis du har valget, s\u00e5 v\u00e6lg Netflow eller IPFIX. Men selv hvis dit udstyr kun arbejder med sFlow, som det g\u00f8r hos indenlandske producenter, kan du stadig f\u00e5 fordel af det i sikkerhedssammenh\u00e6ng. <\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/ee75809ccde4f366ca5f5ead7beed58c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI sommeren 2019 analyserede jeg mulighederne, som de russiske producenter af netv\u00e6rksudstyr har, og alle, undtagen NSG, Poligon og Kraftvey, h\u00e6vdede at st\u00f8tte sFlow (i det mindste Zelax, Natex, Eltex, QTech, Rusteletech). <\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/acd1ed477af59e1439d941374c596d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet n\u00e6ste sp\u00f8rgsm\u00e5l, du m\u00e5 stille dig selv, er, hvor man implementerer flow-support til sikkerhedsm\u00e6ssige form\u00e5l? Faktisk er sp\u00f8rgsm\u00e5let stillet lidt ukorrekt. P\u00e5 moderne udstyr er der n\u00e6sten altid support for flow-protokoller. Derfor ville jeg omformulere sp\u00f8rgsm\u00e5let: Hvor er det mest effektivt at indsamle telemetri i forhold til sikkerhed? Svaret vil v\u00e6re temmelig \u00e5benlyst \u2014 p\u00e5 adgangsniveauet, hvor du ser 100% af al trafik, hvor du har detaljeret information om v\u00e6rter (MAC, VLAN, interface-ID), og hvor du kan spore endda P2P-trafik mellem v\u00e6rter, hvilket er kritisk for at opdage scanning og spredning af ondsindet software. P\u00e5 kerne-niveau kan du simpelthen ikke se en del trafik, og p\u00e5 perimeter-niveau vil du h\u00f8jst se en fjerdedel af al din netv\u00e6rkstrafik. Men hvis der af en eller anden grund er kommet ukendte enheder ind i dit netv\u00e6rk, som tillader angribere at \"g\u00e5 ind og ud\", omg\u00e5s perimetret, s\u00e5 vil analyse af telemetri fra dem ikke give dig noget. Derfor anbefales det for maksimal d\u00e6kning at aktivere indsamling af telemetri netop p\u00e5 adgangsniveauet. Det er v\u00e6rd at bem\u00e6rke, at selvom vi taler om virtualisering eller containere, s\u00e5 findes der ofte support for flow i moderne virtuelle switche, hvilket g\u00f8r det muligt at kontrollere trafikken der.<\/p>\n<p>Men da jeg nu har taget emnet op, m\u00e5 jeg svare p\u00e5 sp\u00f8rgsm\u00e5let: Hvad hvis udstyret, fysisk eller virtuelt, ikke underst\u00f8tter flow-protokoller? Eller hvis dens aktivering er forbudt (for eksempel i industrielle segmenter for at sikre p\u00e5lidelighed)? Eller hvis aktivering f\u00f8rer til h\u00f8j belastning p\u00e5 centralprocessoren (det kan ske p\u00e5 gammelt udstyr)? For at l\u00f8se denne opgave findes der specialiserede virtuelle sensorer (flow sensor), som i bund og grund er almindelige fordelere, der lader trafik passere gennem dem og transmitterer det som flow til en indsamlingsmodul. Men i dette tilf\u00e6lde f\u00e5r vi hele bunken af problemer, som vi talte om tidligere i forbindelse med pakkeopsamlingsv\u00e6rkt\u00f8jer. Det vil sige, man skal forst\u00e5 ikke kun fordelene ved flow-analyseteknologi, men ogs\u00e5 dens begr\u00e6nsninger.<\/p>\n<p>En anden ting at huske, n\u00e5r man taler om analysesoftware til datastreams, er, at hvis vi anvender metrikken EPS (events per second, h\u00e6ndelser pr. sekund) til almindelig sikkerhedsgenerering, s\u00e5 g\u00e6lder den ikke for telemetryanalyse; her erstattes den af FPS (flows per second, str\u00f8mme pr. sekund). Ligesom med EPS kan vi ikke beregne dette p\u00e5 forh\u00e5nd, men vi kan vurdere det omtrentlige antal str\u00f8mme, som en enhed genererer afh\u00e6ngigt af dens opgave. Du kan finde tabeller online med omtrentlige v\u00e6rdier for forskellige typer af virksomhedsenheder og betingelser, som vil hj\u00e6lpe dig med at estimere, hvilke licenser du har brug for til analysev\u00e6rkt\u00f8jer, og hvilken arkitektur der vil v\u00e6re n\u00f8dvendig. Sensoren til IDS har en begr\u00e6nset b\u00e5ndbredde, som den kan \"tr\u00e6kke\", og flowkollektoren har sine egne begr\u00e6nsninger, som man skal forst\u00e5. Derfor er der typisk flere kollektorer i store, geografisk distribuerede netv\u00e6rk. Da jeg beskrev, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">hvordan netv\u00e6rket overv\u00e5ges inden for Cisco<\/a><\/noindex>, n\u00e6vnte jeg allerede antallet af vores kollektorer \u2014 21. Og det g\u00e6lder for et netv\u00e6rk, der str\u00e6kker sig over fem kontinenter og omfatter omkring en halv million aktive enheder).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/a5935ef7f7a3511cbf291fce59e96d71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSom overv\u00e5gningssystem for Netflow bruger vi vores eget <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch<\/a><\/noindex>, som er specielt rettet mod at l\u00f8se sikkerhedsopgaver. Den har mange indbyggede motorer til at opdage anomal, mist\u00e6nkelig og \u00e5benlyst skadelig aktivitet, hvilket g\u00f8r det muligt at detektere et bredt spektrum af forskellige trusler \u2014 fra kryptovalutaudvinding til datal\u00e6kager, fra spredning af skadelig kode til svindel. Ligesom de fleste str\u00f8mmeanalysatorer er Stealthwatch bygget p\u00e5 et tre-niveau skema (generator \u2014 samler \u2014 analyser), men den er suppleret med en r\u00e6kke interessante funktioner, der er vigtige i konteksten af det materiale, vi behandler. For det f\u00f8rste integreres den med packet capturing-l\u00f8sninger (f.eks. Cisco Security Packet Analyzer), hvilket g\u00f8r det muligt at optage udvalgte netv\u00e6rkssessioner til efterf\u00f8lgende dybdeg\u00e5ende unders\u00f8gelse og analyse. For det andet, med henblik p\u00e5 at udvide sikkerhedsopgaverne, har vi udviklet en s\u00e6rlig protokol kaldet nvzFlow, som g\u00f8r det muligt at<\/p>\n<p>transmittere<\/p>\n<p>SiLK \u2014 et s\u00e6t af v\u00e6rkt\u00f8jer (System for Internet-Level Knowledge) til trafikanalyse, udviklet af det amerikanske CERT\/CC, som st\u00f8tter Netflow (de femte og niende, de mest popul\u00e6re versioner), IPFIX og sFlow. Det g\u00f8r det muligt at udf\u00f8re forskellige operationer p\u00e5 netv\u00e6rkstelemtri ved hj\u00e6lp af forskellige v\u00e6rkt\u00f8jer (rwfilter, rwcount, rwflowpack osv.) med det form\u00e5l at opdage tegn p\u00e5 uautoriserede handlinger. Men der er et par vigtige punkter at bem\u00e6rke. SiLK er et kommandolinjev\u00e6rkt\u00f8j, s\u00e5 operationel analyse kr\u00e6ver indtastning af kommandoer som (opdagelse af ICMP-pakker st\u00f8rre end 200 byte):<\/p>\n<p><code>rwfilter --flowtypes=all\/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15<\/code><\/p>\n<p>det er ikke s\u00e6rlig praktisk. Du kan bruge den grafiske gr\u00e6nseflade i iSiLK, men den vil ikke g\u00f8re din hverdag meget lettere, da den kun fungerer som visualisering og ikke som erstatning for analytikeren. Og det er det andet punkt. I mods\u00e6tning til kommercielle l\u00f8sninger, som allerede har en solid analytisk base, algoritmer til opdagelse af anomalier, relevante workflows osv., skal du i tilf\u00e6lde af SiLK selv udf\u00f8re alt dette, hvilket kr\u00e6ver lidt andre kompetencer end at bruge et allerede f\u00e6rdigt v\u00e6rkt\u00f8j. Dette er hverken godt eller d\u00e5rligt \u2014 det er en egenskab ved n\u00e6sten ethvert gratis v\u00e6rkt\u00f8j, som antager, at du ved, hvad du laver, og det kun hj\u00e6lper dig med det (kommercielle v\u00e6rkt\u00f8jer er mindre afh\u00e6ngige af deres brugeres kompetencer, selvom de ogs\u00e5 foruds\u00e6tter, at analytikere forst\u00e5r i det mindste grundl\u00e6ggende netv\u00e6rksunders\u00f8gelser og overv\u00e5gning). Men lad os g\u00e5 tilbage til SiLK. Arbejdscyklussen for analytikeren ser s\u00e5dan ud:<\/p>\n<ul>\n<li>Formulering af hypotese. Vi skal forst\u00e5, hvad vi leder efter i netv\u00e6rkstelemtrien, og kende de unikke attributter, som vi vil bruge til at identificere bestemte anomalier eller trusler.<\/li>\n<li>Modellering. N\u00e5r vi har formuleret vores hypotese, programmerer vi den ved hj\u00e6lp af Python, shell eller andre v\u00e6rkt\u00f8jer, der ikke er en del af SiLK.<\/li>\n<li>Testning. Det er tid til at kontrollere rigtigheden af vores hypotese, som bekr\u00e6ftes eller afkr\u00e6ftes ved hj\u00e6lp af SiLK-v\u00e6rkt\u00f8jer, der begynder med 'rw', 'set', 'bag'.<\/li>\n<li>Analyse af reelle data. I industriel drift hj\u00e6lper SiLK med at identificere noget, og analytikeren skal besvare sp\u00f8rgsm\u00e5l som \"Har vi fundet det, vi antog?\", \"Stemmer dette overens med vores hypotese?\", \"Hvordan kan vi mindske antallet af falske alarmer?\", \"Hvordan kan vi forbedre genkendelsesniveauet?\" osv.<\/li>\n<li>Forbedring. I den afsluttende fase forbedrer vi det tidligere udf\u00f8rte \u2014 vi skaber skabeloner, forbedrer og optimerer koden, omformulerer og pr\u00e6ciserer hypotesen osv.<\/li>\n<\/ul>\n<p>Denne cyklus vil ogs\u00e5 v\u00e6re anvendelig for Cisco Stealthwatch, dog automatiserer den sidstn\u00e6vnte i videst muligt omfang de fem trin, hvilket reducerer analytikernes fejl og \u00f8ger hastigheden p\u00e5 opdagelse af h\u00e6ndelser. For eksempel kan du i SiLK berige netv\u00e6rksstatistik med eksterne data om ondsindede IP-adresser ved hj\u00e6lp af selvskrevne scripts, mens det i Cisco Stealthwatch er en indbygget funktion, der straks viser en alarm, hvis der er interaktion med IP-adresser fra en sortliste i netv\u00e6rkstrafikken.<\/p>\n<p>Hvis man g\u00e5r h\u00f8jere op i \"betalingspyramiden\" for flow-analyse software, vil den helt gratis SiLK blive efterfulgt af et betinget gratis ELK, best\u00e5ende af tre n\u00f8glekomponenter \u2014 Elasticsearch (indeksering, s\u00f8gning og dataanalyse), Logstash (dataindgang\/udgang) og Kibana (visualisering). I mods\u00e6tning til SiLK, hvor alt skal skrives fra bunden, har ELK allerede mange f\u00e6rdige biblioteker\/moduler (nogle er betalte, andre ikke), der automatiserer analysen af netv\u00e6rkstelemetri. For eksempel tillader GeoIP-filteret i Logstash at knytte de observerede IP-adresser til deres geografiske placering (den funktion er indbygget i Stealthwatch).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/addd9d9656f64f81d86a0cce8ee0810b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nELK har ogs\u00e5 et stort f\u00e6llesskab, der tilf\u00f8jer manglende komponenter til denne overv\u00e5gningsl\u00f8sning. For eksempel, for at arbejde med Netflow, IPFIX og sFlow kan du benytte modulet <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/robcowart\/elastiflow\">elastiflow<\/a><\/noindex>, hvis du ikke er tilfreds med Logstash Netflow Module, som kun underst\u00f8tter Netflow.<\/p>\n<p>Ved at give mere hastighed til indsamling af flow og s\u00f8gning i det, har ELK i \u00f8jeblikket ikke en rig indbygget analyse til opdagelse af anomalier og trusler i netv\u00e6rkstelemetri. Det vil sige, at hvis man f\u00f8lger den ovenfor beskrevne livscyklus, bliver man n\u00f8dt til selv at beskrive brudmodeller og derefter bruge dem i det operative system (der er ingen indbyggede modeller der).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/6d8368f4c130c3a5770890cb6c5fe5ab.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer findes selvf\u00f8lgelig ogs\u00e5 mere avancerede udvidelser til ELK, hvor nogle modeller til opdagelse af anomalier i netv\u00e6rkstelemetri allerede er indbygget, men s\u00e5danne udvidelser koster penge, og s\u00e5 st\u00e5r sp\u00f8rgsm\u00e5let - er det pengene v\u00e6rd? Skal man selv skrive en lignende model, k\u00f8be en implementering til sit overv\u00e5gningssystem eller k\u00f8be en f\u00e6rdig l\u00f8sning inden for Network Traffic Analysis?<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/d938ebb4271c4dfb73a1e4b6e94c91d6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJeg vil egentlig ikke g\u00e5 ind i polemik om, hvad der er bedst: at bruge penge p\u00e5 at k\u00f8be en f\u00e6rdig l\u00f8sning til overv\u00e5gning af anomalier og trusler i netv\u00e6rkstelemetri (f.eks. Cisco Stealthwatch) eller selv s\u00e6tte sig ind i det og tilpasse f.eks. SiLK, ELK eller nfdump eller OSU Flow Tools (jeg henviser til de sidste to) <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">har jeg tidligere talt om<\/a><\/noindex> sidste gang)? Hver v\u00e6lger for sig selv, og hver har sine egne motiver for at v\u00e6lge en af de to muligheder. Jeg ville bare vise, at netv\u00e6rkstelemetri er et meget vigtigt v\u00e6rkt\u00f8j til at sikre netv\u00e6rkssikkerheden i ens interne infrastruktur, og man b\u00f8r ikke negligere det for ikke at ende p\u00e5 listen over virksomheder, hvis navne n\u00e6vnes i medierne sammen med epitetter som \"brudt\", \"ikke overholdt kravene til informationssikkerhed\", \"ikke t\u00e6nkt p\u00e5 sikkerheden af sine egne data og kunders data\".<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/de7df67df66b7abe89170c7f92fcefca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAfslutningsvis vil jeg gerne opsummere nogle n\u00f8gle r\u00e5d, som man b\u00f8r f\u00f8lge, n\u00e5r man indretter overv\u00e5gning af informationssikkerheden i sin interne infrastruktur:<\/p>\n<ol>\n<li>Begr\u00e6ns dig ikke kun til perimetret! Brug (og v\u00e6lg) netv\u00e6rksinfrastrukturen ikke kun til at overf\u00f8re trafik fra punkt A til punkt B, men ogs\u00e5 til at h\u00e5ndtere sp\u00f8rgsm\u00e5l om cybersikkerhed.<\/li>\n<li>Unders\u00f8g de eksisterende overv\u00e5gningsmekanismer i dit netv\u00e6rksudstyr og anvend dem.<\/li>\n<li>Til intern overv\u00e5gning skal du prioritere analyse af telemetri - det muligg\u00f8r opdagelse af op til 80-90% af alle netv\u00e6rksrelaterede sikkerhedsh\u00e6ndelser, hvilket g\u00f8r det muligt at g\u00f8re noget, som ikke kan lade sig g\u00f8re med indsamling af netv\u00e6rkspakker, samtidig med at det sparer plads til opbevaring af alle sikkerhedsh\u00e6ndelser.<\/li>\n<li>Til overv\u00e5gning af str\u00f8mmene skal du bruge Netflow v9 eller IPFIX \u2013 de giver mere information i sikkerhedssammenh\u00e6ng og g\u00f8r det muligt at overv\u00e5ge ikke kun IPv4, men ogs\u00e5 IPv6, MPLS osv.<\/li>\n<li>Brug et ikke-pr\u00f8vet flowprotokol \u2013 det giver mere information til opdagelse af trusler. For eksempel, Netflow eller IPFIX.<\/li>\n<li>Kontroller indl\u00e6sningen af dit netv\u00e6rksudstyr \u2013 det kan v\u00e6re, at det ikke kan h\u00e5ndtere flow-protokollen. Overvej derfor at anvende virtuelle sensorer eller en Netflow Generation Appliance.<\/li>\n<li>Implementer kontrol f\u00f8rst og fremmest p\u00e5 adgangsniveau \u2013 det vil give dig mulighed for at se 100% af al trafik.<\/li>\n<li>Hvis du ikke har noget valg og bruger russisk netv\u00e6rksudstyr, s\u00e5 v\u00e6lg det, der underst\u00f8tter flow-protokoller eller har SPAN\/RSPAN-porte.<\/li>\n<li>Kombiner systemer til opdagelse\/forebyggelse af indbrud\/angreb p\u00e5 gr\u00e6nserne og systemer til analyse af flow i det interne netv\u00e6rk (herunder ogs\u00e5 i skyen).<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/c54e4b02a906f470bbfb617f48cdd216.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvad ang\u00e5r det sidste r\u00e5d, vil jeg gerne give en illustration, som jeg tidligere har n\u00e6vnt. Du kan se, at hvis Cisco's Informationssikkerhedstjeneste tidligere n\u00e6sten udelukkende byggede sit overv\u00e5gningssystem p\u00e5 systemer til opdagelse af indbrud og signaturmetoder, s\u00e5 st\u00e5r de nu for kun 20% af h\u00e6ndelserne. Yderligere 20% henf\u00f8res til systemer til analyse af flow, hvilket viser, at disse l\u00f8sninger ikke er en luksus, men et reelt v\u00e6rkt\u00f8j i informationssikkerhedstjenesternes arbejde i moderne virksomheder. Is\u00e6r da du har det vigtigste til deres implementering \u2013 netv\u00e6rksinfrastrukturen, investeringer i hvilken kan beskyttes yderligere ved at p\u00e5l\u00e6gge netv\u00e6rket ogs\u00e5 overv\u00e5gningsfunktioner.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protokoller som v\u00e6rkt\u00f8j til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk\" src=\"\/wp-content\/uploads\/2019\/08\/2166f265222c43b0b2cbbcf4091c1f8c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJeg har bevidst ikke ber\u00f8rt emnet om reaktion p\u00e5 identificerede anomalier eller trusler i netv\u00e6rksflow, men jeg tror, det er klart, at overv\u00e5gning ikke b\u00f8r stoppe ved blot at opdage en trussel. Der b\u00f8r f\u00f8lge en reaktion, helst i en automatisk eller automatiseret tilstand. Men det er allerede emnet for separate materiale.<\/p>\n<p>Yderligere information:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/products\/ios-nx-os-software\/ios-netflow\/index.html\">Beskrivelse af Cisco IOS Netflow<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/community.cisco.com\/t5\/security-documents\/netflow-support-matrix\/ta-p\/3644638\">Matrix for st\u00f8tte til Netflow i forskellige Cisco-l\u00f8sninger<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/dam\/en\/us\/td\/docs\/security\/stealthwatch\/netflow\/Cisco_NetFlow_Configuration.pdf\">Guide til ops\u00e6tning af Netflow p\u00e5 forskellige Cisco-platforme<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/sflow.org\">sFlow-samfundet<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ciscolive.com\/c\/dam\/r\/ciscolive\/us\/docs\/2015\/pdf\/LTRSEC-3336.pdf\">Laboratoriekursus i brug af Stealthwatch, SiLK og ELK til analyse af Netflow set fra et sikkerhedsm\u00e6ssigt perspektiv<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/\">SiLK-websted<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/analysis-handbook.pdf\">Trehundrede siders guide til brug af SiLK med masser af eksempler<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/logstash\/current\/netflow-module.html\">Logstash Netflow-modul<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.cisco.com\/security\/step-by-step-setup-of-elk-for-netflow-analytics\">Trinvise instruktioner fra Cisco til analyse af Netflow i ELK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/307528\/\">Analyse af NetFlow v.9 Cisco ASA ved hj\u00e6lp af Logstash (ELK)<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch-l\u00f8sning<\/a><\/noindex><\/li>\n<\/ul>\n<p>P.S. Hvis det er lettere for dig at opfatte alt, hvad der er skrevet ovenfor, s\u00e5 kan du se en times pr\u00e6sentation, som dannede grundlaget for denne note.<\/p>\n<p><center><div class=\"youtube-placeholder\" data-id=\"ncDRZsueETo\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/ncDRZsueETo\/hqdefault.jpg\" alt=\"Afspil video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/464601\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439. \u0410 \u0435\u0441\u043b\u0438 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0443\u0442\u043e\u0447\u043d\u0438\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441 \u0438 \u0441\u043f\u0440\u043e\u0441\u0438\u0442\u044c, \u043a\u0430\u043a \u0432\u044b \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0432\u0430\u0435\u0442\u0435 \u0430\u0442\u0430\u043a\u0438 \u0432\u043e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u043e\u0442\u0432\u0435\u0442\u043e\u043c \u0431\u0443\u0434\u0435\u0442, \u043a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u0443\u043f\u043e\u043c\u0438\u043d\u0430\u043d\u0438\u0435 \u0441\u0438\u0441\u0442\u0435\u043c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0430\u0442\u0430\u043a (intrusion detection systems, IDS). \u0418 \u0442\u043e, \u0447\u0442\u043e \u0431\u044b\u043b\u043e \u0435\u0434\u0438\u043d\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28091,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37437","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Flow-\u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u043a\u0430\u043a \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:17:38+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:17:38+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Flow-protokoller som et redskab til overv\u00e5gning af sikkerheden i det interne netv\u00e6rk | ProHoster","description":"N\u00e5r det kommer til overv\u00e5gning af sikkerheden i et internt virksomhed- eller myndighedsnetv\u00e6rk, t\u00e6nker mange p\u00e5 kontrol med informationsl\u00e6kager og implementering af DLP-l\u00f8sninger.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Flow-\u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u043a\u0430\u043a \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438 | ProHoster","og:description":"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:17:38+00:00","article:modified_time":"2019-10-31T19:17:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37437","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 17:49:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:26:28","updated":"2026-01-23 17:49:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=37437"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37437\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/28091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=37437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=37437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=37437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}