Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 11 Min.

OPNids: Suricata mit eingebautem Machine Learning: Pakete checken


Linux Magazin - epaper ⋅ Ausgabe 2/2020 vom 02.01.2020

Angriffe auf das Netz lassen sich nicht vermeiden, doch mit Intrusion Detection Systemen wie Suricata kann der Admin ihnen entgegentreten. OPNids kombiniert Suricata mit Machine Learning, um Bedrohungen automatisch zu erkennen.


Artikelbild für den Artikel "OPNids: Suricata mit eingebautem Machine Learning: Pakete checken" aus der Ausgabe 2/2020 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 2/2020

© Maxxyustas, 123RF


Menschen machen Fehler, gerade auch beim Programmieren und das schafft Sicherheitsprobleme. Dem Admin hilft die Erkenntnis freilich wenig: Durchwühlt ein ausländischer Geheimdienst sein Setup oder nimmt Daten mit, ist das für ihn beinahe das schlimmste Szenario. Beinahe deshalb, weil es noch eine Steigerung gibt: Die besteht darin, dass sich Ganoven an der ...

Weiterlesen
epaper-Einzelheft 5,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 2/2020 von Die Alleswisser. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Die Alleswisser
Titelbild der Ausgabe 2/2020 von News. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News
Titelbild der Ausgabe 2/2020 von Zahlen & Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zahlen & Trends
Titelbild der Ausgabe 2/2020 von Bericht von der VMworld 2019 in Barcelona: In Richtung Pazifik. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Bericht von der VMworld 2019 in Barcelona: In Richtung Pazifik
Titelbild der Ausgabe 2/2020 von Kernel 5.4: ExFAT in Staging, Lockdown-Modus: Neues Sperrgebiet. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Kernel 5.4: ExFAT in Staging, Lockdown-Modus: Neues Sperrgebiet
Titelbild der Ausgabe 2/2020 von Sicher auf Kubernetes zugreifen: Fallen vermeiden. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Sicher auf Kubernetes zugreifen: Fallen vermeiden
Vorheriger Artikel
DNS absichern: DNScrypt, DoH, DoT und ESNI: Zweischneidiger Schut…
aus dieser Ausgabe
Nächster Artikel In eigener Sache: DELUG-DVD: Kali Linux, DebConf-Videos
aus dieser Ausgabe

Menschen machen Fehler, gerade auch beim Programmieren und das schafft Sicherheitsprobleme. Dem Admin hilft die Erkenntnis freilich wenig: Durchwühlt ein ausländischer Geheimdienst sein Setup oder nimmt Daten mit, ist das für ihn beinahe das schlimmste Szenario. Beinahe deshalb, weil es noch eine Steigerung gibt: Die besteht darin, dass sich Ganoven an der IT-Infrastruktur zu schaffen machen, ohne dass der Admin es überhaupt merkt. In nicht wenigen Fällen fiel den Verantwortlichen großer Unternehmen erst Monate oder gar Jahre später auf, dass ungebetener Besuch da war – und das auch nur, weil die Auswirkungen eines Hacks sichtbar wurden. So landeten etwa Accounts, Logins und Passwörter Hunderttausender Nutzer im Netz.
Eine solche Situation entwickelt sich für ein Unternehmen schnell zur handfesten Gefahr für sein Fortbestehen. Jedes Leck kostet Vertrauen der Nutzer, und die vergraulten Anwender wandern irgendwann zur Konkurrenz ab. Gehen keine Daten verloren, ist das auch kein Trost, wenn eine Umgebung dafür über Stunden oder Tage ausfällt: Ersatzleistungen an Kunden, Verdienstausfälle – all das kann schnell horrende Summen auftürmen.

Vorsicht ist besser

