{"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\/nl\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","title":{"rendered":"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Wanneer het gaat om het monitoren van de veiligheid van een interne bedrijfs- of overheidsnetwerk, hebben velen de associatie met informatielekken en de implementatie van DLP-oplossingen. Maar als we de vraag specifieker maken en vragen hoe u aanvallen in uw interne netwerk ontdekt, is het antwoord doorgaans een vermelding van inbraakdetectiesystemen (intrusion detection systems, IDS). Wat twintig jaar geleden de enige optie was, is vandaag de dag een anachronisme geworden. Er is een effectievere, en soms de enige mogelijke optie voor het monitoren van een intern netwerk \u2014 gebruik maken van flowprotocollen, die oorspronkelijk zijn ontworpen voor het opsporen van netwerkproblemen (troubleshooting), maar in de loop van de tijd zijn getransformeerd tot een zeer interessant beveiligingsinstrument. We zullen in dit artikel bespreken welke flowprotocollen er zijn, welke het beste helpen bij het opsporen van netwerkaanvallen, waar je het beste monitoring van flow kunt implementeren, waar je op moet letten bij het opzetten van een dergelijk schema, en zelfs hoe je dit alles kunt 'opzetten' op binnenlandse apparatuur.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Ik zal niet ingaan op de vraag \"Waarom is monitoring van de veiligheid van de interne infrastructuur nodig?\" Het antwoord daarop is eigenlijk al duidelijk. Maar als u nogmaals wilt bevestigen dat dit tegenwoordig onmisbaar is, <noindex><a rel=\"nofollow\" href=\"https:\/\/gblogs.cisco.com\/ru\/17attackvectors\/\">kijk naar<\/a><\/noindex> een korte video die uitlegt hoe je op 17 verschillende manieren kunt doordringen in een bedrijfsnetwerk dat wordt beschermd door een firewall. Laten we dus aannemen dat we begrijpen dat interne monitoring noodzakelijk is en dat we alleen nog moeten begrijpen hoe dit kan worden georganiseerd.<\/p>\n<p>Ik zou drie belangrijke databronnen voor het monitoren van de infrastructuur op netwerkniveau willen onderscheiden:<\/p>\n<ul>\n<li>\"rauwe\" traffic die we onderscheppen en ter analyse aanbieden aan bepaalde analysesystemen,<\/li>\n<li>gebeurtenissen van netwerkapparaten waar het verkeer doorheen gaat,<\/li>\n<li>informatie over verkeer verkregen via een van de flowprotocollen.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/09c7087593661d5b159ecc9e9ab39d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet vastleggen van ruwe netwerkinformatie is de populairste optie onder beveiligingsprofessionals, omdat het historisch gezien de eerste methode was. Gewone netwerkdetectiesystemen (de eerste commerci\u00eble systeem was NetRanger van Wheel Group, gekocht door Cisco in 1998) waren gericht op het vastleggen van pakketten (en later sessies), waarin naar bepaalde handtekeningen (\"beslissende regels\" in de terminologie van FSTEC) werd gezocht die op aanvallen wijzen. Uiteraard kan ruwe netwerkinformatie niet alleen met IDS worden geanalyseerd, maar ook met andere middelen (bijvoorbeeld Wireshark, tcpdump of de functionaliteit NBAR2 in Cisco IOS), maar deze ontbreken meestal de kennisbasis die een informatiebeveilingsmiddel van een gewoon IT-instrument onderscheidt.<\/p>\n<p>Dus, aanvallsdetectiesystemen. De oudste en meest populaire methode voor het detecteren van netwerkaanvallen, die redelijk goed zijn taak uitvoert aan de rand (ongeacht of dat een bedrijfsnetwerk, datacenter of segment is), maar faalt in moderne geschakelde en softwarematig gedefinieerde netwerken. In het geval van een netwerk dat is opgebouwd uit gewone schakelaars, wordt de infrastructuur van de aanvallsensoren veel te groot \u2014 je zou voor elke verbinding met een knooppunt dat je wilt bewaken een sensor moeten plaatsen. Elke fabrikant zal je graag honderden of duizenden sensoren verkopen, maar ik denk niet dat je budget dat kan dragen. Ik kan zeggen dat zelfs bij Cisco (waar wij NGIPS ontwikkelen) wij dit niet konden realiseren, hoewel de prijs eigenlijk voor ons geen probleem zou moeten zijn \u2014 het is immers onze eigen oplossing. Bovendien rijst de vraag hoe een sensor in zo\u2019n situatie aan te sluiten? In een onderbreking? En als de sensor uitvalt? Moet er een bypass-module in de sensor zitten? Gebruik maken van taps? Dit alles verhoogt de kosten van de oplossing en maakt deze onbetaalbaar voor bedrijven van elke omvang.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/4763c13237dbe9ffa38d62075939ffba.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJe kunt proberen de sensor op de SPAN\/RSPAN\/ERSPAN-poort te 'hangen' en het verkeer van de benodigde poorten van de switch daarheen te leiden. Deze optie verlicht gedeeltelijk het probleem dat in de vorige alinea is beschreven, maar brengt een ander probleem met zich mee: de SPAN-poort kan niet al het verkeer verwerken dat er naartoe wordt geleid \u2014 de bandbreedte is niet voldoende. Je zult ergens concessies moeten doen. Of je laat een deel van de knooppunten zonder monitoring (in dat geval moet je ze prioriteren), of je leidt niet al het verkeer van het knooppunt, maar alleen van een bepaald type. In elk geval kunnen we enkele aanvallen missen. Bovendien kan de SPAN-poort voor andere doeleinden in gebruik zijn. Uiteindelijk zullen we de bestaande netwerktopologie moeten heroverwegen en mogelijk aanpassen om uw netwerk maximaal te dekken met het aantal sensoren dat u heeft (en dit afstemmen met IT).<\/p>\n<p>Maar wat als uw netwerk asymmetrische routes gebruikt? Wat als u SDN hebt ge\u00efmplementeerd of van plan bent dit te doen? Wat als u gemoduleerde machines of containers moet monitoren, wiens verkeer helemaal niet het fysieke switch bereikt? Deze vragen vinden traditionele IDS-fabrikanten lastig, omdat ze niet weten hoe ze erop moeten antwoorden. Misschien zullen ze u aanmoedigen te denken dat al deze trendy technologie\u00ebn hype zijn en dat u ze niet nodig heeft. Misschien zal men zeggen dat u klein moet beginnen. Of ze kunnen beweren dat u een krachtige machine in het centrum van het netwerk moet plaatsen en al het verkeer daarheen moet leiden via load balancers. Welke optie ze ook aanbieden, het is essentieel dat u zelf duidelijk begrijpt in hoeverre deze passend is voor u. Pas daarna kunt u beslissen over de aanpak voor het monitoren van de IT-beveiliging van uw netwerkinfrastructuur. Wat betreft pakketcaptatie, wil ik zeggen dat deze methode nog steeds zeer populair en belangrijk is, maar het is voornamelijk bedoeld voor grensbewaking; de grenzen tussen uw organisatie en het internet, de grenzen tussen het datacentrum en de rest van het netwerk, de grenzen tussen SCADA-systemen en het bedrijfssegment. Op deze plekken hebben traditionele IDS\/IPS-systemen nog steeds bestaansrecht en presteren ze goed in de gestelde taken.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/7a5898e0aa9e3e9275dda3e2c7b75c5c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLaten we doorgaan met de tweede optie. Het analyseren van gebeurtenissen die van netwerkapparaten komen, kan ook worden gebruikt voor detectiedoeleinden, maar niet als de belangrijkste methode, omdat het alleen een beperkte klasse van inbreuken kan detecteren. Bovendien heeft het enige reactieve kenmerken \u2014 een aanval moet eerst plaatsvinden, en vervolgens moet deze worden geregistreerd door het netwerkapparaat, dat op de een of andere manier zal signaleren dat er een probleem is met de informatiebeveiliging. Er zijn verschillende manieren om dit te doen. Dit kan syslog, RMON of SNMP zijn. De laatste twee protocollen voor netwerkmonitoring worden in de context van informatiebeveiliging alleen toegepast als we een DoS-aanval op het netwerkapparaat zelf moeten detecteren, omdat we met behulp van RMON en SNMP bijvoorbeeld de CPU-lading of de interfaces van het apparaat kunnen volgen. Dit is een van de goedkoopste methoden (syslog of SNMP zijn voor iedereen beschikbaar), maar ook de minst effectieve manier van informatiebeveiligingsmonitoring van de interne infrastructuur \u2014 veel aanvallen blijven voor deze methoden verborgen. Natuurlijk moet men ze niet verwaarlozen en dezelfde syslog-analyse helpt je om tijdig wijzigingen in de configuratie van het apparaat zelf te identificeren, maar ze zijn niet erg geschikt voor het detecteren van aanvallen op het hele netwerk.<\/p>\n<p>De derde optie is het analyseren van informatie over het verkeer dat door een apparaat stroomt dat een van de verschillende flow-protocollen ondersteunt. In dit geval bestaat de infrastructuur voor het werken met flows, ongeacht het protocol, altijd uit drie componenten:<\/p>\n<ul>\n<li>Generatie of export van flow. Deze rol wordt meestal vervuld door een router, switch of ander netwerkapparaat, dat, terwijl het netwerkverkeer doorstroomt, in staat is om belangrijke parameters eruit te halen die vervolgens naar de verzamelmodule worden verzonden. Bijvoorbeeld, bij Cisco wordt het Netflow-protocol niet alleen ondersteund op routers en switches, waaronder zowel virtuele als industri\u00eble, maar ook op draadloze controllers, firewalls en zelfs servers.<\/li>\n<li>Verzameling van flow. Gezien het feit dat er in een modern netwerk meestal meer dan \u00e9\u00e9n netwerkapparaat is, ontstaat de taak van het verzamelen en consolideren van flows, die wordt opgelost met behulp van zogenaamde collectoren die de verkregen flows verwerken en vervolgens doorgeven voor analyse.<\/li>\n<li>Flow-analyse. De analyzer neemt de belangrijkste intellectuele taak op zich en past verschillende algoritmes toe op de stromen om bepaalde conclusies te trekken. Bijvoorbeeld, binnen de IT-functie kan zo'n analyzer knelpunten in het netwerk identificeren of het verkeersprofiel analyseren voor verdere netwerkoptimalisatie. Voor Informatiebeveiliging kan een dergelijke analyzer datalekken, de verspreiding van malware of DoS-aanvallen opsporen. <\/li>\n<\/ul>\n<p>Je moet niet denken dat zo'n drievoudige architectuur te complex is \u2014 alle andere opties (behalve misschien netwerk bewakingssystemen die werken met SNMP en RMON) werken ook volgens hetzelfde principe. We hebben een gegevensgenerator voor analyse, die een netwerkapparaat of een zelfstandig sensor is. We hebben een alarmsignaalverzamelingssysteem en een systeem voor het beheer van de hele monitoringinfrastructuur. De laatste twee componenten kunnen binnen \u00e9\u00e9n node worden gecombineerd, maar in grotere netwerken zijn ze meestal verdeeld over minstens twee apparaten om schaalbaarheid en betrouwbaarheid te waarborgen.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/65de74b0a7556606355f9b176ef7e19c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn tegenstelling tot packet-analyse, die zich richt op het bestuderen van de header en de gegevens van elk pakket en de sessies die daaruit voortkomen, steunt flow-analyse op het verzamelen van metadata over netwerkverkeer. Wanneer, hoeveel, van waar en naar waar, hoe\u2026 dat zijn de vragen die netwerktelemetrie-analyse met verschillende flow-protocollen beantwoordt. Oorspronkelijk werden ze gebruikt voor het analyseren van statistieken en het opsporen van IT-problemen in het netwerk, maar naarmate analytische mechanismen zich ontwikkelden, werd het mogelijk om ze ook voor telemetrie en veiligheidsdoeleinden te gebruiken. Hier moet nogmaals worden benadrukt dat flow-analyse geen vervanging of annulering van packet-capture biedt. Elk van deze methoden heeft zijn eigen toepassingsgebied. Maar in de context van dit artikel is flow-analyse het meest geschikt voor het monitoren van de interne infrastructuur. Je hebt netwerkapparaten (ongeacht of ze werken in een softwaregedefinieerde paradigma of volgens statische regels) die niet door een aanval kunnen worden omzeild. Een traditionele IDS-sensor kan worden omzeild, maar een netwerkapparaat dat flow-protocollen ondersteunt, kan dat niet. Dit is het voordeel van deze methode. <\/p>\n<p>Aan de andere kant, als u bewijs nodig heeft voor wetshandhavingsinstanties of voor uw eigen incidentonderzoeksgroep, komt u niet om packet capture heen \u2014 netwerktelemetrie is geen kopie van het verkeer dat kan worden gebruikt bij het verzamelen van bewijs; het is nodig voor operationele detectie en besluitvorming op het gebied van informatiebeveiliging. Aan de andere kant, door gebruik te maken van telemetrie-analyse, kunt u niet al het netwerkverkeer 'vastleggen' (voor de duidelijkheid, Cisco en datacenters zijn erbij betrokken :-), maar alleen datgene dat betrokken is bij de aanval. Instrumenten voor telemetrie-analyse vullen in dit opzicht traditionele packet-capture-mechanismen goed aan, door een opdracht te geven voor selectieve capture en opslag. Anders moet u een enorme opslaginfrastructuur hebben.<\/p>\n<p>Stel een netwerk voor dat werkt met een snelheid van 250 Mbit\/s. Als u al dit volume wilt opslaan, heeft u 31 MB opslag nodig voor \u00e9\u00e9n seconde gegevensoverdracht, 1,8 GB voor \u00e9\u00e9n minuut, 108 GB voor \u00e9\u00e9n uur en 2,6 TB voor \u00e9\u00e9n dag. Voor het opslaan van dagelijkse gegevens van een netwerk met een bandbreedte van 10 Gbit\/s heeft u 108 TB opslag nodig. En sommige regelgevers vereisen dat gegevens jarenlang worden opgeslagen... De opnames 'op aanvraag', die u helpt te realiseren via stroomanalyses, helpen deze waarden met een paar factoren te verlagen. Trouwens, als we het hebben over de verhouding van de hoeveelheid opgeslagen gegevens van netwerktelemetrie en de volledige vastlegging van gegevens, is deze ongeveer 1 op 500. Voor de eerder genoemde waarden zou het opslaan van de volledige transcriptie van al het dagelijkse verkeer respectievelijk 5 en 216 GB zijn (je kunt het zelfs op een gewone USB-stick opslaan).<\/p>\n<p>Als het gaat om analysemethoden voor ruwe netwerkgegevens, verschilt de methodiek voor het vastleggen ervan nauwelijks van leverancier tot leverancier. Maar in het geval van stroomanalyse is de situatie anders. Er zijn verschillende versies van flow-protocollen, waarvan de verschillen precies in de context van beveiliging belangrijk zijn om te weten. Het populairste protocol is Netflow, ontwikkeld door Cisco. Er zijn verschillende versies van dit protocol, die vari\u00ebren in mogelijkheden en de hoeveelheid vastgelegde informatie over verkeer. De huidige versie is de negende (Netflow v9), waarop de industriestandaard Netflow v10 is gebaseerd, ook bekend als IPFIX. Tegenwoordig ondersteunen de meeste netwerkleveranciers Netflow of IPFIX in hun apparatuur. Maar er zijn ook verschillende andere varianten van flow-protocollen \u2014 sFlow, jFlow, cFlow, rFlow, NetStream, etc., waarbij sFlow de populairste is. Dit protocol wordt het vaakst ondersteund door binnenlandse producenten van netwerkapparatuur vanwege de eenvoud van implementatie. Wat zijn de belangrijkste verschillen tussen Netflow, dat als de facto standaard is geworden, en sFlow? Ik zou enkele belangrijkste verschillen willen benadrukken. Ten eerste heeft Netflow instelbare gebruikersvelden, in tegenstelling tot de vaste velden in sFlow. Ten tweede, en dit is het belangrijkste voor ons geval, verzamelt sFlow zogenaamde gesamplede telemetry; in tegenstelling tot de niet-gesamplede telemetry van Netflow en IPFIX. Wat is het verschil tussen hen?<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/96782b57ccaddd731d5084c127076d49.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nStel je voor dat je het boek \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 van mijn collega's \u2014 Gary McIntyre, Joseph Muniz en Nadeem AlFardan \u2014 wilt bekijken (via de link kun je een deel van het boek downloaden). Je hebt drie opties om dit doel te bereiken: het boek helemaal lezen, het snel doorbladeren, waarbij je om de 10e of 20e pagina stopt, of proberen een samenvatting van de belangrijkste concepten te vinden in een blog of een service zoals SmartReading. Gesamplede telemetry is als het lezen van elke \u201cpagina\u201d van het netwerkverkeer, dat wil zeggen het analyseren van metadata van elk pakket. Niet-gesamplede telemetry is selectief onderzoek van verkeer in de hoop dat in de gekozen monsters de informatie zit die je nodig hebt. Afhankelijk van de snelheid van de verbinding zal gesamplede telemetry elke 64e, 200e, 500e, 1000e, 2000e of zelfs 10000e pakket voor analyse afleveren.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/28b798498a11a5e6f72ef847ea2dbaaa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn the context of security monitoring, this means that sampled telemetry is well-suited for detecting DDoS attacks, scanning, and the spread of malware, but may miss atomic or multi-packet attacks that were not included in the sample sent for analysis. Unsampled telemetry does not have such drawbacks, and with its help, the spectrum of detectable attacks is much broader. Here\u2019s a brief list of events that can be detected using network telemetry analysis tools.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/be3a11d4826978d9c882074f22ee97c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOf course, any open-source NetFlow analyzer will not allow you this, as its primary task is to collect telemetry and perform basic analysis from an IT perspective. To identify security threats based on flow, it is necessary to equip the analyzer with various engines and algorithms that will detect cybersecurity issues based on standard or custom NetFlow fields, enrich standard data with external data from various Threat Intelligence sources, and so on.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/60e876dbfbdffd160e9899f87aa6303c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTherefore, if you have a choice, you should opt for NetFlow or IPFIX. But even if your equipment only works with sFlow, as is the case with domestic manufacturers, you can still derive benefits from it in terms of security. <\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/ee75809ccde4f366ca5f5ead7beed58c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn the summer of 2019, I conducted an analysis of the capabilities offered by Russian network equipment manufacturers, and all of them, except for NSG, Poligon, and Kraftway, claimed to support sFlow (at least, Zelaks, NatEx, Eltex, QTech, and Rusteletech). <\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/acd1ed477af59e1439d941374c596d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe volgende vraag die voor u opkomt, is waar u flow-ondersteuning voor beveiligingsdoeleinden moet implementeren? Eigenlijk is de vraag niet helemaal correct geformuleerd. Tegenwoordig is de ondersteuning voor flow-protocollen bijna altijd aanwezig op moderne apparatuur. Daarom zou ik de vraag anders formuleren \u2014 waar is het het meest effectief om telemetrie te verzamelen vanuit het oogpunt van beveiliging? Het antwoord is vrij duidelijk \u2014 op het toegangsniveau, waar u 100% van al het verkeer ziet, waar u gedetailleerde informatie over hosts (MAC, VLAN, interface-ID) heeft, en waar u zelfs P2P-verkeer tussen hosts kunt volgen, wat cruciaal is voor het opsporen van scanning en de verspreiding van malware. Op het kernniveau kunt u een deel van het verkeer eenvoudigweg niet zien, en op het perimeter-niveau ziet u hooguit een kwart van al uw netwerkverkeer. Maar als er om wat voor reden dan ook vreemde apparaten in uw netwerk zijn verschenen die aanvallers in staat stellen om 'in en uit' te gaan, terwijl ze de perimeter omzeilen, dan zal de analyse van de telemetrie daarvan u niets opleveren. Daarom is het aan te raden om de telemetrie op toegangsniveau te verzamelen voor een maximaal bereik. Daarbij moet worden opgemerkt dat zelfs als we het hebben over virtualisatie of containers, moderne virtuele switches ook vaak flow-ondersteuning hebben, wat het mogelijk maakt om verkeer daar te controleren.<\/p>\n<p>Maar aangezien ik het onderwerp heb aangesneden, moet ik de vraag beantwoorden: wat als de apparatuur, zowel fysiek als virtueel, geen flow-protocollen ondersteunt? Of als het inschakelen ervan verboden is (bijvoorbeeld in industri\u00eble segmenten voor de waarborging van betrouwbaarheid)? Of als het inschakelen leidt tot hoge belasting van de centrale processor (dat gebeurt soms op verouderde apparatuur)? Voor deze uitdaging bestaan gespecialiseerde virtuele sensoren (flow sensor), die in wezen gewone splitters zijn die het verkeer doorlaten en het in de vorm van flow naar een verzamelmodule uitzenden. In dit geval krijgen we echter een heleboel problemen, zoals we eerder hebben besproken over pakketcapture-middelen. Dat wil zeggen, men moet niet alleen de voordelen van flow-analysetechnologie begrijpen, maar ook de beperkingen ervan.<\/p>\n<p>Een ander punt dat belangrijk is om te onthouden bij het praten over analysetools voor datastromen. Waar we bij normale beveiligingsevent-generatie de maatstaf EPS (events per second) gebruiken, is deze maatstaf niet van toepassing op telemetrie-analyse; deze wordt vervangen door FPS (flows per second). Net als bij EPS kan je het niet vooraf berekenen, maar je kunt wel een schatting maken van het aantal datastromen dat een bepaald apparaat genereert, afhankelijk van zijn taak. Op internet kun je tabellen vinden met geschatte waarden voor verschillende soorten bedrijfsmatige apparaten en voorwaarden, zodat je kunt inschatten welke licenties je nodig hebt voor analysetools en wat de architectuur daarvan zal zijn. Het is namelijk zo dat de IDS-sensor een bepaalde doorvoersnelheid heeft die hij 'verdragen' kan, en ook de stroomcollector heeft zijn beperkingen die je moet begrijpen. Daarom zijn er in grote, geografisch verspreide netwerken meestal meerdere collectors. Toen ik beschreef, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">hoe het netwerk binnen Cisco wordt gemonitord,<\/a><\/noindex>, had ik al ons aantal collectors vermeld \u2014 21. En dit voor een netwerk verspreid over vijf continenten met ongeveer een half miljoen actieve apparaten).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/a5935ef7f7a3511cbf291fce59e96d71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAls monitoringoplossing voor Netflow gebruiken we onze eigen oplossing, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch<\/a><\/noindex>, dat speciaal is gericht op het oplossen van beveiligingsproblemen. Het heeft veel ingebouwde engines voor het detecteren van abnormale, verdachte en duidelijk kwaadaardige activiteiten, waardoor een breed scala aan verschillende bedreigingen kan worden gedetecteerd - van cryptomining tot gegevenslekken, van de verspreiding van malware tot fraude. Net als de meeste flow-analyzers is Stealthwatch gebouwd volgens een drievoudig schema (generator - verzamelaar - analyzer), maar het is aangevuld met een aantal interessante kenmerken die belangrijk zijn in de context van het onderwerp. Ten eerste integreert het met oplossingen voor pakketcaptatie (bijvoorbeeld Cisco Security Packet Analyzer), waardoor geselecteerde netwerksessies kunnen worden opgenomen voor verdere diepgaande onderzoek en analyse. Ten tweede hebben we speciaal voor het uitbreiden van beveiligingstaken een speciaal protocol ontwikkeld, nvzFlow, dat het mogelijk maakt om de activiteit van applicaties op eindpunten (servers, werkstations, enz.) te 'streamen' naar telemetrie en deze door te geven aan de verzamelaar voor verdere analyse. Terwijl Stealthwatch in zijn oorspronkelijke vorm werkt met elk flow-protocol (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) op netwerkniveau, maakt de ondersteuning van nvzFlow correlatie van gegevens op het niveau van de knoop mogelijk, waardoor de effectiviteit van het hele systeem wordt verhoogd en er meer aanvallen kunnen worden waargenomen dan met gewone netflow-analyzers.<\/p>\n<p>Het is duidelijk dat als we het over Netflow-analyse systemen vanuit het beveiligingsoogpunt hebben, de markt niet alleen door \u00e9\u00e9n oplossing van Cisco wordt beperkt. U kunt zowel commerci\u00eble als gratis of quasi-vrij oplossingen gebruiken. Het is een beetje vreemd als ik in de Cisco-blog voorbeelden van concurrentieoplossingen zou geven, daarom wil ik een paar woorden zeggen over hoe netwerktelemetrie kan worden geanalyseerd met behulp van twee populaire, qua naam vergelijkbare, maar toch verschillende tools - SiLK en ELK.<\/p>\n<p>SiLK is een set van tools (the System for Internet-Level Knowledge) voor het analyseren van verkeer, ontwikkeld door het Amerikaanse CERT\/CC, en ondersteunt, in de context van dit artikel, Netflow (de meest populaire versies 5 en 9), IPFIX en sFlow. Met behulp van verschillende hulpprogramma's (rwfilter, rwcount, rwflowpack, enz.) kunt u verschillende bewerkingen uitvoeren op netwerktelemetrie om tekenen van ongeoorloofd gedrag te detecteren. Het is echter belangrijk om een paar belangrijke punten te benadrukken. SiLK is een commandoregeltool en biedt operationele analyse met commando's zoals (detectie van ICMP-pakketten groter dan 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>niet erg handig. U kunt de grafische interface iSiLK gebruiken, maar deze zal uw leven niet veel gemakkelijker maken, omdat deze alleen de functie van visualisatie vervult en geen vervanging is voor een analist. Dit is het tweede punt. In tegenstelling tot commerci\u00eble oplossingen, die een solide analytische basis, algoritmen voor anomaliedetectie, bijbehorende workflows, enz. al hebben ingebouwd, moet u met SiLK alles zelf doen, wat andere vaardigheden van u vereist dan het gebruik van al kant-en-klaar gereed tools. Dit is niet per se slecht of goed; het is een kenmerk van bijna elke gratis tool die veronderstelt dat u weet wat u moet doen en die u daar alleen bij helpt (commerci\u00eble tools zijn minder afhankelijk van de vaardigheden van hun gebruikers, hoewel ze ook veronderstellen dat analisten ten minste de basisprincipes van netwerkinvestigaties en monitoring begrijpen). Maar laten we terugkeren naar SiLK. De werkwijze van een analist hiermee ziet er als volgt uit:<\/p>\n<ul>\n<li>Het formuleren van een hypothese. We moeten begrijpen wat we binnen de netwerktelemetrie gaan zoeken en welke unieke attributen we zullen gebruiken om bepaalde anomalie\u00ebn of dreigingen te identificeren.<\/li>\n<li>Het opbouwen van een model. Na het formuleren van de hypothese programmeren we deze met behulp van Python, shell of andere tools die niet in SiLK zijn opgenomen.<\/li>\n<li>Testen. Het is tijd om de juistheid van onze hypothese te controleren, die wordt bevestigd of weerlegd met behulp van SiLK-tools die beginnen met 'rw', 'set', 'bag'.<\/li>\n<li>Analyse van echte gegevens. In de industri\u00eble toepassing helpt SiLK ons om iets te identificeren, en de analist moet vragen beantwoorden zoals: \"Hebben we gevonden wat we verwachtten?\", \"Voldoet dit aan onze hypothese?\", \"Hoe kunnen we het aantal valse positieven verminderen?\", \"Hoe kunnen we het herkenningsniveau verbeteren?\" enzovoort.<\/li>\n<li>Verbetering. In de laatste fase verbeteren we wat eerder is gedaan \u2014 we cre\u00ebren sjablonen, verbeteren en optimaliseren de code, herformuleren en verduidelijken de hypothese, en meer.<\/li>\n<\/ul>\n<p>Deze cyclus is ook toepasbaar op Cisco Stealthwatch, hoewel de laatste deze vijf stappen zo veel mogelijk automatiseert, wat het aantal fouten van de analist vermindert en de snelheid van incidentdetectie verhoogt. Bijvoorbeeld, in SiLK kunt u netwerkstatistieken verrijken met externe gegevens over malafide IP-adressen met behulp van zelfgeschreven scripts, terwijl Cisco Stealthwatch deze functie ingebouwd heeft die meteen een alarm toont als er interactie met IP-adressen in de zwarte lijst in het netwerkverkeer voorkomt.<\/p>\n<p>Als we hoger op de 'betalings'-piramide van flow-analyse software kijken, dan komt na de volledige gratis SiLK de voorwaardelijk gratis ELK, die bestaat uit drie kerncomponenten \u2014 Elasticsearch (indexering, zoeken en data-analyse), Logstash (data-invoer\/uitvoer) en Kibana (visualisatie). In tegenstelling tot SiLK, waar alles handmatig geschreven moet worden, heeft ELK al veel kant-en-klare bibliotheken\/modules (gedeeltelijk betaald, gedeeltelijk gratis) die de analyse van netwerktelemetrie automatiseren. Bijvoorbeeld, de GeoIP-filter in Logstash maakt het mogelijk om waargenomen IP-adressen aan hun geografische locatie te koppelen (deze functie is ingebouwd in Stealthwatch).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/addd9d9656f64f81d86a0cce8ee0810b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nELK heeft ook een grote community die ontbrekende componenten voor deze monitoringsoplossing aanvult. Om met Netflow, IPFIX en sFlow te werken, kunt u de module gebruiken <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/robcowart\/elastiflow\">elastiflow<\/a><\/noindex>, als de Logstash Netflow Module, die alleen Netflow ondersteunt, niet aan uw eisen voldoet.<\/p>\n<p>Hoewel ELK momenteel meer snelheid biedt bij het verzamelen van flow en het zoeken daarin, ontbreekt het aan rijke ingebouwde analytics voor het detecteren van anomalie\u00ebn en bedreigingen in netwerktelemetrie. Dit betekent dat u, volgens de eerder beschreven levenscyclus, zelf in staat moet zijn om schendingmodellen te beschrijven en deze vervolgens in het productie systeem te gebruiken (er zijn geen ingebouwde modellen).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/6d8368f4c130c3a5770890cb6c5fe5ab.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEr zijn zeker meer geavanceerde extensies voor ELK, waarin al bepaalde modellen voor het detecteren van anomalie\u00ebn in netwerktelemetrie zijn ingebouwd, maar dergelijke extensies kosten geld en dan is de vraag of het de moeite waard is - moet je zelf een vergelijkbaar model schrijven, de implementatie ervan kopen voor je monitoringtool, of een kant-en-klare oplossing voor Netwerkanalyse aanschaffen.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/d938ebb4271c4dfb73a1e4b6e94c91d6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIk wil eigenlijk niet in de discussie treden of het beter is om geld uit te geven en een kant-en-klare oplossing voor het monitoren van anomalie\u00ebn en bedreigingen in netwerktelemetrie (bijvoorbeeld Cisco Stealthwatch) aan te schaffen, of zelf uit te zoeken en elk nieuwe bedreiging met SiLK, ELK of nfdump of OSU Flow Tools (ik bedoel de laatste twee) aan te passen. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">verteld<\/a><\/noindex> Iedereen kiest voor zichzelf en heeft zijn eigen redenen om voor een van de twee opties te kiezen. Ik wilde gewoon laten zien dat netwerktelemetrie een zeer belangrijk instrument is voor het waarborgen van de netwerkbeveiliging van je interne infrastructuur, en dat je dit niet moet verwaarlozen om niet op de lijst te belanden van bedrijven wiens naam in de media wordt genoemd samen met de epitheta 'gekrackt', 'niet voldaan aan de eisen voor informatiebeveiliging', 'niet nadenkend over de veiligheid van hun gegevens en die van klanten'.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/de7df67df66b7abe89170c7f92fcefca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOm samen te vatten, wil ik enkele belangrijke tips opsommen die je zou moeten volgen bij het opzetten van informatiebeveiligingsmonitoring voor je interne infrastructuur:<\/p>\n<ol>\n<li>Beperk je niet tot alleen de perimeter! Gebruik (en kies) netwerk infrastructuur niet alleen voor het verzenden van verkeer van punt A naar punt B, maar ook voor het oplossen van vragen rond cyberbeveiliging.<\/li>\n<li>Bestudeer de bestaande monitoringmechanismen voor informatiebeveiliging in je netwerkapparatuur en maak er gebruik van.<\/li>\n<li>Voor interne monitoring geef de voorkeur aan het analyseren van telemetrie - dit maakt het mogelijk om tot 80-90% van alle netwerkincidenten in informatiebeveiliging te detecteren, wat onmogelijk is bij het vastleggen van netwerkpakketten en ruimte bespaart voor het opslaan van alle informatiebeveiligingsgebeurtenissen.<\/li>\n<li>Voor het monitoren van stromen gebruik Netflow v9 of IPFIX - zij bieden meer informatie in de context van veiligheid en stellen je in staat om niet alleen IPv4 te monitoren, maar ook IPv6, MPLS, enzovoort.<\/li>\n<li>Gebruik een niet-geampelde flowprotocol - dit biedt meer informatie voor bedreigingsdetectie. Bijvoorbeeld, Netflow of IPFIX.<\/li>\n<li>Controleer de belasting van uw netwerkapparatuur \u2013 misschien kan het niet omgaan met de verwerking van het flow-protocol. Denk dan na over de toepassing van virtuele sensoren of een Netflow Generation Appliance.<\/li>\n<li>Implementeer controle in de eerste plaats op het toegangsniveau \u2013 dit geeft u de mogelijkheid om 100% van al het verkeer te zien.<\/li>\n<li>Als u geen andere keuze heeft en Russische netwerkapparatuur gebruikt, kies dan die welke flow-protocollen ondersteunt of SPAN\/RSPAN-poorten heeft.<\/li>\n<li>Combineer inbraakdetectie\/perceptie systemen aan de randen met flow-analyse systemen in uw interne netwerk (ook in de cloud).<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/c54e4b02a906f470bbfb617f48cdd216.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWat betreft de laatste tip, wil ik een illustratie geven die ik eerder al heb genoemd. U ziet dat als voorheen de security dienst van Cisco bijna volledig haar monitoring systeem bouwde op basis van inbraakdetectiesystemen en handtekeningenmethoden, nu slechts 20% van de incidenten daarop berust. Nog eens 20% komt uit flow-analyse systemen, wat aantoont dat deze oplossingen geen luxe zijn, maar een echt instrument in de activiteit van moderne beveiligingsdiensten in een bedrijf. Bovendien heeft u voor implementatie het belangrijkste \u2013 een netwerkinfrastructuur, waarvan u de investeringen extra kunt beschermen door de netwerken ook functies voor beveiligingsmonitoring te geven.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-protocollen als hulpmiddel voor netwerkbewaking van de interne beveiliging\" src=\"\/wp-content\/uploads\/2019\/08\/2166f265222c43b0b2cbbcf4091c1f8c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIk heb bewust het onderwerp van reageren op ontdekte anomalie\u00ebn of bedreigingen in netwerkstromen niet aangeraakt, maar begrijp dat monitoring niet alleen het detecteren van een bedreiging moet zijn. Het moet gevolgd worden door een reactie, bij voorkeur in automatische of geautomatiseerde modus. Maar dat is al een onderwerp voor apart materiaal.<\/p>\n<p>Aanvullende informatie:<\/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\">Beschrijving van 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 van Netflow-ondersteuning in verschillende Cisco-oplossingen<\/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\">Handleiding voor het instellen van Netflow op verschillende Cisco-platformen<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/sflow.org\">sFlow gemeenschap<\/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\">Laboratoriumwerk voor het gebruik van Stealthwatch, SiLK en ELK voor Netflow-analyse vanuit een beveiligingsperspectief<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/\">SiLK-website<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/analysis-handbook.pdf\">Een driehonderd pagina tellende handleiding voor het gebruik van SiLK met veel voorbeelden<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/logstash\/current\/netflow-module.html\">Logstash Netflow-module<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.cisco.com\/security\/step-by-step-setup-of-elk-for-netflow-analytics\">Stapsgewijze handleiding van Cisco voor Netflow-analyse in ELK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/307528\/\">Analyse van NetFlow v.9 Cisco ASA met 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-oplossing<\/a><\/noindex><\/li>\n<\/ul>\n<p>P.S. Als u het makkelijker vindt om dit alles wat hierboven is geschreven te horen, kunt u een uur durende presentatie bekijken die de basis vormde voor deze notitie.<\/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=\"Video afspelen\" 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 \/>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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-protocollen als hulpmiddel voor het bewaken van de beveiliging van het interne netwerk | ProHoster","description":"Wanneer het gaat om het bewaken van de beveiliging van een interne bedrijfs- of overheidsnetwerk, hebben velen de associatie met het voorkomen van datalekken en de implementatie van DLP-oplossingen.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/37437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=37437"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/37437\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/28091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=37437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=37437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=37437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}