ML IDS mit Suricata: Modelle für Cybersicherheit trainieren

ML-IDS der nächsten Generation: Wie Suricata Modelle für effektive Angriffserkennung trainiert

Moderne Intrusion Detection Systeme (IDS) haben Schwierigkeiten, neuartige und modifizierte Cyberangriffe zu erkennen, da sie auf signaturbasierte Analysen angewiesen sind. Die Fortschritte im Bereich des maschinellen Lernens (ML) bieten eine vielversprechende Lösung, doch der Einsatz von ML-IDS in realen Netzwerken birgt Herausforderungen, insbesondere hinsichtlich der Generierung von gelabelten Daten. Dieser Artikel untersucht einen innovativen Ansatz zum Aufbau von ML-IDS, indem Sicherheitsereignisdaten, die von Suricata aufgezeichnet wurden, genutzt werden, um Modelle zu trainieren und die Effektivität der Abwehr zu steigern.

Die Evolution von Intrusion Detection Systemen: Von Signaturen zu Intelligenz

Das Arsenal an Informationssicherheitstools gegen Cyberangriffe umfasst Firewalls, netzwerk- und hostbasierte Intrusion Detection Systeme (IDS), Next-Generation Firewalls (NGFW) und Security Information and Event Management (SIEM)-Systeme. Trotz ihrer Vielfalt basieren die meisten auf signaturbasierten Analysen, die bekannte Bedrohungen effektiv erkennen, sich aber als ineffektiv gegen neue oder modifizierte Angriffe erweisen. Diese grundlegende Schwäche unterstreicht die Dringlichkeit der Entwicklung von ML-IDS, die zu heuristischer oder intelligenter Erkennung fähig sind.

Die Aufgabe, netzwerkbasierte ML-IDS zu entwickeln, wird typischerweise auf zwei Hauptwegen angegangen:

• Netzwerkverkehrsklassifizierung: Aufteilung des Datenverkehrs in „sauber“ und „Angriff“ (möglicherweise mit Angriffsunterkategorien). Dies erfordert einen gelabelten Datensatz, was in realen Szenarien aufgrund ethischer, infrastruktureller und methodischer Einschränkungen eine Herausforderung darstellt. Die Erstellung präziser Modelle geschützter Ressourcen oder die Sammlung von Angriffsdaten ohne Kompromittierung der Live-Infrastruktur stellt ein erhebliches Hindernis dar.
• Anomalieerkennung: Identifizierung anomaler Netzwerkverbindungen oder Pakete, wenn nur „sauberer“ Datenverkehr bekannt ist. Dieser Ansatz ist weniger anspruchsvoll hinsichtlich gelabelter Daten, kann aber zu einer höheren Rate von Fehlalarmen führen.

Bestehende Forschung zeigt oft eine hohe Genauigkeit für ML-IDS in Laborumgebungen, wo Modelle in kontrollierten Umgebungen trainiert und getestet werden. Werden diese Modelle jedoch in realen Netzwerken eingesetzt, ist ein signifikanter Leistungsabfall zu beobachten. Dies liegt daran, dass die für das Training verwendeten Feature-Vektoren oft stark von der physischen Netzwerkstruktur, den Hardwarekonfigurationen und den Besonderheiten der Netzwerkdienste abhängen, in denen Daten gesammelt wurden. Abweichungen in diesen Parametern zwischen Test- und Produktionsumgebungen führen zu Klassifizierungsfehlern und einer Verringerung der Gesamtgenauigkeit des Modells.

Hypothese und Methodik: Suricata als Wissensquelle

Angesichts dieser Einschränkungen zielten die Autoren des Artikels darauf ab, festzustellen, ob ein effektives ML-IDS in einem bereits operativen Netzwerk aufgebaut werden könnte, indem Daten verwendet werden, die keine gezielten Angriffe auf die Ressource erfordern. Die Kernhypothese ist die Machbarkeit der Nutzung von Sicherheitsereignissen, die von traditionellen Intrusion Detection Systemen wie Suricata aufgezeichnet wurden, für die Datensatzlabeling. Dieser Ansatz umgeht die Herausforderungen der Generierung gelabelter Daten und kann potenziell die Anpassungsfähigkeit von ML-IDS an reale Bedingungen verbessern.

