Runtime Protection

Tools wie Falco (Open Source) oder kommerzielle EDR-Lösungen. Du definierst Regeln: "Ein Webserver (Nginx) darf niemals curl ausführen oder /etc/shadow lesen." Wenn er es doch tut, schreit Falco: "ALARM! Hacker im Nginx Container!" In Kubernetes läuft das meist als DaemonSet (ein Wächter pro Node).

1. RASP (Runtime Application Self-Protection)

Der Schutz ist in die App eingebaut (als Java Agent oder Library). Die App schützt sich selbst. "Hey, diese SQL-Query sieht wie eine Injection aus. Ich breche ab." Vorteil: Kennt den Kontext der App. Nachteil: Performance-Overhead.

2. eBPF (Extended Berkeley Packet Filter)

Die moderne Magie. Der Wächter sitzt direkt im Linux Kernel. Er sieht jeden System Call (Datei öffnen, Netzwerk senden), ohne die App zu verlangsamen. Tools wie Tetragon nutzen das für extrem effiziente Runtime Security.

1. Ptrace Overhead vs eBPF (Performance Tax)

Die erste Generation von Runtime Security Tools (wie alte Auditd Logger oder Sysdig Ptrace Daemons) hookte sich in den Linux Kontext-Switch ein (ptrace), um Systemcalls (wie execve oder open) zu überwachen. Jeder Netzwerk-Call der Applikation rief einen teuren Kontext-Wechsel von User-Space in Kernel-Space, danach in den Agenten-Space (Tool), dann zurück. Das fraß in High-Throughput Kubernetes Clustern bis zu 30% CPU-Ressourcen! Die Revolution ist eBPF (Extended Berkeley Packet Filter). Die Security Engine (wie Tetragon/Cilium) lädt ein JIT (Just-in-Time) kompiliertes C-Programm direkt in den Linux Kernel Ring $0$. Das eBPF-Prog fängt den Syscall asynchron im Kernel ab, prüft die Security-Regel ohne Blockade und wirft (statt eines CPU Kontext-Switches) nur dann ein kompaktes Event über ein asynchrones Ring-Buffer Array in den User-Space, wenn eine Alert ausgelöst wird. CPU Impact: Fast inmessbar ($< 2%$).

2. TOCTOU Exploits (Time-of-Check to Time-of-Use) im eBPF

eBPF-Agents analysieren Syscalls wie execve("/bin/curl", ...). Das klassische eBPF C-Programm liest die Parameter-Pointer des Syscalls – den String "/bin/curl". Falls es legitim ist, poppt ein O.K. Der perfide Hackerangriff ist eine "TOCTOU" Race Condition: Das eBPF-Tool liest den String "curl" im User-Space-Speicher. Das Tool genehmigt den Call. Eine Mikrosekunde später überschreibt der Hacker-Thread exakt diese Memory-Adresse von "curl" zu "nmap"! Der Kernel ruft nun im echten Syscall plötzliche die manipulierte Adresse auf. eBPF sah "curl", der Kernel führte "nmap" aus (!). Moderne Profiler (wie Tetragon) hooken sich nicht mehr per "Kprobe" an den Eingang des Syscalls, sondern blockieren das Binary intern über eBPF "LSM Hooks" (Linux Security Module), als der Syscall die Daten im Kernel-Space bereits fest eingelockt hatte, was die Memory Race Condition unmöglich macht.

3. Fileless Malware & Memfd_create Payload

Das "blinde" CNI-Netzwerkmonitoring und statische File-Scanning versagt bei moderner RCE (Remote Code Execution) "Fileless Malware". Ein Hacker schleust ein Java RCE Script ins Backend ein. Er lädt gar keine böse Binary via curl auf die Linux Festplatte. Er ruft den Linux Syscall memfd_create() auf. Dies erzeugt ein völlig unsichtbares, nur im RAM existierendes temporäres Dateisystem (Anonymous File). Dort dumpt er seinen Hex-Code rein und zwingt die Java API, die Bytes direkt aus dem RAM als Executable zu starten. Das Linux Dateisystem sieht den Hacker niemals. Runtime Tools detektieren genau diese Anomalie: "Ein anonymer Memory-Node verlangt kernel_exec() – Blockiere sofort!".