eBPF-Sensoren und das 18-Minuten-Angriffsfenster in Kubernetes

Jeder Platform Lead, der schon einmal an einem Freitagnachmittag einen frischen AKS-Cluster hochgefahren hat, kennt das ungute Gefühl: Man hat noch nicht einmal die NetworkPolicy fertig geschrieben, und schon klopfen die Bots an. Achtzehn Minuten. Das ist die mediane Schonfrist, bevor ein AKS-Cluster seinen ersten Angriffsscan erhält – laut einem Bericht von Wiz. EKS bekommt mit 28 Minuten etwas mehr Zeit. Beide Zahlen sind kürzer als die meisten On-Call-Übergaben.

Die Zahlen

Achtzehn Minuten reichen nicht aus, um irgendetwas zu tun, was ein Mensch normalerweise tut. Sie reichen nicht aus, um einen Terraform-Plan ordentlich zu prüfen. Sie reichen nicht aus, um in einem Slack-Thread zu diskutieren, ob das Dashboard öffentlich zugänglich sein soll. Sie reichen erst recht nicht aus, damit der wöchentliche Schwachstellenscan durchläuft, ein PDF erzeugt und vom Sicherheitsteam triagiert wird.

Wie CyberSecurityNews berichtete, stammen die 18-Minuten-AKS- und 28-Minuten-EKS-Fenster aus dem eigenen Kubernetes Security Report von Wiz. Der Zehn-Minuten-Unterschied zwischen den beiden Managed Services ist mit ziemlicher Sicherheit auf Bot-Scanmuster zurückzuführen und kein echter defensiver Vorteil von EKS. Betrachten Sie beide als dasselbe Problem: Ihr Cluster steht auf der Zielliste, bevor Ihre CI-Pipeline den ersten Deploy abgeschlossen hat.

Übersetzt in operative Begriffe: Wenn Sie ein zehnköpfiges Platform-Team leiten und On-Call-Engineers durch Kubernetes-Provisionierung rotieren lassen, brauchen Sie automatisiertes Hardening, das in den Cluster-Bootstrap eingebettet ist – denn ein menschlicher Reviewer kann einem Bot nicht zuvorkommen. Das ist ein echter Budgetposten. In Produktionsvorfällen, die ich bei Fintech-Unternehmen mit Managed Kubernetes erlebt habe, ist genau der „Wir härten das nach der Demo"-Cluster derjenige, der am Montagmorgen Monero schürft.

Eine weitere wichtige Zahl: Gute Laufzeittools erkennen Angriffe innerhalb von Sekunden. Stellt man das dem 18-Minuten-Angriffsfenster gegenüber, ist die Rechnung offensichtlich. Man kann automatisierten Angreifern nicht mit menschlich gesteuerten Review-Zyklen entkommen. Die Erkennung muss in dieselbe Größenordnung wie die Automatisierung der Angreifer komprimiert werden – also in den einstelligen Sekundenbereich.

Standard-Kubernetes wird mit weitreichenden Berechtigungen, offenen Dashboards und Service Accounts ausgeliefert, die mehr Zugriff haben als nötig. Diese Kombination plus eine öffentliche IP macht die 18-Minuten-Zahlen reproduzierbar und nicht bloß anekdotisch. Bots brauchen keinen Zero-Day, wenn die Eingangstür ungesichert ist.

Was wirklich neu ist

eBPF selbst ist nicht neu. Der Extended Berkeley Packet Filter klinkt sich seit Jahren in den Linux-Kernel ein, und Falco, Tetragon sowie Cilium liefern schon lange auf eBPF basierende Laufzeiterkennung. Was sich verändert hat: Die Agentless-Anbieter haben eBPF mittlerweile in ihre Plattformen integriert, anstatt es als konkurrierende Kategorie zu behandeln.

Wiz hat seinen Ruf damit aufgebaut, Cloud-Umgebungen ohne den Einsatz von Agenten zu scannen. Die Aufnahme des Wiz Sensor als optionalem, agentenbasierten Add-on zu Wiz Defend ist ein echtes architektonisches Eingeständnis: In-Memory-Exploitation lässt sich von außerhalb des Knotens nicht erkennen. Statisches Scanning prüft, was im Container-Image vorhanden ist, gegen bekannte CVEs. Es sagt nichts darüber aus, was tatsächlich in den Speicher geladen wird, sobald der Container läuft. Ein verwundbares Paket, das nie importiert wird, ist theoretisch. Eine harmlos wirkende Binärdatei, die für Lateral Movement missbraucht wird, ist real.

Der Wiz Sensor validiert Schwachstellen gegen das, was in den Speicher geladen ist – nicht nur gegen das, was auf der Festplatte liegt. Das ist der wirklich nützliche technische Vorteil, weil er die lärmige CVE-Warteschlange verkleinert, in der jedes Sicherheitsteam versinkt. Die Hälfte dessen, was Ihr SBOM-Scanner meldet, ist Code, der niemals ausgeführt wird. Die Erreichbarkeit zur Laufzeit zu bestätigen ist der Weg, um aufzuhören, zwei Engineers mit der Jagd nach Phantomfunden zu beschäftigen.

Ein weiteres, eher neues Element: Der Wiz Runtime Sensor für Windows, der im Juni veröffentlicht wurde, nutzt ein schlankes Kernelmodul, das sich in Windows-Sicherheits-APIs einklinkt und Aktivitätsdaten an den User Space weiterleitet, wo die Erkennungslogik läuft. Sowohl Linux- als auch Windows-Sensoren berichten an dieselbe Plattform. Für alle, die hybride Cluster betreiben – und davon gibt es in Enterprise-iGaming und Legacy-Fintech mehr als Anbieter zugeben möchten – ist die einheitliche Telemetrie-Pipeline der eigentliche Differenziator, nicht das eBPF-Branding.

