Kernel-Layer Execution Blocking: Sicherung von Edge-Hardware-Gateways mit eBPF und Tetragon

Bis ein Security-Agent im Userspace eine Privilegienerweiterung auf einem Edge-Knoten erkennt, hat der Angreifer bereits die Kontrolle über die Hardware. Dieser Beitrag zeigt, wie eBPF-basierte Tools wie Cilium Tetragon Systemaufrufe direkt im Kernel abfangen und beenden — noch bevor sie physischen I/O beeinflussen.

Physische Hardware-Gateways nehmen eine kritische Position in moderner Infrastruktur ein. Am äußersten Rand des Netzwerks — auf Fabrikböden, regionalen Versorgungsstationen, Versandzentren und entfernten Standorten — verbinden diese Maschinen die digitale Cloud mit physischen Assets. Sie erfassen Rohdaten von programmierbaren Logikcontrollern (PLCs), Kameras und Umweltsensoren über lokale Schnittstellen wie Seriell, CAN-Bus, GPIO-Pins und spezielle USB-Komponenten.

Im Gegensatz zu zentralen Cloud-Servern, die in gesicherten Rechenzentren isoliert sind, sind Edge-Gateways physisch zugänglich und oft in untrusted Netzwerken im Einsatz. Wird ein Angreifer physischen oder Netzwerkzugang erlangen, bedeutet das die Kontrolle über die physische Maschine.

Der Schutz dieser Knoten erfordert einen Strategiewechsel. Traditionelle Sicherheitslösungen scheitern an der Edge-Infrastruktur, weil sie asynchron im Userspace arbeiten. Um physische Hardware zu schützen, muss die Durchsetzung synchron, präventiv und direkt im Kernel erfolgen.

Der Fehler der Nachträglichen Erkennung: Warum Userspace-Security am Edge versagt

Historisch basierten Host Intrusion Detection Systems (HIDS) auf Agents im Userspace, die Systemzustand überwachen und bösartiges Verhalten erkennen. Ältere Paradigmen nutzten Systemaudit-Logs (auditd), das Abfragen des /proc-Dateisystems oder asynchrone Ereignisse, die von Kernelmodulen oder Streaming-Sockets übermittelt werden.

Dieses Architekturdesign schafft eine kritische Schwachstelle am Edge: die semantische und zeitliche Lücke.

Verständnis von Time-of-Check to Time-of-Use (TOCTOU)

In einem klassischen Sicherheitsmodell im Userspace läuft die Ereigniskette bei einem Systemaufruf wie folgt ab:

[Userspace-Prozess] --- 1. Systemaufruf auslösen --- [Linux Kernel] (Operation ausführen)
                                                        |
                                                        v
[Userspace-Sicherheitsagent] --- 3. Erkennung/Alarm --- 2. Asynchrones Loggen

1. Eine bösartige Anwendung ruft einen Systemaufruf auf (z.B. sys_write an eine industrielle Schnittstelle).
2. Der Kernel verarbeitet und führt den Systemaufruf aus, was den Hardwarezustand verändert.
3. Der Kernel protokolliert das Ereignis asynchron über Subsysteme wie auditd.
4. Der Userspace-Agent liest den Log-Eintrag, wertet ihn aus und löst einen Alarm aus.

Wenn der Userspace-Agent den Log liest, ist der Systemaufruf bereits abgeschlossen. Bei einer lokalen Privilegienerweiterung (LPE), die eine Kernel-Schwachstelle ausnutzt, erhält der Angreifer Root-Rechte, noch bevor der Monitor im Userspace den initialen Exploit erkennt.

In einer Cloud-VM kann ein kompromittierter Knoten innerhalb Sekunden isoliert, zerstört und neu bereitgestellt werden. Bei physischen Gateways kann ein Angreifer, der dieses Rennen gewinnt, schädliche Firmware auf Microcontroller flashen, den Bootloader überschreiben oder industrielle Aktuatoren manipulieren. Nach der Manipulation ist softwarebasierte Wiederherstellung kaum mehr wirksam.

