Bomfather Agent

Bomfather Agent ist ein eBPF-basierter Agent, der im Kernel-Space läuft, um Aktionen basierend auf einer Policy zu blockieren.

Wir haben diesen Agenten entwickelt, um die Probleme zu lösen, die wir mit bestehenden Lösungen hatten.

1. Sie waren zu komplex einzurichten und zu verwenden.
2. Sie waren zu langsam und ineffizient.
3. Und selbst wenn sie einfach einzurichten waren, waren sie nicht sicher und/oder flexibel genug, um für eine Vielzahl von Anwendungsfällen zu funktionieren.

Diese Punkte sind unser Nordstern für dieses gesamte Projekt. Alle Funktionen und Entwicklungen sollen diese Punkte erfüllen.

Beachte, dass wir versuchen, die Verwendung von KI-generiertem Code in diesem Repo zu vermeiden, und keine KI-generierten PRs akzeptieren werden.

Funktionen

• Einfach zu verwenden: Alles, was du brauchst, ist ein LSM-fähiger Kernel. Du installierst den Agenten, erstellst eine 5- bis 10-zeilige Policy-Datei, startest den Agenten, und schon kann es losgehen.
• Standardmäßige Deny-All-Policy: Wenn eine Einschränkung angewendet wird (z. B. einem Prozess wird erlaubt, eine Datei zu lesen), wird sie auf alle Prozesse angewendet, und nur auf der Whitelist stehende Prozesse dürfen die Einschränkung umgehen.
• Durchsetzung von Richtlinien auf Basis von Executables: Fast die gesamte Policy basiert auf einem Executable und darauf, auf welche Ressourcen (z. B. Dateien, GPUs, Netzwerk usw.) es zugreifen kann.
• Schnell und effizient: Der Agent läuft im Kernel-Space und verwendet eBPF- und LSM-Hooks, um die Policy durchzusetzen, was deutlich effizienter ist als Userspace-Tools wie strace.

Voraussetzungen

(Hier ist eine Anleitung, wie du LSM auf deinem System aktivierst: https://docs.bomfather.dev/prerequisites)

• Linux-Kernel 5.18 oder höher
• LSM auf dem System aktiviert

Installation

Aus dem Quellcode

Um aus dem Quellcode zu bauen, müssen die folgenden Tools installiert sein:

go 1.26 or higher
make
clang
llvm
llvm-14
protobuf-compiler
git

Unter Debian/Ubuntu kannst du die Nicht-Go-Build-Abhängigkeiten mit folgendem Befehl installieren:

apt-get update \
  && apt-get install -y --no-install-recommends \
    clang \
    llvm \
    llvm-14 \
    protobuf-compiler \
  && rm -rf /var/lib/apt/lists/*

Dann baue den Agenten mit:

make

Schnellstart

Für einen schnellen Start kannst du den folgenden Befehl verwenden, um den Agenten mit einer Standard-Policy auszuführen:

sudo ./agent run --config config.yaml

Dies führt den Agenten mit der Policy aus, die in der Konfigurationsdatei definiert ist.

Optional kannst du dann den folgenden Befehl verwenden, um den Status des Agenten anzuzeigen:

sudo ./agent status --help

Der status-Befehl dient in erster Linie zum Auslesen von Prometheus-Metriken vom Agenten.

Wie man eine Policy erstellt

Eine Policy ist eine YAML-Datei, die die Regeln definiert, die der Agent durchsetzt.

Die Konfiguration besteht hauptsächlich aus zwei Abschnitten: policies und attributes. Der Abschnitt policies definiert, wer auf eine geschützte Ressource zugreifen darf. Der Abschnitt policies definiert, welche Executables auf geschützte Verzeichnisse oder IPs zugreifen dürfen. attributes definieren die Grenzen eines Executables, sodass ein Attribut ein Executable dazu bringen kann, sich nur mit einer einzigen IP zu verbinden und es daran hindert, sich mit einer anderen IP zu verbinden.

Es gibt viele Möglichkeiten, eine Policy zu erstellen. Für jede Funktion haben wir einen eigenen Abschnitt in der Dokumentation, der erklärt, wie man eine Policy für diese Funktion erstellt: https://docs.bomfather.dev/configuration-guide.

Für einen Schnellstart-Anwendungsfall kannst du jedoch die folgende Policy-Datei verwenden:

policies:
  - executable: "filepath = [absolute-path]/app/signer"
    can_access_dirs:
      - "[absolute-path]/secrets/keys : read"
    is_allowed_to_access_ip:
      - "kms.us-east-1.amazonaws.com:443"

attributes:
  - path: "type = executable | filepath = [absolute-path]/app/signer"
    can_only_access_ips:
      - "kms.us-east-1.amazonaws.com:443"

Diese Policy ermöglicht es uns, den Signer zu sandboxen und sicherzustellen, dass er der einzige Prozess auf dem System ist, der auf die Daten zugreifen kann.

Im Abschnitt policies definieren wir, dass das Executable signer der einzige Prozess ist, der auf das Verzeichnis /secrets/keys und die IPs zugreifen darf, die mit dem AWS-KMS-Endpunkt verbunden sind.

Im Abschnitt attributes definieren wir, dass das Executable signer nur auf den AWS-KMS-Endpunkt und keine anderen IPs zugreifen darf.

Mit dieser relativ einfachen Konfiguration konnten wir unseren Signer-Prozess (der in der realen Welt Teil eines größeren Systems sein könnte) erheblich härten – mit einer Konfiguration, die nur 10 Zeilen lang ist.

Es gibt noch ein paar weitere praxisnahe Beispiele in der Dokumentation https://docs.bomfather.dev/examples/gpu.

API-Schlüssel

Optional kannst du, wenn du die vom Agenten erkannten Verstöße exportieren möchtest, einen API-Schlüssel angeben, und der Agent sendet die Verstöße an die Bomfather-Server.

Aber am wichtigsten: DIES IST NICHT VERPFLICHTEND, der Agent funktioniert auch ohne ihn auf die gleiche Weise. Es werden keine Funktionen deaktiviert, wenn du keinen API-Schlüssel angibst, und wenn kein API-Schlüssel angegeben ist, werden keinerlei Daten an die Bomfather-Server gesendet.

Wenn du die Bomfather-Server nutzen möchtest, kontaktiere uns bitte unter [email protected].