In der IT gilt deshalb grundsätzlich: Vorsicht ist besser als Nachsicht. In diversen Compliance-Anleitungen etwa finden sich viele Regeln, die den Aufbau einer Umgebung verbessern und deren implizite Sicherheit erhöhen sollen. Allzu blauäugig sollte man als Admin allerdings nicht sein, was den Wunsch nach vollkommener Sicherheit angeht: Die gibt es nicht. Solange man es nur mit typischen Skriptkiddies zu tun bekommt, gelingt es mit Linux-Bordmitteln sowie dem regelmäßigen Einspielen von Sicherheitsupdates, den größten Teil der Angriffe abzuwehren.
Anders sieht die Sache aus, wenn man es mit staatlichen oder in staatlichem Auftrag agierenden Angreifern zu tun hat. Hier spielt Geld meist keine Rolle, das agierende Personal gehört zu den Besten seiner Zunft. Zudem stehen in solchen Szenarien meist ausgefeilte Werkzeuge zur Verfügung, um Angriffe vorzubereiten und auszuführen. Dem lässt sich mit normalen Aufwand kaum entgegentreten, und selbst die totale Abschottung eines Setups vom Internet bietet keinen hundertprozentigen Schutz.
Das liefert freilich keine Entschuldigung dafür, erst gar keine Maßnahmen gegen Angreifer zu ergreifen. Zu den klassischen Gehilfen aus dem Werkzeugkasten des Admins für diese Aufgabe zählen Intrusion-Detection-Systeme (IDS) sowie Intrusion-Prevention-Systeme (IPS). Ein gängiger Vertreter dieser Zunft unter Linux ist Suricata (Abbildung 1).
Für Suricata existieren im Netz verschiedene Datenbanken mit Angriffssignaturen, mit deren Hilfe das Tool den Datenverkehr untersucht und Attacken erkennt. Wie bei Anti-Viren-Programmen gilt hier aber, dass Suricata nur exakt die Angriffe erkennen kann, über deren Signaturen es verfügt. Im Kontext der Machine-Learning-Fortschritte vergangener Jahre gibt es deshalb Bestrebungen, neue Signaturen per KI automatisch zu erarbeiten und in Suricata einzupflegen. OPNids entstammt der Firewall-Lösung OPNsense und integriert Suricata mit der Machine-Learn-Engine des Dragonfly-Projekts.

Dieser Artikel geht zunächst im Detail auf Suricata ein und stellt danach die spezifisch auf Suricata gemünzte Machine Learning Engine Dragonfly vor. Zu guter Letzt geht es dann um den OPNsense-Fork OPNids, der das Konglomerat aus Suricata und Dragonfly einbindet.

Abbildung 1: Suricata ist ein umfangreiches Werkzeug für die Erkennung von digitalen Angriffen.


© Linux Screenshots (USA)

IDS und IPS

Zuvor steht aber eine kurze Schärfung der Begrifflichkeiten an: Die Abkürzungen IDS und IPS stehen für Intrusion Detection System und Intrusion Prevention System. Ein IDS durchsucht lediglich den vorbeifließenden Datenverkehr nach bekannten Mustern. IPS dagegen haben auch die Möglichkeit, in den Traffic einzugreifen und ihn gegebenenfalls komplett zu unterbinden, sobald sie ein Angriffsmuster erkennen. Das hier vorgestellte Suricata bietet beide Funktionen. Der Einfachheit halber behandelt der Artikel Suricata im Folgenden als IDS, meint aber auch den IPS-Teil des Werkzeugs.

Wie IDS-Systeme funktionieren

Damit ein IDS-System eingehenden Traffic auf bekannte Signaturen hin überprüfen kann, muss es ihn erst einmal sehen. Dasselbe gilt für ausgehenden Traffic: Es ist ein noch immer recht verbreiteter Trugschluss, dass Angriffe vorrangig daran zu erkennen seien, dass verdächtiger Netzwerkverkehr eingeht. Aktive Schadsoftware etwa, wie zum Beispiel unerwünschte Bitcoin-Miner, erkennt man ausschließlich daran, dass plötzlich große Mengen unerwünschten Traffics den Weg zur Außenwelt suchen. So oder so: Damit ein IDS überhaupt seine volle Wirkung entfalten kann, muss es die vorbeifließenden Pakete in beide Richtungen zu Gesicht bekommen.
Da liegt die Idee nahe, dass Suricata & Co. sich problemlos auf Load Balancern ausrollen lassen müsste, denn die sehen ja den allergrößten Teil des Traffics. Das IDS wäre dann quasi eine einfache Schleife, die an der jeweiligen Load-Balancing-Software hängt und den Datenverkehr untersucht, bevor er an die Zielsysteme weiterläuft. Der Ansatz greift jedoch zu kurz: Einerseits verfügen Load Balancer und entsprechende Appliances meist nicht über die Ressourcen für eine umfassende Analyse des Netzwerkverkehrs. Darüber hinaus würde dieser Ansatz eines IDS als Proxy zwischen Innen- und Außenseite eines Setups zwangsläufig einen Flaschenhals darstellen, der sich mit der Zeit zum Problem entwickelt.
IDS-Ansätze funktionieren deshalb anders. Praktisch jedes Switch-Betriebssystem (etwa JunOS von Juniper oder Nexus von Cisco) bietet die Möglichkeit, einen Mirror-Port einzurichten. Dazu gibt der Admin anhand von Regeln dem Switch zu verstehen, welcher Traffic grundsätzlich zu untersuchen ist. Den kopieren die Geräte dann auf einen separaten Port, der zuvor zum Mirror-Port erklärt wurde. An diesen Switch-Port hängt der Admin dann sein IDS-System an, das entsprechend den gespiegelten Datenverkehr der anderen Knoten im System sieht. Allerdings schränkt dieses Funktionsprinzip die Möglichkeit ein, IPS-Funktionen zu nutzen: Hierfür wäre es notwendig, dass das IPS-System eine gegebenenfalls vorhandene Firewall passend umkonfiguriert. Erkennen lassen sich Angriffe nach diesem Schema allerdings zuverlässig.

