© Peter Vrabel / 123RF.com

Umfassende Bedrohungserkennung für Docker, Podman sowie Kubernetes auf der Grundlage des fließenden Netzwerkverkehrs: Das verspricht das Tool Falco von Sysdig. Schafft es einen echten Mehrwert, oder ist alles viel Lärm um nichts?

Für die Sicherheit im Rechenzentrum garantiert längst nicht mehr allein regelmäßiges Überprüfen und umfassende Compliance. Weil die Ganoven immer besser und ihre Angriffe immer komplexer und ausgefeilter werden, muss die Abwehr nachziehen. Seit einiger Zeit ist daher die proaktive Überwachung des Netzwerkverkehrs angesagt. Zum Teil im Fahrwasser des KI-Hypes geht es bei diesem Ansatz darum, anhand verdächtiger Datenpakete im Netzwerkverkehr sinistre Aktivitäten zu erkennen und vorbeugend Maßnahmen zu ergreifen, bevor ein Angreifer die Gelegenheit ausnutzen kann.

Dienste dieser Art gibt es auf dem Markt viele, einen Namen hat sich beispielsweise Coroot [1] gemacht (Abbildung 1). Dieses Tool stößt dieser Tage allerdings insbesondere bei europäischen Kunden auf Vorbehalte, weil man es nur nutzen kann, wenn man bereit ist, umfassende Informationen über den eigenen Datenverkehr in die Cloud hochzuladen: Dort ist der KI-Teil der Anwendung zu Hause.

Abbildung 1: Coroot realisiert Sicherheitsanalysen durch KI, lädt dazu aber viele Daten in die Cloud. Falco funktioniert ausschließlich lokal.

Mit weniger KI will die deutlich bodenständigere Lösung Falco [2] punkten. Deren Macher bezeichnen ihr Werkzeug als Cloud-native Bedrohungserkennung, bestens integriert mit Kubernetes und den klassischen Laufzeitumgebungen wie Docker oder Podman. Hersteller Sysdig hat viel Zeit und Aufwand in Falco gesteckt. 2024 wurde aus dem Projekt nach der üblichen Inkubationsphase ein offizielles Projekt der Cloud Native Compute Foundation (CNCF). Grund genug, sich einmal genauer anzuschauen, wie und wie gut aktive Bedrohungserkennung mit Falco funktioniert.

Die Falco-Architektur

Container sind in der Linux-Welt mittlerweile ein absolutes Standardwerkzeug. Große Hersteller wie Red Hat oder Suse haben längst begonnen, ihre Enterprise-Distributionen, einst so etwas wie die Kronjuwelen, in Containerabspieler umzubauen. Das hat aus ihrer Sicht den großen Vorteil, dass man die Pflege des Anwendungsökosystems den Drittanbietern der jeweiligen Werkzeuge überlassen kann. Doch im Sicherheitskontext haben containerbasierte Workloads Herausforderungen im Schlepptau, die es bei konventionellen Anwendungen so nicht gibt. Sie betreffen primär die Sicherheit während der Ausführung, also zur Laufzeit (Runtime). An genau diesem Punkt setzt Falco an.

Die Herausforderung: Workloads, die in Containern laufen, sind (gewollt) durch die jeweilige Laufzeitumgebung vom Rest des Systems abgeschirmt. Ein zentrales Verkaufsargument für Container ist ja gerade, dass sie die Anwendung vom Rest des Systems logisch separieren. Die nutzt ihre eigenen Bibliotheken und eine virtualisierte Netzwerkverbindung. Sie kann auf das Dateisystem des Hosts nur auf strikt definierten Wegen zugreifen. Die Kehrseite dieser Trennung: Gängigen Werkzeugen zur Bedrohungserkennung bleibt ein guter Teil der Aktivitäten von Containern und den darin laufenden Anwendungen verborgen.

Angriffsvektoren gibt es dabei viele. So unterliegen die Bibliotheken und Werkzeuge in Containern beispielsweise normalerweise nicht dem Softwaremanagement des Hosts. Es genügt also in containerbasierten Umgebungen nicht, einmal pro Quartal ein Paket-Update auszuführen. Das aktualisiert zwar die Software des Hosts und die Laufzeitumgebung für Container (wie Podman oder Docker), die Software in den Containern profitiert davon aber nicht. Und das, obwohl sie wesentlich vielfältiger ist, als es auf klassischen Linux-Systemen der Fall wäre.