Die moderne Alternative: eBPF-basierte Durchsetzung

Extended Berkeley Packet Filter (eBPF) verwandelt den Linux-Kernel in eine programmierbare Sandbox. Statt Kernel-Quellcode zu modifizieren oder instabile Kernel-Module zu laden, schreiben Entwickler leichte Programme, die in eBPF-Bytecode kompiliert werden. Dieser wird vom Kernel-Verifier auf Sicherheit geprüft (z.B. gegen Endlosschleifen, ungültigen Speicherzugriff) und JIT-kompiliert, um auf Hardware-Geschwindigkeit ausgeführt zu werden.

+--------------------------------------------------------------+
|                         USERSPACE                            |
|        +-------------------------------------------+          |
|        |           Tetragon Agent Daemon            |         |
|        +-------------------------------------------+          |
|                              ^                                |
|              gRPC / JSON     | Alarme lesen                   |
|              Events          | & Metriken                     |
|                              |                                |
+------------------------------|--------------------------------+
|                            KERNEL                             |
|                              |                                |
|                              | eBPF-Maps (Konfiguration)        |
|                              v                                |
|        +-------------------------------------------+          |
|        |          eBPF Runtime Engine               |         |
|        +-------------------------------------------+          |
|             | Hook                     | Hook                 |
|             v                          v                      |
|      [Syscall-Tabelle]        [LSM Security Hooks]          |
|             |                          |                      |
|             +------------+-------------+                      |
|                          |                                    |
|                          v                                    |
|          Synchronous Block / Process Kill                     |
+--------------------------------------------------------------+

eBPF verschiebt die Sicherheit von passivem Logging zu Inline-Überprüfung. Anstatt auf eine System-Subsystem zu warten, das eine Log-Nachricht sendet, hängen eBPF-Programme direkt an Hook-Punkten im Kernel:

• Kprobes (Kernel Probes): Dynamische Hooks an nahezu jeder internen Kernel-Funktion.
• Tracepoints: Statische Hooks, die Entwickler in den Kernel-Code einbauen, um vorhersehbare Ereignisse zu verfolgen.
• LSM (Linux Security Module) Hooks: Schnittstellenpunkte entlang interner Kernel-Zugriffswege, die Sicherheitsentscheidungen vor Ressourcenallokation erlauben.

Cilium Tetragon, ein CNCF-Subprojekt von Cilium, nutzt eBPF, um Prozesse, Dateisystem- und Namespace-Integrität, Netzwerk-Sockets und Hardware-Schnittstellen zu überwachen und geht über Sichtbarkeit hinaus durch synchrone Laufzeitdurchsetzung.

Ein Detail, das es zu beachten gilt: Das Hooken eines rohen Systemaufrufs (z.B. sys_openat via kprobe) kann immer noch ein schmales TOCTOU-Fenster hinterlassen, wenn das Argument ein Zeiger auf User-Space-Speicher ist, da ein zweiter Thread diesen Speicher zwischen dem Auslösen des Hooks und der Kernel-Verarbeitung überschreiben könnte. Das Hooken einer späteren Kernel-Funktion — insbesondere eines LSM security_* Hooks — vermeidet dies, weil diese Hooks auf Kernel-residente Daten zugreifen, die bereits aus dem Userspace kopiert wurden. Für höchste Sicherheit bei Edge-Policies (z.B. Blockieren von /etc/shadow oder Hardware-Bussen) sind LSM-Hooks die stärkere Wahl; kprobes bei Systemaufrufen bleiben nützlich, sind aber etwas schwächer gegen entschlossene, schnelle Angreifer.

Strukturelle Systemaufruf-Interception

Wenn Tetragon mit einer Durchsetzungspolitik konfiguriert ist, hängen seine eBPF-Programme den Einstiegspunkt sensibler Systemaufrufe ab (z.B. __x64_sys_kexec_load, __x64_sys_ioctl). Wenn ein Prozess einen unautorisierten Systemaufruf auslöst, greift das eBPF-Programm vor der Kernel-Verarbeitung ein.