Zur Umsetzung dieser Hypothese wurde ein proprietäres Tool namens session_analyzer entwickelt. Dieses Tool ist darauf ausgelegt, Feature-Vektor-Werte für den Netzwerkverkehr jeder Netzwerkverbindung zu berechnen. Es ist wichtig zu beachten, dass session_analyzer dem beliebten CICFlowMeter (ehemals NTLFlowLyzer) analog ist, jedoch für spezifische Forschungsaufgaben angepasst wurde. Ursprünglich konzentriert es sich auf das TCP-Protokoll, aber seine Architektur ermöglicht die Erweiterung der Analyse auf andere Protokolle.

Prinzipien der Feature-Vektor-Generierung in session_analyzer

session_analyzer wendet strenge Regeln für die Analyse des Netzwerkverkehrs und die Extraktion aussagekräftiger Features an, die dann für das Training von Machine-Learning-Modellen verwendet werden. Diese Prinzipien gewährleisten die Konsistenz und Relevanz der generierten Daten.

• Protokollfilterung: Es werden nur Pakete der Protokolle Ethernet II, MPLS, VLAN, IPv4, TCP, UDP und ICMPv4 analysiert. Alle anderen Protokolle der Sicherungs-, Netzwerk- und Transportschicht werden ignoriert.
• Netzwerksitzungsidentifikation (Flow ID): Jede Sitzung wird eindeutig über eine 5-Komponenten-Sequenz (5-Tupel) identifiziert: Ziel-IP – Quell-IP – Ziel-Port – Quell-Port – Protokoll.
• Netzwerksitzungsdefinition: Eine Sitzung ist definiert als eine Abfolge von Paketen, die zu einer einzelnen TCP-Verbindung, einem UDP-Flow oder einem ICMP-Flow gehören. Die Zugehörigkeit eines Pakets zu einer Sitzung wird durch den Abgleich der 5-Tupel-Adressinformationen (entweder direkte oder umgekehrte Richtung) hergestellt.
• TCP-Sitzungsstartkriterium: Eine TCP-Sitzung wird nur beim ersten Paket mit den Flags SYN=1 und ACK=0 registriert. Dieses Paket bestimmt auch die Datenübertragungsrichtung (Client-Server).
• UDP/ICMP-Sitzungsstartkriterium: Registrierung erfolgt beim Auftreten des ersten Pakets mit einer neuen Kennung. Potenzial für Fehler bei der Richtungsbestimmung, beispielsweise bei der ersten beobachteten DNS-Antwort.
• Netzwerksitzungsende-Kriterium (Timeout): Für alle Sitzungstypen wird ein Timeout ab dem zuletzt empfangenen Paket bereitgestellt. Konfigurierbare Standardwerte: tcp_session_timeout = 60000 ms, udp_session_timeout = 60000 ms, icmp_session_timeout = 60000 ms.
• TCP-Sitzungsende-Kriterium (Terminierungsflags): RST- oder FIN-Pakete werden zusätzlich überwacht. Beim Empfang eines RST wird die Sitzung als geschlossen betrachtet. Bei FIN wird ein Mechanismus zur Verfolgung von Bestätigungen (ACK) von beiden Seiten initiiert.
• Netzwerkpaketfluss (Flow): Eine strikte Abfolge von Paketen innerhalb einer einzelnen Sitzung, unabhängig von der Richtung.
• Vorwärts-Paketfluss (Fwd): Eine strikte Abfolge von Paketen vom Client zum Server innerhalb einer Sitzung.
• Rückwärts-Paketfluss (Bwd): Eine strikte Abfolge von Paketen vom Server zum Client innerhalb einer Sitzung.
• Netzwerksitzungsdauer: Kann auf zwei Arten berechnet werden: vom ersten bis zum letzten Paket in der Sitzung oder vom ersten bis zum letzten Paket mit Nutzdaten (Payload > 0). Der Parameter is_need_calc_duration_by_last_payload steuert dies.
• Netzwerksitzungsstream (Stream): Eine Menge von Sitzungen zwischen einer einzelnen Quell-IP und einem bestimmten Netzwerkdienst (Ziel-IP | Ziel-Port | Protokoll). Die stream_id wird durch die Verkettung dieser vier Komponenten gebildet. Features mit dem Präfix „Stream“ charakterisieren parallele Sitzungen, deren Erstellungszeiten und Intervalle dazwischen.
• „Unabhängige“ Sitzungen in einem Flow: Sitzungen gelten als unabhängig, wenn die Zeit zwischen ihrer Erstellung session_simple_timeout (Standard 60000000 Mikrosekunden) überschreitet.
• Zeitintervalle zwischen Sitzungen in einem Flow:

* session_time_prev_absent: Das Intervall zwischen der aktuellen und der vorherigen Sitzung. Wenn die aktuelle Sitzung die erste ist oder das Intervall den Schwellenwert überschreitet, wird der Wert session_time_prev_absent gesetzt (Standard 60000000 Mikrosekunden).

* session_time_next_absent: Das Intervall zwischen der aktuellen und der nächsten Sitzung. Wenn die aktuelle Sitzung die letzte ist oder das Intervall den Schwellenwert überschreitet, wird der Wert session_time_next_absent gesetzt (Standard 60000000 Mikrosekunden).

Diese detaillierten Regeln ermöglichen es session_analyzer, einen umfangreichen Satz von Features zu generieren, die für das Training von ML-Modellen verwendet werden können. Die Nutzung von Suricata für die Labeling ermöglicht es, diese Features mit spezifisch erkannten Bedrohungen zu verknüpfen und so gelabelte Datensätze ohne die Notwendigkeit realer Angriffe zu erstellen. Dies ebnet den Weg für den Aufbau adaptiverer und präziserer ML-IDS, die in den dynamischen und einzigartigen Bedingungen realer Netzwerkinfrastrukturen effektiv arbeiten können.

Vorteile und Grenzen des Ansatzes

Die Verwendung von Suricata für die Datenlabeling bietet mehrere entscheidende Vorteile:

• Datenrealismus: Das Training erfolgt auf Basis von tatsächlichem Datenverkehr und realen Vorfällen, die von Suricata aufgezeichnet wurden, was die Relevanz des Modells erhöht.
• Ressourceneffizienz: Es entfällt die Notwendigkeit kostspieliger Testumgebungen zur Simulation von Angriffen oder zur Durchführung von Angriffen auf Produktionssysteme.
• Anpassungsfähigkeit: Das Modell wird mit Daten aus einem spezifischen Netzwerk trainiert, wodurch es sich besser an die einzigartigen Merkmale des Datenverkehrs und der Ausrüstung anpassen kann.

Es gibt jedoch auch Einschränkungen. Die Qualität der Labeling hängt direkt von der Effektivität von Suricata und der Aktualität seiner Signaturen ab. Wenn Suricata einen neuen Angriff nicht erkennt, wird dieser Angriff im Datensatz nicht gelabelt, und das ML-Modell wird nicht lernen, ihn zu identifizieren. Darüber hinaus kann der Feature-Generierungsprozess durch session_analyzer selbst ressourcenintensiv sein. Nichtsdestotrotz stellt dieser Ansatz einen bedeutenden Fortschritt bei der Bewältigung der Herausforderung dar, zuverlässige und adaptive ML-IDS für reale Produktionsumgebungen zu schaffen.

Wichtige Erkenntnisse

• Traditionelle IDS sind aufgrund ihres signaturbasierten Ansatzes anfällig für neue und modifizierte Angriffe.
• ML-IDS sind vielversprechend, erfordern jedoch gelabelte Daten, die in realen Szenarien schwer zu beschaffen sind.
• Die Nutzung von Suricata-Ereignissen für die Datensatzlabeling ermöglicht das Training von ML-IDS mit realem Datenverkehr, ohne Angriffe durchführen zu müssen.
• Das Tool session_analyzer generiert detaillierte Feature-Vektoren für Netzwerksitzungen basierend auf 14 Prinzipien.
• Dieser Ansatz verbessert die Anpassungsfähigkeit von ML-IDS an die einzigartigen Merkmale realer Netzwerke, ist jedoch von der Qualität der Suricata-Erkennungen abhängig.

— Editorial Team