Auf einem Ubuntu-System beispielsweise, auf dem Ceph in Containerform läuft, bekommt der Administrator es außer mit Ubuntu auch mit CentOS Stream zu tun. Denn das ist die Distribution, die Red Hat für seine Ceph-Container einsetzt. Kommen dann noch weitere Anwendungen in Containerform hinzu, die wieder andere Grunddistributionen nutzen, ist das Chaos perfekt. Aus Sicht des Systemverwalters ist es nur durch kontinuierliches Updaten der Container in den Griff bekommen. Wer aber nicht jeden Tag alle Systeme im Hinblick auf Zero-Day-Lücken untersuchen möchte, braucht eine Software, die etwaige Bedrohungen eigenständig erkennt und entsprechend Alarm schlägt. Mit ebendiesem Versprechen tritt Falco an (Abbildung 2).

Abbildung 2: Falco besteht im Kern aus dem Regelwerk und den Plugins für Datenquellen wie eBPF. In Sachen Ausgabe unterstützt es diverse Dienste. Quelle: Falco-Projekt

Noch mehr Probleme

Fehlerhafte Anwendungen im Container selbst sind dabei nur ein Problemfeld. Andere Szenarien sind mittlerweile ebenfalls weitverbreitet: Durch (schlimmstenfalls unbekannte) Sicherheitslücken in der Laufzeitumgebung könnten Angreifer beispielsweise versuchen, aus dem Container auszubrechen und Zugriff auf die Ressourcen des Hosts zu erlangen. Eine solche Privilege Escalation hinterlässt im Normalfall eindeutige Spuren. Ein Linux-System mit Standardkonfiguration und Docker-CE hat aber keine Werkzeuge, um sie automatisiert zu erkennen. Auch diesen Aspekt deckt Falco deshalb ab.

Zu guter Letzt kann auch fehlerhafte Software in Containern zum Problem werden. Das betrifft zum Beispiel jene Situationen, in denen laufende Software ihren Arbeitsspeicher nicht richtig verwaltet und insbesondere nicht gründlich genug freigibt, sobald sie ihn nicht mehr benötigt. Stößt ein Angreifer auf eine derart fehlerhafte Anwendung, kann er durch geschicktes Bombardieren mit Anfragen oft nicht nur die Anwendung selbst zum Absturz bringen, sondern indirekt auch andere Container auf demselben Host. Im schlimmsten Fall beeinträchtigt das die gesamte Umgebung.

Falco bringt deshalb Funktionen mit, die Anwendungen hinsichtlich ihres Verhaltens überwachen und Fehler wie Speicher-Leaks ohne Zutun des Administrators erkennen. Wichtig dabei: Falco fokussiert nicht nur auf einzelne Container und Laufzeitumgebungen in einzelnen Systemen. Stattdessen existiert für Falco auch eine komplette Einbindung in Kubernetes, den gängigsten Containerorchestrierer. Das macht es für Entwickler und Systemverwalter leicht, die eigentlichen Anwendungen auf ihren Systemen von Falco beobachten zu lassen.

Die Falco-Architektur

Für das Verständnis von Falco ist es hilfreich, sich zunächst dessen Architektur anzuschauen. Ursprünglich hatte der Hersteller das Werkzeug als integralen Bestandteil einer anderen Software entwickelt, heute funktioniert Falco dagegen hervorragend eigenständig. Es besteht selbst aus mehreren Komponenten. Aus Anwendersicht ist das wichtigste Stück Software in Falco das Kommandozeilenprogramm »falco«. Mittels dieses Tools lässt sich die Software umfassend konfigurieren. Dabei legt der Systemverwalter fest, auf welche Ereignisse Falco reagieren soll und welche Reaktionen jeweils gewünscht sind.