Was Suricata kann

Suricata gilt mit Fug und Recht als Musterbeispiel für ein umfassendes und gut funktionierendes IDS. Die quelloffene Software steht unter der GPL, hat bereits einige Lenze auf dem Buckel und gilt deshalb als stabil und ausgereift. Damit geht eine entsprechende Verbreitung einher, und Suricata steht für alle relevanten Distributionen paketiert zur Verfügung, meist sogar über das offizielle Repository. Alternativ gibt es Drittanbieter, die etwa für Ubuntu Suricata-PPAs pflegen. Das erleichtert die Installation des Diensts. Im folgenden Schritt muss der Admin dann nur noch die Konfiguration bauen und an die lokalen Gegebenheiten anpassen. Wie bereits erwähnt, verfügt Suricata über eine interne Engine, die alle Regeln für das IDS verwaltet. Mittels eines eigenen Werkzeugs namens Oinkmaster lässt sich sogar ein für den jeweiligen Anwendungsfall spezifisches Regelwerk erstellen. Als Vorlage dienen bestimmte Online-Verzeichnisse, in denen eine Vielzahl von Autoren ihre persönlichen Regeln veröffentlichen.
Diese Regeln sollte man allerdings nicht allesamt blind installieren, sondern vorab eine Auswahl treffen. Es ergäbe Anwenüberhaupt keinen Sinn, Suricata im Datenverkehr nach SMTP-Paketen suchen zu lassen, wenn man selbst gar keinen SMTP-Server betreibt. Jede Regel, die Suricata auf Pakete anwenden muss, kostet zudem Systemressourcen. Am Ende haben die meisten Admins deshalb relativ bald ein Subset eigener Suricata-Regeln gebaut, das exakt zum jeweiligen Einsatzszenario passt.

Abbildung 2: Per Eve-Schnittstelle lassen sich Suricata-Events auch an andere Systeme übertragen.


© Elastic

Gesprächig beim Loggen

Wie schon kurz angeschnitten, ist die Sache mit starren Regeln für IPS und IDS etwas problematisch. Einerseits zwingt ein solches System den Admin dazu, die Signaturen kontinuierlich zu aktualisieren, andererseits können Angriffe in freier Wildbahn bereits stattfinden, die noch gar nicht systematisch beschrieben wurden und für die es entsprechend auch keine Signaturen gibt.
Da wäre es doch praktisch, wenn Suricata sich selbst trainieren könnte, um Angriffe automatisch zu erkennen. Ganz abwegig ist die Idee nicht, sie funktioniert ja beispielsweise bei Spam auch. Zu den zentralen Merkmalen von Werkzeugen wie Spamassassin zählt ja gerade der Umstand, dass sie sich selbst an eingehende Mails anpassen und auf Basis von Statistiken und mit Hilfe vom User ihr Regelwerk automatisch auf neue Gegebenheiten abstimmen. In diesem Fall würde zwar noch keiner von KI reden, aber das Prinzip ist dasselbe.
Die schlechte Nachricht: Derartige Funktionen liefert Suricata aktuell nicht, auch wenn das Programm dem Admin zumindest die Grundlage liefert, sich ein solches System zu bauen. Das Zauberwort heißt Eve und beschreibt die äußerst flexible Protokollfunktion von Suricata.

Eve listet die Details

