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

Wenn es um die Sicherheitsüberwachung interner Unternehmens- oder Behördennetze geht, denken viele zunächst an die Kontrolle von Datenlecks und die Implementierung von DLP-Lösungen. Wenn man jedoch die Frage präzisiert und fragt, wie man Angriffe im internen Netzwerk entdeckt, wird in der Regel auf Intrusion Detection Systeme (IDS) verwiesen. Was vor 10 bis 20 Jahren die einzige Option war, gilt heute als veraltet. Es gibt effizientere – und teilweise sogar die einzigen praktikablen – Methoden zur Überwachung interner Netzwerke: die Verwendung von Flow-Protokollen, die ursprünglich zur Fehlerbehebung (Troubleshooting) konzipiert wurden, sich jedoch im Laufe der Zeit zu einem sehr interessanten Sicherheitsinstrument entwickelt haben. In diesem Artikel werden wir über die verschiedenen Arten von Flow-Protokollen sprechen, die eine bessere Erkennung von Netzwerkangriffen ermöglichen, wo die Überwachung von Flows am besten implementiert werden sollte, welche Aspekte bei der Umsetzung dieser Strategie zu beachten sind und wie man all das auf heimischer Hardware umsetzen kann.

Ich werde nicht auf die Frage eingehen: „Warum ist die Überwachung der Sicherheit der internen Infrastruktur notwendig?“ Die Antwort darauf sollte klar sein. Aber falls Sie sich dennoch vergewissern möchten, dass man heute nicht darauf verzichten kann, sehen Sie sich ein kurzes Video an, das zeigt, wie man auf 17 verschiedenen Wegen in ein durch eine Firewall geschütztes Unternehmensnetz eindringen kann. Daher wollen wir annehmen, dass wir verstehen, dass eine interne Überwachung notwendig ist, und es bleibt nur noch zu klären, wie man diese organisieren kann.

Ich würde drei Schlüsselquellen für die Überwachung der Infrastruktur auf Netzwerkebene hervorheben:

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

Der Rohdatenverkehr ist bei Sicherheitsexperten die beliebteste Option, da er historisch gesehen die erste war. Traditionelle Intrusion Detection Systeme (das erste kommerzielle IDS war NetRanger von Wheel Group, das 1998 von Cisco übernommen wurde) konzentrierten sich auf das Abfangen von Paketen (später auch von Sitzungen), in denen nach bestimmten Signaturen („entscheidende Regeln“ in der Terminologie des FSTEK) gesucht wurde, die auf Angriffe hinwiesen. Natürlich kann der Rohdatenverkehr nicht nur mit IDS analysiert werden, sondern auch mit anderen Mitteln (zum Beispiel Wireshark, tcpdump oder die Funktion NBAR2 im Cisco IOS), jedoch fehlt diesen häufig die Wissensbasis, die ein Informationssicherheitswerkzeug von einem herkömmlichen IT-Tool unterscheidet.

Angriffsdetektionssysteme stellen die älteste und bekannteste Methode zur Erkennung von Netzwerkangriffen dar, die am Perimeter (unabhängig davon, ob es sich um Unternehmensnetzwerke, Rechenzentren oder Segmente handelt) recht gut funktioniert, jedoch in modernen, switchbasierten und softwaredefinierten Netzwerken an ihre Grenzen stößt. Bei einem Netzwerk, das auf herkömmlichen Switches basiert, wird die Infrastruktur der Angriffsdetektoren so groß, dass Sie für jede Verbindung zu einem Knoten, den Sie überwachen möchten, einen Detektor benötigen. Jeder Hersteller wird Ihnen sicherlich gerne Hunderte und Tausende von Sensoren verkaufen, aber ich bezweifle, dass Ihr Budget solche Ausgaben tragen kann. Selbst bei Cisco (wir sind Entwickler von NGIPS) konnten wir dies nicht umsetzen, obwohl es schien, dass der Preis kein Hindernis darstellen sollte – schließlich handelt es sich um unsere eigene Lösung. Zudem stellt sich die Frage, wie man in diesem Fall den Sensor anschließt. Ist ein Bypass erforderlich? Was passiert, wenn der Sensor selbst ausfällt? Ist es notwendig, ein Bypass-Modul im Sensor zu haben? Sollten wir Splitter (Taps) verwenden? All dies erhöht die Kosten der Lösung und macht sie für Unternehmen jeder Größe unerschwinglich.

