{"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\/de\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","title":{"rendered":"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Wenn es um die Sicherheits\u00fcberwachung von internen Unternehmens- oder Beh\u00f6rdennetzen geht, denken viele an den Schutz vor Datenlecks und die Implementierung von DLP-L\u00f6sungen. Wenn man jedoch die Frage pr\u00e4zisieren und fragen w\u00fcrde, wie Sie Angriffe im internen Netzwerk erkennen, w\u00e4re die Antwort in der Regel der Hinweis auf Intrusion Detection Systeme (IDS). Was fr\u00fcher noch die einzige Option vor 10-20 Jahren war, wird heute zum Anachronismus. Es gibt eine effektivere \u2013 und manchmal sogar die einzige \u2013 M\u00f6glichkeit zur \u00dcberwachung interner Netzwerke: die Nutzung von Flow-Protokollen, die urspr\u00fcnglich zur Fehlersuche (Troubleshooting) entwickelt wurden, sich aber im Laufe der Zeit zu einem sehr interessanten Sicherheitstool entwickelt haben. In diesem Artikel werden wir dar\u00fcber sprechen, welche Flow-Protokolle existieren, welche davon am besten dabei helfen, Netzwerkangriffe zu erkennen, wo die \u00dcberwachung von Flows am besten implementiert werden sollte, worauf man bei der Einrichtung eines solchen Systems achten sollte und sogar, wie man das alles auf heimischer Hardware umsetzen kann.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Ich will nicht auf die Frage eingehen: \u201eWarum ist die Sicherheits\u00fcberwachung der internen Infrastruktur notwendig?\u201c Die Antwort darauf scheint klar zu sein. Aber wenn Sie sich dennoch erneut \u00fcberzeugen m\u00f6chten, dass man heute ohne das nicht auskommt, <noindex><a rel=\"nofollow\" href=\"https:\/\/gblogs.cisco.com\/ru\/17attackvectors\/\">schauen Sie sich<\/a><\/noindex> ein kurzes Video, das zeigt, wie man auf 17 verschiedene Arten in ein durch eine Firewall gesch\u00fctztes Unternehmensnetz eindringen kann. Daher betrachten wir es als gegeben, dass wir verstehen, dass interne \u00dcberwachung notwendig ist, und es bleibt nur zu kl\u00e4ren, wie man sie organisieren kann.<\/p>\n<p>Ich w\u00fcrde drei Schl\u00fcsselquellen f\u00fcr die Daten\u00fcberwachung auf Netzwerkebene hervorheben:<\/p>\n<ul>\n<li>den \u201erohen\u201c Datenverkehr, den wir erfassen und zur Analyse an spezielle Systeme \u00fcbergeben,<\/li>\n<li>Ereignisse von Netzwerkger\u00e4ten, durch die der Datenverkehr flie\u00dft,<\/li>\n<li>Informationen \u00fcber den Datenverkehr, die \u00fcber eines der Flow-Protokolle erhalten werden.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/09c7087593661d5b159ecc9e9ab39d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Erfassung von Rohdatenverkehr ist die beliebteste Methode unter Sicherheitsfachleuten, da sie historisch die erste war. \u00dcbliche Intrusion Detection Systeme (IDS) \u2014 das erste kommerzielle IDS war NetRanger von der Firma Wheel Group, das 1998 von Cisco \u00fcbernommen wurde \u2014 besch\u00e4ftigten sich mit der Paket- (und sp\u00e4ter auch mit der Sitzungs-) Erfassung, um nach bestimmten Signaturen (den \"entscheidenden Regeln\" in der Terminologie von FSTEK) zu suchen, die auf Angriffe hinweisen. Nat\u00fcrlich kann Rohdatenverkehr nicht nur mit IDS analysiert werden, sondern auch mit anderen Tools (z.B. Wireshark, tcpdump oder der NBAR2-Funktion in Cisco IOS), jedoch fehlen diesen oft die Wissensdatenbanken, die ein Sicherheitsinstrument von einem gew\u00f6hnlichen IT-Werkzeug unterscheiden.<\/p>\n<p>Also, Intrusion Detection Systeme. Die \u00e4lteste und beliebteste Methode zur Erkennung von Netzwerkangriffen, die ihre Aufgabe am Perimeter (unabh\u00e4ngig davon, ob es sich um einen Unternehmens-, Rechenzentrum- oder Segmentperimeter handelt) recht gut erf\u00fcllt, aber in modernen Switch- und Software-definierten Netzwerken versagt. Bei einem Netzwerk, das auf normalen Switches basiert, wird die Infrastruktur der Angriffserkennungssensoren zu gro\u00df \u2014 man m\u00fcsste f\u00fcr jede Verbindung mit einem Knoten, dessen Angriffe man \u00fcberwachen m\u00f6chte, einen Sensor installieren. Jeder Hersteller wird sicherlich bereit sein, Ihnen Hunderte oder Tausende von Sensoren zu verkaufen, aber ich bezweifle, dass Ihr Budget solche Ausgaben verkraften kann. Ich kann sagen, dass selbst bei Cisco (wo wir NGIPS entwickeln) wir das nicht geschafft haben, auch wenn es scheinbar kein Preisproblem f\u00fcr uns geben sollte \u2014 es ist schlie\u00dflich unsere eigene L\u00f6sung. Zudem stellt sich die Frage, wie man in solch einem Fall einen Sensor anschlie\u00dfen soll? In die Leitung? Und was, wenn der Sensor selbst ausf\u00e4llt? Soll der Sensor einen Bypass-Modul erfordern? Soll man Taps verwenden? All dies verteuert die L\u00f6sung und macht sie unerschwinglich f\u00fcr Unternehmen jeder Gr\u00f6\u00dfe.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/4763c13237dbe9ffa38d62075939ffba.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSie k\u00f6nnen versuchen, einen Sensor an einen SPAN\/RSPAN\/ERSPAN-Port zu \u201eh\u00e4ngen\u201c und den Verkehr von den erforderlichen Ports des Switches darauf zu leiten. Diese Option mindert teilweise das Problem, das im vorherigen Absatz beschrieben wurde, bringt aber ein anderes mit sich \u2013 der SPAN-Port kann nicht den gesamten Verkehr aufnehmen, der ihm zugef\u00fchrt wird \u2013 er hat nicht gen\u00fcgend Bandbreite. Es wird notwendig sein, auf etwas zu verzichten. Entweder bestimmte Knoten ohne \u00dcberwachung lassen (in diesem Fall m\u00fcssen Sie sie priorisieren), oder nur bestimmten Verkehr von einem Knoten leiten. In jedem Fall k\u00f6nnen wir einige Angriffe \u00fcbersehen. Dar\u00fcber hinaus kann der SPAN-Port f\u00fcr andere Zwecke genutzt werden. Daher m\u00fcssen wir die bestehende Netzwerktopologie \u00fcberdenken und m\u00f6glicherweise Anpassungen vornehmen, um Ihre gesamte Netzwerk mit der vorhandenen Anzahl von Sensoren maximal abzudecken (und dies mit der IT abzustimmen).<\/p>\n<p>Was ist, wenn Ihr Netzwerk asymmetrische Routen verwendet? Was ist, wenn Sie SDN implementiert haben oder es geplant ist? Was ist, wenn Sie virtualisierte Maschinen oder Container \u00fcberwachen m\u00fcssen, deren Verkehr \u00fcberhaupt nicht den physischen Switch erreicht? Diese Fragen m\u00f6gen die Hersteller traditioneller IDS nicht, weil sie nicht wissen, wie sie darauf antworten sollen. M\u00f6glicherweise werden sie versuchen, Sie davon zu \u00fcberzeugen, dass all diese modernen Technologien nur ein Hype sind und Sie ihn nicht ben\u00f6tigen. Vielleicht werden sie \u00fcber die Notwendigkeit sprechen, klein anzufangen. Oder sie werden Ihnen sagen, dass Sie eine leistungsstarke Maschine im Zentrum des Netzwerks installieren und den gesamten Verkehr mit Hilfe von Load Balancern dorthin leiten sollten. Welche Option auch immer Ihnen angeboten wird, Sie m\u00fcssen selbst klar verstehen, wie gut sie zu Ihnen passt. Und erst danach sollten Sie eine Entscheidung \u00fcber den Ansatz zur \u00dcberwachung der IT-Sicherheit Ihrer Netzwerkinfrastruktur treffen. Zur\u00fcck zum Paketfang m\u00f6chte ich sagen, dass diese Methode weiterhin sehr beliebt und wichtig ist, aber ihr Hauptzweck ist die Kontrolle der Grenzen; Grenzen zwischen Ihrer Organisation und dem Internet, Grenzen zwischen dem Rechenzentrum und dem restlichen Netzwerk, Grenzen zwischen der Automatisierungstechnik und dem Unternehmensbereich. An diesen Stellen haben klassische IDS\/IPS weiterhin das Recht auf Existenz und bew\u00e4ltigen die gestellten Aufgaben gut.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/7a5898e0aa9e3e9275dda3e2c7b75c5c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLass uns zur zweiten Variante \u00fcbergehen. Die Analyse von Ereignissen, die von Netzwerkger\u00e4ten empfangen werden, kann ebenfalls zur Entdeckung von Angriffen verwendet werden, jedoch nicht als prim\u00e4rer Mechanismus, da sie nur eine kleine Klasse von Eindringlingen erkennen kann. Zudem ist sie reaktiv \u2014 ein Angriff muss zuerst geschehen, dann muss er von dem Netzwerkger\u00e4t aufgezeichnet werden, das auf irgendeine Weise ein Signal \u00fcber ein Problem in der IT-Sicherheit sendet. Es gibt mehrere solcher Methoden. Dies kann \u00fcber Syslog, RMON oder SNMP geschehen. Die letzten beiden Protokolle zur Netzwerk\u00fcberwachung im Kontext der IT-Sicherheit werden nur eingesetzt, wenn wir eine DoS-Attacke auf das Netzwerkger\u00e4t selbst identifizieren m\u00fcssen, da man mit RMON und SNMP z. B. die Auslastung der zentralen Verarbeitungseinheit des Ger\u00e4ts oder seiner Schnittstellen \u00fcberwachen kann. Dies ist eine der \u201eg\u00fcnstigsten\u201c Methoden (Syslog oder SNMP sind \u00fcberall verf\u00fcgbar), aber auch die ineffektivste Methode zur \u00dcberwachung der IT-Sicherheit der internen Infrastruktur \u2014 viele Angriffe bleiben einfach verborgen. Nat\u00fcrlich sollten sie nicht vernachl\u00e4ssigt werden, und die Analyse von Syslog hilft Ihnen, rechtzeitig \u00c4nderungen in der Konfiguration des Ger\u00e4ts selbst zu erkennen, sowie dessen Kompromittierung. Aber zur Entdeckung von Angriffen auf das gesamte Netzwerk ist dies nicht sehr geeignet.<\/p>\n<p>Die dritte Variante ist die Analyse von Informationen \u00fcber den Verkehr, der durch ein Ger\u00e4t flie\u00dft, das eines der mehreren Flow-Protokolle unterst\u00fctzt. In diesem Fall besteht die Infrastruktur zur Verarbeitung von Flows unabh\u00e4ngig vom Protokoll unbedingt aus drei Komponenten:<\/p>\n<ul>\n<li>Generierung oder Export von Flows. Diese Rolle wird normalerweise einem Router, Switch oder einem anderen Netzwerkger\u00e4t zugewiesen, das, w\u00e4hrend es den Netzwerkverkehr durchl\u00e4sst, erm\u00f6glicht, Schl\u00fcsseldaten daraus zu extrahieren, die dann an das Sammelmodul \u00fcbermittelt werden. Zum Beispiel wird das Netflow-Protokoll bei Cisco nicht nur auf Routern und Switches unterst\u00fctzt, einschlie\u00dflich virtueller und industrieller, sondern auch auf drahtlosen Controllern, Firewalls und sogar Servern.<\/li>\n<li>Sammeln von Flows. Angesichts der Tatsache, dass in modernen Netzwerken in der Regel mehr als ein Netzwerkger\u00e4t vorhanden ist, besteht die Aufgabe darin, die Flows zu sammeln und zu konsolidieren, die mit Hilfe von sogenannten Collectoren gel\u00f6st wird, die die empfangenen Flows verarbeiten und sie dann zur Analyse \u00fcbermitteln.<\/li>\n<li>Flow-Analyse. Der Analysator \u00fcbernimmt die Hauptaufgabe der Intelligenz und wendet verschiedene Algorithmen auf die Str\u00f6me an, um bestimmte Schlussfolgerungen zu ziehen. Beispielsweise kann ein solcher Analysator innerhalb der IT-Funktion Engp\u00e4sse im Netzwerk identifizieren oder das Traffic-Profil zur weiteren Optimierung des Netzwerks analysieren. Im Bereich der Informationssicherheit kann ein solcher Analysator Datenlecks, die Verbreitung von Malware oder DoS-Angriffe erkennen. <\/li>\n<\/ul>\n<p>Man sollte nicht denken, dass eine solche dreistufige Architektur zu kompliziert ist \u2013 alle anderen Optionen (au\u00dfer vielleicht Netzwerkanalysesysteme, die mit SNMP und RMON arbeiten) funktionieren ebenfalls gem\u00e4\u00df dieser. Wir haben einen Datengenerator zur Analyse, der durch ein Netzwerkger\u00e4t oder einen eigenst\u00e4ndigen Sensor repr\u00e4sentiert wird. Es gibt ein System zur Erfassung von Alarmmeldungen und ein System zur Verwaltung der gesamten \u00dcberwachungsinfrastruktur. Die letzten beiden Komponenten k\u00f6nnen in einem Knoten zusammengefasst werden, aber in mehr oder weniger gro\u00dfen Netzwerken sind sie in der Regel auf mindestens zwei Ger\u00e4te verteilt, um Skalierbarkeit und Zuverl\u00e4ssigkeit zu gew\u00e4hrleisten.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/65de74b0a7556606355f9b176ef7e19c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIm Gegensatz zur Paket-Analyse, die auf der Untersuchung der Kopfzeilen und der Inhalte jedes Pakets sowie der aus ihnen bestehenden Sessions basiert, st\u00fctzt sich die Flow-Analyse auf die Erfassung von Metadaten \u00fcber den Netzwerkverkehr. Wann, wie viel, von wo und wohin, wie\u2026 das sind die Fragen, die die Analyse der Netzwerk-Telemetrie mithilfe verschiedener Flow-Protokolle beantwortet. Urspr\u00fcnglich wurden sie zur Analyse von Statistiken und zur Erkennung von IT-Problemen im Netzwerk eingesetzt, aber mit der Entwicklung analytischer Mechanismen wurden sie auch f\u00fcr dieselbe Telemetrie zu Sicherheitszwecken anwendbar. Hier ist es wichtig zu betonen, dass die Flow-Analyse die Paketauffangung nicht ersetzt oder annulliert. Jede dieser Methoden hat ihr eigenes Anwendungsgebiet. Aber im Kontext dieses Artikels ist die Flow-Analyse am besten geeignet, um die interne Infrastruktur zu \u00fcberwachen. Sie verf\u00fcgen \u00fcber Netzwerkger\u00e4te (und es spielt keine Rolle, ob sie in einer softwaredefinierten Paradigma oder gem\u00e4\u00df statischen Regeln arbeiten), die nicht umgangen werden k\u00f6nnen. Ein Sensor einer klassischen IDS kann umgangen werden, ein Netzwerkger\u00e4t, das das Flow-Protokoll unterst\u00fctzt, jedoch nicht. Das ist der Vorteil dieser Methode. <\/p>\n<p>Andererseits, wenn Sie Beweise f\u00fcr die Strafverfolgungsbeh\u00f6rden oder Ihre eigene Incident-Response-Gruppe ben\u00f6tigen, kommen Sie um die Paketerfassung nicht herum \u2013 Netzwerk-Telemetrie ist kein Abbild des Traffics, das f\u00fcr die Beweissicherung verwendet werden kann; sie ist erforderlich f\u00fcr die schnelle Erkennung und Entscheidungsfindung im Bereich IT-Sicherheit. Andererseits k\u00f6nnen Sie mit der Analyse der Telemetrie nicht den gesamten Netzwerktraffic \u201eaufzeichnen\u201c (f\u00fcr den Fall, dass Cisco und Rechenzentren sich darum k\u00fcmmern :-), sondern nur den, der an einem Angriff beteiligt ist. Die Werkzeuge zur Analyse der Telemetrie erg\u00e4nzen in diesem Sinne gut die traditionellen Mechanismen der Paketerfassung, indem sie das selektive Erfassen und Speichern anordnen. Andernfalls m\u00fcssten Sie \u00fcber eine enorme Speicherinfrastruktur verf\u00fcgen.<\/p>\n<p>Stellen Sie sich ein Netzwerk vor, das mit 250 Mbit\/s arbeitet. Wenn Sie diesen gesamten Datenverkehr speichern m\u00f6chten, ben\u00f6tigen Sie 31 MB Speicherplatz f\u00fcr eine Sekunde Daten\u00fcbertragung, 1,8 GB f\u00fcr eine Minute, 108 GB f\u00fcr eine Stunde und 2,6 TB f\u00fcr einen Tag. Um die t\u00e4glichen Daten eines Netzwerks mit einer Bandbreite von 10 Gbit\/s zu speichern, ben\u00f6tigen Sie 108 TB Speicherplatz. Und schlie\u00dflich verlangen einige Regulierungsbeh\u00f6rden, dass sicherheitsrelevante Daten jahrelang aufbewahrt werden... Die \u201eOn-Demand\u201c-Aufzeichnung, die Ihnen die Analyse der Str\u00f6me erm\u00f6glicht, hilft, diese Werte um Gr\u00f6\u00dfenordnungen zu reduzieren. \u00dcbrigens, im Verh\u00e4ltnis des Volumens der aufgezeichneten Daten der Netzwerk-Telemetrie zur vollst\u00e4ndigen Datenerfassung betr\u00e4gt es etwa 1 zu 500. F\u00fcr die oben angegebenen Werte w\u00fcrde die Speicherung der vollst\u00e4ndigen Entschl\u00fcsselung des gesamten Tagesverkehrs 5 GB bzw. 216 GB betragen (man k\u00f6nnte es sogar auf einen normalen USB-Stick speichern).<\/p>\n<p>Wenn bei der Analyse von Rohnetzwerkdaten die Methode ihrer Erfassung nahezu identisch ist, egal von welchem Anbieter, verh\u00e4lt es sich bei der Analyse von Fl\u00fcssen anders. Es gibt mehrere Varianten von Flow-Protokollen, \u00fcber deren Unterschiede man insbesondere im Kontext der Sicherheit informiert sein sollte. Das bekannteste ist das Netflow-Protokoll, entwickelt von Cisco. Es gibt mehrere Versionen dieses Protokolls, die sich in ihren M\u00f6glichkeiten und dem Umfang der aufgezeichneten Verkehrsinformationen unterscheiden. Die aktuelle Version ist die neunte (Netflow v9), auf deren Basis der Industriestandard Netflow v10, auch bekannt als IPFIX, entwickelt wurde. Heute unterst\u00fctzen die meisten Netzwerkanbieter genau dieses Netflow oder IPFIX in ihrer Hardware. Aber es gibt auch verschiedene andere Varianten von Flow-Protokollen \u2013 sFlow, jFlow, cFlow, rFlow, NetStream usw., von denen sFlow am popul\u00e4rsten ist. Dieser wird von inl\u00e4ndischen Herstellern von Netzwerkhardware aufgrund der einfachen Implementierung am h\u00e4ufigsten unterst\u00fctzt. Was sind die entscheidenden Unterschiede zwischen Netflow, das de facto zum Standard geworden ist, und sFlow? Ich w\u00fcrde mehrere wesentliche Unterschiede herausstellen. Erstens hat Netflow konfigurierbare Benutzerfelder im Gegensatz zu den festen Feldern in sFlow. Zweitens und das ist am wichtigsten in unserem Fall, sFlow sammelt sogenannte sampling Telemetrie; im Gegensatz zur nicht-sampling Telemetrie von Netflow und IPFIX. Was ist der Unterschied zwischen ihnen?<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/96782b57ccaddd731d5084c127076d49.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nStellen Sie sich vor, Sie m\u00f6chten das Buch \"<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>\" meiner Kollegen \u2013 Gary McIntyre, Joseph Muniz und Nadeem AlFardan (\u00fcber den Link k\u00f6nnen Sie einen Teil des Buches herunterladen). Sie haben drei M\u00f6glichkeiten, Ihr Ziel zu erreichen \u2013 das Buch vollst\u00e4ndig zu lesen, es \u00fcberfliegend zu durchbl\u00e4ttern und dabei auf jeder 10. oder 20. Seite anzuhalten oder zu versuchen, eine Zusammenfassung der Schl\u00fcsselkonzepte in einem Blog oder einem Dienst wie SmartReading zu finden. So ist die nicht-sampling Telemetrie das Lesen jeder \u201cSeite\u201d des Netzwerkverkehrs, d.h. die Analyse von Metadaten f\u00fcr jedes Paket. Sampling Telemetrie ist das selektive Studieren des Verkehrs in der Hoffnung, dass in den gew\u00e4hlten Proben das, was Sie ben\u00f6tigen, enthalten ist. Je nach Bandbreite gibt die Sampling Telemetrie f\u00fcr die Analyse jedes 64., 200., 500., 1000., 2000. oder sogar 10000. Paket zur\u00fcck.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/28b798498a11a5e6f72ef847ea2dbaaa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIm Kontext der \u00dcberwachung der IT-Sicherheit bedeutet dies, dass die gesampelte Telemetrie gut geeignet ist, um DDoS-Angriffe, Scans und die Verbreitung von Malware zu erkennen, jedoch atomare oder mehrteilige Angriffe, die nicht im Sample enthalten sind, \u00fcbersehen kann. Die unsampelte Telemetrie hat solche Nachteile nicht und mit ihrer Hilfe ist das Spektrum der erkennbaren Angriffe viel breiter. Hier ist eine kleine Liste von Ereignissen, die mithilfe von Analysewerkzeugen f\u00fcr Netzwerktelemetrie erkannt werden k\u00f6nnen.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/be3a11d4826978d9c882074f22ee97c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNat\u00fcrlicherweise wird Ihnen kein Open-Source-Netflow-Analyzer dies erm\u00f6glichen, da seine Hauptaufgabe darin besteht, Telemetrie zu sammeln und eine grundlegende Analyse aus IT-Perspektive durchzuf\u00fchren. Um Bedrohungen der IT-Sicherheit auf der Basis von Flow zu identifizieren, muss der Analyzer mit verschiedenen Engines und Algorithmen ausgestattet werden, die dann basierend auf Standard- oder benutzerdefinierten Netflow-Feldern Sicherheitsprobleme identifizieren und Standarddaten mit externen Daten von verschiedenen Threat-Intelligence-Quellen anreichern.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/60e876dbfbdffd160e9899f87aa6303c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWenn Sie also die Wahl haben, entscheiden Sie sich f\u00fcr Netflow oder IPFIX. Aber selbst wenn Ihre Hardware nur mit sFlow funktioniert, wie es bei inl\u00e4ndischen Herstellern der Fall ist, k\u00f6nnen Sie auch in diesem Fall Vorteile im Sicherheitskontext daraus ziehen. <\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/ee75809ccde4f366ca5f5ead7beed58c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIm Sommer 2019 f\u00fchrte ich eine Analyse der M\u00f6glichkeiten durch, die die russischen Hersteller von Netzwerkhardware bieten, und alle, mit Ausnahme von NSG, Polygon und Kraftway, behaupteten die Unterst\u00fctzung von sFlow (mindestens Zela\u0441k, Natex, Eltex, QTech, Rusteletech). <\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/acd1ed477af59e1439d941374c596d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie n\u00e4chste Frage, die sich Ihnen stellen wird, ist: Wo implementieren Sie die Unterst\u00fctzung f\u00fcr Flows zu Sicherheitszwecken? Tats\u00e4chlich ist die Frage nicht ganz korrekt formuliert. Auf moderner Hardware ist die Unterst\u00fctzung f\u00fcr Flow-Protokolle nahezu immer vorhanden. Deshalb w\u00fcrde ich die Frage anders umformulieren \u2014 wo ist es am effektivsten, Telemetrie aus sicherheitsrelevanter Sicht zu sammeln? Die Antwort wird recht offensichtlich sein \u2014 auf Zugangsebene, wo Sie 100% des Verkehrs sehen, wo Sie detaillierte Informationen zu Hosts (MAC, VLAN, Schnittstellen-ID) erhalten, und wo Sie sogar P2P-Verkehr zwischen Hosts verfolgen k\u00f6nnen, was entscheidend f\u00fcr die Erkennung von Scans und die Verbreitung von Malware ist. Auf Kernel-Ebene k\u00f6nnen Sie m\u00f6glicherweise einen Teil des Verkehrs einfach nicht sehen, und auf Perimeter-Ebene sehen Sie bestenfalls ein Viertel Ihres gesamten Netzwerkverkehrs. Aber wenn aus irgendeinem Grund in Ihrem Netzwerk unbefugte Ger\u00e4te vorhanden sind, die es Angreifern erm\u00f6glichen, \u201eein- und auszugehen\u201c, ohne den Perimeter zu passieren, wird die Analyse der Telemetrie von dort nichts bringen. Daher wird empfohlen, die Telemetrieerfassung genau auf Zugangsebene zu aktivieren. Es ist auch zu beachten, dass selbst wenn wir \u00fcber Virtualisierung oder Container sprechen, moderne virtuelle Switches ebenfalls h\u00e4ufig Flow-Unterst\u00fctzung bieten, was eine Kontrolle des Verkehrs dort erm\u00f6glicht.<\/p>\n<p>Aber da ich das Thema angesprochen habe, sollten wir die Frage beantworten: Was ist, wenn die Hardware, sei es physisch oder virtuell, nicht in der Lage ist, Flow-Protokolle zu unterst\u00fctzen? Oder wenn die Aktivierung verboten ist (zum Beispiel in Industriesegmenten zur Gew\u00e4hrleistung der Zuverl\u00e4ssigkeit)? Oder wenn ihre Aktivierung zu einer hohen Auslastung des Prozessors f\u00fchrt (was bei veralteter Hardware vorkommen kann)? F\u00fcr diese Aufgabe gibt es spezialisierte virtuelle Sensoren (Flow-Sensoren), die im Grunde genommen gew\u00f6hnliche Verzweigungen sind, die den Verkehr durchlassen und ihn als Flow an das Sammelmodul \u00fcbertragen. Allerdings haben wir in diesem Fall all die Probleme, \u00fcber die wir zuvor in Bezug auf Paketfangmittel gesprochen haben. Das bedeutet, dass man nicht nur die Vorteile der Str\u00f6me-Analyse-Technologie verstehen muss, sondern auch deren Einschr\u00e4nkungen.<\/p>\n<p>Ein weiterer Punkt, den man beim Thema Analysetools f\u00fcr Datenstr\u00f6me beachten sollte. W\u00e4hrend wir f\u00fcr herk\u00f6mmliche Sicherheitsereignis-Generierungswerkzeuge die Kennzahl EPS (Events pro Sekunde) verwenden, ist diese Kennzahl f\u00fcr die Analyse der Telemetrie nicht anwendbar; hier wird sie durch FPS (Flows pro Sekunde) ersetzt. Genau wie bei EPS kann man diese Zahl nicht im Voraus berechnen, aber man kann eine ungef\u00e4hre Anzahl an Flows sch\u00e4tzen, die ein bestimmtes Ger\u00e4t je nach seinen Aufgaben erzeugt. Im Internet finden Sie Tabellen mit ungef\u00e4hren Werten f\u00fcr verschiedene Arten von Unternehmensger\u00e4ten und Bedingungen, die Ihnen helfen, abzusch\u00e4tzen, welche Lizenzen Sie f\u00fcr Analysetools ben\u00f6tigen und wie deren Architektur aussehen wird. Der Punkt ist, dass ein IDS-Sensor durch eine bestimmte Bandbreite, die er \u201ebew\u00e4ltigen\u201c kann, limitiert ist, ebenso hat der Flusskollektor seine eigenen Einschr\u00e4nkungen, die man verstehen muss. Daher gibt es in gro\u00dfen, geografisch verteilten Netzwerken meist mehrere Kollektoren. Als ich die <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">\u00dcberwachung des Netzwerks innerhalb von Cisco<\/a><\/noindex>, habe ich bereits die Anzahl unserer Kollektoren erw\u00e4hnt \u2014 es sind 21. Und das f\u00fcr ein Netzwerk, das sich \u00fcber f\u00fcnf Kontinente erstreckt und etwa eine halbe Million aktive Ger\u00e4te umfasst).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/a5935ef7f7a3511cbf291fce59e96d71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAls \u00dcberwachungssystem f\u00fcr Netflow verwenden wir unsere eigene L\u00f6sung <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch<\/a><\/noindex>, das speziell auf die L\u00f6sung von Sicherheitsaufgaben ausgerichtet ist. Es verf\u00fcgt \u00fcber zahlreiche integrierte Engines zur Erkennung anomaler, verd\u00e4chtiger und eindeutig sch\u00e4dlicher Aktivit\u00e4ten, die eine breite Palette verschiedener Bedrohungen erkennen k\u00f6nnen \u2013 von Krypto-Mining bis zu Datenlecks, von der Verbreitung von Malware bis hin zu Betrug. Wie die meisten Stream-Analyser basiert Stealthwatch auf einem dreistufigen Schema (Generator \u2013 Collector \u2013 Analyzer), ist jedoch um eine Reihe interessanter Funktionen erg\u00e4nzt, die im Kontext des behandelten Materials wichtig sind. Erstens integriert es sich mit L\u00f6sungen zur Paketaufnahme (zum Beispiel dem Cisco Security Packet Analyzer), was es erm\u00f6glicht, ausgew\u00e4hlte Netzwerksitzungen f\u00fcr eine nachfolgende tiefgehende Untersuchung und Analyse aufzuzeichnen. Zweitens haben wir speziell zur Erweiterung der Sicherheitsaufgaben ein spezielles Protokoll namens nvzFlow entwickelt, das es erm\u00f6glicht, die Aktivit\u00e4t von Anwendungen an Endpunkten (Servern, Arbeitsstationen usw.) in Telemetrie zu \u201e\u00fcbertragen\u201c und sie an den Collector zur weiteren Analyse zu senden. W\u00e4hrend Stealthwatch in seiner urspr\u00fcnglichen Version mit jedem Flow-Protokoll (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) auf Netzwerkebene arbeitet, erm\u00f6glicht die Unterst\u00fctzung von nvzFlow eine Datenkorrelation auch auf Knotenebene, wodurch die Effizienz des gesamten Systems erh\u00f6ht wird und mehr Angriffe als mit herk\u00f6mmlichen Netzwerk-Stream-Analysern sichtbar sind.<\/p>\n<p>Es ist klar, dass der Markt f\u00fcr Netflow-Analyse-Systeme im Hinblick auf die Sicherheit nicht nur durch die L\u00f6sung von Cisco begrenzt ist. Sie k\u00f6nnen sowohl kommerzielle als auch kostenlose oder bedingt kostenlose L\u00f6sungen verwenden. Es w\u00e4re seltsam, wenn ich in einem Cisco-Blog Beispiele von Konkurrenzl\u00f6sungen anf\u00fchren w\u00fcrde, daher m\u00f6chte ich ein paar Worte dar\u00fcber verlieren, wie Netzwerk-Telemetrie mit zwei beliebten, \u00e4hnlich benannten, aber dennoch unterschiedlichen Werkzeugen \u2013 SiLK und ELK \u2013 analysiert werden kann.<\/p>\n<p>SiLK ist ein Toolset (System for Internet-Level Knowledge) zur Analyse von Netzwerkverkehr, entwickelt vom amerikanischen CERT\/CC, das im Kontext dieses Artikels Netflow (5. und 9. der bekanntesten Versionen), IPFIX und sFlow unterst\u00fctzt. Es erm\u00f6glicht verschiedene Operationen an der Netzwerk-Telemetrie durch Tools wie rwfilter, rwcount, rwflowpack und andere, um Anzeichen von unbefugten Aktivit\u00e4ten zu erkennen. Es gibt jedoch ein paar wichtige Punkte zu beachten. SiLK ist ein Kommandozeilenwerkzeug, und f\u00fcr die Durchf\u00fchrung von Echtzeitanalysen muss man st\u00e4ndig Befehle eingeben, wie etwa (Erkennung von ICMP-Paketen gr\u00f6\u00dfer als 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>nicht sehr praktisch. Sie k\u00f6nnen die grafische Benutzeroberfl\u00e4che iSiLK verwenden, aber diese erleichtert Ihnen das Leben nicht gro\u00dfartig, da sie nur die Funktion der Visualisierung \u00fcbernimmt und keinen Analysten ersetzt. Und das ist der zweite Punkt. Im Gegensatz zu kommerziellen L\u00f6sungen, die bereits \u00fcber eine umfangreiche Analysebasis, Anomalieerkennungsalgorithmen, konforme Workflows usw. verf\u00fcgen, m\u00fcssen Sie bei SiLK alles selbst erledigen, was andere Kompetenzen erfordert als die Verwendung eines bereitgestellten Werkzeugs. Dies ist weder gut noch schlecht \u2013 es ist ein Merkmal fast jedes kostenlosen Tools, das davon ausgeht, dass Sie wissen, was zu tun ist, und es Ihnen nur dabei hilft (kommerzielles Werkzeug ist weniger abh\u00e4ngig von den Kompetenzen seiner Benutzer, obwohl auch hier erwartet wird, dass die Analysten zumindest die Grundlagen der Netzwerkermittlungen und des Monitorings verstehen). Aber lassen Sie uns zu SiLK zur\u00fcckkehren. Der Arbeitszyklus eines Analysts mit diesem Werkzeug sieht folgenderma\u00dfen aus:<\/p>\n<ul>\n<li>Formulierung einer Hypothese. Wir m\u00fcssen verstehen, wonach wir in der Netzwerk-Telemetrie suchen, und die einzigartigen Attribute kennen, mit denen wir bestimmte Anomalien oder Bedrohungen entdecken werden.<\/li>\n<li>Modellbildung. Nachdem wir die Hypothese formuliert haben, programmieren wir sie unter Verwendung von Python, Shell oder anderen Werkzeugen, die nicht Teil von SiLK sind.<\/li>\n<li>Testen. Es ist Zeit, die Richtigkeit unserer Hypothese zu \u00fcberpr\u00fcfen, die mithilfe der SiLK-Utilities, die mit 'rw', 'set' und 'bag' beginnen, best\u00e4tigt oder widerlegt wird.<\/li>\n<li>Analyse echter Daten. Bei der industriellen Nutzung von SiLK hilft uns, etwas zu identifizieren, und der Analyst sollte Fragen beantworten wie \u201eHaben wir gefunden, wonach wir gesucht haben?\u201c, \u201eEntspricht das unserer Hypothese?\u201c, \u201eWie k\u00f6nnen wir die Anzahl der Fehlalarme reduzieren?\u201c, \u201eWie k\u00f6nnen wir die Erkennungsgenauigkeit verbessern?\u201c usw.<\/li>\n<li>Verbesserung. In der abschlie\u00dfenden Phase verbessern wir das, was wir zuvor gemacht haben \u2014 wir erstellen Vorlagen, verbessern und optimieren den Code, reformulieren und pr\u00e4zisieren die Hypothese und mehr.<\/li>\n<\/ul>\n<p>Dieser Zyklus wird auch auf Cisco Stealthwatch anwendbar sein, wobei letzterer diese f\u00fcnf Schritte gr\u00f6\u00dftenteils automatisiert, wodurch die Fehlerquote des Analysts reduziert und die Reaktionsgeschwindigkeit bei der Entdeckung von Vorf\u00e4llen erh\u00f6ht wird. Zum Beispiel k\u00f6nnen Sie in SiLK die Netzwerkstatistik mit externen Daten \u00fcber sch\u00e4dliche IPs durch selbstgeschriebene Skripte anreichern, w\u00e4hrend dies in Cisco Stealthwatch eine integrierte Funktion ist, die sofort einen Alarm ausl\u00f6st, wenn im Netzwerkverkehr Interaktionen mit IP-Adressen aus der Blacklist festgestellt werden.<\/p>\n<p>Wenn man h\u00f6her in der \u201eKostenpyramide\u201c f\u00fcr Software zur Flow-Analyse geht, dann folgt auf das v\u00f6llig kostenlose SiLK die bedingt kostenlose ELK, die aus drei Hauptkomponenten besteht \u2014 Elasticsearch (Indizierung, Suche und Analyse von Daten), Logstash (Dateninput\/-output) und Kibana (Visualisierung). Im Gegensatz zu SiLK, wo man alles selbst schreiben muss, verf\u00fcgt ELK bereits \u00fcber viele fertige Bibliotheken\/Module (ein Teil kostenpflichtig, ein Teil nicht), die die Analyse von Netzwerktelemetrie automatisieren. Zum Beispiel erm\u00f6glicht der GeoIP-Filter in Logstash, die beobachteten IP-Adressen mit ihrem geografischen Standort zu verkn\u00fcpfen (bei Stealthwatch ist dies eine integrierte Funktion).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/addd9d9656f64f81d86a0cce8ee0810b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nELK hat auch eine recht gro\u00dfe Community, die fehlende Komponenten f\u00fcr diese Monitoring-L\u00f6sung hinzuf\u00fcgt. Zum Beispiel k\u00f6nnen Sie das Modul verwenden, um mit Netflow, IPFIX und sFlow zu arbeiten. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/robcowart\/elastiflow\">elastiflow<\/a><\/noindex>, wenn Sie mit dem Logstash Netflow-Modul, das nur Netflow unterst\u00fctzt, unzufrieden sind.<\/p>\n<p>Obwohl ELK derzeit eine schnellere Erfassung von Flows und deren Durchsuchung bietet, fehlt es an einer umfangreichen integrierten Analyse zur Erkennung von Anomalien und Bedrohungen in der Netzwerktelemetrie. Das hei\u00dft, wenn Sie dem oben beschriebenen Lebenszyklus folgen, m\u00fcssen Sie die Modelle f\u00fcr St\u00f6rungen selbst definieren und diese dann in einem Produktionssystem verwenden (es gibt keine integrierten Modelle).<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/6d8368f4c130c3a5770890cb6c5fe5ab.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEs gibt nat\u00fcrlich auch ausgefeiltere Erweiterungen f\u00fcr ELK, die bereits einige Modelle zur Erkennung von Anomalien in der Netzwerktelemetrie beinhalten. Diese Erweiterungen sind jedoch kostenpflichtig, und hier stellt sich die Frage, ob es sich lohnt, das Risiko einzugehen \u2013 ob man ein \u00e4hnliches Modell selbst schreiben, eine Implementierung f\u00fcr sein \u00dcberwachungswerkzeug kaufen oder eine fertige L\u00f6sung der Klasse Network Traffic Analysis erwerben sollte.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/d938ebb4271c4dfb73a1e4b6e94c91d6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIch m\u00f6chte mich eigentlich nicht in die Diskussion vertiefen, ob es besser ist, Geld auszugeben und eine fertige L\u00f6sung zur \u00dcberwachung von Anomalien und Bedrohungen in der Netzwerktelemetrie (zum Beispiel Cisco Stealthwatch) zu kaufen oder sich selbst damit auseinanderzusetzen und SiLK, ELK oder nfdump oder OSU Flow Tools (ich meine die letzten beiden) individuell anzupassen. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">erz\u00e4hlt<\/a><\/noindex> Jeder w\u00e4hlt f\u00fcr sich selbst aus und hat seine eigenen Gr\u00fcnde, eine der beiden Optionen zu w\u00e4hlen. Ich wollte nur zeigen, dass Netzwerktelemetrie ein sehr wichtiges Instrument zur Gew\u00e4hrleistung der Netzwerksicherheit der eigenen Infrastruktur ist und dass man es nicht vernachl\u00e4ssigen sollte, um nicht auf die Liste von Unternehmen zu kommen, deren Namen in den Medien mit Bezeichnungen wie \"gehackt\", \"nicht die Anforderungen an die Informationssicherheit eingehalten\" oder \"nicht an der Sicherheit ihrer Daten und der Daten ihrer Kunden denkend\" erw\u00e4hnt werden.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/de7df67df66b7abe89170c7f92fcefca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZusammenfassend m\u00f6chte ich die wichtigsten Ratschl\u00e4ge auflisten, die man bei der Umsetzung der Informationssicherheits\u00fcberwachung seiner internen Infrastruktur beachten sollte:<\/p>\n<ol>\n<li>Begrenzen Sie sich nicht nur auf den Perimeter! Nutzen Sie (und w\u00e4hlen Sie) die Netzwerkinfrastruktur nicht nur zur \u00dcbertragung von Datenverkehr von Punkt A nach Punkt B, sondern auch zur L\u00f6sung von Cybersecurity-Fragen.<\/li>\n<li>Untersuchen Sie die vorhandenen Mechanismen zur Informationssicherheits\u00fcberwachung in Ihrer Netzwerkhardware und setzen Sie diese um.<\/li>\n<li>F\u00fcr die interne \u00dcberwachung sollten Sie die Analyse von Telemetrie priorisieren \u2013 sie erm\u00f6glicht die Erkennung von 80-90 % aller Informationssicherheitsvorf\u00e4lle und erzielt dabei Ergebnisse, die bei der Erfassung von Netzwerkpaketen unm\u00f6glich sind, w\u00e4hrend gleichzeitig Speicherplatz f\u00fcr alle Sicherheitsereignisse gespart wird.<\/li>\n<li>F\u00fcr die \u00dcberwachung von Fl\u00fcssen verwenden Sie Netflow v9 oder IPFIX \u2013 diese bieten mehr Informationen im Sicherheitskontext und erm\u00f6glichen die \u00dcberwachung nicht nur von IPv4, sondern auch von IPv6, MPLS usw.<\/li>\n<li>Verwenden Sie ungesampelte Flow-Protokolle \u2013 diese bieten mehr Informationen zur Bedrohungserkennung. Zum Beispiel Netflow oder IPFIX.<\/li>\n<li>\u00dcberpr\u00fcfen Sie die Ladef\u00e4higkeit Ihrer Netzwerkausr\u00fcstung \u2013 m\u00f6glicherweise ist sie nicht in der Lage, auch das Flow-Protokoll zu verarbeiten. Denken Sie dann \u00fcber den Einsatz virtueller Sensoren oder eines Netflow Generation Appliance nach.<\/li>\n<li>F\u00fchren Sie die Kontrollen in erster Linie auf Zugangsebene durch \u2013 das gibt Ihnen die M\u00f6glichkeit, 100 % des gesamten Traffics zu sehen.<\/li>\n<li>Wenn Sie keine Wahl haben und russische Netzwerkausr\u00fcstung verwenden, w\u00e4hlen Sie die, die Flow-Protokolle unterst\u00fctzt oder SPAN\/RSPAN-Ports besitzt.<\/li>\n<li>Kombinieren Sie Systeme zur Entdeckung\/Verhinderung von Eindringlingen\/Angriffen an den Grenzen mit Systemen zur Analyse des Traffics im internen Netzwerk (einschlie\u00dflich in der Cloud).<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/c54e4b02a906f470bbfb617f48cdd216.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWas den letzten Ratschlag betrifft, m\u00f6chte ich ein Beispiel anf\u00fchren, das ich schon fr\u00fcher gebracht habe. Sie sehen, dass die Sicherheitsdienste von Cisco fr\u00fcher fast ihre gesamte \u00dcberwachungsinfrastruktur auf Intrusion-Detection-Systemen und signature-basierten Methoden aufgebaut haben, w\u00e4hrend heute nur noch 20 % der Vorf\u00e4lle auf sie entfallen. Weitere 20 % entfallen auf Systeme zur Analyse des Traffics, was zeigt, dass diese L\u00f6sungen kein Luxus sind, sondern ein tats\u00e4chliches Werkzeug f\u00fcr die Sicherheitsdienste moderner Unternehmen. Vor allem, weil Sie f\u00fcr deren Einf\u00fchrung das Wichtigste haben \u2013 eine Netzwerk-Infrastruktur, in die Sie zus\u00e4tzlich investieren k\u00f6nnen, indem Sie der Netzwerkinfrastruktur auch Funktionen zur \u00dcberwachung der IT-Sicherheit zuweisen.<\/p>\n<p><img decoding=\"async\" alt=\"Flow-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung des internen Netzwerks\" src=\"\/wp-content\/uploads\/2019\/08\/2166f265222c43b0b2cbbcf4091c1f8c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIch habe absichtlich das Thema der Reaktion auf in Netzwerktrafics identifizierte Anomalien oder Bedrohungen nicht angesprochen, aber ich denke, es ist auch so klar, dass die \u00dcberwachung nicht nur mit der Entdeckung einer Bedrohung enden sollte. Es sollte eine Reaktion folgen, vorzugsweise automatisch oder automatisiert. Aber das ist ein Thema f\u00fcr ein separates Material.<\/p>\n<p>Zus\u00e4tzliche Informationen:<\/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\">Beschreibung von 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\">Netflow-Unterst\u00fctzungsmatrix f\u00fcr verschiedene Cisco-L\u00f6sungen<\/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\">Anleitung zur Konfiguration von Netflow auf verschiedenen Cisco-Plattformen<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/sflow.org\">sFlow-Community<\/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\">Laborarbeit zur Verwendung von Stealthwatch, SiLK und ELK zur Analyse von Netflow aus Sicherheitsgesichtspunkten<\/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\">Dreihundertseitiges Handbuch zur Verwendung von SiLK mit vielen Beispielen<\/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\">Schritt-f\u00fcr-Schritt-Anleitung von Cisco zur Analyse von Netflow in ELK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/307528\/\">Analyse von NetFlow v.9 Cisco ASA mit 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\u00f6sung<\/a><\/noindex><\/li>\n<\/ul>\n<p>P.S. Wenn es Ihnen leichter f\u00e4llt, alles, was oben geschrieben wurde, durch Zuh\u00f6ren zu verstehen, k\u00f6nnen Sie sich die einst\u00fcndige Pr\u00e4sentation ansehen, die dieser Notiz zugrunde liegt.<\/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 abspielen\" 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 \/>Quelle: <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.1.1 - 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\/de\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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-Protokolle als Werkzeug zur Sicherheits\u00fcberwachung interner Netzwerke | ProHoster","description":"Wenn es um die Sicherheits\u00fcberwachung interner Unternehmens- oder Beh\u00f6rdennetze geht, denken viele sofort an die Kontrolle von Datenlecks und die Implementierung von DLP-L\u00f6sungen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/37437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=37437"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/37437\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/28091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=37437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=37437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=37437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}