Einführung in die Bedrohungserkennung in Kubernetes mit Falco

Beispielsweise ist das Öffnen einer Shell in einem Container höchstwahrscheinlich nicht erforderlich und könnte einen Angriff darstellen. Falco ist eine Threat Detection Engine für Kubernetes und kann verwendet werden, um solche Ereignisse sichtbar zu machen. Es handelt sich dabei um ein Projekt, das von Sysdig an die Cloud Native Computing Foundation (CNCF) übergeben wurde.

Falco ist im Wesentlichen eine Engine, die Syscalls im Linux-Kernel abhört, sie mit einer Engine und einem Regelsatz verarbeitet und Warnungen ausgibt, sobald eine Regel zutrifft. Diese Warnungen können über verschiedene Kanäle ausgegeben werden. Dieser Blogbeitrag ist der erste in einer zweiteiligen Reihe und erläutert die grundlegenden Konzepte zu Falco. Der zweite Blogbeitrag beschreibt die ersten Schritte mit Falco auf AKS und erklärt, wie man die Grundeinstellungen konfiguriert und den Standardregelsatz verwendet. Darüber hinaus bietet er Samples von Log Analytics Queries, die es Ihnen ermöglichen, sich über die aktuelle Umgebung zu informieren und die Falco-Regeln daran anzupassen. Den zweiten Blogbeitrag finden Sie hier.

Warum Sie Falco benötigen
Es gibt viele Ereignisse in einem Kubernetes-Cluster, die nicht typisch sind oder die eigentlich gar nicht vorkommen sollten. Je nach Umgebung gibt es möglicherweise bereits Mechanismen, die es den Betreibern ermöglichen, diese Ereignisse (z. B. über einen Proxy) zu steuern oder zu überwachen. Falco ermöglicht eine direkte Überwachung solcher Ereignisse innerhalb des Clusters. Folgende Ereignisse könnten auftreten (die vollständige Liste finden Sie hier):
 

• Ausgehende Verbindungen zu bestimmten IPs oder Domains
• Verwendung oder Mutation sensibler Dateien wie /etc/passwd
• Ausführung von System-Binaries wie su
• Rechteausweitung oder -änderung am Namespace
• Änderungen in bestimmten Ordnern wie /sbin

Ein Standard-Kubernetes-Cluster bietet keine Mechanismen zur Überwachung solcher Ereignisse, sodass ein Tool wie Falco erforderlich ist. Das Sichtbarmachen solcher Ereignisse innerhalb des Clusters ermöglicht es, Angriffe und potenziell böswilliges Verhalten zu erkennen und das betreffende Personal frühzeitig zu warnen.
 

Wie bei jedem anderem Tool gibt es natürlich auch hier Einschränkungen. Ein Supply-Chain-Angriff, der auf einem bösartigen Image basiert, löst zum Beispiel keines dieser Ereignisse aus. Eine Demonstration eines solchen Angriffs findet sich in diesem CNCF Community Talk.

Falco-Internals
Aus einer High-Level-Ansicht besteht Falco aus den folgenden Komponenten:

• Ereignisquellen (Treiber, Kubernetes Audit Events)
• Einer Rule Engine und einem Regelsatz
• Der Integration eines Ausgabesystems

Falco-Internals (vgl. Falco Docs, vertrieben unter CC BY 4.0).

Falco befindet sich direkt im Herzen eines Linux-Systems – dem Kernel. Es verwendet sogenannte Treiber zur Überwachung von anwendungsinduzierten Syscalls, sodass es alles überwachen kann, was zu einem Syscall führt. Da Container einen Kernel teilen, ist es möglich, Syscalls von allen Containern auf einem Host zu überwachen. Dies ist bei isolierteren Container-Hosts, die nicht auf der gemeinsamen Nutzung eines Kernels basieren und eine andere Laufzeit verwenden (zum Beispiel Kata-Container) nicht möglich. Falco unterstützt drei Arten von Treibern: Kernel-Module, eBPF-Probes und Userspace-Instrumentierung:

• Kernel-Module (der Standard): Ein Kernel-Modul, das für den Kernel kompiliert werden muss, auf dem Falco ausgeführt wird.
• eBPF-Probes: Es muss kein Kernel-Modul geladen werden, allerdings benötigt es einen neueren Kernel, der eBPF unterstützt. Wird von vielen verwalteten Diensten nicht unterstützt.
• Userspace-Instrumentierung: Läuft komplett im Userspace, allerdings gibt es derzeit keine unterstützte Implementierung einer Userspace-Instrumentierung.

