🥇Flow-Protokolle als Werkzeug zur Sicherheitsüberwachung interner Netzwerke

Wenn es um die Sicherheitsüberwachung von internen Unternehmens- oder Behördennetzen geht, denken viele an den Schutz vor Datenlecks und die Implementierung von DLP-Lösungen. Wenn man jedoch die Frage präzisieren und fragen würde, wie Sie Angriffe im internen Netzwerk erkennen, wäre die Antwort in der Regel der Hinweis auf Intrusion Detection Systeme (IDS). Was früher noch die einzige Option vor 10-20 Jahren war, wird heute zum Anachronismus. Es gibt eine effektivere – und manchmal sogar die einzige – Möglichkeit zur Überwachung interner Netzwerke: die Nutzung von Flow-Protokollen, die ursprünglich zur Fehlersuche (Troubleshooting) entwickelt wurden, sich aber im Laufe der Zeit zu einem sehr interessanten Sicherheitstool entwickelt haben. In diesem Artikel werden wir darüber sprechen, welche Flow-Protokolle existieren, welche davon am besten dabei helfen, Netzwerkangriffe zu erkennen, wo die Überwachung 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.

Ich will nicht auf die Frage eingehen: „Warum ist die Sicherheitsüberwachung der internen Infrastruktur notwendig?“ Die Antwort darauf scheint klar zu sein. Aber wenn Sie sich dennoch erneut überzeugen möchten, dass man heute ohne das nicht auskommt, schauen Sie sich ein kurzes Video, das zeigt, wie man auf 17 verschiedene Arten in ein durch eine Firewall geschütztes Unternehmensnetz eindringen kann. Daher betrachten wir es als gegeben, dass wir verstehen, dass interne Überwachung notwendig ist, und es bleibt nur zu klären, wie man sie organisieren kann.

Ich würde drei Schlüsselquellen für die Datenüberwachung auf Netzwerkebene hervorheben:

den „rohen“ Datenverkehr, den wir erfassen und zur Analyse an spezielle Systeme übergeben,
Ereignisse von Netzwerkgeräten, durch die der Datenverkehr fließt,
Informationen über den Datenverkehr, die über eines der Flow-Protokolle erhalten werden.

Die Erfassung von Rohdatenverkehr ist die beliebteste Methode unter Sicherheitsfachleuten, da sie historisch die erste war. Übliche Intrusion Detection Systeme (IDS) — das erste kommerzielle IDS war NetRanger von der Firma Wheel Group, das 1998 von Cisco übernommen wurde — beschäftigten sich mit der Paket- (und später auch mit der Sitzungs-) Erfassung, um nach bestimmten Signaturen (den "entscheidenden Regeln" in der Terminologie von FSTEK) zu suchen, die auf Angriffe hinweisen. Natürlich 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öhnlichen IT-Werkzeug unterscheiden.

Also, Intrusion Detection Systeme. Die älteste und beliebteste Methode zur Erkennung von Netzwerkangriffen, die ihre Aufgabe am Perimeter (unabhängig davon, ob es sich um einen Unternehmens-, Rechenzentrum- oder Segmentperimeter handelt) recht gut erfüllt, aber in modernen Switch- und Software-definierten Netzwerken versagt. Bei einem Netzwerk, das auf normalen Switches basiert, wird die Infrastruktur der Angriffserkennungssensoren zu groß — man müsste für jede Verbindung mit einem Knoten, dessen Angriffe man überwachen möchte, 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ür uns geben sollte — es ist schließlich unsere eigene Lösung. Zudem stellt sich die Frage, wie man in solch einem Fall einen Sensor anschließen soll? In die Leitung? Und was, wenn der Sensor selbst ausfällt? Soll der Sensor einen Bypass-Modul erfordern? Soll man Taps verwenden? All dies verteuert die Lösung und macht sie unerschwinglich für Unternehmen jeder Größe.