Das Herzstück von Falco ist der sogenannte Driver. Mit diesem Begriff bezeichnen die Falco-Entwickler ein direkt mit dem Linux-Kernel verbundenes Programm, das aus Events der containerisierten Applikationen einen Datenstrom erzeugt und ihn an Falco weitergibt. Der Treiber kann bei Falco gegenwärtig in mehreren Formen daherkommen, Standard ist eine eBPF-Probe. Von dieser gibt es auch eine ältere und weniger leistungsfähige Variante, die Falco aus Gründen der Abwärtskompatibilität bis heute beiliegt. Außerdem existiert für Falco auch ein Kernel-Modul, das nach dem Laden einen Event-Stream erzeugt, den Falco bearbeiten kann. Hier wird deutlich, dass Falco keine ganz neue Lösung ist, denn der Kernel-Treiber ist streng genommen Legacy-Software und stammt aus einer Zeit, in der eBPF [3] noch nicht im heutigen Umfang zur Verfügung stand.

Wichtig: Damit ein Driver Falco mit sinnvollen Informationen füttert, benötigt der Dienst eine Definition seiner Event-Quellen. Spezifisch geht es dabei darum, dem Kernel-Treiber oder eBPF mitzuteilen, welche Ereignisse Beachtung finden sollen und auf welche Benachrichtigungen der jeweilige Treiber zu achten hat. Falco präsentiert sich dabei als sehr vielseitig, denn Ereignisquellen lassen sich über einen Plugin-Mechanismus [5] dynamisch in Falco definieren oder aus ihm entfernen.

Schließlich ist auch die Kommunikation mit der Außenwelt wichtig. Dazu bietet die Software die Möglichkeit, sich mit diversen externen Diensten zu verbinden, um spezifische Ereignisse per Notification direkt an die zuständigen Systemverwalter zu melden.

eBPF als Matchwinner

Falcos bevorzugter Mechanismus, um Daten abzugreifen, ist – wie erwähnt – eBPF (Abbildung 3). Weil das Werkzeug in Falco eine zentrale Rolle spielt, schadet ein kurzer Exkurs in Sachen eBPF nicht. Zwar ist die Paketfiltererweiterung bereits seit einiger Zeit fester Bestandteil von Linux. Werkzeuge, die wie Falco eBPF effizient nutzen, gibt es aber noch nicht so viele. eBPF ist eine Abkürzung und steht für “extended Berkeley Packet Filter”. Die Technik macht also Anleihen an BPF, dem ursprünglichen Paketfilter von BSD. Dieser gilt in Fachkreisen seit Jahrzehnten als äußerst leistungsfähig und vielseitig und wurde deswegen auch auf Linux portiert.

An Werkzeugen zum Filtern von Paketen mangelt es Linux nicht, erinnert sei an Netfilter und seine verschiedenen Frontends wie Iptables und neuerdings Nftables. Dass eBPF “extended” ist, also erweitert, ist eigentlich untertrieben. Hinter der Technik verbirgt sich nicht weniger als eine Virtualisierungsumgebung. eBPF nutzt eine spezielle Form der Virtualisierung, deren Ziel es ist, beliebige Programme – sogenannte Probes – im Netzwerk-Stack des Linux-Kernels auszuführen.

eBPF kann die im Transit befindlichen Daten innerhalb eines Linux-Systems mitschreiben und wo gewünscht modifizieren. Ein Kernargument der eBPF-Befürworter ist die extreme Leistungsfähigkeit von eBPF. Im heutigen Rechenzentrum haben Administratoren es schließlich nicht mehr mit Bandbreiten von nur 1 Gbit/s zu tun. Stattdessen sind 25 Gbit/s die Regel, und selbst 400 Gbit/s stellen keine Seltenheit mehr dar. Andere Paketfilter für Linux, allen voran das mittlerweile ausgemusterte Iptables, sind dafür schlicht zu langsam. In Form von eBPF aber steht Entwicklern und Admins eine Schnittstelle im Linux-Kernel zur Verfügung, die das Untersuchen und Manipulieren von Paketen in Echtzeit selbst bei hohen Bandbreiten problemlos leistet.

Abbildung 3: Wegen der hohen Performance gilt eBPF unter Linux als Königsweg, wenn es darum geht, durchlaufenden Traffic genau zu analysieren. Quelle: eBPF-Projekt