Es besteht die Möglichkeit, einen Sensor an einen SPAN/RSPAN/ERSPAN-Port anzuschließen und den Verkehr von den benötigten Ports des Switches dorthin zu lenken. Diese Lösung mildert teilweise das Problem, das im vorherigen Absatz beschrieben wurde, bringt jedoch ein anderes mit sich: Der SPAN-Port kann nicht den gesamten Verkehr aufnehmen, der ihm zugewiesen wird – seine Bandbreite reicht dafür nicht aus. Es wird notwendig sein, Kompromisse einzugehen. Entweder müssen einige Knoten ohne Überwachung bleiben (in diesem Fall sollten Sie zuvor deren Priorität festlegen), oder es wird nur ein bestimmter Verkehrstyp von einem Knoten umgeleitet. In jedem Fall besteht die Möglichkeit, dass wir einige Angriffe übersehen. Darüber hinaus kann der SPAN-Port für andere Zwecke belegt sein. Letztendlich müssen wir die bestehende Netzwerkarchitektur überdenken und eventuell Änderungen vornehmen, um die Maximalabdeckung Ihres Netzwerks mit der verfügbaren Anzahl an Sensoren zu gewährleisten und dies mit der IT abzustimmen.

Was ist, wenn Ihr Netzwerk asymmetrische Routen verwendet? Was ist, wenn Sie SDN implementiert haben oder planen, es zu implementieren? Was ist, wenn Sie virtualisierte Maschinen oder Container überwachen müssen, deren Verkehr die physische Switch überhaupt nicht erreicht? Diese Fragen sind für Anbieter traditioneller IDS unangenehm, da sie nicht wissen, wie sie darauf antworten sollen. Vielleicht werden sie Ihnen einreden, dass all diese modernen Technologien nur Hype sind und Sie sie nicht benötigen. Vielleicht sagen sie, dass Sie klein anfangen sollten. Oder sie empfehlen Ihnen, eine leistungsstarke Maschine ins Netzwerk zu stellen und den gesamten Verkehr über Lastverteiler dorthin zu leiten. Welches Angebot auch immer Sie erhalten, es ist wichtig, selbst zu verstehen, wie gut es zu Ihren Anforderungen passt. Nur dann können Sie eine fundierte Entscheidung über den Ansatz zur Überwachung der IT-Sicherheit Ihrer Netzwerk-Infrastruktur treffen. Zum Thema Paketvorausschau möchte ich sagen, dass diese Methode nach wie vor sehr beliebt und wichtig ist, ihr Hauptzweck jedoch die Kontrolle von Grenzen ist: die Grenze zwischen Ihrer Organisation und dem Internet, die Grenze zwischen dem Rechenzentrum und dem Rest des Netzwerks, die Grenze zwischen dem Betriebsführungssystem und dem Unternehmenssegment. In diesen Bereichen haben klassische IDS/IPS nach wie vor ihre Berechtigung und erfüllen ihre Aufgaben gut.

Kommen wir zur zweiten Variante. Die Analyse von Ereignissen, die von Netzwerkteilen eingehen, kann ebenfalls zur Erkennung von Angriffen genutzt werden, jedoch nicht als primärer Mechanismus, da sie nur eine kleine Klasse von Eindringlingen erkennen kann. Außerdem ist sie reaktiv — ein Angriff muss zuerst stattfinden, bevor er von einem Netzwerkgerät erfasst wird, das dann irgendwie auf das Problem im Bereich der Informationssicherheit hinweist. Es gibt mehrere Methoden dafür. Das kann syslog, RMON oder SNMP sein. Letztere beiden Protokolle werden im Kontext der Informationssicherheit nur verwendet, wenn wir eine DoS-Attacke auf die Netzwerkinfrastruktur selbst erkennen müssen, da wir mit RMON und SNMP zum Beispiel die Auslastung des Prozessors oder seiner Schnittstellen überwachen können. Dies ist eine der kostengünstigsten Methoden (da syslog oder SNMP überall verfügbar sind), aber sie ist auch die ineffektivste Methode zur Überwachung der Informationssicherheit in der internen Infrastruktur — viele Angriffe bleiben einfach unentdeckt. Selbstverständlich sollten sie nicht ignoriert werden, und die Analyse des syslogs hilft Ihnen, rechtzeitig Änderungen in der Konfiguration des Geräts selbst oder dessen Kompromittierung zu erkennen, aber zur Erkennung von Angriffen auf das gesamte Netzwerk ist sie weniger geeignet.

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