Sie können versuchen, einen Sensor an einen SPAN/RSPAN/ERSPAN-Port zu „hängen“ 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 – der SPAN-Port kann nicht den gesamten Verkehr aufnehmen, der ihm zugeführt wird – er hat nicht genügend Bandbreite. Es wird notwendig sein, auf etwas zu verzichten. Entweder bestimmte Knoten ohne Überwachung lassen (in diesem Fall müssen Sie sie priorisieren), oder nur bestimmten Verkehr von einem Knoten leiten. In jedem Fall können wir einige Angriffe übersehen. Darüber hinaus kann der SPAN-Port für andere Zwecke genutzt werden. Daher müssen wir die bestehende Netzwerktopologie überdenken und möglicherweise Anpassungen vornehmen, um Ihre gesamte Netzwerk mit der vorhandenen Anzahl von Sensoren maximal abzudecken (und dies mit der IT abzustimmen).

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 überwachen müssen, deren Verkehr überhaupt nicht den physischen Switch erreicht? Diese Fragen mögen die Hersteller traditioneller IDS nicht, weil sie nicht wissen, wie sie darauf antworten sollen. Möglicherweise werden sie versuchen, Sie davon zu überzeugen, dass all diese modernen Technologien nur ein Hype sind und Sie ihn nicht benötigen. Vielleicht werden sie über 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üssen selbst klar verstehen, wie gut sie zu Ihnen passt. Und erst danach sollten Sie eine Entscheidung über den Ansatz zur Überwachung der IT-Sicherheit Ihrer Netzwerkinfrastruktur treffen. Zurück zum Paketfang möchte 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ältigen die gestellten Aufgaben gut.

Lass uns zur zweiten Variante übergehen. Die Analyse von Ereignissen, die von Netzwerkgeräten empfangen werden, kann ebenfalls zur Entdeckung von Angriffen verwendet werden, jedoch nicht als primärer Mechanismus, da sie nur eine kleine Klasse von Eindringlingen erkennen kann. Zudem ist sie reaktiv — ein Angriff muss zuerst geschehen, dann muss er von dem Netzwerkgerät aufgezeichnet werden, das auf irgendeine Weise ein Signal über ein Problem in der IT-Sicherheit sendet. Es gibt mehrere solcher Methoden. Dies kann über Syslog, RMON oder SNMP geschehen. Die letzten beiden Protokolle zur Netzwerküberwachung im Kontext der IT-Sicherheit werden nur eingesetzt, wenn wir eine DoS-Attacke auf das Netzwerkgerät selbst identifizieren müssen, da man mit RMON und SNMP z. B. die Auslastung der zentralen Verarbeitungseinheit des Geräts oder seiner Schnittstellen überwachen kann. Dies ist eine der „günstigsten“ Methoden (Syslog oder SNMP sind überall verfügbar), aber auch die ineffektivste Methode zur Überwachung der IT-Sicherheit der internen Infrastruktur — viele Angriffe bleiben einfach verborgen. Natürlich sollten sie nicht vernachlässigt werden, und die Analyse von Syslog hilft Ihnen, rechtzeitig Änderungen in der Konfiguration des Geräts selbst zu erkennen, sowie dessen Kompromittierung. Aber zur Entdeckung von Angriffen auf das gesamte Netzwerk ist dies nicht sehr geeignet.

Die dritte Variante ist die Analyse von Informationen über den Verkehr, der durch ein Gerät fließt, das eines der mehreren Flow-Protokolle unterstützt. In diesem Fall besteht die Infrastruktur zur Verarbeitung von Flows unabhängig vom Protokoll unbedingt aus drei Komponenten:

Generierung oder Export von Flows. Diese Rolle wird normalerweise einem Router, Switch oder einem anderen Netzwerkgerät zugewiesen, das, während es den Netzwerkverkehr durchlässt, ermöglicht, Schlüsseldaten daraus zu extrahieren, die dann an das Sammelmodul übermittelt werden. Zum Beispiel wird das Netflow-Protokoll bei Cisco nicht nur auf Routern und Switches unterstützt, einschließlich virtueller und industrieller, sondern auch auf drahtlosen Controllern, Firewalls und sogar Servern.
Sammeln von Flows. Angesichts der Tatsache, dass in modernen Netzwerken in der Regel mehr als ein Netzwerkgerät vorhanden ist, besteht die Aufgabe darin, die Flows zu sammeln und zu konsolidieren, die mit Hilfe von sogenannten Collectoren gelöst wird, die die empfangenen Flows verarbeiten und sie dann zur Analyse übermitteln.
Flow-Analyse. Der Analysator übernimmt die Hauptaufgabe der Intelligenz und wendet verschiedene Algorithmen auf die Ströme an, um bestimmte Schlussfolgerungen zu ziehen. Beispielsweise kann ein solcher Analysator innerhalb der IT-Funktion Engpässe 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.

