Wenn es um die Überwachung der Sicherheit eines internen Unternehmens- oder Abteilungsnetzwerks geht, verbinden viele damit die Kontrolle von Informationslecks und die Implementierung von DLP-Lösungen. Und wenn Sie versuchen, die Frage zu verfeinern und zu fragen, wie Sie Angriffe auf das interne Netzwerk erkennen, dann wird die Antwort in der Regel die Erwähnung von Intrusion-Detection-Systemen (IDS) sein. Und was vor 10 bis 20 Jahren die einzige Option war, wird heute zum Anachronismus. Es gibt eine effektivere und an manchen Stellen einzig mögliche Möglichkeit zur Überwachung des internen Netzwerks – die Verwendung von Flow-Protokollen, die ursprünglich für die Suche nach Netzwerkproblemen (Fehlerbehebung) entwickelt wurden, sich aber im Laufe der Zeit zu einem sehr interessanten Sicherheitstool entwickelt haben. Hier werden wir darüber sprechen, was Flow-Protokolle sind und welche dabei helfen, Netzwerkangriffe besser zu erkennen, wo die Flow-Überwachung am besten implementiert werden kann, worauf bei der Bereitstellung eines solchen Schemas zu achten ist und sogar, wie man alles auf Haushaltsgeräten „anhebt“. , wir werden im Rahmen dieses Artikels sprechen.
Auf die Frage „Warum müssen wir die Sicherheit der internen Infrastruktur überwachen?“ möchte ich nicht näher eingehen. Die Antwort darauf liegt auf der Hand. Wenn Sie sich dennoch noch einmal vergewissern möchten, dass Sie heute nicht darauf verzichten können, Ein kurzes Video mit einer Geschichte darüber, wie Sie auf 17 Arten in ein durch eine Firewall geschütztes Unternehmensnetzwerk gelangen können. Daher gehen wir davon aus, dass wir verstehen, dass die interne Überwachung eine notwendige Sache ist und dass wir nur noch verstehen müssen, wie sie organisiert werden kann.
Ich würde drei wichtige Datenquellen für die Infrastrukturüberwachung auf Netzwerkebene hervorheben:
- „roher“ Datenverkehr, den wir erfassen und zur Analyse an einige Analysesysteme übermitteln,
- Ereignisse von Netzwerkgeräten, über die der Datenverkehr läuft,
- Verkehrsinformationen, die über eines der Flussprotokolle empfangen werden.
Die Erfassung des Rohdatenverkehrs ist bei Sicherheitsleuten die beliebteste Option, da sie historisch gesehen die allererste war. Herkömmliche Netzwerk-Intrusion-Detection-Systeme (das allererste kommerzielle Intrusion-Detection-System war NetRanger von der Wheel Group, das 1998 von Cisco gekauft wurde) waren lediglich mit der Erfassung von Paketen (und späteren Sitzungen) beschäftigt, in denen nach bestimmten Signaturen gesucht wurde („entscheidende Regeln“ im Englischen). Terminologie des FSTEC), Signalisierung von Angriffen. Natürlich können Sie Rohdatenverkehr nicht nur mit IDS analysieren, sondern auch mit anderen Tools (z. B. Wireshark, tcpdum oder der NBAR2-Funktionalität in Cisco IOS), aber ihnen fehlt normalerweise die Wissensbasis, die ein Informationssicherheitstool von einem unterscheidet normales IT-Tool.
Also Einbruchmeldesysteme. Die älteste und beliebteste Methode zur Erkennung von Netzwerkangriffen, die am Perimeter (egal was – Unternehmen, Rechenzentrum, Segment usw.) gute Arbeit leistet, in modernen Switched- und Software-definierten Netzwerken jedoch versagt. Bei einem Netzwerk, das auf der Basis herkömmlicher Switches aufgebaut ist, wird die Infrastruktur der Intrusion-Detection-Sensoren zu groß – Sie müssen an jeder Verbindung zum Host, gegen den Sie Angriffe überwachen möchten, einen Sensor anbringen. Natürlich verkauft Ihnen jeder Hersteller gerne Hunderte und Tausende von Sensoren, aber ich denke, Ihr Budget kann solche Kosten nicht tragen. Ich kann sagen, dass uns dies selbst bei Cisco (und wir sind die Entwickler von NGIPS) nicht gelungen ist, obwohl wir scheinbar vor der Frage des Preises stehen. sollte nicht bestehen - das ist unsere eigene Entscheidung. Außerdem stellt sich die Frage, wie wird der Sensor in dieser Version angeschlossen? In eine Lücke? Was passiert, wenn der Sensor selbst ausfällt? Benötigen Sie ein Bypass-Modul im Sensor? Splitter (Wasserhahn) verwenden? All dies erhöht die Kosten der Lösung und macht sie für ein Unternehmen jeder Größe unerschwinglich.
Sie können versuchen, den Sensor am SPAN/RSPAN/ERSPAN-Port zu „hängen“ und den Datenverkehr von den erforderlichen Switch-Ports dorthin zu leiten. Diese Option beseitigt teilweise das im vorherigen Absatz beschriebene Problem, wirft jedoch ein anderes auf: Der SPAN-Port kann nicht absolut den gesamten Datenverkehr empfangen, der an ihn gesendet wird – er verfügt dann nicht über genügend Bandbreite. Bereit, etwas zu opfern. Lassen Sie entweder einige der Knoten ohne Überwachung (dann müssen Sie sie zuerst priorisieren) oder senden Sie nicht den gesamten Verkehr vom Knoten, sondern nur einen bestimmten Typ. Auf jeden Fall können wir einige Angriffe verpassen. Darüber hinaus kann der SPAN-Port für andere Zwecke belegt werden. Daher müssen wir die bestehende Netzwerktopologie überprüfen und gegebenenfalls Anpassungen vornehmen, um Ihr Netzwerk mit der Anzahl Ihrer Sensoren maximal abzudecken (und dies mit der IT abzustimmen).
Was passiert, wenn Ihr Netzwerk asymmetrische Routen verwendet? Und wenn Sie SDN implementiert haben oder dies planen? Was aber, wenn Sie virtualisierte Maschinen oder Container überwachen müssen, deren Datenverkehr den physischen Switch überhaupt nicht erreicht? Dies sind Fragen, die traditionelle IDS-Anbieter nicht mögen, weil sie nicht wissen, wie sie sie beantworten sollen. Vielleicht überzeugen sie Sie davon, dass all diese modischen Technologien ein Hype sind und Sie sie nicht brauchen. Vielleicht werden sie über die Notwendigkeit sprechen, klein anzufangen. Oder vielleicht sagen sie, dass Sie einen leistungsstarken Thresher in der Mitte des Netzwerks platzieren und den gesamten Datenverkehr mithilfe von Load Balancern dorthin leiten müssen. Welche Option Ihnen auch angeboten wird, Sie müssen selbst klar verstehen, wie sie zu Ihnen passt. Und erst danach entscheiden Sie sich für den Ansatz zur Überwachung der Informationssicherheit der Netzwerkinfrastruktur. Zurück zur Paketerfassung möchte ich sagen, dass diese Methode weiterhin sehr beliebt und wichtig ist, ihr Hauptzweck jedoch die Grenzkontrolle ist; die Grenzen zwischen Ihrer Organisation und dem Internet, die Grenzen zwischen dem Rechenzentrum und dem Rest des Netzwerks, die Grenzen zwischen dem Prozessleitsystem und dem Unternehmenssegment. An diesen Orten haben klassische IDS/IPS noch immer ihre Daseinsberechtigung und erledigen ihre Aufgaben gut.
Kommen wir zur zweiten Option. Die Analyse von Ereignissen, die von Netzwerkgeräten ausgehen, kann auch zur Erkennung von Eindringlingen verwendet werden, jedoch nicht als Hauptmechanismus, da nur eine kleine Klasse von Eindringlingen erkannt wird. Darüber hinaus ist eine gewisse Reaktivität damit verbunden – zuerst muss ein Angriff stattfinden, dann muss er von einem Netzwerkgerät behoben werden, was auf die eine oder andere Weise auf ein Problem mit der Informationssicherheit hinweist. Es gibt mehrere solcher Methoden. Es kann Syslog, RMON oder SNMP sein. Die letzten beiden Protokolle zur Netzwerküberwachung im Rahmen der Informationssicherheit werden nur dann verwendet, wenn wir einen DoS-Angriff auf das Netzwerkgerät selbst erkennen müssen, da Sie mit RMON und SNMP beispielsweise die Auslastung des Zentralprozessors des Geräts überwachen können oder seine Schnittstellen. Dies ist eine der „billigsten“ (jeder hat Syslog oder SNMP), aber auch die ineffizienteste aller Möglichkeiten, die Informationssicherheit der internen Infrastruktur zu überwachen – viele Angriffe bleiben ihr einfach verborgen. Natürlich sollten sie nicht vernachlässigt werden, und die gleiche Syslog-Analyse hilft Ihnen, Änderungen in der Konfiguration des Geräts selbst rechtzeitig zu erkennen und es zu gefährden, ist jedoch nicht sehr geeignet, um Angriffe auf das gesamte Netzwerk zu erkennen.
Die dritte Möglichkeit besteht darin, Informationen über den Datenverkehr zu analysieren, der über ein Gerät läuft, das eines von mehreren Flussprotokollen unterstützt. In diesem Fall besteht die Streaming-Infrastruktur unabhängig vom Protokoll zwangsläufig aus drei Komponenten:
- Generierungs- oder Exportfluss. Diese Rolle wird normalerweise einem Router, Switch oder einem anderen Netzwerkgerät zugewiesen, das durch die Weiterleitung des Netzwerkverkehrs über sich selbst die Extraktion wichtiger Parameter ermöglicht, die dann an das Erfassungsmodul übertragen werden. Beispielsweise wird das Netflow-Protokoll von Cisco nicht nur auf Routern und Switches unterstützt, darunter sowohl virtuelle als auch industrielle, sondern auch auf drahtlosen Controllern, Firewalls und sogar Servern.
- Sammelfluss. Bedenkt man, dass es in einem modernen Netzwerk in der Regel mehr als ein Netzwerkgerät gibt, stellt sich das Problem des Sammelns und Konsolidierens von Streams, das mit Hilfe sogenannter Collectors gelöst wird, die die empfangenen Streams verarbeiten und anschließend zur Analyse weiterleiten.
- Strömungsanalyse. Der Analysator übernimmt die intellektuelle Hauptaufgabe und zieht durch die Anwendung verschiedener Algorithmen auf die Streams bestimmte Schlussfolgerungen. Beispielsweise kann ein solcher Analysator innerhalb einer IT-Funktion Netzwerkengpässe identifizieren oder das Verkehrslastprofil analysieren, um das Netzwerk weiter zu optimieren. Und für die Informationssicherheit kann ein solcher Analysator Datenlecks, die Verbreitung von Schadcode oder DoS-Angriffe erkennen.
Denken Sie nicht, dass eine solche dreistufige Architektur zu kompliziert ist – alle anderen Optionen (mit der möglichen Ausnahme von Netzwerküberwachungssystemen, die mit SNMP und RMON arbeiten) funktionieren auch danach. Für die Analyse verfügen wir über einen Datengenerator, bei dem es sich um ein Netzwerkgerät oder einen eigenständigen Sensor handelt. Wir verfügen über ein Alarmsammelsystem und ein Managementsystem für die gesamte Überwachungsinfrastruktur. Die letzten beiden Komponenten können innerhalb eines einzigen Knotens kombiniert werden, in mehr oder weniger großen Netzwerken werden sie jedoch normalerweise auf mindestens zwei Geräte verteilt, um Skalierbarkeit und Zuverlässigkeit zu gewährleisten.
Im Gegensatz zur Paketanalyse, die auf der Untersuchung des Headers und des Datenkörpers jedes Pakets und der daraus bestehenden Sitzungen basiert, basiert die Flussanalyse auf der Sammlung von Metadaten über den Netzwerkverkehr. Wann, wie viel, von wo und wo, wie ... das sind die Fragen, die die Netzwerktelemetrieanalyse mithilfe verschiedener Flussprotokolle beantwortet. Ursprünglich dienten sie der Analyse von Statistiken und der Suche nach IT-Problemen im Netzwerk, doch mit der Entwicklung analytischer Mechanismen wurde es dann möglich, sie aus Sicherheitsgründen auf dieselbe Telemetrie anzuwenden. An dieser Stelle sei noch einmal darauf hingewiesen, dass die Flussanalyse weder die Paketerfassung ersetzt noch ersetzt. Jede dieser Methoden hat ihren eigenen Anwendungsbereich. Im Kontext dieses Artikels eignet sich jedoch die Flussanalyse am besten für die Überwachung der internen Infrastruktur. Sie verfügen über Netzwerkgeräte (unabhängig davon, ob sie nach einem softwaredefinierten Paradigma oder nach statischen Regeln arbeiten), die ein Angriff nicht umgehen kann. Es kann den klassischen IDS-Sensor umgehen, aber kein Netzwerkgerät, das das Flow-Protokoll unterstützt. Das ist der Vorteil dieser Methode.
Wenn Sie andererseits eine Beweisgrundlage für die Strafverfolgung oder Ihr eigenes Team zur Untersuchung von Vorfällen benötigen, können Sie nicht auf die Paketerfassung verzichten – Netzwerktelemetrie ist keine Kopie des Datenverkehrs, die zum Sammeln von Beweisen verwendet werden kann; es wird für eine schnelle Erkennung und Entscheidungsfindung im Bereich der Informationssicherheit benötigt. Andererseits können Sie mithilfe der Telemetrieanalyse nicht den gesamten Netzwerkverkehr „schreiben“ (wenn überhaupt, ist Cisco auch an Rechenzentren beteiligt :-), sondern nur den, der am Angriff beteiligt ist. In dieser Hinsicht ergänzen Telemetrie-Analysetools herkömmliche Mechanismen zur Paketerfassung gut und geben einen Befehl zur selektiven Erfassung und Speicherung an. Andernfalls benötigen Sie eine riesige Speicherinfrastruktur.
Stellen Sie sich ein Netzwerk vor, das mit 250 Mbit/s läuft. Wenn Sie dieses gesamte Volumen einsparen möchten, benötigen Sie 31 MB Speicherplatz für eine Sekunde Verkehrsü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 aus einem Netzwerk mit einer Bandbreite von 10 Gbit/s zu speichern, benötigen Sie 108 TB Speicher. Einige Aufsichtsbehörden verlangen jedoch, dass Sie Sicherheitsdaten jahrelang speichern ... Die On-Demand-Aufzeichnung dieser Flussanalyse hilft Ihnen, diese Werte um Größenordnungen zu reduzieren. Übrigens, wenn wir über das Verhältnis des Volumens der aufgezeichneten Daten der Netzwerktelemetrie und der vollständigen Datenerfassung sprechen, dann beträgt es ungefähr 1 zu 500. Für die gleichen oben angegebenen Werte ist die Speicherung einer vollständigen Entschlüsselung erforderlich des gesamten täglichen Datenverkehrs betragen 5 bzw. 216 GB (Sie können sogar auf ein normales Flash-Laufwerk schreiben).
Wenn die Methode zur Erfassung roher Netzwerkdaten für Analysetools von Anbieter zu Anbieter nahezu gleich ist, ist die Situation bei der Stream-Analyse anders. Es gibt verschiedene Varianten von Flussprotokollen, deren Unterschiede Sie im Zusammenhang mit der Sicherheit kennen müssen. Am beliebtesten ist das von Cisco entwickelte Netflow-Protokoll. Es gibt mehrere Versionen dieses Protokolls, die sich in ihren Fähigkeiten und der Menge der über den Datenverkehr aufgezeichneten Informationen unterscheiden. Die aktuelle Version ist die neunte (Netflow v9), aus der der Industriestandard Netflow v10, auch bekannt als IPFIX, entwickelt wurde. Heutzutage unterstützen die meisten Netzwerkanbieter Netflow oder IPFIX in ihren Geräten. Es gibt aber auch verschiedene andere Varianten von Flussprotokollen – sFlow, jFlow, cFlow, rFlow, NetStream usw., von denen sFlow am beliebtesten ist. Aufgrund der einfachen Implementierung wird er am häufigsten von inländischen Herstellern von Netzwerkgeräten unterstützt. Was sind die Hauptunterschiede zwischen Netflow als De-facto-Standard und demselben sFlow? Ich möchte einige wichtige hervorheben. Erstens verfügt Netflow über vom Benutzer konfigurierbare Felder im Gegensatz zu festen Feldern in sFlow. Und zweitens, und das ist in unserem Fall das Wichtigste, sammelt sFlow die sogenannte abgetastete Telemetrie; im Gegensatz zu nicht abgetastetem Netflow und IPFIX. Was ist der Unterschied zwischen ihnen?
Stellen Sie sich vor, Sie entscheiden sich, das Buch „” meine Kollegen Gary McIntyre, Joseph Munitz und Nadem Alfardan (Sie können einen Teil des Buches über den Link herunterladen). Sie haben drei Möglichkeiten, Ihr Ziel zu erreichen: Lesen Sie das Buch vollständig, überfliegen Sie es, halten Sie bei jeder 10. oder 20. Seite an oder versuchen Sie, in einem Blog oder Dienst wie SmartReading eine Nacherzählung wichtiger Konzepte zu finden. Bei der nicht abgetasteten Telemetrie handelt es sich also um das Auslesen jeder „Seite“ des Netzwerkverkehrs, also um die Analyse der Metadaten für jedes Paket. Stichprobentelemetrie ist eine selektive Untersuchung des Verkehrs in der Hoffnung, dass die ausgewählten Stichproben Ihren Anforderungen entsprechen. Abhängig von der Kanalgeschwindigkeit sendet die abgetastete Telemetrie jedes 64., 200., 500., 1000., 2000. oder sogar 10000. Paket zur Analyse.
Im Zusammenhang mit der Überwachung der Informationssicherheit bedeutet dies, dass sich die abgetastete Telemetrie gut zum Erkennen von DDoS-Angriffen, Scannen und Verbreiten von Schadcode eignet, aber atomare Angriffe oder Angriffe mit mehreren Paketen übersehen kann, die nicht in der zur Analyse gesendeten Stichprobe enthalten sind. Auch die ungesweepte Telemetrie weist keine derartigen Mängel auf. Die Nutzung der Reichweite erkannter Angriffe ist viel größer. Hier ist eine kleine Liste von Ereignissen, die mithilfe von Netzwerktelemetrie-Analysetools erkannt werden können.
Natürlich ist dies mit einigen Open-Source-Netflow-Analysatoren nicht möglich, da seine Hauptaufgabe darin besteht, Telemetriedaten zu sammeln und aus IT-Sicht eine grundlegende Analyse durchzuführen. Um IS-Bedrohungen anhand des Datenflusses zu identifizieren, muss der Analysator mit verschiedenen Engines und Algorithmen ausgestattet werden, die Cybersicherheitsprobleme anhand von Standard- oder benutzerdefinierten Netflow-Feldern identifizieren, Standarddaten mit externen Daten aus verschiedenen Threat Intelligence-Quellen anreichern usw.
Wenn Sie also die Wahl haben, stoppen Sie es auf Netflow oder IPFIX. Aber selbst wenn Ihre Geräte wie inländische Hersteller nur mit sFlow funktionieren, können Sie auch in diesem Fall im Sicherheitskontext davon profitieren.
Im Sommer 2019 habe ich die Möglichkeiten analysiert, die russische Netzwerkeisenhersteller haben, und alle, mit Ausnahme von NSG, Polygon und Craftway, haben die Unterstützung für sFlow angekündigt (zumindest Zelaks, Natex, Eltex, QTech, Rusteletech).
Die nächste Frage, die sich Ihnen stellen wird, ist, wo Sie die Flow-Unterstützung aus Sicherheitsgründen implementieren können. Eigentlich ist die Frage nicht ganz richtig gestellt. Auf modernen Geräten werden Flussprotokolle fast immer unterstützt. Daher würde ich die Frage anders formulieren: Wo lassen sich Telemetriedaten aus Sicherheitsgründen am effizientesten erfassen? Die Antwort liegt ganz auf der Hand – auf der Zugriffsebene, wo Sie 100 % des gesamten Datenverkehrs sehen, wo Sie detaillierte Informationen zu Hosts haben (MAC, VLAN, Schnittstellen-ID), wo Sie sogar den P2P-Verkehr zwischen Hosts verfolgen können ist für die Scan-Erkennung und Verbreitung von Schadcode von entscheidender Bedeutung. Auf der Kernebene sehen Sie möglicherweise einfach keinen Teil des Datenverkehrs, auf der Perimeterebene sehen Sie jedoch gut ein Viertel Ihres Netzwerkdatenverkehrs. Wenn Sie jedoch aus irgendeinem Grund fremde Geräte in Ihrem Netzwerk haben, die es Angreifern ermöglichen, unter Umgehung des Perimeters „ein- und auszusteigen“, dann wird Ihnen die Analyse der Telemetriedaten nichts bringen. Für eine maximale Abdeckung wird daher empfohlen, die Telemetrieerfassung auf Zugriffsebene zu aktivieren. Gleichzeitig ist anzumerken, dass moderne virtuelle Switches, selbst wenn es um Virtualisierung oder Container geht, häufig auch den Fluss unterstützen, wodurch Sie auch dort den Datenverkehr steuern können.
Aber da ich das Thema angesprochen habe, muss ich die Frage beantworten: Was ist, wenn die Ausrüstung, ob physisch oder virtuell, schließlich keine Flussprotokolle unterstützt? Oder ist die Einbeziehung verboten (z. B. in Industriesegmenten zur Gewährleistung der Zuverlässigkeit)? Oder verursacht das Einschalten eine hohe CPU-Auslastung (dies passiert auf älterer Hardware)? Um dieses Problem zu lösen, gibt es spezielle virtuelle Sensoren (Flusssensoren), bei denen es sich im Wesentlichen um gewöhnliche Splitter handelt, die den Verkehr durch sich selbst leiten und ihn in Form eines Flusses an das Sammelmodul senden. Es stimmt, in diesem Fall treten die ganzen Probleme auf, die wir oben in Bezug auf Paketerfassungstools besprochen haben. Das heißt, es ist notwendig, nicht nur die Vorteile der Strömungsanalysetechnologie zu verstehen, sondern auch ihre Grenzen.
Ein weiterer Punkt, den es zu beachten gilt, wenn es um Tools zur Flussanalyse geht. Wenn wir die EPS-Metrik (Ereignis pro Sekunde, Ereignisse pro Sekunde) in Bezug auf die üblichen Mittel zur Generierung von Sicherheitsereignissen anwenden, ist dieser Indikator nicht auf die Telemetrieanalyse anwendbar; es wird durch FPS (Flow pro Sekunde, Fluss pro Sekunde) ersetzt. Wie im Fall von EPS kann es nicht im Voraus berechnet werden, es ist jedoch möglich, die ungefähre Anzahl der Threads abzuschätzen, die ein bestimmtes Gerät abhängig von seiner Aufgabe generiert. Im Internet finden Sie Tabellen mit ungefähren Werten für verschiedene Arten von Unternehmensgeräten und Bedingungen, anhand derer Sie abschätzen können, welche Art von Lizenzen Sie für Analysetools benötigen und wie diese aussehen werden. Tatsache ist, dass der IDS-Sensor auf eine bestimmte Bandbreite beschränkt ist, die er „herauszieht“, und der Durchflusskollektor seine eigenen Einschränkungen hat, die verstanden werden müssen. Daher gibt es in großen, geografisch verteilten Netzwerken meist mehrere Kollektoren. Als ich beschrieben habe Ich habe bereits die Anzahl unserer Sammler angegeben – es sind 21. Und das für ein Netzwerk, das über fünf Kontinente verstreut ist und etwa eine halbe Million aktive Geräte umfasst.
Wir nutzen unsere eigene Lösung als Netflow-Monitoring-System , das sich speziell auf die Lösung von Sicherheitsproblemen konzentriert. Es verfügt über viele integrierte Engines zur Erkennung anomaler, verdächtiger und offensichtlich bösartiger Aktivitäten, die es Ihnen ermöglichen, ein breites Spektrum unterschiedlicher Bedrohungen zu erkennen – von Kryptomining bis hin zu Informationslecks, von der Verbreitung von Schadcode bis hin zu Betrug. Wie die meisten Durchflussanalysatoren basiert Stealthwatch auf einem dreistufigen Schema (Generator – Kollektor – Analysator), wird jedoch durch eine Reihe interessanter Funktionen ergänzt, die im Kontext des betrachteten Materials wichtig sind. Erstens lässt es sich in Paketerfassungslösungen (z. B. Cisco Security Packet Analyzer) integrieren, wodurch Sie ausgewählte Netzwerksitzungen für eine spätere eingehende Untersuchung und Analyse aufzeichnen können. Zweitens haben wir speziell zur Erweiterung der Sicherheitsaufgaben ein spezielles nvzFlow-Protokoll entwickelt, mit dem Sie Anwendungsaktivitäten auf Endknoten (Servern, Workstations usw.) in Telemetrie „übertragen“ und zur weiteren Analyse an einen Collector übertragen können. Wenn Stealthwatch in seiner ursprünglichen Version mit jedem Flussprotokoll (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) auf Netzwerkebene funktioniert, ermöglicht die nvzFlow-Unterstützung dadurch die Korrelation von Daten auch auf Knotenebene. Verbessert die Gesamtsystemeffizienz und erkennt mehr Angriffe als herkömmliche Netzwerkflussanalysatoren.
Wenn es um Netflow-Analysesysteme aus Sicherheitssicht geht, ist klar, dass der Markt nicht auf eine einzelne Lösung von Cisco beschränkt ist. Sie können sowohl kommerzielle als auch kostenlose oder Shareware-Lösungen verwenden. Es ist ziemlich seltsam, wenn ich im Cisco-Blog Lösungen von Mitbewerbern zitiere, deshalb möchte ich ein paar Worte darüber sagen, wie Netzwerktelemetrie mit zwei beliebten, im Namen ähnlichen, aber dennoch unterschiedlichen Tools analysiert werden kann – SiLK und ELK.
SiLK ist eine Reihe von Tools (System for Internet-Level Knowledge) zur Verkehrsanalyse, die vom amerikanischen CERT/CC entwickelt wurden und im Kontext des heutigen Artikels Netflow (5. und 9., die beliebtesten Versionen), IPFIX und unterstützen sFlow und die Verwendung verschiedener Dienstprogramme (rwfilter, rwcount, rwflowpack usw.), um verschiedene Operationen an der Netzwerktelemetrie durchzuführen, um darin Anzeichen für nicht autorisierte Aktionen zu erkennen. Es gibt jedoch ein paar wichtige Dinge zu beachten. SiLK ist ein Befehlszeilentool und führt Online-Analysen durch, während Sie gleichzeitig einen Befehl der Form eingeben (Erkennung von ICMP-Paketen, die größer als 200 Bytes sind):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nicht sehr bequem. Sie können die iSiLK-GUI verwenden, aber es wird Ihnen das Leben nicht viel einfacher machen, wenn Sie nur die Visualisierungsfunktion lösen und nicht den Analysten ersetzen. Und das ist der zweite Punkt. Im Gegensatz zu kommerziellen Lösungen, die bereits über eine solide analytische Basis, dem Workflow entsprechende Anomalieerkennungsalgorithmen usw. verfügen, müssen Sie im Fall von SiLK dies alles selbst tun, was von Ihnen etwas andere Kompetenzen erfordert als bei der Verwendung bereits fertiger Lösungen -zu verwendendes Toolkit. Das ist weder gut noch schlecht – das ist ein Merkmal fast aller kostenlosen Tools, das darauf zurückzuführen ist, dass Sie wissen, was zu tun ist, und es wird Ihnen nur dabei helfen (kommerzielle Tools sind weniger abhängig von den Kompetenzen ihrer Benutzer). Allerdings wird auch davon ausgegangen, dass Analysten zumindest die Grundlagen der Durchführung von Netzwerkuntersuchungen und -überwachung verstehen. Aber zurück zu SiLK. Der Arbeitszyklus des Analysten damit ist wie folgt:
- Formulierung einer Hypothese. Wir müssen verstehen, wonach wir in der Netzwerktelemetrie suchen werden, und die einzigartigen Merkmale kennen, anhand derer wir bestimmte Anomalien oder Bedrohungen identifizieren können.
- Modellbau. Nachdem wir eine Hypothese formuliert haben, programmieren wir sie mit demselben Python, derselben Shell oder anderen Tools, die nicht in SiLK enthalten sind.
- Testen. Es ist an der Zeit, die Richtigkeit unserer Hypothese zu überprüfen, die mithilfe der SiLK-Dienstprogramme bestätigt oder widerlegt wird, die mit „rw“, „set“, „bag“ beginnen.
- Analyse realer Daten. Im kommerziellen Betrieb hilft uns SiLK, etwas zu identifizieren, und der Analyst muss die Fragen beantworten: „Haben wir gefunden, was wir erwartet hatten?“, „Entspricht dies unserer Hypothese?“, „Wie wird dadurch die Anzahl falsch positiver Ergebnisse verringert?“ „Wie kann der Bekanntheitsgrad verbessert werden?“ usw.
- Verbesserung. In der letzten Phase verbessern wir das, was zuvor getan wurde – wir erstellen Vorlagen, verbessern und optimieren den Code, formulieren und verfeinern die Hypothese usw.
Dieser Zyklus ist auf die gleiche Cisco Stealthwatch anwendbar, nur die letzten fünf Schritte werden maximal automatisiert, wodurch die Anzahl der Analystenfehler reduziert und die Effizienz der Vorfallerkennung erhöht wird. In SiLK können Sie beispielsweise Netzwerkstatistiken mithilfe Ihrer eigenen Skripte mit externen Daten zu bösartigen IPs anreichern, und in Cisco Stealthwatch handelt es sich um eine integrierte Funktion, die Ihnen sofort einen Alarm anzeigt, wenn im Netzwerk eine Interaktion mit auf der schwarzen Liste stehenden IP-Adressen stattfindet Verkehr.
Wenn Sie die Pyramide der „kostenpflichtigen“ Flussanalysesoftware hinaufsteigen, folgt auf das absolut kostenlose SiLK ein Shareware-ELK, das aus drei Schlüsselkomponenten besteht: Elasticsearch (Indizierung, Suche und Analyse von Daten), Logstash (Dateneingabe/-ausgabe). und Kibana (Visualisierung). Im Gegensatz zu SiLK, wo man alles selbst schreiben muss, verfügt ELK bereits über viele vorgefertigte Bibliotheken/Module (manche sind kostenpflichtig, andere nicht), die die Analyse der Netzwerktelemetrie automatisieren. Mit dem GeoIP-Filter in Logstash können Sie beispielsweise die überwachten IP-Adressen an ihren geografischen Standort binden (die gleiche Stealthwatch verfügt über diese integrierte Funktion).
ELK hat auch eine ziemlich große Community, die dieser Überwachungslösung die fehlenden Komponenten hinzufügt. Um beispielsweise mit Netflow, IPFIX und sFlow zu arbeiten, können Sie das Modul verwenden wenn Sie mit dem Logstash Netflow-Modul, das nur Netflow unterstützt, nicht zufrieden sind.
ELK bietet derzeit keine umfassenden integrierten Analysen zur Erkennung von Anomalien und Bedrohungen in der Netzwerktelemetrie, um den Datenfluss effizienter zu erfassen und darin zu suchen. Das heißt, nach dem oben beschriebenen Lebenszyklus müssen Sie Verletzungsmodelle unabhängig beschreiben und sie dann im Kampfsystem verwenden (es gibt keine integrierten Modelle).
Natürlich gibt es anspruchsvollere Erweiterungen für ELK, die bereits einige Modelle zur Erkennung von Anomalien in der Netzwerktelemetrie enthalten, aber solche Erweiterungen kosten Geld und die Frage ist, ob sich das Spiel lohnt – schreiben Sie selbst ein ähnliches Modell und kaufen Sie dessen Implementierung Ihr Monitoring-Tool oder kaufen Sie eine schlüsselfertige Lösung der Klasse „Network Traffic Analysis“.
Im Allgemeinen möchte ich nicht auf eine Kontroverse darüber eingehen, ob es besser ist, Geld auszugeben und eine fertige Lösung zur Überwachung von Anomalien und Bedrohungen in der Netzwerktelemetrie (z. B. Cisco Stealthwatch) zu kaufen oder es selbst herauszufinden und zu optimieren die gleichen SiLK-, ELK- oder nfdump- oder OSU-Flow-Tools für jede neue Bedrohung (ich spreche von den letzten beiden). letztes Mal)? Jeder wählt für sich selbst und jeder hat seine eigenen Beweggründe, sich für eine der beiden Optionen zu entscheiden. Ich wollte nur zeigen, dass die Netzwerktelemetrie ein sehr wichtiges Instrument zur Gewährleistung der Netzwerksicherheit Ihrer internen Infrastruktur ist und dass Sie sie nicht vernachlässigen sollten, um nicht ein Unternehmen in die Liste aufzunehmen, dessen Name in den Medien zusammen mit den Beinamen erwähnt wird „gehackt“, „nicht konform mit den Anforderungen an die Informationssicherheit“, „nicht an die Sicherheit ihrer Daten und Kundendaten denkend“.
Zusammenfassend möchte ich die wichtigsten Tipps auflisten, die Sie beim Aufbau der Informationssicherheitsüberwachung Ihrer internen Infrastruktur beachten sollten:
- Beschränken Sie sich nicht nur auf den Umfang! Nutzen (und wählen) Sie die Netzwerkinfrastruktur nicht nur, um Datenverkehr von Punkt A nach Punkt B zu übertragen, sondern auch, um Cybersicherheitsprobleme zu lösen.
- Studieren Sie die vorhandenen Mechanismen zur Überwachung der Informationssicherheit in Ihrer Netzwerkausrüstung und nutzen Sie diese.
- Geben Sie für die interne Überwachung der Telemetrieanalyse den Vorzug – sie ermöglicht es Ihnen, bis zu 80-90 % aller Netzwerk-Informationssicherheitsvorfälle zu erkennen, während Sie bei der Erfassung von Netzwerkpaketen das Unmögliche tun und Speicherplatz für alle Informationssicherheitsereignisse sparen.
- Um Flows zu überwachen, verwenden Sie Netflow v9 oder IPFIX – sie liefern mehr Informationen im Zusammenhang mit der Sicherheit und ermöglichen Ihnen die Überwachung nicht nur von IPv4, sondern auch von IPv6, MPLS usw.
- Verwenden Sie ein nicht abgetastetes Flussprotokoll – es bietet mehr Informationen zur Erkennung von Bedrohungen. Zum Beispiel Netflow oder IPFIX.
- Überprüfen Sie die Auslastung Ihrer Netzwerkausrüstung – diese ist möglicherweise nicht in der Lage, die Verarbeitung des Flussprotokolls ebenfalls zu bewältigen. Dann erwägen Sie den Einsatz virtueller Sensoren oder einer Netflow Generation Appliance.
- Implementieren Sie die Kontrolle zunächst auf der Zugriffsebene – so haben Sie die Möglichkeit, 100 % des gesamten Datenverkehrs zu sehen.
- Wenn Sie keine andere Wahl haben und russische Netzwerkgeräte verwenden, wählen Sie eines, das Flow-Protokolle unterstützt oder über SPAN/RSPAN-Ports verfügt.
- Kombinieren Sie Einbruchs-/Angriffserkennung/-prävention an den Grenzen und Flussanalysesysteme im internen Netzwerk (auch in den Clouds).
Was den letzten Tipp betrifft, möchte ich eine Illustration geben, die ich bereits zuvor gegeben habe. Sie können sehen, dass der Cisco IS-Dienst früher sein IS-Überwachungssystem fast vollständig auf Basis von Intrusion-Detection-Systemen und Signaturmethoden aufbaute, heute jedoch nur noch 20 % der Vorfälle ausmacht. Weitere 20 % entfallen auf Flussanalysesysteme, was darauf hindeutet, dass diese Lösungen keine Laune, sondern ein echtes Werkzeug in den Aktivitäten der Informationssicherheitsdienste eines modernen Unternehmens sind. Darüber hinaus verfügen Sie über das Wichtigste für deren Umsetzung – die Netzwerkinfrastruktur, deren Investitionen zusätzlich geschützt werden können, indem dem Netzwerk Funktionen zur Überwachung der Informationssicherheit zugewiesen werden.
Ich habe das Thema der Reaktion auf Anomalien oder Bedrohungen, die in Netzwerkflüssen erkannt wurden, bewusst nicht angesprochen, aber ich denke, es ist klar, dass die Überwachung nicht erst mit der Erkennung einer Bedrohung enden sollte. Es sollte eine Antwort folgen, vorzugsweise im automatischen oder automatisierten Modus. Dies ist jedoch ein Thema für einen separaten Artikel.
Zusätzliche Information:
PS. Wenn es für Sie einfacher ist, sich alles anzuhören, was oben geschrieben wurde, können Sie sich die einstündige Präsentation ansehen, die die Grundlage dieser Notiz bildet.
Source: habr.com