Die Falco-Entwickler fokussieren dabei vor allem auf die Untersuchung aktiver Datenströme. Besonders praktisch: Anders als bei anderen Paketfiltern ist es aus eBPF-Probes heraus möglich, den Traffic samt Quellen und Zielen als nutzbare Parameter zu verwenden. Datenverbindungen zwischen einzelnen Mikroarchitekturanwendungen einer App zum Beispiel lassen sich mit eBPF viel besser untersuchen als mit anderen Lösungen, weil sich in einer eBPF-Probe auch das empfangende und sendende Programm auf dem System genau zuordnen lässt. Diese Eigenschaft ist es auch, die das Gespann aus Falco und eBPF so effektiv macht.

Genauer Mitschreiber

Im Kern tut Falco nichts anderes, als sich mittels eBPF in den Netzwerkverkehr eines Systems einzuklinken und per Probe dort in Abhängigkeit von der hinterlegten Konfiguration Traffic mitzuschreiben. Das eingangs erwähnte Falco-Kernel-Modul ist demgegenüber Legacy-Software. Es stammt noch aus einer Zeit, in der es eBPF noch nicht gab beziehungsweise die Technik noch nicht reif für den produktiven Einsatz war. Darum kommt das Modul heute nur noch in Bestandsinstallationen zum Einsatz.

Neuere Falco-Setups sollten ausnahmslos auf die eBPF-Quelle für Falco setzen. Zusätzlich zu eBPF unterstützt Falco weitere Methoden, um das Verhalten von Anwendungen zu analysieren. So kann das Tool, wenn man es einer App als Sidecar beifügt, auch deren Syscall-Aufrufe untersuchen und bewerten. Das ist insbesondere dort wichtig, wo Bedrohungsanalyse nicht nur Netzwerk-Traffic betrifft, sondern das generelle Verhalten von Anwendungen etwa im Hinblick auf deren Speichernutzung.

Filtern nach Regeln

Wie also funktioniert die Untersuchung von Traffic mit Falco konkret? Hinter den Kulissen werkelt dabei die Falco Rule Engine [5]. Hier sind in einer nativen, deklarativen Syntax die Anweisungen hinterlegt, mittels derer sich das Falco-Verhalten bestimmen lässt. Eine Falco-Regel besteht mindestens aus einem eindeutigen Namen, einer Beschreibung, einer Liste der Bedingungen, die gegeben sein müssen, damit die Regel greift, sowie einer Liste der Ausgaben, die die Regel generiert. Obendrein ist die Priority festzulegen, die für Ereignisse gilt, die auf eine bestimmte Regel in Falco matchen.

Von besonderem Interesse aus Sicht des Admins sind die Felder für die Bedingungen, die Ausgabe sowie die Priorität. Listing 1 zeigt ein Beispiel direkt aus der Falco-Dokumentation und verdeutlicht gut, wozu das Werkzeug bereits mit relativ wenig Aufwand in der Lage ist.

rule: shell_in_container
desc: notice shell activity within a container
condition: >
  evt.type = execve and
  evt.dir = < and
  container.id != host and
  (proc.name = bash or
  proc.name = ksh)
output: >
shell in a container | user=%user.name container_id=%container.id container_name=%container.name
shell=%proc.name parent=%proc.pname
cmdline=%proc.cmdline
priority: WARNING

Dabei definiert »rule« den Regelnamen und »desc« eine Beschreibung des Regelzwecks. Viel spannender ist allerdings die Liste der Conditions. Es lässt sich gut erkennen, dass hier mehrere Bedingungen zusammenkommen, die jeweils eine »and«-Anweisung verbindet. Damit die Regel greift, müssen also alle Bedingungen erfüllt sein. Der »evt.type« gibt die Art des Ereignisses an, im Beispiel das Ausführen des Systemaufrufs »execve«; »evt.dir« beschreibt die Kommunikationsrichtung. Hier steht »>« für den Beginn eines Aufrufs und »<« für dessen Ende. Die »container.id« stellt auf die ID des Containers ab und legt im Beispiel fest, dass die ID des Containers nicht mit der imaginären ID des Hosts identisch sein soll.