Man sollte nicht denken, dass eine solche dreistufige Architektur zu kompliziert ist – alle anderen Optionen (außer vielleicht Netzwerkanalysesysteme, die mit SNMP und RMON arbeiten) funktionieren ebenfalls gemäß dieser. Wir haben einen Datengenerator zur Analyse, der durch ein Netzwerkgerät oder einen eigenständigen Sensor repräsentiert wird. Es gibt ein System zur Erfassung von Alarmmeldungen und ein System zur Verwaltung der gesamten Überwachungsinfrastruktur. Die letzten beiden Komponenten können in einem Knoten zusammengefasst werden, aber in mehr oder weniger großen Netzwerken sind sie in der Regel auf mindestens zwei Geräte verteilt, um Skalierbarkeit und Zuverlässigkeit zu gewährleisten.

Im Gegensatz zur Paket-Analyse, die auf der Untersuchung der Kopfzeilen und der Inhalte jedes Pakets sowie der aus ihnen bestehenden Sessions basiert, stützt sich die Flow-Analyse auf die Erfassung von Metadaten über den Netzwerkverkehr. Wann, wie viel, von wo und wohin, wie… das sind die Fragen, die die Analyse der Netzwerk-Telemetrie mithilfe verschiedener Flow-Protokolle beantwortet. Ursprünglich 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ür 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 überwachen. Sie verfügen über Netzwerkgeräte (und es spielt keine Rolle, ob sie in einer softwaredefinierten Paradigma oder gemäß statischen Regeln arbeiten), die nicht umgangen werden können. Ein Sensor einer klassischen IDS kann umgangen werden, ein Netzwerkgerät, das das Flow-Protokoll unterstützt, jedoch nicht. Das ist der Vorteil dieser Methode.

Andererseits, wenn Sie Beweise für die Strafverfolgungsbehörden oder Ihre eigene Incident-Response-Gruppe benötigen, kommen Sie um die Paketerfassung nicht herum – Netzwerk-Telemetrie ist kein Abbild des Traffics, das für die Beweissicherung verwendet werden kann; sie ist erforderlich für die schnelle Erkennung und Entscheidungsfindung im Bereich IT-Sicherheit. Andererseits können Sie mit der Analyse der Telemetrie nicht den gesamten Netzwerktraffic „aufzeichnen“ (für den Fall, dass Cisco und Rechenzentren sich darum kümmern :-), sondern nur den, der an einem Angriff beteiligt ist. Die Werkzeuge zur Analyse der Telemetrie ergänzen in diesem Sinne gut die traditionellen Mechanismen der Paketerfassung, indem sie das selektive Erfassen und Speichern anordnen. Andernfalls müssten Sie über eine enorme Speicherinfrastruktur verfügen.

Stellen Sie sich ein Netzwerk vor, das mit 250 Mbit/s arbeitet. Wenn Sie diesen gesamten Datenverkehr speichern möchten, benötigen Sie 31 MB Speicherplatz für eine Sekunde Datenübertragung, 1,8 GB für eine Minute, 108 GB für eine Stunde und 2,6 TB für einen Tag. Um die täglichen Daten eines Netzwerks mit einer Bandbreite von 10 Gbit/s zu speichern, benötigen Sie 108 TB Speicherplatz. Und schließlich verlangen einige Regulierungsbehörden, dass sicherheitsrelevante Daten jahrelang aufbewahrt werden... Die „On-Demand“-Aufzeichnung, die Ihnen die Analyse der Ströme ermöglicht, hilft, diese Werte um Größenordnungen zu reduzieren. Übrigens, im Verhältnis des Volumens der aufgezeichneten Daten der Netzwerk-Telemetrie zur vollständigen Datenerfassung beträgt es etwa 1 zu 500. Für die oben angegebenen Werte würde die Speicherung der vollständigen Entschlüsselung des gesamten Tagesverkehrs 5 GB bzw. 216 GB betragen (man könnte es sogar auf einen normalen USB-Stick speichern).