Aktiviert der Admin in Suricata die Eve-Ausgabe (Abbildung 2), landen die Log-Einträge im JSON-Format in der Regel in einer zentralen Datei namens »eve.json«. Dabei lässt sich Eve nicht lumpen: Für verschiedene Arten des eingehenden Datenverkehrs definiert es per JSON-Feld etwa die Art des Traffics oder zentrale Details wie die Größe eines Requests. Zudem versteht Suricata sich darauf, die wichtigsten Protokolle zu erkennen und zu interpretieren. Versucht etwa jemand, von außen per Wurm die Kontrolle über eine Website via HTTPRequest zu übernehmen, fischt Suricata diese Information aus dem Paketstrom heraus und vermerkt sie entsprechend in einer Log-Datei.
Eve ist jedoch längst nicht die einzige Logging-Funktion, die Suricata bietet: Obendrein kann das Programm auch spezifische Informationen zu Paketflüssen erkennen und in einer Flow-Log-Datei ablegen. Für DNS pflegt Suricata zudem noch eine eigene Datei, die Nameserver-Requests enthält. Damit kennt es alle Details, die eine Machine-Learning-Engine benötigt, um Suricata auf Basis festgelegter Parameter zu trainieren. An dieser Stelle kommt Dragonfly-MLE für Suricata ins Spiel.

Dragonfly-MLE als Quasi-KI

Dragonfly-MLE entspringt der Feder der Autoren von OPNids. Es arbeitet in drei Phasen: Zunächst hängt es sich an eine oder mehrere Datenquellen an, etwa an Eve-Logs aus Suricata. Dann analysiert es die in diesen Protokolldateien gefundenen Ereignisse und korreliert sie. Schließlich gibt es das Ergebnis seiner Überlegungen in einen sogenannten Sink aus – das kann im Jargon der Programmiersprache LUA etwa eine simple Datei oder ein Socket sein. Der Clou: Andere Werkzeuge, die ebenfalls LUA verwenden, können sich an diese Sinks anhängen und daraus ihr Regelwerk beziehen. Und eben diese Funktion bietet Suricata: Wirft der Admin ihm einen LUA-Sink hin, bedient es sich und sein Regelwerk daraus automatisch.
Der beschriebene Prozess klingt in der Theorie freilich etwas trocken; ein praktisches Beispiel soll die Angelegenheit verdeutlichen. Angenommen sei zunächst, der Admin habe ein lauffähiges Suricata, das in schöner Regelmäßigkeit eingehende Events in sein Eve-Log schreibt. Parallel dazu installiert er eine Instanz des Dragonfly-MLE-Systems, die ebenso als Daemon im Hintergrund läuft. Sie hängt sich unmittelbar an den Eve-Stream im Suricata-Log und bekommt auf diese Weise Wind von allem, was Suricata tut. Hat Dragonfly-MLE die eingehenden Daten erst einmal unter seinen Fittichen, durchlaufen sie die Schicht der Analyzer. Deren zentrale Aufgabe besteht darin, die von Suricata zur Verfügung gestellten Informationen zu analysieren und auf Basis des Ergebnisses eine Bewertung nach einem Punkteschema vorzunehmen. Dragonfly-MLE liefert ab Werk bereits einige Analyzer mit, Admins und Anwender sind aber durchaus aufgerufen, auch eigene Varianten zu schreiben und zu verwenden. Die ab Werk mitgelieferten Exemplare bewerten Traffic etwa anhand von ungewöhnlichen Herkunftsländern oder eigenartigen Zeitstempeln.

Vom Prinzip her funktioniert das so ähnlich wie in Spamassassin: Für einzelne Kriterien gibt es eine bestimmte Punktzahl. Weist ein Ereignis am Ende der Kalkulation einen hinreichend hohen Punktestand auf, leitet Dragonfly diese Info an die bereits erwähnten LUA-Sinks weiter. Konfiguriert der Admin Suricata in der vorgesehen Art und Weise, holt es sich die Informationen wieder aus dem von Dragonfly-MLE zur Verfügung gestellten Sink.
Es entsteht eine Art Kreislauf von Events, daraus resultierenden Aktionen und erweitertem Regelwerk auf Suricata-Seite. Von Machine Learning zu sprechen, wäre hier genaugenommen unzutreffend: Das System verbessert ja, anders als komplexe neuronale Netze, seine Ergebnisse nicht aufgrund eines Feedbacks selbstständig – was den Kern eines Lernvorgangs darstellt. Es geht eher um Filter, die deswegen etwas intelligenter arbeiten, weil der Anwender sie mit Gewichten (den Punktwerten) versieht.