Im konkreten Beispiel soll die Regel für Falco den Aufruf von Shells in Containern identifizieren und melden, nicht aber den Aufruf von Shells auf dem Host. Entsprechend gelten die Einschränkungen von »proc.name«, die den Namen des aufgerufenen Programms festlegen. Die Angabe »output« schließlich gibt vor, welche Log-Meldung Falco bei einem Ereignis produziert, das alle in »condition« festgelegten Kriterien erfüllt. Das Argument »priority« legt das Level der Warnung fest. Damit ist klar, was die Beispielregel aus Listing 1 tut: Sie warnt jedes Mal, wenn in einem laufenden Container auf dem Host eine Shell in Form von Bash oder Ksh aufgerufen wird (Abbildung 4).

Abbildung 4: Anhand von Systemaufrufen und dem analysierten Netzwerkverkehr erkennt Falco potenziell problematische Ereignisse wie den Aufruf einer Shell in einem Container.

Mit Warnungen arbeiten

Nun ist die Warnung allein noch nicht viel wert, wenn keine Möglichkeit besteht, sie auf direktem Wege zur zuständigen Stelle zu bringen. Möglichkeiten für das Erstellen von Warnungen bietet Falco wahrlich genug, aber wie lässt sich eine Alarmierung sicherstellen? Hier kommen die Falco-Output-Plugins ins Spiel. Sie bieten vielfältige Möglichkeiten, um Warnungen aus Falco heraus direkt an externe Dienste zu versenden [6].

Das Tool unterstützt dabei neben gängigen Chat-Plattformen wie Slack [7] und Teams [8] klassische Instant-Messaging-Dienste. Auch diverse Pager-Dienste wie PagerDuty [9] oder Opsgenie [10] lassen sich direkt aus Falco heraus ansprechen. Für die Anbindung an Dienste, die SMS zustellen, steht eine ReST-Schnittstelle zur Verfügung. Mit diversen Monitoring-Systemen ist Falco ebenfalls kompatibel, unter anderem mit dem Alert-Manager von Prometheus [11] sowie mit Nagios [12] und Icinga [13]. Das bringt den Vorteil mit sich, dass sich bestehende Alarmierungsketten und bestehende Eskalationsstufen problemlos wiederverwenden lassen. Sobald Falco einmal mit dem bestehenden Monitoring verbunden ist, erfolgt die Alarmierung automatisch.

Im Gespann mit Kubernetes

Falco ist praktisch, dürfte aber in den meisten Fällen nicht ausschließlich im Gespann mit einer Laufzeitumgebung für Container wie Docker oder Podman zum Einsatz kommen. Stattdessen werden viele Administratoren Falco vor allem in Kombination mit Kubernetes einsetzen wollen, das meistens mit ins Spiel kommt, wenn es darum geht, Flotten von Containern zu orchestrieren.

Die gute Nachricht dabei: Die Integration von Falco und Kubernetes ist weitgehend vollständig. So bietet das Projekt selbst beispielsweise Helm-Charts an, also Metadaten zur Installation von Falco in Kubernetes-basierten Clustern unter Verwendung des K8s-Paketmanagers Helm. Alternativ steht auch ein Operator zur Verfügung, der Falco in Kubernetes an den Start bringt. Beiden Ansätzen ist gemein, dass sich mit ihnen Instanzen von Falco starten und verwalten lassen und dass jeweils die Möglichkeit besteht, einem oder vielen Containern Falco als Sidecar zur Verfügung zu stellen. Dann untersucht Falco in den ausgerollten Pods anhand der definierten Regeln die Prozesse und analysiert zudem den Netzwerkverkehr wie per Konfiguration festgelegt.

Noch mehr Input

Im Standard-Deployment erhält Falco Daten zur Analyse vor allem wie beschrieben über eBPF oder das Kernel-Modul. Allerdings ist die Plugin-Architektur von Falco so generisch gehalten, dass sie sich darüber hinaus verwenden lässt, um Ereignismeldungen von anderen Diensten zu empfangen und auf Grundlage des bestehenden Regelwerks auszuwerten. Regelmäßig zum Beispiel kommt Kubernetes zusammen mit einem SSO-Dienst wie Okta zum Einsatz, der eigene Log-Meldungen produzieren und ausgeben kann (Abbildung 5).

Damit der Administrator nicht jede Komponente der Umgebung separat konfigurieren muss, um Daten in mögliche Alarmierungen zu bekommen, lassen sich manche externen Dienste per Plugin an Falco anklöppeln. Das trägt in Summe dazu bei, dass sich mit Falco echte Audit-Trails für Ereignisse in Kubernetes erstellen lassen.