Wenn bei der Analyse von Rohnetzwerkdaten die Methode ihrer Erfassung nahezu identisch ist, egal von welchem Anbieter, verhält es sich bei der Analyse von Flüssen anders. Es gibt mehrere Varianten von Flow-Protokollen, über 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öglichkeiten 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ützen die meisten Netzwerkanbieter genau dieses Netflow oder IPFIX in ihrer Hardware. Aber es gibt auch verschiedene andere Varianten von Flow-Protokollen – sFlow, jFlow, cFlow, rFlow, NetStream usw., von denen sFlow am populärsten ist. Dieser wird von inländischen Herstellern von Netzwerkhardware aufgrund der einfachen Implementierung am häufigsten unterstützt. Was sind die entscheidenden Unterschiede zwischen Netflow, das de facto zum Standard geworden ist, und sFlow? Ich würde 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?

Stellen Sie sich vor, Sie möchten das Buch "Security Operations Center: Building, Operating, and Maintaining your SOC" meiner Kollegen – Gary McIntyre, Joseph Muniz und Nadeem AlFardan (über den Link können Sie einen Teil des Buches herunterladen). Sie haben drei Möglichkeiten, Ihr Ziel zu erreichen – das Buch vollständig zu lesen, es überfliegend zu durchblättern und dabei auf jeder 10. oder 20. Seite anzuhalten oder zu versuchen, eine Zusammenfassung der Schlüsselkonzepte in einem Blog oder einem Dienst wie SmartReading zu finden. So ist die nicht-sampling Telemetrie das Lesen jeder “Seite” des Netzwerkverkehrs, d.h. die Analyse von Metadaten für jedes Paket. Sampling Telemetrie ist das selektive Studieren des Verkehrs in der Hoffnung, dass in den gewählten Proben das, was Sie benötigen, enthalten ist. Je nach Bandbreite gibt die Sampling Telemetrie für die Analyse jedes 64., 200., 500., 1000., 2000. oder sogar 10000. Paket zurück.

Im Kontext der Überwachung 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, übersehen 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ür Netzwerktelemetrie erkannt werden können.

Natürlicherweise wird Ihnen kein Open-Source-Netflow-Analyzer dies ermöglichen, da seine Hauptaufgabe darin besteht, Telemetrie zu sammeln und eine grundlegende Analyse aus IT-Perspektive durchzuführen. 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.

Wenn Sie also die Wahl haben, entscheiden Sie sich für Netflow oder IPFIX. Aber selbst wenn Ihre Hardware nur mit sFlow funktioniert, wie es bei inländischen Herstellern der Fall ist, können Sie auch in diesem Fall Vorteile im Sicherheitskontext daraus ziehen.

Im Sommer 2019 führte ich eine Analyse der Möglichkeiten durch, die die russischen Hersteller von Netzwerkhardware bieten, und alle, mit Ausnahme von NSG, Polygon und Kraftway, behaupteten die Unterstützung von sFlow (mindestens Zelaсk, Natex, Eltex, QTech, Rusteletech).

Die nächste Frage, die sich Ihnen stellen wird, ist: Wo implementieren Sie die Unterstützung für Flows zu Sicherheitszwecken? Tatsächlich ist die Frage nicht ganz korrekt formuliert. Auf moderner Hardware ist die Unterstützung für Flow-Protokolle nahezu immer vorhanden. Deshalb würde ich die Frage anders umformulieren — wo ist es am effektivsten, Telemetrie aus sicherheitsrelevanter Sicht zu sammeln? Die Antwort wird recht offensichtlich sein — 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önnen, was entscheidend für die Erkennung von Scans und die Verbreitung von Malware ist. Auf Kernel-Ebene können Sie möglicherweise 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äte vorhanden sind, die es Angreifern ermöglichen, „ein- und auszugehen“, 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 über Virtualisierung oder Container sprechen, moderne virtuelle Switches ebenfalls häufig Flow-Unterstützung bieten, was eine Kontrolle des Verkehrs dort ermöglicht.

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ützen? Oder wenn die Aktivierung verboten ist (zum Beispiel in Industriesegmenten zur Gewährleistung der Zuverlässigkeit)? Oder wenn ihre Aktivierung zu einer hohen Auslastung des Prozessors führt (was bei veralteter Hardware vorkommen kann)? Für diese Aufgabe gibt es spezialisierte virtuelle Sensoren (Flow-Sensoren), die im Grunde genommen gewöhnliche Verzweigungen sind, die den Verkehr durchlassen und ihn als Flow an das Sammelmodul übertragen. Allerdings haben wir in diesem Fall all die Probleme, über die wir zuvor in Bezug auf Paketfangmittel gesprochen haben. Das bedeutet, dass man nicht nur die Vorteile der Ströme-Analyse-Technologie verstehen muss, sondern auch deren Einschränkungen.