Keine Lösung von der Stange

Während Suricata sich durchaus von der Stange installieren lässt, liegt die Sache bei Dragonfly-MLE etwas anders: Das Produkt existiert im Moment als freie Software im Wesentlichen auf Github, die großen Distributoren liefern es nicht in ihren Repos. Im Klartext bedeutet das für den Admin Handarbeit: Er installiert Dragonfly-MLE wahlweise händisch, baut sich ein Paket daraus oder verfrachtet es in einen Docker-Container.
Letzteres wäre jedenfalls die eleganteste und sauberste Methode, die Machine-Learning-Engine zu betreiben, weil auf diese Art und Weise das darunterliegende System unangetastet bleibt. Sonderlich bequem ist jedoch auch dieser Ansatz nicht, denn es gilt, die gesamte Integration von Suricata und Dragonfly-MLE händisch zu erledigen.

Abbildung 3: OPNsense ist eine Firewall-Appliance auf Basis freier Software, die sich einiger Beliebtheit erfreut.


© OPNsense

OPNids zur Rettung

Da kommt ein Produkt namens OPNids gerade recht, das auf Github zu finden ist [1]. Es entstammt zwar nicht der Feder der OPNsense-Entwickler, ist aber ein direkter Fork von OPNsense. Es erscheint deshalb sinnvoll, sich kurz mit der Ausgangsbasis zu beschäftigen.
OPNsense (Abbildung 3) bezeichnet sich selbst bescheiden als High-End-Security-Firewall auf Basis quelloffener Software. Im Kern betreibt OPNsense als Stateful Firewall mit Bordmitteln Paketfilterung. Der Anbieter reichert das Produkt allerdings mit allerlei Funktionen an: Eine eigene grafische Oberfläche („Dashboard“) und ein eigenes Verwaltungswerkzeug für die aktiven Firewall-Regeln gehören ebenso zu OPNsense wie Zwei-Faktor-Authentifizierung und ein Traffic Shaper, der gegebenenfalls den Datenfluss unterbindet. Als Endpunkt für eine klassische VPNVerbindung agiert OPNsense auf Wunsch ebenso wie als Proxy mit Cache-Funktion für ausgehenden Traffic.
Zu den Bestandteilen von OPNsense zählt auch ein IDS in Form von Suricata (Abbildung 4). Das lässt sich per GUI steuern und verwalten und bringt Suricata so noch schneller in Aktion, als es auf Standardsystemen der Fall wäre. Der Hersteller stattet das Programm gleich mit einem guten Set an Standardsignaturen aus, sodass sich der Admin hier Herumprobieren ersparen kann.

OPNids als OPNsense-Ableger

Da OPNsense vollständig unter einer freien Lizenz steht, konnten es die OPNids-Entwickler problemlos als Grundlage nutzen. Die Programmierer sind übrigens nicht dieselben: Hätten die Entwickler von OPNsense sich des Themas Machine Learning angenommen, hätten sie vermutlich die entstehende Funktionalität gleich in OPNsense integriert. Wer OPNids statt OPNsense verwenden möchte, gerät vermutlich in Schwierigkeiten: OPNids bietet eine einzelne Funktion, die OPNsense fehlt; OPNsense hingegen offeriert einen mächtigen Funktionsumfang, nicht aber die MLEFunktionalität. Als echtes Drop-in-Replacement kann jedenfalls keine der Lösungen für die jeweils andere einspringen.

Abbildung 4: OPNsense kommt ab Werk zwar auch mit Suricata, es fehlt aber der Dragonfly-MLE-Teil für automatisches Lernen.


© OPNsense

Abbildung 5: OPNids liefert zwar ein GUI-Plugin für Dragonfly-MLE mit, das ist aber nicht sonderlich nützlich.


© OPNids

Komplizierter Build-Prozess