Generierung oder Export von Flows. Diese Aufgabe wird in der Regel einem Router, Switch oder einem anderen Netzwerkgerät übertragen, das, während es den Netzwerkverkehr durchlässt, die Schlüsselparameter herausfiltert, die anschließend an das Sammlungmodul übermittelt werden. Bei Cisco wird das NetFlow-Protokoll nicht nur auf Routern und Switches, einschließlich virtueller und industrieller Geräte, unterstützt, sondern auch auf drahtlosen Controllern, Firewalls und sogar Servern.
Sammlung von Flows. Da in modernen Netzwerken normalerweise mehr als ein Netzwerkgerät vorhanden ist, stellt sich die Aufgabe der Sammlung und Konsolidierung von Flows, die durch sogenannte Collector-Geräte gelöst wird, welche die erhaltenen Flows verarbeiten und sie dann zur Analyse weitergeben.
Flow-Analyse. Der Analyzer übernimmt die zentrale intellektuelle Aufgabe und wendet verschiedene Algorithmen auf die Datenströme an, um entsprechende Schlussfolgerungen zu ziehen. Im Rahmen der IT-Funktion kann ein solcher Analyzer Engpässe im Netzwerk identifizieren oder das Traffic-Lastprofil analysieren, um das Netzwerk weiter zu optimieren. Für die Informationssicherheit kann dieser Analyzer Datenlecks, die Verbreitung von Malware oder DoS-Angriffe aufdecken.

Es ist ein Missverständnis zu glauben, dass eine dreischichtige Architektur zu kompliziert ist – alle anderen Varianten (außer vielleicht Netzwerküberwachungssysteme, die mit SNMP und RMON arbeiten) folgen ebenfalls diesem Prinzip. Wir verfügen über einen Datengenerator zur Analyse, der ein Netzwerkgerät oder einen separaten Sensor darstellt. Zusätzlich haben wir ein System zur Erfassung von Alarmmeldungen und ein System zur Verwaltung der gesamten Monitoring-Infrastruktur. Die letzten beiden Komponenten können innerhalb eines einzelnen Knotens zusammengefasst werden, aber in größeren Netzwerken sind sie in der Regel auf mindestens zwei separate Geräte verteilt, um Skalierbarkeit und Zuverlässigkeit zu gewährleisten.

Im Gegensatz zur Paketanalyse, die sich auf die Untersuchung der Header und Datenkörper jedes Pakets sowie der damit verbundenen Sitzungen stützt, basiert die Flow-Analyse auf der Sammlung von Metadaten über den Netzwerkverkehr. Wann, wie viel, von wo und wohin – das sind die Fragen, auf die die Analyse der Netztelemetrie mittels verschiedener Flow-Protokolle Antworten gibt. Ursprünglich wurden sie zur Analyse von Statistiken und zur Identifizierung von IT-Problemen im Netzwerk verwendet, aber mit der Weiterentwicklung der Analysemethoden konnten sie auch für dieselbe Telemetrie zu Sicherheitszwecken eingesetzt werden. Hier ist es wichtig zu betonen, dass die Flow-Analyse die Paketaufnahme nicht ersetzt und nicht annulliert. Jeder dieser Methoden hat seine eigenen Anwendungsbereiche. Aber im Kontext dieses Artikels eignet sich die Flow-Analyse am besten für die Überwachung der internen Infrastruktur. Sie haben Netzwerkgeräte (und es spielt keine Rolle, ob sie nach einem softwaredefinierten Paradigma oder nach statischen Regeln arbeiten), die von einem Angriff nicht umgangen werden können. Ein klassischer IDS-Sensor kann möglicherweise umgangen werden, aber ein Netzwerkgerät, das ein Flow-Protokoll unterstützt, nicht. Das ist der Vorteil dieser Methode.

Andererseits, wenn Sie Beweismaterial für Strafverfolgungsbehörden oder Ihr eigenes Incident-Response-Team benötigen, kommen Sie nicht ohne Packet Capture aus – die Netzwerk-Telemetrie ist kein Traffic-Kopie, die zur Beweissammlung verwendet werden kann; sie ist notwendig für die schnelle Erkennung und Entscheidungsfindung im Bereich der Informationssicherheit. Andererseits können Sie mit der Analyse von Telemetrie nicht den gesamten Netzwerkverkehr „aufzeichnen“ (für den Fall, dass Cisco und Rechenzentren involviert sind :-), sondern nur den, der an einem Angriff beteiligt ist. Telemetrie-Analysetools ergänzen in dieser Hinsicht die traditionellen Packet-Capture-Mechanismen gut, indem sie der Mannschaft die selektive Erfassung und Speicherung ermöglichen. Andernfalls müssten Sie eine enorme Speicherinfrastruktur bereitstellen.

