Anomalieerkennung mit Falco

Für den Betrieb der NETWAYS Cloud und unserer anderen Services setzen wir auf Container und Kubernetes. Dieser Ansatz ermöglicht uns unter anderem eine saubere Trennung verschiedener Microservices auf demselben Hypervisor und den Betrieb mandantenfähiger SaaS-Lösungen.
Doch diese Architektur sorgt auch für neue Angriffsflächen, bspw. aus Containern heraus.
Softwarelösungen wie Falco, ein Graduated CNCF Project, können hier Abhilfe schaffen: Falco überwacht Datenquellen wie den Kernel oder Kubernetes‘ Auditlogs in Echtzeit und schlägt Alarm, wenn etwas Verdächtiges passiert.

Falco: Der Bewegungsmelder auf unseren Systemen

Falco sitzt bei uns im Rechenzentrum als Docker-Container auf jedem Hypervisor und liest auf Kernelebene zuvor definierte Events mit. Möglich macht das Falcos Architektur: Je nach Zielsystem nutzt die Software entweder ein Kernelmodul oder eine sog. eBPF-Probe, die im Kernel des Systems installiert wird und die Kommunikation mit dem Agenten im Userspace ermöglicht.

Wird anhand der vordefinierten oder eigens hinzugefügten Regeln ein zu protokollierendes Event bemerkt, schreibt Falco dieses in seinem Container nach stdout. Hier können wir es dann mit Fluent Bit einsammeln und zu Auditzwecken in unser OpenSearch-Backend schreiben.

Doch welche Events werden von Falco erfasst und führen zu einer Alarmierung? Und wie formuliert man weitere Regeln? Hierfür stellt die Software ihr eigenes Konfigurationsformat bereit.

Falco Rules und Condition Syntax

Falcos Konfiguration geschieht über eine oder mehrere Konfigurationsdateien im YAML-Format. Diese können Makros, Rules, Overrides und Exceptions beinhalten, die in der Condition Syntax des Projekts geschrieben werden.

Eine beispielhafte Regel lässt sich in der offiziellen Dokumentation finden:

- 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

- 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

Das Beispiel beinhaltet die zwingend notwendigen Felder rule, desc, condition, output und priority. Jede Falco-Rule besteht aus diesen (und optional weiteren) Feldern, um das Verhalten der Regel und die zu überwachenden Events zu definieren.

Je nach zu überwachendem Event werden von Falco verschiedene Parameter und Attribute mit Informationen zum beobachteten Event zur Verfügung gestellt, bspw. proc.name, container.id oder evt.type. Diese Attribute können auch im Output wiederaufgegriffen und somit für Auditierung und Benachrichtigung von Events genutzt werden.

Die beobachteten Attribute und Anreicherung der Events geschieht durch das vom Falco-Agent genutzte Kernelmodul bzw. eBPF-Probe. Beide Architekturen erlauben es dem Agenten, auf syscall-Ebene „zuzuschauen“, was andere Prozesse auf dem System anstellen. Diese Beobachtungen können dann mit den definierten Regeln abgeglichen werden.

Die condition des obigen Beispiels bedeutet bspw. nichts anderes als:

• evt.type = execve – Der beobachtete syscall ist execve
• evt.dir = < – Der beobachtete syscall ist vollständig abgearbeitet
• container.id != host – Der beobachtete syscall stammt aus einem Container
• (proc.name = bash or proc.name = ksh) – der beobachtete syscall spawnt einen Prozess namens bash oder ksh

Zusätzlich können diese logischen Abfragen wie im Beispiel noch verundet/odert und gruppiert werden. So lassen sich beliebig komplexe Regeln für verschiedene Szenarien schreiben, um bspw. unsere Cloudplattform auf dem Hypervisor-Level ordentlich auf Anomalien zu überwachen.
Eine ganze Bandbreite an sinnvollen Regeln im Kontext von Containern, Kubernetes, und Linuxservern allgemein liefert Falco dabei von Haus aus mit.

Aktion und Reaktion: Sidekick und Talon

Für unseren hauptsächlichen Beweggrund für den Einsatz von Falco – Auditierbarkeit von Events in unserer Infrastruktur – reicht das oben beschriebene Setup bereits aus. Falco liefert die meisten Regeln bei der Installation mit, den Rest ergänzen oder passen wir an, und im Betrieb schreibt Fluent Bit die beobachteten Events in unser OpenSearch.

Doch was ist, wenn man auf Events anders oder unmittelbarer reagieren möchte? Hierfür stellt das Falco-Projekt Begleitsoftware zur Verfügung:

• Falco Sidekick: Ein Notificationdaemon für Falco, der Events an über 50 unterstützte Dienste verschicken kann, von Slack bis zu SMS.
• Falco Talon: Eine Reaction Engine für Falco, die entweder an die Software selbst oder an den Sidekick angeschlossen werden kann.

Sidekick ist vor allem dann sinnvoll, wenn man anders als in unserem Setup mehrere Destinationen für Events hat: Sidekick könnte Events bspw. zeitgleich an ein Speicherbackend wie OpenSearch oder Loki weiterleiten, via Webhook eine Nachricht in einem Slack- oder Teamschannel erstellen, und dem diensthabenden On-Call-Kollegen eine SMS zukommen lassen.

Talon versetzt ein Falcosetup hingegen in die Lage, aktiv auf beobachtete Events zu reagieren. Das Tool befindet sich noch in einer frühen Phase seiner Entwicklung und einige Features fehlen sicherlich noch, doch ist es bereits in der Lage, in Kubernetes-Umgebungen bspw. Pods zu terminieren, Networkpolicies zu erstellen, oder Serverless Functions in Public Cloud-Umgebungen auszulösen.

„Einfach loslegen“ mit Falco

Im Gegensatz zu anderen Lösungen im Bereich Echtzeiterkennung von Anomalien oder Sicherheitsrisiken wie bspw. Tetragon bietet Falco einen nicht zu unterschätzenden Vorteil: Du kannst einfach loslegen:

Dank Softwarepaketen für verschiedene Linuxdistributionen, Containerimages und Helmchart lässt sich das Sicherheitstool auch in heterogenen Umgebungen ohne großen Aufwand installieren. Der mitgelieferte Regelkatalog für eine Vielzahl an unterstützten Event hilft bei den ersten Schritten und kann bei Bedarf angepasst, erweitert oder überschrieben werden. Und dank eines kleinen Ökosystems mit Tools wie Sidekick oder Talon musst du das Rad nicht neu erfinden, nur um Events nach deinen Vorstellungen verarbeiten zu können oder um sogar proaktiv auf diese zu reagieren.

Natürlich bedeutet das nicht, dass Falco die einzige oder naheliegendste Lösung für sämtliche denkbaren Szenarien ist. Wir haben uns für die Überwachung unserer Infrastruktur für Falco entschieden, um mit einem relativ kleinen Team und ohne viel spezifisches Wissen zum Linuxkernel und syscalls dennoch schnell loslegen zu können.

Hat man mehr Zeit, Knowhow und Ressourcen zur Verfügung, kann aber auch Tetragon einen Blick wert sein, das ebenfalls auf eBPF basiert und feingranularer konfigurierbar ist. So erhält man mächtigere Möglichkeiten für Reaktionen und proaktives Handeln, auf Kosten allgemeingültiger Regeln und einfacher Konfiguration.
Doch das ist ein Thema für einen zukünftigen Blogpost.