Sind die Argumente policywidrig, handelt das eBPF-Programm sofort im Kernel-Kontext. Es kann den Rückgabewert des Systemaufrufs mit einem Fehlercode wie EPERM (Operation nicht erlaubt) überschreiben oder ein tödliches Signal (SIGKILL) direkt an den Prozess senden (task_struct). Der Prozess wird beendet, bevor der Systemaufruf die Hardware beeinflussen kann.

Edge-Gateways gegen physische und cyber-physische Angriffe absichern

Physische Hardware-Gateways führen spezialisierte Workloads aus, sind aber besonderen Bedrohungen ausgesetzt. Hier zeigt sich, wie Kernel-Layer-Durchsetzung bestimmte Angriffsmuster auf Edge-Hardware stoppt.

1. Unbefugten Zugriff auf Hardware-Schnittstellen (/dev/*) blockieren

Edge-Systeme stellen physische Kommunikationsbusse als Character- oder Raw-Block-Geräte unter /dev/ bereit (z.B. /dev/ttyUSB0 für Modbus-Seriell-Adapter, /dev/can0 für Automotive-Netzwerke, oder rohe GPIO-Ports).

Ein kompromittierter Web- oder MQTT-Broker-Container auf dem Gateway könnte versuchen, diese Schnittstellen zu manipulieren. Standard-UNIX-Berechtigungen reichen nicht aus, wenn ein Angreifer eine lokale Schwachstelle ausnutzt, um Root-Zugriff zu erlangen.

Mit Tetragon können Sie Policies durchsetzen, die Funktionen wie sys_openat oder fd_install auf Kernel-Ebene überwachen. Selbst wenn ein Prozess als Root in einem kompromittierten Container läuft, kann Tetragon die Container-Namespace-Metadaten prüfen. Ist der Container nicht explizit autorisiert, /dev/ttyUSB0 zu öffnen, überschreibt der Kernel den Aufruf, blockiert die Dateideskriptor-Erstellung und protokolliert eine hochauflösende Warnung inklusive Container-Metadaten.

2. Unbefugte Netzwerk-Exfiltration verhindern

Industrielle Gateways kommunizieren meist nur mit vordefinierten Endpunkten: einem lokalen Broker, einem Cloud-Digital-Twin oder einem NTP-Server. Jede andere Netzwerkverbindung ist verdächtig.

Angreifer, die ein Gateway kompromittieren, versuchen oft, sekundäre Payloads herunterzuladen, Reverse-Shells zu starten oder Konfigurationsgeheimnisse zu exfiltrieren. Tetragon interceptiert die Erstellung von Netzwerk-Sockets auf Kernel-Ebene via Funktionen wie tcp_connect und __sys_connect.

Durch die Bewertung der Netzwerkaufrufe im Kernel, verbindet Tetragon Laufzeitkontext (Binary-Pfad, Elternprozess, Container-ID) mit Netzwerkdaten (Ziel-IP und Port). Wenn eine unautorisierte Binärdatei wie curl oder wget versucht, einen nicht genehmigten Port zu erreichen, beendet Tetragon den Prozess, noch bevor ein TCP-Handshake das Netzwerkinterface passiert — ein dokumentiertes Muster (z.B. wget zu Port 443 blockieren, während curl unberührt bleibt, ist in Tetragon-Field-Reports zu finden).

3. Container-Escape und Privilegienerweiterung verhindern

Viele Edge-Gateways nutzen leichte Laufzeitumgebungen wie K3s, Docker oder Podman. Container-Containment basiert auf Kernel-Namespace- und cgroup-Mechanismen. Ein Angreifer, der eine Kernel-Schwachstelle ausnutzt, um aus einem Container auszubrechen, erhält Zugriff auf das Host-Betriebssystem.

Das ist kein hypothetisches Szenario: Die Dirty Pipe-Schwachstelle (CVE-2022-0847), 2022 veröffentlicht, erlaubt es unprivilegierten Prozessen, Daten in schreibgeschützten Dateien durch Exploitation eines Linux-Pipe-Buffer-Fehlers zu überschreiben — ein Fehler, der unabhängig von Container-Konfigurationen funktioniert und zur Privilegienerweiterung oder Manipulation von Dateien über Namespace-Grenzen genutzt werden kann. Tetragon nennt es als Beispiel, warum kernel-integrierte, namespace-abhängige Durchsetzung auch bei scheinbar isolierten Containern essenziell ist. Zudem zeigt die interne Analyse von Tetragon, dass etwa 44% der Container-escape-Exploits auf der Fähigkeit unprivilegierter Prozesse basieren, neue User-Namespaces zu erstellen, was volle Capabilities innerhalb dieses Namespace gewährt.

Tetragon überwacht Namespace-Übergänge und Credential-Änderungen in Echtzeit durch Hooks in Funktionen wie commit_creds und Systemaufrufen wie setns/unshare. Es erkennt Capability-Gains (CAP_SYS_ADMIN, CAP_SYS_RAWIO) oder Namespace-Änderungen bei Prozessen außerhalb des Host-Namespaces und kann diese sofort isolieren oder beenden, noch bevor sie weitere Befehle auf dem Host-Dateisystem ausführen.

Tetragon auf Bare-Metal-Edge-Gateways implementieren

Obwohl Tetragon häufig in Kubernetes-Umgebungen eingesetzt wird, läuft es auch als eigenständiger System-Daemon auf Bare-Metal-Edge-Knoten.

Voraussetzungen für Edge-Knoten

Zur Nutzung der eBPF-basierten Laufzeitsicherheit muss der Linux-Kernel des Edge-Gateways BTF (BPF Type Format) unterstützen, damit eBPF-Programme CO-RE (Compile Once – Run Everywhere) verwenden können. So kann ein Programm, das auf einer Kernel-Version gebaut wurde, die richtigen Struktur-Offsets auf einer anderen lesen.

Die Kompatibilitätsdokumentation von Tetragon listet folgende Kernel-Konfigurationsoptionen als Voraussetzungen:

CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_BPF=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_JIT=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_BPF_SYSCALL=y
CONFIG_CGROUPS=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_SECURITY=y

CONFIG_BPF_KPROBE_OVERRIDE ist eine spezielle Option: Sie steuert, ob das Override-Verfahren bei Policy 2 genutzt werden kann. Ohne diese Option kann Tetragon zwar erkennen und Sigkill senden, aber nicht den Rückgabewert eines Systemaufrufs überschreiben.

Prüfen Sie die BTF-Unterstützung auf einem laufenden Knoten mit:

ls -l /sys/kernel/btf/vmlinux

Wenn Sie LSM-Hook-Policies verwenden möchten, braucht der Kernel außerdem bpf im LSM-Stack aktiviert zu haben, was bei vielen Distributionen standardmäßig nicht der Fall ist. Überprüfen Sie mit:

cat /sys/kernel/security/lsm

Wenn bpf nicht in der Ausgabe erscheint, muss es in den Kernel-Boot-Parameter lsm= eingetragen werden (z.B. via /etc/default/grub und Neuaufbau der grub-Konfiguration). Testen Sie dies zuerst auf Nicht-Produktions-Hardware, da Änderungen am LSM-Stack das Boot-Verhalten beeinflussen können.

Tetragon unterstützt Kernel-Versionen mit Long-Term-Support (LTS) von 4.19, 5.4, 5.10 und 5.15. Es wird empfohlen, den neuesten stabilen Kernel zu verwenden, der mit Ihrer Hardware kompatibel ist, da eBPF-Fähigkeiten (wie kprobe_multi-Fast-Attach oder vollständige Argument-Visibilität auf arm64) in neueren Releases landen.

Installationsablauf

Für Edge-Knoten mit Debian, Ubuntu oder Yocto-basierten Distributionen kann Tetragon direkt als Binärdatei installiert und via systemd verwaltet werden. Die aktuelle Version laut Tetragon-Installationsanleitung ist v1.7.0:

# 1. Neueste Release-Bündel herunterladen
curl -LO https://github.com/cilium/tetragon/releases/download/v1.7.0/tetragon-v1.7.0-amd64.tar.gz

# 2. Archiv entpacken
tar -xvf tetragon-v1.7.0-amd64.tar.gz
cd tetragon-v1.7.0-amd64/

# 3. Native Installationsskript ausführen
sudo ./install.sh

# 4. Systemdienststatus prüfen
sudo systemctl status tetragon

Da Releases sich schnell ändern, empfiehlt es sich, vor der Versionierung in Automatisierungsskripten die Tetragon-Releases-Seite zu prüfen.

Zwei weitere unterstützte Deploy-Methoden für Edge-Umgebungen:

• Container-Deployment, falls der Gateway bereits eine Container-Laufzeit für eigene Workloads nutzt: bash docker run --name tetragon --rm -d \ --pid=host --cgroupns=host --privileged \ -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf \ quay.io/cilium/tetragon:v1.7.0 - Helm-Installation, bei lightweight Kubernetes-Distributionen wie K3s: bash helm repo add cilium https://helm.cilium.io helm repo update helm install tetragon cilium/tetragon -n kube-system kubectl rollout status -n kube-system ds/tetragon -w

Nach dem Start verbindet der Tetragon-Daemon mit dem Kernel und streamt Telemetrie-Events in eine lokale Logdatei /var/log/tetragon/tetragon.log im JSON-Format.

Tetragon-Policies für Edge-Schutz erstellen

Tetragon nutzt deklarative YAML TracingPolicy-Ressourcen, um Hook-Punkte und Durchsetzungsmaßnahmen zu definieren. Diese CRs funktionieren gleich, egal ob Kubernetes läuft oder nicht — bei Bare-Metal-Deployments zeigt man die Policy-Datei direkt mit --tracing-policy an.

Policy 1: Präventives Blockieren unautorisierter Binär-Execution

Diese Policy überwacht Binär-Ausführungen und beschränkt sie in volatile oder schreibbare Verzeichnisse (/tmp, /var/tmp, /dev/shm), klassische Angriffsflächen für Drop-and-Execute-Payloads.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-volatile-execution
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string" # Pfad zum ausführenden Binär
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/tmp/"
                - "/var/tmp/"
                - "/dev/shm/"
          matchActions:
            - action: Sigkill

Wenn ein Binär aus /tmp/ ausgeführt werden soll, erkennt Tetragon im eBPF-Probe die String-Präfix-Bedingung bei sys_execve. Der Kernel löst die Sigkill-Aktion aus und beendet den Prozess, bevor der Binärcode ausgeführt wird.

Policy 2: Schutz physischer Hardware-Schnittstellen vor Containern

Diese Policy verhindert, dass containerisierte Prozesse auf rohe serielle oder USB-Schnittstellen (/dev/ttyUSB*, /dev/bus/usb/*) zugreifen, außer sie laufen im eigenen Namespace des Hosts — also nur innerhalb von Containern, nicht auf dem Host.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: protect-hardware-buses
spec:
  kprobes:
    - call: "sys_openat"
      syscall: true
      args:
        - index: 1
          type: "string" # Dateipfad-Parameter
      selectors:
        - matchArgs:
            - index: 1
              operator: "Prefix"
              values:
                - "/dev/ttyUSB"
                - "/dev/bus/usb/"
          matchNamespaces:
            - namespace: Pid
              operator: "NotIn"
              values:
                - "host_ns"
          matchActions:
            - action: Override
              argError: -1 # -EPERM: Operation nicht erlaubt

matchNamespaces schränkt die Policy auf “alles, was nicht im Host-PID-Namespace läuft” ein. Das Schlüsselwort host_ns wird automatisch auf den richtigen Namespace-Inode aufgelöst. NotIn trifft auf alle anderen, also containerisierte Workloads. Durch Rückgabe von -1 (-EPERM) via Override erhält die Software eine Zugriff verweigerte Rückmeldung, ohne dass der Kernel den ursprünglichen sys_openat-Aufruf ausführt.

 Hinweis: In einer früheren Version wurde matchNamespaces mit einer Textbeschreibung (namespace: "those_outside_host_pid") verwendet. Das ist nicht gültig. Das korrekte Schema nutzt namespace: Pid, operator: NotIn, und values: ["host_ns"]. Diese Syntax ist in Tetragon-Dokumentation und Beispiel-Policies bestätigt.

Persistente Durchsetzung: Agenten-Neustart überbrücken

Ein Risiko bei Edge-Hardware ist die intermittierende Konnektivität und regelmäßige Agenten-Neustarts — genau hier entsteht eine Sicherheitslücke. Tetragon bietet eine Lösung: persistente Durchsetzung.

Durch den Start des Daemons mit --keep-sensors-on-exit bleiben die geladenen eBPF-Programme im Kernel unter /sys/fs/bpf/tetragon verankert, auch wenn der Userspace-Prozess abstürzt, beendet oder während eines Updates neu gestartet wird. Aktionen wie Sigkill oder Override laufen im Kernel weiter, nur die Event-Reporting-Pipeline ist unterbrochen, bis der Daemon wieder läuft.

tetragon --bpf-lib bpf/objs/ --keep-sensors-on-exit --tracing-policy protect-hardware-buses.yaml

Für einen Fabrik-Gateway mit instabiler WAN-Verbindung schließt dies die Lücke, die im Artikel beschrieben wird: Die Durchsetzung bleibt auch bei Agent-Ausfall aktiv.

Sicherer Rollout: Modi der Durchsetzung

Da eine falsche Policy die Leistung beeinträchtigen oder legitime Prozesse auf schwer erreichbarer Hardware stoppen kann, unterstützt Tetragon zwei Modi: - Monitoring-Modus: Aktionen werden nur protokolliert, nicht ausgeführt. - Enforcement-Modus: Aktionen werden tatsächlich durchgesetzt.

Der empfohlene Workflow: Policy zunächst im Monitoring-Modus testen, um sicherzustellen, dass nur unerwünschtes Verhalten erkannt wird, dann auf Enforcement umstellen.

Performance bei ressourcenbeschränkter Edge-Computing

Edge-Infrastruktur arbeitet oft mit engen Ressourcen: industrielle Computer, ARM64-Boards, oder Gateways mit begrenztem RAM. Heavy Telemetrie kann Ressourcen erschöpfen, Paketverluste oder verzögerte Sensorwerte verursachen.

Tetragon minimiert Overhead durch aggressive Kernel-Filterung:

TRADITIONALER HOST INTRUSION DETECTION (z.B. Falco)
[Kernel Space] --- Alle Systemaufrufe in Echtzeit ---
[Userspace Daemon] (Filter & Entscheidung)

TETRAGON eBPF-Architektur
[Kernel Space: eBPF evaluiert Regeln lokal] --- nur bestätigte Alarme --- [Userspace Daemon]

Wenn ein Systemaufruf harmlos ist, verwirft Tetragon das Event oder erhöht einen Zähler im Kernel. Daten werden nur bei Verstößen oder unbekannten Events an den Userspace weitergeleitet.

Zur Overhead-Bewertung: Es gibt keine offizielle, allgemeingültige Cilium-Benchmarkzahl. Verschiedene Quellen berichten von 1% bis 8% CPU-Last, abhängig vom Event-Volumen und Policy-Anzahl. Für kleine, stabile Setups auf Edge-Gateways ist der Overhead am unteren Ende. Benchmarking sollte vor Kapazitätsplanung immer auf die eigene Hardware abgestimmt werden.

Bekannte Einschränkung: eBPF ist nicht unfehlbar

Kernel-gestützte Kontrolle ist kein Allheilmittel. Ein Angreifer mit CAP_BPF oder CAP_SYS_ADMIN kann eigene eBPF-Programme laden, die die Überwachung umgehen. Das ist aktives Forschungsfeld (Stand 2026). Tetragon sollte daher als Teil einer mehrschichtigen Sicherheitsstrategie eingesetzt werden, inklusive Beschränkung der Capabilities und Überwachung unerwarteter BPF-Programm-Loads.

Vergleich: Legacy HIDS vs. eBPF Tetragon

Sicherheitsmerkmal	Legacy Userspace HIDS (z.B. auditd, Falco)	Moderne eBPF Kernel-Durchsetzung (Tetragon)
Ausführungsebene	Userspace-Agent, liest Logs	Kernel-integrierter Sandbox
Durchsetzungszeit	Asynchron, nach Exploit	Synchron, präventiv vor Abschluss des Systemaufrufs
Umgehungssicherheit	Hoch: Root-Komprimierung kann Agenten deaktivieren	Geringer, aber vorhanden: Mit CAP_BPF kann Angreifer eigene Programme laden
Ressourcenverbrauch	Mittel bis hoch, abhängig vom Event-Volumen	Gering, skaliert mit Policy-Anzahl und Event-Volumen
Eignung für Edge-Hardware	Schlecht: TOCTOU-Risiko, physische Manipulation	Stark: schützt I/O-Schnittstellen auf OS/Driver-Ebene, mit persistenter Durchsetzung

Fazit: Schutz am Maschinenrand

Mit fortschreitender Edge-Computing-Entwicklung ist ein Schutz, der die Geschwindigkeit des Betriebssystems widerspiegelt, notwendig. Traditionelle, reaktive Erkennung lässt eine gefährliche Lücke zwischen Exploit-Ausführung und Userspace-Alarm.

Durch den Einsatz von eBPF und Tools wie Cilium Tetragon können Infrastruktur-Ingenieure widerstandsfähige, proaktive Schutzmaßnahmen um physische Gateways aufbauen. Die Verschiebung der Filterung in den Kernel ermöglicht das Abfangen von Angriffen bei Systemaufrufen und LSM-Ebenen. Unbefugte Verbindungsversuche werden blockiert, bösartige Privilegienwechsel verhindert und manipulierte Hardware-Anfragen neutralisiert — allerdings nur als eine Schicht in einer mehrstufigen Sicherheitsstrategie.

---

Changelog

Metadaten entfernt: Der zusammenhängende Titel/Untertitel-Block wurde in einen klaren H1-Titel und einen Einleitungstext umgewandelt.

Korrekturen: - Das fehlerhafte matchNamespaces-Block in Policy 2 wurde korrigiert (namespace: Pid, operator: NotIn, values: ["host_ns"]). Das entspricht Tetragon-Dokumentation und Praxisbeispielen. - Die Kernel-Konfigurationsliste wurde auf alle erforderlichen Flags erweitert, inklusive CONFIG_BPF_KPROBE_OVERRIDE, das die Override-Aktion bei Policy 2 steuert. - Die CPU-Overhead-Angabe wurde abgeschwächt, da keine offizielle Benchmarkzahl existiert. Stattdessen wird eine Bandbreite von Werten genannt. - Kleinere Formulierungsfehler wurden korrigiert. - Hinweise auf die Unterschiede zwischen kprobe-basierten Hooks und LSM-Hooks wurden ergänzt.

Unveränderte, bestätigte Inhalte: - Die Installationsbefehle für v1.7.0 entsprechen den aktuellen Anleitungen. - Architektur, Enforcement-Modelle und Policy-YAML sind korrekt.

Neue, verifizierte Abschnitte: - Persistente Durchsetzung (--keep-sensors-on-exit), relevant bei instabiler Verbindung. - Modi der Durchsetzung (Monitoring vs. Enforcement). - Beispiel für Container-escape durch Dirty Pipe (CVE-2022-0847) und die 44%-Zahl für Escape-Chain-Exploits. - Abschnitt zu bekannten Limitationen (Rootkits, Kernel-Residenz, aktive Forschung). - Notwendigkeit des bpf-Parameters im Kernel für LSM-Hooks.

Quellen: - Offizielle Tetragon-Dokumentation (tetragon.io) - Tetragon Blog 2025, Sicherheits- und Performance-Analysen - Unabhängige Fachartikel 2025–2026 zu Tetragon-Leistung und Rootkit-Erkennung