Stellen Sie sich ein Netzwerk vor, das mit einer Geschwindigkeit von 250 Mbit/s arbeitet. Wenn Sie all diese Daten speichern möchten, benötigen Sie 31 MB Speicher 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 tägliche Daten von einem Netzwerk mit einer Bandbreite von 10 Gbit/s zu speichern, benötigen Sie 108 TB Speicher. Einige Aufsichtsbehörden verlangen schließlich, dass Daten aus Sicherheitsgründen über Jahre hinweg aufbewahrt werden... Die Aufzeichnung "nach Bedarf", die Ihnen durch die Analyse von Datenströmen ermöglicht wird, hilft, diese Werte um ein Vielfaches zu reduzieren. Übrigens, wenn wir das Verhältnis des Volumens der aufgezeichneten Daten aus der Netzwerktelemetrie zur vollständigen Datenerfassung betrachten, beträgt dieses etwa 1 zu 500. Für die oben genannten Werte würde die Speicherung der vollständigen Aufschlüsselung des gesamten täglichen Traffics 5 und 216 GB entsprechen (was sogar auf einem normalen USB-Stick gespeichert werden kann).

Wenn es bei der Analyse roher Netzwerkdaten kaum Unterschiede zwischen den Erfassungsmethoden der Anbieter gibt, sieht die Lage bei der Analyse von Streams anders aus. Es gibt mehrere Varianten von Flow-Protokollen, über deren Unterschiede man im Kontext der Sicherheit Bescheid wissen sollte. Das bekannteste Protokoll ist Netflow, das von Cisco entwickelt wurde. Es existieren mehrere Versionen dieses Protokolls, die sich hinsichtlich ihrer Funktionen und der Menge der aufgezeichneten Verkehrsinformationen unterscheiden. Die aktuelle Version ist die neunte (Netflow v9), auf deren Grundlage der Industriestandard Netflow v10, auch bekannt als IPFIX, entwickelt wurde. Heutzutage unterstützen die meisten Netzwerk-Anbieter entweder Netflow oder IPFIX in ihrer Hardware. Es gibt jedoch auch verschiedene andere Varianten von Flow-Protokollen – sFlow, jFlow, cFlow, rFlow, NetStream usw., wobei sFlow am beliebtesten ist. Es wird am häufigsten von einheimischen Herstellern von Netzwerkhardware wegen der einfachen Implementierung unterstützt. Was sind die wesentlichen Unterschiede zwischen Netflow, das de facto zum Standard geworden ist, und sFlow? Ich würde mehrere Hauptunterschiede herausstellen. Erstens hat Netflow anpassbare Benutzerfelder, im Gegensatz zu den festen Feldern in sFlow. Und zweitens – und das ist in unserem Fall am wichtigsten – sammelt sFlow die sogenannte samplierte Telemetrie, im Gegensatz zu der unsampierten Telemetrie bei Netflow und IPFIX. Wo liegen also die Unterschiede 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 Alfarwan (ü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 betrachten und dabei auf jeder 10. oder 20. Seite zu verweilen, oder zu versuchen, eine Zusammenfassung der wichtigsten Konzepte in einem Blog oder einem Service wie SmartReading zu finden. Unsamplierte Telemetrie bedeutet, jede “Seite” des Netzwerkverkehrs zu lesen, also die Metadaten jedes Pakets zu analysieren. Samplierte Telemetrie hingegen ist die selektive Untersuchung des Verkehrs in der Hoffnung, dass in den ausgewählten Proben das enthalten ist, was Sie benötigen. Je nach Kanalgeschwindigkeit wird die samplierte Telemetrie jede 64., 200., 500., 1000., 2000. oder sogar 10000. Probe zur Analyse abgeben.

Im Kontext der Sicherheitsüberwachung bedeutet dies, dass die gesampelte Telemetrie gut geeignet ist, um DDoS-Angriffe, Scans und die Verbreitung von Malware zu erkennen. Jedoch kann sie atomare oder paketübergreifende Angriffe, die nicht in das gesampelte Datenpaket zur Analyse aufgenommen werden, übersehen. Solche Mängel hat die unsamplete Telemetrie nicht, und ihrem Einsatz ermöglicht eine breitere Palette von erkennbaren Angriffen. Hier ist eine kleine Liste von Ereignissen, die mit Hilfe von Netzanalysetools zur Telemetriedatenanalyse erkannt werden können.

Natürlich wird Ihnen ein Open-Source-Netflow-Analyzer dies nicht ermöglichen, da dessen Hauptaufgabe darin besteht, Telemetrie zu sammeln und eine grundlegende Analyse aus Sicht der IT durchzuführen. Um Bedrohungen im Bereich der Cybersicherheit basierend auf Flow-Daten zu erkennen, muss der Analyzer mit verschiedenen Engines und Algorithmen ausgestattet werden, die in der Lage sind, Probleme der Cybersicherheit durch Standard- oder benutzerdefinierte Netflow-Felder zu identifizieren und die Standarddaten mit externen Daten aus verschiedenen Threat Intelligence-Quellen anzureichern.

Wenn Sie die Wahl haben, wählen Sie Netflow oder IPFIX. Selbst wenn Ihre Geräte nur sFlow unterstützen, wie bei einigen heimischen Herstellern, können Sie dennoch im Hinblick auf die Sicherheit davon profitieren.

Im Sommer 2019 habe ich die Möglichkeiten russischer Hersteller von Netzwerktechnik untersucht. Alle, mit Ausnahme von NSG, Poligon und Kraftway, gaben an, sFlow zu unterstützen (zumindest Zelax, Natex, Eltex, QTech, Rusteletech).

Die nächste Frage, die sich Ihnen stellen wird, ist, wo Sie die Flow-Unterstützung für Sicherheitszwecke implementieren sollten. Tatsächlich ist die Frage nicht ganz korrekt formuliert. Bei modernem Equipment ist die Unterstützung von Flow-Protokollen fast immer vorhanden. Daher würde ich die Frage anders formulieren – wo ist es am effizientesten, Telemetrie aus sicherheitstechnischer Sicht zu sammeln? Die Antwort ist recht offensichtlich: auf der Zugriffsebene, wo Sie 100 % des gesamten Verkehrs sehen, wo Sie detaillierte Informationen zu Hosts (MAC, VLAN, Schnittstellen-ID) erhalten und sogar P2P-Verkehr zwischen Hosts überwachen können, was entscheidend für die Erkennung von Scanning und der Verbreitung von Malware ist. Auf der Kernel-Ebene können Sie einen Teil des Verkehrs einfach nicht sehen, und auf der 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 durchlaufen, wird die Analyse der Telemetrie von dort Ihnen nichts bringen. Daher wird empfohlen, die Telemetriesammlung genau auf der Zugriffsebene zu aktivieren. Dabei sollte beachtet werden, dass selbst wenn wir über Virtualisierung oder Container sprechen, moderne virtuelle Switches oft auch Flow-Unterstützung bieten, was eine Überwachung des Verkehrs dort ermöglicht.

Aber da ich das Thema angesprochen habe, sollte ich auch die Frage beantworten: Was passiert, wenn die Hardware, egal ob physisch oder virtuell, die Flow-Protokolle nicht unterstützt? Oder wenn deren Aktivierung untersagt ist (wie beispielsweise im Industriesektor zur Gewährleistung der Zuverlässigkeit)? Oder wenn die Aktivierung zu einer hohen CPU-Auslastung führt (was bei veralteter Hardware vorkommen kann)? Um dieses Problem zu lösen, gibt es spezielle virtuelle Sensoren (Flow Sensoren), die im Grunde genommen gewöhnliche Splitter sind, die den Verkehr durchlassen und ihn in Form von Flows an das Sammelmodul weiterleiten. Allerdings bringt dies die Vielzahl von Problemen mit sich, die wir zuvor in Bezug auf die Paketaufnahme angesprochen haben. Es ist also wichtig, nicht nur die Vorteile der Technologie zur Flussanalyse zu verstehen, sondern auch ihre Einschränkungen.

Ein weiterer Punkt, den es zu beachten gilt, wenn man über Analysetools für Datenströme spricht. Während wir bei gewöhnlichen Sicherheitsereignis-Generatoren die Metrik EPS (events per second, Ereignisse pro Sekunde) verwenden, ist diese Metrik für die Telemetrieanalyse nicht anwendbar; hier wird sie durch FPS (flows per second, Ströme pro Sekunde) ersetzt. Genau wie bei EPS kann man diesen Wert nicht im Voraus berechnen, jedoch kann man die ungefähre Anzahl der Ströme, die ein bestimmtes Gerät in Abhängigkeit von seiner Aufgabe erzeugt, schätzen. Im Internet finden Sie Tabellen mit ungefähren Werten für verschiedene Arten von Unternehmensgeräten und Bedingungen, die Ihnen helfen werden, abzuschätzen, welche Lizenzen für Ihre Analysetools benötigt werden und wie deren Architektur aussehen wird. Der Punkt ist, dass ein IDS-Sensor eine bestimmte Bandbreite hat, die er „ziehen“ kann, und auch der Stream-Collector hat seine eigenen Grenzen, die man verstehen muss. Daher gibt es in großen, geografisch verteilten Netzwerken in der Regel mehrere Collector-Instanzen. Als ich beschrieb, wie das Netzwerk innerhalb von Cisco überwacht wird., Ich habe bereits die Zahl unserer Collector-Geräte 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 Sicherheitsherausforderungen ausgerichtet ist. Es verfügt über zahlreiche integrierte Engines zur Erkennung von anomaler, verdächtiger und offensichtlich schädlicher Aktivität, die es ermöglicht, eine Vielzahl unterschiedlicher Bedrohungen zu erkennen – von Krypto-Mining über Datenlecks bis hin zu Malware-Verbreitung und Betrug. Wie die meisten Stealthwatch-Datenanalysatoren folgt auch dieses einem dreistufigen Schema (Generator – Collector – Analyzer), ist jedoch mit einer Reihe interessanter Funktionen ausgestattet, die im Kontext des behandelten Themas wichtig sind. Erstens integriert es sich mit Lösungen zum Paket-Sniffing (zum Beispiel dem Cisco Security Packet Analyzer), was es ermöglicht, ausgewählte Netzwerk-Sitzungen für eine tiefgehende Untersuchung und Analyse aufzuzeichnen. Zweitens haben wir speziell zur Erweiterung der Sicherheitsaufgaben ein eigenes Protokoll namens nvzFlow entwickelt, das die Aktivität von Anwendungen auf Endgeräten (Servern, Workstations usw.) in Telemetrie “überträgt” und diese zur weiteren Analyse an den Collector sendet. 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 die Datenkorrelation auch auf Knotenebene, wodurch die Effizienz des gesamten Systems gesteigert wird und mehr Angriffe sichtbar gemacht werden als mit herkömmlichen Netzwerk-Flow-Analysewerkzeugen.

Es ist klar, dass der Markt für NetFlow-Analyse-Systeme in Bezug auf Sicherheit nicht auf eine einzige Lösung von Cisco beschränkt ist. Sie können sowohl kommerzielle als auch kostenlose oder freemium-basierte Lösungen nutzen. Es wäre seltsam, wenn ich in einem Cisco-Blog Beispiele von Konkurrenzprodukten anführe, daher möchte ich ein paar Worte darüber verlieren, wie Netzwerktelemtrie mit zwei beliebten, ähnlich benannten, jedoch unterschiedlichen Werkzeugen – SiLK und ELK – analysiert werden kann.

SiLK ist ein Werkzeugset (System for Internet-Level Knowledge) zur Analyse von Datenverkehr, das vom US-amerikanischen CERT/CC entwickelt wurde und im Kontext dieses Artikels NetFlow (Versionen 5 und 9, die populärsten) sowie IPFIX und sFlow unterstützt. Mit verschiedenen Tools (rwfilter, rwcount, rwflowpack usw.) können diverse Operationen auf der Netzwerktelemtrie durchgeführt werden, um Anzeichen unbefugter Aktivitäten zu entdecken. Dennoch sollten einige wichtige Punkte erwähnt werden. SiLK ist ein Befehlszeilenwerkzeug, und die Durchführung von Echtzeitanalysen erfordert ständig Eingaben wie (Erkennung von ICMP-Paketen über 200 Bytes):

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

es ist nicht besonders praktisch. Sie können das grafische iSiLK-Interface nutzen, aber das wird Ihr Leben nicht wesentlich erleichtern, da es nur die Funktion der Visualisierung und nicht die Analyse ersetzt. Das ist der zweite Punkt. Im Gegensatz zu kommerziellen Lösungen, in die bereits eine umfangreiche analytische Basis, Algorithmen zur Anomalieerkennung und entsprechende Workflows integriert sind, müssen Sie bei SiLK all dies selbst umsetzen, was andere Kompetenzen erfordert als die Nutzung eines bereits einsatzbereiten Tools. Das ist weder gut noch schlecht – es ist eine Eigenschaft nahezu jedes kostenlosen Werkzeugs, das davon ausgeht, dass Sie wissen, was zu tun ist, und es Ihnen lediglich dabei hilft. Kommerzielle Werkzeuge sind weniger von den Fähigkeiten ihrer Nutzer abhängig, setzen jedoch ebenfalls voraus, dass die Analysten wenigstens die Grundlagen der Netzwerkermittlungen und -überwachung verstehen. Aber zurück zu SiLK. Der Arbeitsablauf eines Analysten damit sieht folgendermaßen aus:

Hypothesenbildung. Wir müssen verstehen, wonach wir innerhalb der Netzwerk-Telemetrie suchen werden und die einzigartigen Attribute kennen, anhand derer wir bestimmte Anomalien oder Bedrohungen identifizieren.
Modellierung. Nachdem wir die Hypothese formuliert haben, setzen wir sie mit Python, Shell oder anderen nicht in SiLK enthaltenen Werkzeugen um.
Testen. Jetzt kommt die Überprüfung unserer Hypothese, die mit Hilfe von SiLK-Tools, die mit 'rw', 'set', 'bag' beginnen, bestätigt oder widerlegt wird.
Analyse realer Daten. In der praktischen Anwendung von SiLK hilft es uns, etwas zu identifizieren, und der Analyst sollte auf die Fragen antworten: 'Haben wir gefunden, was wir erwartet haben?', 'Entspricht das unserer Hypothese?', 'Wie können wir die Anzahl der falsch positiven Ergebnisse reduzieren?', 'Wie können wir die Erkennungsrate verbessern?' usw.
Verbesserung. Im finalen Schritt verbessern wir, was wir zuvor gemacht haben – wir erstellen Vorlagen, optimieren und verbessern den Code, überarbeiten und präzisieren die Hypothese und mehr.

Dieser Zyklus ist auch auf Cisco Stealthwatch anwendbar, wobei letzteres die fünf Schritte maximal automatisiert, um die Anzahl der Analystenfehler zu reduzieren und die Erkennung von Vorfällen zu beschleunigen. Zum Beispiel können Sie in SiLK Netzstatistiken mit externen Daten zu bösartigen IPs mithilfe selbstgeschriebener Skripte anreichern, während Cisco Stealthwatch eine integrierte Funktion bietet, die sofort einen Alarm anzeigt, wenn im Netzwerkverkehr eine Interaktion mit IP-Adressen aus der schwarzen Liste auftritt.

Wenn man höher in der „Preispyramide“ für Flow-Analyse-Software geht, folgt auf das völlig kostenlose SiLK das bedingt kostenlose ELK, das aus drei Hauptkomponenten besteht – Elasticsearch (Indizierung, Suche und Analyse von Daten), Logstash (Dateninput/-output) und Kibana (Visualisierung). Im Unterschied zu SiLK, wo alles selbst geschrieben werden muss, bietet ELK bereits viele fertige Bibliotheken/Module (einige kostenpflichtig, andere kostenlos), die die Analyse von Netzwerktelemetrie automatisieren. Zum Beispiel ermöglicht der GeoIP-Filter in Logstash die Zuordnung beobachteter IP-Adressen zu deren geografischem Standort (bei Stealthwatch ist dies eine integrierte Funktion).

Bei ELK gibt es auch eine recht große Community, die fehlende Komponenten für diese Überwachungs-Lösung ergänzt. Um mit NetFlow, IPFIX und sFlow zu arbeiten, können Sie das Modul elastiflow, verwenden, falls Sie mit dem Logstash NetFlow-Modul, das nur NetFlow unterstützt, unzufrieden sind.

Während die Flussdatensammlung und -analyse bei ELK schneller erfolgt, fehlt es gegenwärtig an umfassenden integrierten Analysefunktionen zur Entdeckung von Anomalien und Bedrohungen in der Netzwerktelemetrie. Das bedeutet, dass Sie gemäß dem zuvor beschriebenen Lebenszyklus Modelle für Verstöße selbst erstellen müssen, um diese dann im operativen System zu nutzen (eingebaute Modelle sind nicht vorhanden).

Es gibt natürlich auch ausgefeiltere Erweiterungen für ELK, die bereits einige Modelle zur Erkennung von Anomalien in der Netzwerktelemetrie enthalten, aber solche Erweiterungen kosten Geld. Hier stellt sich die Frage, ob sich der Aufwand lohnt — ein ähnliches Modell selbst zu entwickeln, dessen Implementierung zu kaufen oder eine fertige Lösung aus der Kategorie Netzwerk-Traffic-Analyse zu erwerben.

Ich möchte überhaupt nicht in die Debatte einsteigen, ob es besser ist, Geld auszugeben und eine fertige Lösung zur Überwachung von Anomalien und Bedrohungen in der Netztelemetrie zu kaufen (wie zum Beispiel Cisco Stealthwatch), oder ob man selbst Hand anlegt und selbstständig Lösungen wie SiLK, ELK oder nfdump bzw. OSU Flow Tools anpasst (ich spreche von Letzteren aus der letzten Runde). erzählt Jeder wählt für sich selbst und hat seine eigenen Gründe, eine der beiden Optionen zu bevorzugen. Ich wollte lediglich aufzeigen, dass Netztelemetrie ein äußerst wichtiges Werkzeug für die Sicherheit der internen Infrastruktur ist, und man sollte es nicht vernachlässigen, um nicht auf der Liste von Unternehmen zu landen, deren Namen in den Medien zusammen mit den Schlagworten „gehackt“, „nicht konform mit Sicherheitsanforderungen“, „sich keine Gedanken über die Sicherheit ihrer Daten und der Daten ihrer Kunden machend“ erwähnt wird.

Abschließend möchte ich einige wichtige Tipps auflisten, die man beim Aufbau der Sicherheitsüberwachung der eigenen internen Infrastruktur beachten sollte:

Begrenzen Sie sich nicht nur auf den Netzwerkperimeter! Nutzen Sie (und wählen Sie) Ihre Netzwerkinfrastruktur nicht nur zur Übertragung von Daten von Punkt A nach Punkt B, sondern auch zur Verbesserung der Cybersicherheit.
Untersuchen Sie die bestehenden Überwachungsmechanismen der Informationssicherheit in Ihrer Netzwerktechnologie und setzen Sie diese ein.
Für die interne Überwachung bevorzugen Sie die Analyse von Telemetriedaten – sie ermöglicht es, 80-90% aller Sicherheitsvorfälle im Netzwerk zu erkennen, ohne dabei auf die Erfassung von Netzwerkpaketen angewiesen zu sein, und spart Speicherplatz für alle Sicherheitsereignisse.
Für das Monitoring von Datenströmen verwenden Sie NetFlow v9 oder IPFIX – diese bieten mehr Informationen im Kontext der Sicherheit und ermöglichen es, nicht nur IPv4, sondern auch IPv6, MPLS usw. zu überwachen.
Verwenden Sie einen nicht-sampelnden Flow-Protokoll – er liefert mehr Informationen zur Bedrohungserkennung. Beispiele hierfür sind NetFlow oder IPFIX.
Überprüfen Sie die Auslastung Ihrer Netzwerktechnologie – möglicherweise kann diese den zusätzlichen Flow-Protokollverkehr nicht bewältigen. In diesem Fall sollten Sie die Verwendung von virtuellen Sensoren oder einer NetFlow-Generierungsappliance in Betracht ziehen.
Implementieren Sie die Kontrolle zunächst auf Zugriffsebene – dies ermöglicht es Ihnen, 100% des gesamten Datenverkehrs zu sehen.
Wenn Sie keine andere Wahl haben und russische Netzwerkausrüstung verwenden, wählen Sie diejenige, die Flow-Protokolle unterstützt oder über SPAN/RSPAN-Ports verfügt.
Kombinieren Sie Systeme zur Erkennung und Verhinderung von Eindringlingen/Angriffen an den Grenzen mit Systemen zur Analyse von Datenströmen im internen Netzwerk (einschließlich in der Cloud).

Was den letzten Ratschlag betrifft, möchte ich ein Bild zeigen, das ich bereits früher verwendet habe. Sie sehen, dass die Cisco-Sicherheitsdienste früher nahezu vollständig ihr Überwachungssystem auf der Grundlage von Eindringungserkennungssystemen und signaturbasierten Methoden aufgebaut haben, während dies jetzt nur noch 20% der Vorfälle ausmacht. Weitere 20% entfallen auf Systeme zur Analyse von Datenströmen, was zeigt, dass diese Lösungen kein Luxus, sondern ein echtes Werkzeug für die Sicherheitsdienste moderner Unternehmen sind. Umso mehr, da Sie für deren Implementierung das Wichtigste haben — die Netzwerkinfrastruktur, in die Sie zusätzlich investieren können, um auch Funktionen zur Sicherheitsüberwachung zu integrieren.

Ich habe bewusst das Thema der Reaktion auf erkannte Anomalien oder Bedrohungen im Datenverkehr nicht angesprochen, aber ich denke, es ist offensichtlich, dass die Überwachung nicht nur mit der Entdeckung einer Bedrohung enden sollte. Darauf sollte eine Reaktion folgen, idealerweise automatisch oder automatisiert. Aber das ist bereits das Thema eines separaten Artikels.

Zusätzliche Informationen:

PS: Wenn es für Sie einfacher ist, alles, was oben geschrieben wurde, akustisch zu erfassen, können Sie sich die einstündige Präsentation ansehen, die der Grundlage dieser Notiz zugrunde liegt.

Quelle: habr.com

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

Juri Gagarin