Meine Einschätzung: Die eigentliche Geschichte hier ist nicht „eBPF ist cool." eBPF ist seit 2018 cool. Die Geschichte ist, dass die Agentless-Anbieter leise eingestanden haben, dass die Laufzeit einen Agenten braucht, und nun darum wetteifern, einen hinzuzufügen, bevor die reinen Laufzeit-Tools ihnen die Wachstumserlöse wegnehmen.

Was für Sicherheitsteams bereits eingepreist ist

Wer die letzten drei Jahre Kubernetes-Sicherheit verfolgt hat, hat das meiste davon bereits im Bedrohungsmodell. Man weiß bereits, dass Standardkonfigurationen gefährlich sind. Man weiß bereits, dass Service Accounts überberechtig sind, weil enge Scopes Dinge kaputtmachen und niemand Zeit hat, RBAC an einem Dienstag zu debuggen. Man weiß bereits, dass Living-off-the-Land-Binaries wie curl, bash und Paketmanager nicht weggescannt werden können, weil die eigene Anwendung sie legitim benötigt. Teams, mit denen ich an Zahlungsinfrastruktur gearbeitet habe, mappen das seit Jahren auf MITRE ATT&CK-Techniken für Container.

Was noch nicht eingepreist ist – und hier sehe ich, dass Teams weiterhin erwischt werden – sind die operativen Kosten des eBPF-Agenten selbst. eBPF ist Linux-spezifisch. Es funktioniert nur auf Linux-Knoten. Das bedeutet: Jeder Windows-Knoten, jeder Managed Service, der den Knoten abstrahiert, jede serverlose Container-Laufzeit ohne Kernel-Zugriff ist eine Deckungslücke. Ihr Dashboard zeigt Grün, während ganze Teile Ihrer Flotte unüberwacht sind.

Die unbequeme Wahrheit: Die meisten Teams kaufen Laufzeiterkennung, setzen sie auf den von ihnen kontrollierten Linux-Worker-Pools ein und ignorieren stillschweigend, dass ihre Windows-Knoten, ihre Fargate-Tasks und ihre GKE Autopilot-Workloads außerhalb der Reichweite des Sensors liegen. Das Windows-Sensor-Release schließt eine dieser Lücken. Die anderen bleiben bestehen.

Die Gegenmeinung

Hier ist das Argument, dem ich widersprechen würde: dass das Hinzufügen eines eBPF-Agenten auf jedem Knoten offensichtlich die richtige Antwort ist. Das ist sie keineswegs offensichtlich. Kernel-Level-Agenten haben eine Geschichte von Ausfällen, die die Vorfälle, die sie verhindern sollten, in den Schatten stellen. Wer einen bestimmten Morgen im Juli 2024 miterlebt hat, weiß, was passiert, wenn sich ein Kernelmodul im großen Maßstab falsch verhält.

eBPF ist sicherer als ein rohes Kernelmodul, weil es in einer verifizierten Sandbox läuft – aber „sicherer" ist nicht „sicher". Jeder zusätzliche Hook in Syscalls, Prozessausführung und Netzwerkpfade kostet CPU, die für Beobachtung statt für die Bearbeitung von Anfragen aufgewendet wird. Bei Hochdurchsatz-Workloads ist dieser Overhead real, und ich habe Teams erlebt, die Laufzeitsensoren zurückgerollt haben, nachdem Benchmarks eine messbare Latenzbelastung bei p99 zeigten.

Die Gegenmeinung: Für viele Workloads bringt das Härten des Clusters bei der Provisionierung – gesperrtes RBAC, keine öffentlichen Dashboards, Admission Controller, Image-Signierung – mehr Sicherheit pro ausgegebenem Euro als das Hinzufügen eines Laufzeitsensors auf einem schlecht konfigurierten Cluster. Laufzeiterkennung ist das, was man hinzufügt, nachdem die Grundlagen erledigt sind – nicht statt ihrer.

Wichtigste Erkenntnisse

• Die 18-Minuten-AKS- und 28-Minuten-EKS-Angriffsfenster bedeuten, dass das Cluster-Hardening bei der Provisionierung automatisiert sein muss und nicht nachträglich von Menschen überprüft werden kann.
• Statisches Image-Scanning kann keine In-Memory-Exploitation oder den Living-off-the-Land-Missbrauch von curl, bash und Paketmanagern erkennen. Laufzeittransparenz ist die einzige Möglichkeit, diese zu erfassen.
• eBPF-basierte Sensoren (Falco, Tetragon, Cilium, Wiz Sensor) schließen die Linux-Laufzeitlücke, aber eBPF ist ausschließlich für Linux. Windows-Knoten benötigen einen separaten Kernelmodul-Ansatz.
• Die Validierung von Schwachstellen gegen das, was im Speicher geladen ist (statt gegen das, was auf der Festplatte liegt), ist das nützlichste Feature zur Reduzierung des CVE-Queue-Rauschens. Priorisieren Sie Tools, die das leisten.
• Bevor Sie einen Kernel-Level-Agenten auf jedem Knoten einsetzen, sperren Sie Standardeinstellungen, schränken Sie Service Accounts ein und schließen Sie offene Dashboards. Laufzeiterkennung ist eine Schicht über guter Hygiene – kein Ersatz dafür.