Abbildung 5: Über Outputs lassen sich Daten aus Falco an andere Dienste wie Prometheus ausgeben und dort verwerten und analysieren. Quelle: Falco-Projekt

Ins Bild passt, dass Falco sich auch mit der Kubernetes-Audit-Komponente K8saudit koppeln lässt. Audit-relevante Ereignisse landen dann als Meldung in Falco und können als Grundlage für einen Alarm dienen. Obendrein arbeitet man bei Falco aktiv an neuen Plugins. So ist ein Modul geplant, mit dem sich ein AI-Modell für adaptive Bedrohungsvorhersage angepasst an lokale Begebenheiten entwickeln lässt. Das soll nach entsprechendem Training in der Lage sein, Auffälligkeiten im Netzwerkverkehr automatisiert zu erkennen und Angriffen damit aktiv vorzubeugen.

Das geht (noch) nicht

Schon während der ersten Schritte mit Falco merkt der Systemverwalter schnell, dass es sich um ein sehr mächtiges Werkzeug handelt. Das bedeutet allerdings, dass es darauf ankommt zu verstehen, was Falco ist und was nicht. Viele Admins würden bei einem Werkzeug für Laufzeitsicherheit intuitiv vermutlich einen eingebauten Scanner für verwundbare Software erwarten. Sie hätten also gern ein Werkzeug, das sich in laufende Container einloggt, die dort vorhandenen Versionsnummern der installierten Software untersucht und Alarm schlägt, wenn ein CVE existiert, das in der gegebenen Version eine Schwachstelle dokumentiert.

Einerseits ist Falco tatsächlich in der Lage, erfolgreich Angriffe zu erkennen. Wird etwa in einem Container plötzlich eine Shell ausgeführt, ist das zwar immer ein Grund zur Sorge, doch Falco erkennt es problemlos, wie im Beispiel aus Listing 1 gezeigt. Andererseits funktioniert die Angriffserkennung hier aber eben nicht auf Basis von Versionsnummern. Stattdessen untersucht Falco den laufenden Netzwerkverkehr des Containers aktiv nach Spuren von Einbrüchen und schlägt gegebenenfalls Alarm. Die Philosophie dahinter ist klar: Verwundbarkeitsscanner für Container gibt es mittlerweile in mannigfaltiger Form. Die Falco-Entwickler sehen keinen Grund, noch einen neuen zu bauen. Stattdessen entdeckt Falco Probleme auf andere Weise.

Übrigens: Administratoren müssen Falco-Regelwerke nicht notwendigerweise mühsam von Grund auf selbst erstellen. In der Community existieren bereits mehrere Git-Verzeichnisse mit vorgefertigten Regeln für viele Einsatzbereiche. Sie lassen sich problemlos in ein bestehendes Falco-Setup übernehmen und dort aktivieren.

Fazit

Falco ist ein mächtiges Werkzeug zur Bedrohungserkennung und Schadensvorbeugung in Umgebungen, in denen Container den Ton angeben. Besonders in Kombination mit Kubernetes spielt das Werkzeug seine Stärken voll aus. Hier integriert es sich nahtlos in K8s und überwacht die darin laufenden Container anhand ihrer Kommunikation, ohne dass die Anwendung dafür angepasst werden müsste.

Darin unterscheidet sich Falco von anderen Lösungen für Monitoring und Alerting wie jenen des OpenTelemetry-Projekts [14]: Die setzen voraus, dass ein Dienst spezifisch für die Verwendung von OpenTelemetry vorbereitet und gegen die OpenTelemetry-Werkzeuge kompiliert ist. Falco lässt sich stattdessen mit jedem Werkzeug in jedem Container verwenden, der auf einem Standard-Linux-System läuft. Die Qualität des Programms überzeugt dabei ebenso wie die große Community, die an Falco arbeitet.

Allzu viele Alternativen existieren ohnehin nicht, naheliegend wäre lediglich Tetragon [15]. Wenn Sie es mit dem Thema Bedrohungserkennungen zur Laufzeit in Containern zu tun haben, sollten Sie Falco aber auf jeden Fall unter die Lupe nehmen. (jcb/jlu)