Ein weiterer Punkt, den man beim Thema Analysetools für Datenströme beachten sollte. Während wir für herkömmliche Sicherheitsereignis-Generierungswerkzeuge die Kennzahl EPS (Events pro Sekunde) verwenden, ist diese Kennzahl für 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ähre Anzahl an Flows schätzen, die ein bestimmtes Gerät je nach seinen Aufgaben erzeugt. Im Internet finden Sie Tabellen mit ungefähren Werten für verschiedene Arten von Unternehmensgeräten und Bedingungen, die Ihnen helfen, abzuschätzen, welche Lizenzen Sie für Analysetools benötigen und wie deren Architektur aussehen wird. Der Punkt ist, dass ein IDS-Sensor durch eine bestimmte Bandbreite, die er „bewältigen“ kann, limitiert ist, ebenso hat der Flusskollektor seine eigenen Einschränkungen, die man verstehen muss. Daher gibt es in großen, geografisch verteilten Netzwerken meist mehrere Kollektoren. Als ich die Überwachung des Netzwerks innerhalb von Cisco, habe ich bereits die Anzahl unserer Kollektoren erwähnt — es sind 21. Und das für ein Netzwerk, das sich über fünf Kontinente erstreckt und etwa eine halbe Million aktive Geräte umfasst).

Als Überwachungssystem für Netflow verwenden wir unsere eigene Lösung Cisco Stealthwatch, das speziell auf die Lösung von Sicherheitsaufgaben ausgerichtet ist. Es verfügt über zahlreiche integrierte Engines zur Erkennung anomaler, verdächtiger und eindeutig schädlicher Aktivitäten, die eine breite Palette verschiedener Bedrohungen erkennen können – 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 – Collector – Analyzer), ist jedoch um eine Reihe interessanter Funktionen ergänzt, die im Kontext des behandelten Materials wichtig sind. Erstens integriert es sich mit Lösungen zur Paketaufnahme (zum Beispiel dem Cisco Security Packet Analyzer), was es ermöglicht, ausgewählte Netzwerksitzungen für eine nachfolgende tiefgehende Untersuchung und Analyse aufzuzeichnen. Zweitens haben wir speziell zur Erweiterung der Sicherheitsaufgaben ein spezielles Protokoll namens nvzFlow entwickelt, das es ermöglicht, die Aktivität von Anwendungen an Endpunkten (Servern, Arbeitsstationen usw.) in Telemetrie zu „übertragen“ und sie an den Collector zur weiteren Analyse zu senden. Während Stealthwatch in seiner ursprünglichen Version mit jedem Flow-Protokoll (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) auf Netzwerkebene arbeitet, ermöglicht die Unterstützung von nvzFlow eine Datenkorrelation auch auf Knotenebene, wodurch die Effizienz des gesamten Systems erhöht wird und mehr Angriffe als mit herkömmlichen Netzwerk-Stream-Analysern sichtbar sind.

Es ist klar, dass der Markt für Netflow-Analyse-Systeme im Hinblick auf die Sicherheit nicht nur durch die Lösung von Cisco begrenzt ist. Sie können sowohl kommerzielle als auch kostenlose oder bedingt kostenlose Lösungen verwenden. Es wäre seltsam, wenn ich in einem Cisco-Blog Beispiele von Konkurrenzlösungen anführen würde, daher möchte ich ein paar Worte darüber verlieren, wie Netzwerk-Telemetrie mit zwei beliebten, ähnlich benannten, aber dennoch unterschiedlichen Werkzeugen – SiLK und ELK – analysiert werden kann.

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ützt. Es ermöglicht verschiedene Operationen an der Netzwerk-Telemetrie durch Tools wie rwfilter, rwcount, rwflowpack und andere, um Anzeichen von unbefugten Aktivitäten zu erkennen. Es gibt jedoch ein paar wichtige Punkte zu beachten. SiLK ist ein Kommandozeilenwerkzeug, und für die Durchführung von Echtzeitanalysen muss man ständig Befehle eingeben, wie etwa (Erkennung von ICMP-Paketen größer als 200 Byte):

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

