eBPF-Sicherheit unter Linux 2026: Runtime-Schutz mit Tetragon, Falco und Tracee
Tetragon, Falco und Tracee im Praxisvergleich: eBPF-Runtime-Schutz mit LSM-Enforcement, TracingPolicy-Beispielen, Kernel-Voraussetzungen und Overhead-Messungen fuer Linux-Produktionsumgebungen 2026.
eBPF-Sicherheit unter Linux bezeichnet das Einsetzen von im Kernel laufenden, verifizierten Sandbox-Programmen, um Syscalls, Prozessstarts, Datei- und Netzwerkzugriffe in Echtzeit zu beobachten und – im Fall von Tetragon – noch vor Rückkehr des Syscalls durch LSM-Hooks zu blockieren. Für 2026 sind drei Open-Source-Werkzeuge relevant: Falco (Detection, CNCF Graduated), Tetragon (Detection plus in-kernel Enforcement) und Tracee (Detection plus forensische Artefakt-Erfassung). Dieser Leitfaden zeigt, welches Werkzeug welche Rolle spielt, wie die Kernel-Voraussetzungen aussehen und wie eine belastbare Produktionsarchitektur aufgebaut wird.
Falco erkennt und alarmiert, blockiert aber nicht – ideal für breite Detection-Coverage mit geringer Betriebslast.
Tetragon ist das einzige Open-Source-eBPF-Werkzeug mit synchronem SIGKILL-Enforcement über BPF-LSM-Hooks – wirksam gegen TOCTOU-Races bei Syscall-Argumenten.
Tracee erfasst pro Event ausführbare Binaries, Speicherregionen und Netzwerkverkehr – erste Wahl für Incident Response und Supply-Chain-Analysen.
Für BTF und CO-RE wird Kernel 5.8 vorausgesetzt; produktiv empfehle ich mindestens 6.1 LTS, da BPF-LSM erst dort stabil einsetzbar ist.
Ein Hybrid-Deployment aus Falco (breite Regelbasis) und Tetragon (fokussierte Enforcement-Policies) hält den kombinierten Overhead unter etwa 3 % auf typischen Nodes.
eBPF-Sensoren vertrauen dem Kernel als Beobachter – ein kompromittiertes Kernelmodul kann sie blind machen, daher gehört Kernel-Lockdown und Signierung immer dazu.
Warum eBPF zur Basis moderner Linux-Runtime-Sicherheit wurde
Extended BPF ist heute die Standard-Sensorbasis für sicherheitsrelevante Kernel-Instrumentierung, weil es drei zuvor unvereinbare Eigenschaften vereint: sichere Ausführung im Kernel (verifizierte Programme, Bounds-Checks, keine unbeschränkten Loops), messbar geringer Overhead (JIT-kompiliert, 1–5 % typisch statt zweistelliger Werte bei klassischen Kernelmodulen) und Portabilität durch CO-RE (Compile Once, Run Everywhere), sodass Programme auf verschiedenen Kernel-Versionen ohne Neubau laufen. Details zur Architektur beschreibt die Übersicht der eBPF Foundation.
Was mich als Kernel-Ingenieurin überzeugt hat, war weniger die Performance als die Beobachtungsposition. Ein User-Space-Agent sieht Ereignisse erst nach Rückkehr des Syscalls; ein eBPF-Programm sieht sie an der Quelle. Für Detection bedeutet das kaum blinde Flecken; für Enforcement bedeutet es, dass eine Policy den Prozess töten kann, bevor der schadhafte execve überhaupt Register zurückschreibt. Die alten Muster – auditd-Ströme in einen User-Space-Parser, dann Reaktion per Cron – waren gegen ephemere Container-Workloads schlicht zu langsam und zu grob. Mit eBPF sind Erkennungs- und Reaktionsgrenzen so eng aneinander, dass die klassische Race zwischen Alarm und Angreiferaktion verschwindet.
Zwischen Kernel 5.8 (BTF stabil) und 6.6 LTS ist die für Sicherheitswerkzeuge nutzbare Fläche massiv gewachsen: BPF_PROG_TYPE_LSM, signierte eBPF-Programme, ein deutlich verbesserter Verifier und Ringpuffer statt Perf-Buffer haben die Werkzeugklasse produktionsreif gemacht.
Was ist der Unterschied zwischen Tetragon, Falco und Tracee?
Alle drei Werkzeuge beobachten über eBPF, aber sie unterscheiden sich in ihrer Schwerpunktsetzung. Falco ist der Detection-Standard mit dem größten Ökosystem und der einfachsten Regelbasis; es alarmiert, aber blockiert nicht. Tetragon kommt aus dem Cilium-Umfeld (heute Cisco/Isovalent) und ist das einzige Werkzeug, das synchron im Kernel eingreifen kann – über LSM-Hooks und die Aktion Sigkill. Tracee stammt von Aqua Security und ist auf Forensik zugeschnitten: Es erfasst pro Ereignis Binaries, Speicherregionen und Netzverkehr, was es zu meiner ersten Wahl in Incident-Response-Sets macht.
Merkmal
Falco
Tetragon
Tracee
Herkunft / Governance
Sysdig, CNCF Graduated (2024)
Isovalent/Cisco, Cilium-Ökosystem
Aqua Security
Primärer Fokus
Detection und Alerting
Detection und in-kernel Enforcement
Detection und forensische Erfassung
Blockieren im Kernel
Nein (nur Alarm)
Ja, SIGKILL via LSM/kprobe
Nein (nur Alarm)
Regelsprache
Falco-Rules (YAML/DSL)
TracingPolicy (Kubernetes CR)
Rego (OPA) oder Go-Signaturen
Mindest-Kernel für BTF/CO-RE
5.8 (Fallback: Kernelmodul)
5.8, praktisch 6.1+
5.8
Typischer CPU-Overhead
1–3 %
< 1–3 %
2–8 %
Stärke
Größter Regelkatalog
Prävention, nicht nur Erkennung
Artefakt-Erfassung für IR
Diese Aufteilung entspricht auch dem, was ich in Produktionsclustern sehe: Falco für breite Coverage, Tetragon für einzelne, präzise Enforcement-Pfade, Tracee als forensischer Zweitagent, wenn ein Alarm losgeht. Wer Container härtet, findet einen praxisnahen Einstieg in unserem Leitfaden zur Container-Härtung mit Falco.
Kernel-Voraussetzungen: BTF, CO-RE und BPF-LSM
Für CO-RE benötigen die eBPF-Programme BTF-Debuginformationen im laufenden Kernel. Diese sind seit 5.8 stabil und in praktisch allen Distributionskerneln von RHEL 9.2+, Ubuntu 22.04+ und Debian 12 aktiviert. Prüfen lässt sich das mit einem Blick auf /sys/kernel/btf/vmlinux:
Für Tetragons LSM-basiertes Enforcement muss CONFIG_BPF_LSM=y gesetzt und BPF in der aktiven LSM-Liste enthalten sein. Auf Debian/Ubuntu-Systemen ergänzt man dazu die Kernel-Cmdline und prüft anschließend:
Für Details zur Interaktion zwischen LSM-Frameworks empfehle ich unseren Vergleich SELinux vs AppArmor 2026. Wichtig: BPF-LSM ergänzt SELinux oder AppArmor, es ersetzt sie nicht. Die Hooks laufen additiv; ein Deny einer beliebigen LSM setzt sich durch.
Falco einrichten: Detection ohne Enforcement
Für Bare-Metal- und VM-Hosts ist die native Paketinstallation nach wie vor der stabilste Weg. Falco 0.39 (Mai 2026) nutzt standardmäßig den modernen eBPF-Treiber und benötigt keine externen Kernel-Header mehr. Die Installation auf Debian/Ubuntu:
Eine typische Regel zur Erkennung interaktiver Shells in Containern demonstriert die Rule-DSL:
# /etc/falco/rules.d/interactive_shell.yaml
- rule: Shell in Container gestartet
desc: Interaktive Shell innerhalb eines Container-PID-Namespace
condition: >
spawned_process and container and shell_procs
and proc.tty != 0 and not user_expected_shell
output: >
Interaktive Shell in Container (user=%user.name container=%container.id
shell=%proc.name parent=%proc.pname cmd=%proc.cmdline)
priority: WARNING
tags: [container, shell, mitre_execution]
- macro: user_expected_shell
condition: proc.pname in (docker-entrypoint, kubectl-exec)
Die vollständige Regelsprache samt Priority- und Output-Feldern dokumentiert die offizielle Falco Rules Reference. Wichtig für Produktion: priority steuert die spätere Weiterverarbeitung im Alerting-Pfad (Falcosidekick, Loki, SIEM), und der output-String sollte konsistente Feldnamen benutzen, damit Downstream-Parser wie Vector oder Fluent Bit sie ohne Sonderfälle in JSON umsetzen können.
Falco erkennt und meldet – aber es tötet keinen Prozess. Wer aktives Blockieren möchte, greift zu Falco Talon als separatem Response-Engine, das per Regel Container isolieren oder kill-Aktionen auslösen kann. Der Preis ist eine User-Space-Roundtrip: zwischen Alarm und Kill liegen typischerweise 40–200 ms – für Massen-Alerts akzeptabel, für gezielte Angriffe auf sensible Pfade zu langsam. Genau hier setzt Tetragon an.
Tetragon-TracingPolicy schreiben: Enforcement im Kernel
Tetragon 1.4 (Juni 2026) verwaltet Policies als Kubernetes-CustomResources, läuft aber ebenso auf Bare-Metal-Hosts über das Kommando tetragon --tracing-policy-dir. Eine TracingPolicy beschreibt einen Hook-Punkt (kprobe, uprobe, tracepoint oder LSM-Hook), Selektoren zur In-Kernel-Filterung und optional eine Aktion.
Das folgende Beispiel schützt /etc/shadow vor Lesezugriffen durch andere Prozesse als sshd und login. Es benutzt den LSM-Hook file_open, der TOCTOU-Races vermeidet, weil er nach dem Kopieren des Dateipfads in den Kernelspace greift:
Der Zugriff wird nicht nur gemeldet, sondern der auslösende Prozess erhält SIGKILL innerhalb desselben Syscalls. Kein Race, keine erfolgreiche Leseoperation. Die vollständige Feldreferenz beschreibt die Tetragon TracingPolicy-Dokumentation.
Warum LSM-Hooks statt kprobes für sicherheitskritische Enforcement-Pfade? Ein kprobe auf sys_openat greift, bevor der Pfad-String aus dem User-Space kopiert ist – ein Angreifer kann in einem parallelen Thread den Speicher zwischen Prüfung und Verwendung ändern (Time-of-Check-to-Time-of-Use). LSM-Hooks sitzen an definierten Punkten nach dem Kopiervorgang und operieren auf kernel-residenten Datenstrukturen. Für die Prüfung gefährlicher Argumente ist das die einzige rennsichere Position.
Eine zweite, in Produktion sehr nützliche Policy: das Verhindern von Container-Escape über schreibbare Bind-Mounts:
Der Selektor filtert direkt im Kernel: nur Mounts vom Typ proc oder cgroup innerhalb der Kubelet-Pod-Verzeichnisse lösen aus. In Ring-Buffer-Metriken bleibt der User-Space davon unberührt – das ist der Hebel, warum Tetragon selbst bei tausenden aktiven Selektoren wenig CPU verbraucht.
Tracee für Forensik und Supply-Chain-Untersuchungen
Tracee 0.24 (Q2 2026) ist auf Detection plus Erfassung ausgelegt. Wo Falco eine Zeile schreibt und Tetragon einen Prozess tötet, packt Tracee auf Wunsch das ausgeführte Binary, die ELF-Sektionen, ggf. den Anonymous-Mapping-Speicher und die zugehörigen Netzwerkflows in einen Artefakt-Ordner. Für Supply-Chain-Untersuchungen – etwa bei einem Fund wie xz-utils CVE-2024-3094 – ist das genau die Datenbasis, die man später braucht.
Eine gezielte Signatur für dynamisch nachgeladenen Code:
Das --capture-Flag ist entscheidend: es persistiert das ausgeführte Binary sowie Speicherregionen mit gesetztem PROT_EXEC | PROT_WRITE (klassischer W^X-Verstoß, den seriöse Anwendungen nicht produzieren). Für Reverse Engineering hat der Responder damit direkt eine untersuchbare Datei statt einer Log-Zeile.
Die eingebauten Signaturen decken u. a. Anti-Debugging, LD_PRELOAD-Injection, Ptrace-Manipulation, Kernel-Modul-Load und Container-Escape ab. Eigene Signaturen lassen sich in Rego oder Go schreiben – Rego, weil Aqua auf die gleiche Sprache wie Open Policy Agent setzt. Für kritische Hosts läuft Tracee bei mir im Detection-Modus dauerhaft, mit engem Event-Set und deaktiviertem --capture; erst wenn eine korrelierte Detection-Kette losgeht, wird die Capture-Konfiguration temporär aktiviert.
Wie viel Overhead verursachen eBPF-Sicherheitswerkzeuge?
Der Overhead skaliert mit Event-Volumen und aktiver Regelanzahl, nicht mit Node-Größe. Aus meinen Messungen und öffentlich verfügbaren Benchmarks (u. a. SciTePress 2025, „Comparative Analysis of eBPF-Based Runtime Security Monitoring") ergeben sich folgende Richtwerte auf einem 8-Core-Node mit gemischten Web- und DB-Workloads:
Falco mit dem Standardregelkatalog: 1–3 % CPU, ~ 120 MB RSS. Skaliert linear mit Event-Rate.
Tetragon mit ~ 20 aktiven TracingPolicies: unter 1 % CPU auf ruhigen Nodes, 1–3 % bei hoher Syscall-Aktivität. Der Grund ist die kernel-seitige Selektor-Auswertung, die den Ringbuffer schont.
Tracee im breiten Detection-Modus: 2–4 % CPU, im Capture-Modus 4–8 %, im Extremfall (viele executable memory events) deutlich höher.
Die Faustregel für Kapazitätsplanung: Detection-only mit Falco kostet weniger als eine Log-Aggregations-Pipeline. Enforcement mit Tetragon kostet unter 1 %, solange die Selektoren scharf gehalten werden. Tracee sollte auf produktive Nodes fokussiert eingesetzt werden – dauerhaftes Capture ist teurer als ein zusätzlicher Auditd-Stream.
Grenzen des Sicherheitsmodells: Was eBPF nicht sieht
Öffentlich dokumentierte Techniken zeigen, dass Rootkits eBPF-basierte Observability blenden können, indem sie die zurückgegebenen Ringbuffer-Einträge filtern oder Prozessnamen im task_struct in-place tauschen. Für die Praxis heißt das: eBPF-Werkzeuge sind ein starkes, aber nicht das letzte Layer. Ergänzt gehören:
Kernel Lockdown im confidentiality-Modus, damit unsignierte Module gar nicht erst geladen werden.
UEFI Secure Boot plus Shim, sodass die Kernel-Chain of Trust unterhalb der eBPF-Ebene abgesichert ist – Details dazu in unserem Leitfaden zur Boot-Chain-Sicherheit und systemd-Härtung.
Externe Telemetrie: SSH-Session-Recording, Netzwerk-Flow-Logs, unabhängige Auditd-Aggregation. Wer nur eBPF hat, hat einen Single Point of Failure gebaut.
Zusätzlich empfehle ich, den Kernel dem Auditor-Prinzip folgend regelmäßig zu aktualisieren: Der eBPF-Verifier selbst hatte 2024 und 2025 mehrere ausgenutzte Bugs (u. a. CVE-2024-1086, out-of-bounds write via nf_tables, mit eBPF-Hilfe eskaliert). Ein aktueller LTS-Kernel ist Voraussetzung, kein Nice-to-have.
Produktionsarchitektur: Hybrid-Deployment in der Praxis
Nach mehreren Rollouts hat sich für mich folgende Schichtung bewährt und liegt in Overhead und Ergonomie deutlich vor Einzeltool-Ansätzen:
Falco als Basis-Detection-Layer auf jedem Node. Standardregelkatalog aktiv, plus 10–20 organisationsspezifische Regeln. Ausgabe an Falcosidekick, von dort in das SIEM.
Tetragon mit einer engen Enforcement-Policy-Bibliothek: Schutz sensibler Dateien (/etc/shadow, private Schlüssel), Verhinderung verdächtiger Mounts, Blockade von modprobe und insmod für nicht privilegierte UIDs. Keine breite Detection-Coverage – dafür ist Falco zuständig.
Tracee als On-Demand-Forensik-Agent. Standardmäßig nur Detection, Capture wird über eine SOAR-Playbook-Regel bei bestimmten Falco- oder Tetragon-Events aktiviert.
Diese Trennung hält den kombinierten Overhead in meinen Messungen unter 3 % CPU, deckt aber Detection, Prevention und forensische Erfassung ab. Wichtig ist die klare Zuständigkeit pro Werkzeug: Doppelte Regeln in Falco und Tetragon führen zu widersprüchlichen Alarmen und erhöhen den Ringbuffer-Druck ohne Sicherheitsgewinn.
Für Auditing und Compliance sind die Falco-Alerts und Tetragon-Events maschinenlesbar – wer bereits mit CIS-Benchmarks arbeitet, kombiniert das gut mit den Verfahren aus dem Leitfaden zu CIS-Benchmark-Scans mit OpenSCAP.
Häufig gestellte Fragen
Kann Falco Prozesse blockieren?
Nein, Falco erkennt und alarmiert, blockiert aber nicht direkt. Für aktives Eingreifen gibt es die separate Komponente Falco Talon, die im User-Space auf Alarme reagiert und Aktionen wie Container-Isolation oder Prozessbeendigung ausführt. In-Kernel-Enforcement leistet nur Tetragon.
Welche Kernel-Version wird für Tetragon-Enforcement benötigt?
Für reine Detection reicht Kernel 5.8 mit BTF-Support. Für LSM-basiertes Enforcement mit Sigkill ist Kernel 5.13 die technische Untergrenze, produktiv empfehle ich Kernel 6.1 LTS oder neuer, damit CONFIG_BPF_LSM plus signierte eBPF-Programme durchgängig verfügbar sind.
Ist eBPF für den produktiven Einsatz sicher?
Ja, unter der Voraussetzung eines aktuellen Kernels. Der Verifier verhindert Kernel-Crashes durch geladene Programme, und Programme laufen in einer Sandbox mit begrenztem Kontext. Bekannte Verifier-CVEs (z. B. CVE-2024-1086) sind in LTS-Kerneln gefixt; ein LTS-Rollout ist zwingend.
Kann ich SELinux oder AppArmor durch BPF-LSM ersetzen?
Nein, und das ist nicht der Zweck. BPF-LSM ergänzt bestehende Major-LSMs additiv – ein Deny einer beliebigen LSM entscheidet. Für breite MAC-Coverage bleibt SELinux oder AppArmor die Basis, BPF-LSM adressiert punktgenaue, dynamisch ladbare Regeln.
Wie viel Overhead verursacht eine typische Falco-plus-Tetragon-Installation?
In meinen Messungen bleibt die Kombination unter 3 % CPU auf einem 8-Core-Node mit gemischtem Workload, sofern Tetragon-Policies mit scharfen Selektoren geschrieben sind. Der Speicherbedarf liegt bei etwa 150–200 MB RSS gesamt.
Welches MAC-Framework härtet Linux 2026 besser? Direkter Vergleich von SELinux und AppArmor mit Konfigurationsbeispielen, Container-Integration, Performance-Daten und Compliance-Empfehlungen für RHEL, Ubuntu und Kubernetes.
Praxisleitfaden zur Absicherung der Linux-Boot-Chain mit UEFI Secure Boot, TPM 2.0 und UKIs sowie zur systematischen Härtung von systemd-Services. Mit Konfigurationsbeispielen, Audit-Skripten und CI/CD-Integration.