Weiterführende Informationen finden Sie in diesem Blogbeitrag auf der Falco-Homepage. Zusätzlich zu den Treibern können auch Kubernetes Audit Events mit Falco verknüpft werden. Dies wird über Auditrichtlinien und einen Webhook umgesetzt.

Zusammenfassung: Alle Treiber fangen Syscalls (durch verschiedene Techniken) ab und stellen sie der Falco Rule Engine zur Verfügung. Die Rule Engine wird mit einem Regelsatz konfiguriert. Der Regelsatz enthält Bedingungen, die mit zuvor definierten Ereignissen übereinstimmen, z. B. Shell Spawning. Jedes Mal, wenn eine Übereinstimmung mit einer Regel festgestellt wird, generiert Falco eine Warnung und gibt sie an das konfigurierte Ausgabesystem ab. Das Falco-Projekt verfügt über einen grundlegenden Regelsatz mit vielen nützlichen Regeln und ist auf GitHub verfügbar.

Obwohl Falco eine cloudnative Threat Detection Engine ist, ist sie direkt in den Linux-Kernel integriert und kann daher auch für Nicht-Container-Hosts verwendet werden.

Verarbeitung von Falco-Logs mit einem Logsystem

Falco unterstützt generierte Warnungen für eine Vielzahl von Ausgabekanälen. Dazu gehören u. a. stdout, gRPC, syslog und Dateien. Eine komplette Liste der unterstützten Schnittstellen/Systeme finden Sie in der Dokumentation. Diese Flexibilität ermöglicht viele unterschiedliche Integrationsmuster, zum Beispiel in bestehende Logsysteme. Beispiele dafür sind:

• Mit einem Sidecar-Container, der die dateibasierten Protokolle von Falco in einem freigegebenen Verzeichnis analysiert und aufgliedert und an das Logsystem weiterleitet.
• Der Log-Agent auf dem Cluster-Knoten leitet die stdout-Protokolle von Falco direkt an das Logsystem weiter (Spoiler: Blogbeitrag 2 verwendet dieses Muster).
• Jeder Host ist bereits mit einem Log-System-Agent ausgestattet, der das syslog liest und weiterleitet. Daher kann Falco seine Protokolle direkt in syslog aufnehmen.

Allerdings ist jede Integration anders und hängt von den jeweils bestehenden Setups ab. Es ist auch möglich, Falco so zu konfigurieren, dass Warnungen im JSON-Format ausgegeben werden. Dies ist äusserst hilfreich und ermöglicht es dem Logsystem, die Protokolle abzufragen, ohne jeden Eintrag analysieren und aufgliedern zu müssen.

Falco installieren
Das Falco-Projekt unterstützt verschiedene Möglichkeiten der Installation. Der für Kubernetes empfohlene Weg besteht darin, Falco direkt auf dem Host zu installieren (beispielsweise über ein APT Repository) und es als systemd-Dienst auszuführen. Dies ermöglicht eine saubere Trennung zwischen dem mit Berechtigungen ausgestatteten Teil von Falco und einem schreibgeschützten Agent, der als Container ausgeführt wird. Wenn benutzerdefinierte Host-Images nicht unterstützt werden, ist dies allerdings nicht möglich (z. B. bei einigen verwalteten Diensten). AKS ist solch ein Beispiel. Für solche Fälle gibt es Installationsverfahren von Drittanbietern, beispielsweise über Helm. Dies wird in der Dokumentation beschrieben.

Beachten Sie, dass Falco je nach gewähltem Treiber und Installationstyp unterschiedliche Laufzeitrechte erfordern kann. Der Helm-Chart beispielsweise führt den Falco-Container mit «privileged: true» aus, da er für die Installation des Kernel-Moduls auf dem Host benötigt wird. Abhängig von den jeweiligen Sicherheitsanforderungen ist dies möglicherweise nicht tolerierbar – und es wird auch nicht empfohlen.

Zusammenfassung
Falco ist ein grossartiges Tool zur Überwachung eines Kubernetes-Clusters und bietet tiefe Einblicke in den Cluster. Dadurch kann es eine wertvolle Bereicherung für Ihre Umgebung sein. Wie bei jedem Tool ist ein gewisser Anfangsaufwand erforderlich, um Falco richtig einzurichten und zu konfigurieren. Insbesondere die Anpassung an die Zielumgebung kann sehr zeitaufwendig sein, ebenso wie das Einarbeiten in die Sprache der Regelspezifikation. Im zweiten Blogbeitrag finden Sie grundlegende Informationen dazu, wie Sie Falco auf AKS installieren, wie Sie es einrichten und wie sich Ihre Umgebung verhält.

Weitere Informationen zu unseren Cloud-Lösungen finden Sie hier.