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