nicht sehr praktisch. Sie können die grafische Benutzeroberfläche iSiLK verwenden, aber diese erleichtert Ihnen das Leben nicht großartig, da sie nur die Funktion der Visualisierung übernimmt und keinen Analysten ersetzt. Und das ist der zweite Punkt. Im Gegensatz zu kommerziellen Lösungen, die bereits über eine umfangreiche Analysebasis, Anomalieerkennungsalgorithmen, konforme Workflows usw. verfügen, müssen Sie bei SiLK alles selbst erledigen, was andere Kompetenzen erfordert als die Verwendung eines bereitgestellten Werkzeugs. Dies ist weder gut noch schlecht – 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ängig 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ückkehren. Der Arbeitszyklus eines Analysts mit diesem Werkzeug sieht folgendermaßen aus:

Formulierung einer Hypothese. Wir müssen verstehen, wonach wir in der Netzwerk-Telemetrie suchen, und die einzigartigen Attribute kennen, mit denen wir bestimmte Anomalien oder Bedrohungen entdecken werden.
Modellbildung. Nachdem wir die Hypothese formuliert haben, programmieren wir sie unter Verwendung von Python, Shell oder anderen Werkzeugen, die nicht Teil von SiLK sind.
Testen. Nun steht die Überprüfung der Richtigkeit unserer Hypothese an, die mit Hilfe der SiLK-Tools, die mit 'rw', 'set', 'bag' beginnen, bestätigt oder widerlegt wird.
Analyse echter Daten. Bei der industriellen Nutzung von SiLK hilft uns, etwas zu identifizieren, und der Analyst sollte Fragen beantworten wie „Haben wir gefunden, wonach wir gesucht haben?“, „Entspricht das unserer Hypothese?“, „Wie können wir die Anzahl der Fehlalarme reduzieren?“, „Wie können wir die Erkennungsgenauigkeit verbessern?“ usw.
Verbesserung. In der abschließenden Phase verbessern wir das, was wir zuvor gemacht haben — wir erstellen Vorlagen, verbessern und optimieren den Code, reformulieren und präzisieren die Hypothese und mehr.

Dieser Zyklus wird auch auf Cisco Stealthwatch anwendbar sein, wobei letzterer diese fünf Schritte größtenteils automatisiert, wodurch die Fehlerquote des Analysts reduziert und die Reaktionsgeschwindigkeit bei der Entdeckung von Vorfällen erhöht wird. Zum Beispiel können Sie in SiLK die Netzwerkstatistik mit externen Daten über schädliche IPs durch selbstgeschriebene Skripte anreichern, während dies in Cisco Stealthwatch eine integrierte Funktion ist, die sofort einen Alarm auslöst, wenn im Netzwerkverkehr Interaktionen mit IP-Adressen aus der Blacklist festgestellt werden.

Wenn man höher in der „Kostenpyramide“ für Software zur Flow-Analyse geht, dann folgt auf das völlig kostenlose SiLK die bedingt kostenlose ELK, die aus drei Hauptkomponenten besteht — Elasticsearch (Indizierung, Suche und Analyse von Daten), Logstash (Dateninput/-output) und Kibana (Visualisierung). Im Gegensatz zu SiLK, wo man alles selbst schreiben muss, verfügt ELK bereits über viele fertige Bibliotheken/Module (ein Teil kostenpflichtig, ein Teil nicht), die die Analyse von Netzwerktelemetrie automatisieren. Zum Beispiel ermöglicht der GeoIP-Filter in Logstash, die beobachteten IP-Adressen mit ihrem geografischen Standort zu verknüpfen (bei Stealthwatch ist dies eine integrierte Funktion).

ELK hat auch eine recht große Community, die fehlende Komponenten für diese Monitoring-Lösung hinzufügt. Zum Beispiel können Sie das Modul verwenden, um mit Netflow, IPFIX und sFlow zu arbeiten. elastiflow, wenn Sie mit dem Logstash Netflow-Modul, das nur Netflow unterstützt, unzufrieden sind.

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ßt, wenn Sie dem oben beschriebenen Lebenszyklus folgen, müssen Sie die Modelle für Störungen selbst definieren und diese dann in einem Produktionssystem verwenden (es gibt keine integrierten Modelle).

Es gibt natürlich auch ausgefeiltere Erweiterungen für 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 – ob man ein ähnliches Modell selbst schreiben, eine Implementierung für sein Überwachungswerkzeug kaufen oder eine fertige Lösung der Klasse Network Traffic Analysis erwerben sollte.

