© Maxxyustas, 123RF

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.

Menschen machen Fehler, gerade auch beim Programmieren – so lautet eine gern zitierte Binsenweisheit im Kontext von Sicherheitsproblemen. Dem Admin hilft das freilich wenig: Durchwühlt ein ausländischer Geheimdienst sein Setup und manipuliert Dienste oder nimmt Daten mit, ist das für ihn beinahe das schlimmstmögliche 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, oder ganze Umgebungen waren plötzlich nicht mehr nutzbar.

Eine solche Situation entwickelt sich für ein Unternehmen in Windeseile zur handfesten Gefahr für sein Fortbestehen. Jedes Leck kostet eine gehörige Portion 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 als Nachsicht

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 aber 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 der 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 hundertprozentig zuverlässigen 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 das gut funktionierende Werkzeug Suricata (Abbildung 1).

Abbildung 1: Suricata ist ein umfangreiches Werkzeug zur Erkennung von digitalen Angriffen. Quelle: Linux Screenshots (USA)

Für Suricata existieren im Netz verschiedene Datenbanken mit Angriffssignaturen, mit deren Hilfe das Tool den Datenverkehr untersucht und Angriffe 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.

IDS und IPS

Zuvor steht aber noch eine kurze Schärfung der Begrifflichkeiten an: Die Abkürzungen IDS und IPS stehen für die englischsprachigen Begriffe Intrusion Detection System und Intrusion Prevention System. Ein IDS untersucht lediglich den vorbeifließenden Datenverkehr auf bekannte Muster hin. 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, kann also sowohl als IDS wie auch als IPS fungieren. Der Einfachheit halber subsummiert 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 zu überprüfen vermag, 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 einer Umgebung. 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. Findet sich dort kein passendes Paket, gibt es Drittanbieter, die etwa für Ubuntu Suricata-PPAs pflegen. Das verkürzt den Weg vom Wunsch, Suricata zu betreiben, bis zur 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 ü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.

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, könnte Suricata sich anhand eingehender Daten selbst trainieren, um Angriffe automatisch zu erkennen. Ganz abwegig ist die Idee nicht, sie klappt 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 Support vom User ihr Regelwerk automatisch auf neue Gegebenheiten abstimmen. Von KI und Machine Learning würde bei Spamfiltern zwar noch keiner 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 meisten 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 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 HTTP-Request zu übernehmen, fischt Suricata diese Information aus dem Paketstrom heraus und vermerkt sie entsprechend in einer Log-Datei.

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

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 auf Basis festgelegter Parameter Suricata 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.

OPNids zur Rettung

Da kommt ein Produkt namens OPNids gerade recht, das sich auf Github findet [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 VPN-Verbindung agiert OPNsense auf Wunsch ebenso wie als Proxy mit Cache-Funktion für ausgehenden Traffic.

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

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.

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

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. Dass das nicht passierte, könnte für OPNids noch zum Problem werden – doch dazu später mehr.

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 MLE-Funktionalität. Als echtes Drop-in-Replacement kann jedenfalls keine der Lösungen für die jeweils andere einspringen.

Komplizierter Build-Prozess

Anders als die Entwickler von OPNsense, stellen die OPNids-Entwickler von ihrem Produkt aktuell keine ISO-Images zur Verfügung. Man kann also keine einzelne Datei herunterladen und die OPNids-Appliance daraus installieren. 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 schlicht und ergreifend so, als seien die OPNids-Entwickler mit ihrer Arbeit nicht fertig geworden (Abbildung 5).

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

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. Vielfalt zählt zwar zu den Schlüsselfaktoren in der FL/OSS-Welt, doch manchmal ergibt es mehr Sinn, die Kräfte zu bündeln, als sein eigenes Süppchen zu kochen.

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. Ob der Admin nun zu überwachende Suricata-Log-Dateien in eine Konfigurationsdatei einträgt oder in ein Pfad-Feld im Webinterface, das ist am Ende auch egal. 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. Angesichts des Zustands, in dem sich das Projekt aktuell befindet, wäre das aber auch keine Tragödie.

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. Trainiert man eine Engine für IDS-Regeln so, dass sie diese Muster erkennt und ihre Heuristik sinnvoll adaptiert, kann sie Angriffe tatsächlich autark erkennen.

Dragonfly-MLE wurde explizit für die Verwendung mit Suricata konzipiert, womit seine Entwickler zweifellos auf das beste Pferd im Stall quelloffener IDS-Systeme setzen. Die Kombination mit OPNids indes vermag nicht zu begeistern. OPNids wirkt mehr tot als lebendig. Es sei dahingestellt, ob es wirklich sinnvoll ist, im produktiven Umfeld eines Setups einen halbgaren Fork einer an sich gut funktionierenden Lösung zu nutzen. Die meisten Admins dürften sich diese Frage ohnehin intuitiv selbst beantworten.

Zum Glück geht die Dragonfly-MLE-Entwicklung 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. OPNids ist sicherlich eine schöne Idee, sinnvoll nutzen lässt es sich aktuell jedoch nicht. (jcb/jlu)