Anders als die Entwickler von OPNsense, stellen die OPNids-Entwickler von ihrem Produkt aktuell keine ISO-Images zur Verfügung. Allerdings lassen sich mit den OPNsense-Tools und dem Github-Verzeichnis von OPNids entsprechende ISO-Abbilder bauen. Ein Anleitung [2] verrät, wie das funktioniert; komfortabel ist das aber nicht.
Hat man sich durch den Prozess gekämpft, steht die schon erwähnte grundlegende OPNsense-Basis von OPNids bereit. Zudem findet man im Web-GUI sofort auch die Dragonfly-MLE-spezifischen Einträge. Aus nicht nachvollziehbaren Gründen sind sie in OPNids in der Standardinstallation deaktiviert, sodass der Admin sie zunächst einschalten muss. Er darf auch nicht vergessen, den Port der Maschine, auf der OPNids läuft, am Switch als Mirror-Port zu definieren, weil OPNids sonst gar nicht alle Pakete seiner Umgebung zu sehen bekommt.
Lästig ist auch, dass OPNids zwar Dragonfly-MLE integriert, der Admin aber zentrale Einstellungen wie das Verzahnen von Suricata und Dragonfly-MLE trotzdem händisch leisten muss. Das wirkt so, als seien die OPNids-Entwickler mit ihrer Arbeit nicht fertig geworden (Abbildung 5).

Unsichere Zukunft?

Diesen Eindruck untermauert auch ein Umstand, der quasi erst während der Arbeiten an diesem Text zutage trat: Die OPNids-Website [3] verschwand plötzlich aus dem Internet. Rief man sie zu Redaktionsschluss auf, bekam man nur noch ein Connection Refused zurück. An mangelnder Popularität kann das bei OPNids nicht liegen, denn eine Vielzahl anderer Seiten verweist auf dessen Webpräsenz. Da liegt der Verdacht nahe, dass den OPNids-Entwicklern schlicht die Pflege eines halben OPNsense-Forks über den Kopf gewachsen ist.
Der Arbeitseinsatz, den ein Admin aktuell investieren muss, um OPNids sinnvoll zu nutzen, übersteigt jedenfalls bei Weitem den Aufwand, den es braucht, um Suricata und OPNids auf einem Linux-System von der Stange händisch zu konfigurieren. Dann fehlt zwar das GUI, das bei OPNids die Suricata- und Dragonfly-MLE-Konfiguration übernimmt, doch das hilft bei OPNids auch nur für Suricata wirklich weiter. Der Teil, der sich mit Dragonfly-MLE beschäftigt, bietet dagegen kaum Mehrwert.
Suricata kommt in OPNids schließlich in einer Standardkonfiguration – wo das Eve-Log liegt und wie Dragonfly-MLE darauf zugreifen kann, ließe sich also sogar automatisiert einstellen. Stattdessen erzwingt die OPNids-Oberfläche nutzlose Mausakrobatik.
Dragonfly-MLE befindet sich noch in aktiver Entwicklung, der letzte Commit im OPNids-Github-Repo liegt hingegen schon eine ganze Weile zurück. Es lässt sich also nicht ausschließen, dass der Abgesang auf OPNids bald folgt.

Fazit

Die Idee, Angriffe automatisiert anhand verschiedener Faktoren zu erkennen und über ein Punktesystem zu bewerten, erscheint clever und ergibt viel Sinn. Was bei Spamassassin & Co. funktioniert, lässt sich auch bei einem IDS anwenden: Weisen die Muster des eingehenden Traffics bestimmte Merkmale auf, steigt die Wahrscheinlichkeit, dass etwas Unerwünschtes im Busch ist.
Dragonfly-MLE wurde explizit für die Verwendung mit Suricata konzipiert. Die Kombination mit OPNids indes vermag nicht zu begeistern. OPNids wirkt mehr tot als lebendig. Es sei dahingestellt, ob es wirklich sinnvoll ist, einen halbgaren Fork einer an sich gut funktionierenden Lösung zu nutzen.
Zum Glück geht die Dragonfly-MLEEntwicklung weiter, und wer Suricata und die MLE auf einem normalen Linux aufsetzt, der hat eine funktionale Kombination für automatische Threat Detection zur Hand. Genau zu diesem Einsatzszenario rät dieser Artikel letztlich auch.

(jcb/jlu

Der Autor

Martin Gerhard Loschwitz ist Senior Cloud Architect bei Drei Austria, wo er sich hauptsächlich mit Open-Stack, Ceph und Kubernetes beschäftigt.

Infos

[1] OPNids auf Github: [https:// github.com/OPNids]
[2] Bauanleitung zu OPNsense/ OPNids:[https:// github.tools]
[3] OPNids-Website (defekt): [https:// www.opnids.io]