Ich möchte mich eigentlich nicht in die Diskussion vertiefen, ob es besser ist, Geld auszugeben und eine fertige Lösung zur Überwachung 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. erzählt Jeder wählt für sich selbst aus und hat seine eigenen Gründe, eine der beiden Optionen zu wählen. Ich wollte nur zeigen, dass Netzwerktelemetrie ein sehr wichtiges Instrument zur Gewährleistung der Netzwerksicherheit der eigenen Infrastruktur ist und dass man es nicht vernachlässigen 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ähnt werden.

Zusammenfassend möchte ich die wichtigsten Ratschläge auflisten, die man bei der Umsetzung der Informationssicherheitsüberwachung seiner internen Infrastruktur beachten sollte:

Begrenzen Sie sich nicht nur auf den Perimeter! Nutzen Sie (und wählen Sie) die Netzwerkinfrastruktur nicht nur zur Übertragung von Datenverkehr von Punkt A nach Punkt B, sondern auch zur Lösung von Cybersecurity-Fragen.
Untersuchen Sie die vorhandenen Mechanismen zur Informationssicherheitsüberwachung in Ihrer Netzwerkhardware und setzen Sie diese um.
Für die interne Überwachung sollten Sie die Analyse von Telemetrie priorisieren – sie ermöglicht die Erkennung von 80-90 % aller Informationssicherheitsvorfälle und erzielt dabei Ergebnisse, die bei der Erfassung von Netzwerkpaketen unmöglich sind, während gleichzeitig Speicherplatz für alle Sicherheitsereignisse gespart wird.
Für die Überwachung von Flüssen verwenden Sie Netflow v9 oder IPFIX – diese bieten mehr Informationen im Sicherheitskontext und ermöglichen die Überwachung nicht nur von IPv4, sondern auch von IPv6, MPLS usw.
Verwenden Sie ungesampelte Flow-Protokolle – diese bieten mehr Informationen zur Bedrohungserkennung. Zum Beispiel Netflow oder IPFIX.
Überprüfen Sie die Ladefähigkeit Ihrer Netzwerkausrüstung – möglicherweise ist sie nicht in der Lage, auch das Flow-Protokoll zu verarbeiten. Denken Sie dann über den Einsatz virtueller Sensoren oder eines Netflow Generation Appliance nach.
Führen Sie die Kontrollen in erster Linie auf Zugangsebene durch – das gibt Ihnen die Möglichkeit, 100 % des gesamten Traffics zu sehen.
Wenn Sie keine Wahl haben und russische Netzwerkausrüstung verwenden, wählen Sie die, die Flow-Protokolle unterstützt oder SPAN/RSPAN-Ports besitzt.
Kombinieren Sie Systeme zur Entdeckung/Verhinderung von Eindringlingen/Angriffen an den Grenzen mit Systemen zur Analyse des Traffics im internen Netzwerk (einschließlich in der Cloud).

Was den letzten Ratschlag betrifft, möchte ich ein Beispiel anführen, das ich schon früher gebracht habe. Sie sehen, dass die Sicherheitsdienste von Cisco früher fast ihre gesamte Überwachungsinfrastruktur auf Intrusion-Detection-Systemen und signature-basierten Methoden aufgebaut haben, während heute nur noch 20 % der Vorfälle auf sie entfallen. Weitere 20 % entfallen auf Systeme zur Analyse des Traffics, was zeigt, dass diese Lösungen kein Luxus sind, sondern ein tatsächliches Werkzeug für die Sicherheitsdienste moderner Unternehmen. Vor allem, weil Sie für deren Einführung das Wichtigste haben – eine Netzwerk-Infrastruktur, in die Sie zusätzlich investieren können, indem Sie der Netzwerkinfrastruktur auch Funktionen zur Überwachung der IT-Sicherheit zuweisen.

Ich 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 Überwachung nicht nur mit der Entdeckung einer Bedrohung enden sollte. Es sollte eine Reaktion folgen, vorzugsweise automatisch oder automatisiert. Aber das ist ein Thema für ein separates Material.

Zusätzliche Informationen:

P.S. Wenn es Ihnen leichter fällt, alles, was oben geschrieben wurde, durch Zuhören zu verstehen, können Sie sich die einstündige Präsentation ansehen, die dieser Notiz zugrunde liegt.

Quelle: habr.com

Flow-Protokolle als Werkzeug zur Sicherheitsüberwachung des internen Netzwerks