CONTAINERSHIELD: Ein formales und empirisches Rahmenwerk zur Erkennung und Minderung von Bedrohungen in Containerumgebungen auf Basis mehrschichtiger Telemetrie

1. Einleitung

Die leichte Virtualisierung mittels Containern hat sich als dominierendes Paradigma im Cloud-Computing etabliert und ermöglicht die Isolation von Anwendungen durch Namespaces und cgroups des Linux-Kernels. Im Gegensatz zu traditionellen virtuellen Maschinen teilen sich Container denselben Kernel, was den Overhead reduziert, jedoch die gemeinsame Angriffsfläche vergrößert. Diese strukturelle Eigenschaft macht das Sicherheitsmodell inhärent von Isolationsmechanismen des Betriebssystems abhängig, deren fehlerhafte Konfiguration oder Ausnutzung mehrere Workloads gleichzeitig kompromittieren kann.

Aktuelle Vorfälle verdeutlichen die Kritikalität des Problems. Die Schwachstelle CVE-2019-5736 ermöglichte einen Container-Escape durch Manipulation der Runtime runc und erlaubte das Überschreiben des Host-Binaries. In ähnlicher Weise nutzte CVE-2022-0492 Defizite in der Konfiguration von cgroups aus, um privilegierte Ausführung zu erlangen. Kampagnen wie TeamTNT missbrauchten falsch konfigurierte Kubernetes-Umgebungen für Kryptowährungs-Mining und setzten dabei Techniken ein, die dem MITRE ATT&CK zugeordnet sind, wie T1611 (Escape to Host) und T1610 (Deploy Container). Berichte von Red Hat und Sysdig (2023) weisen darauf hin, dass mehr als 60% der Images in öffentlichen Registries bekannte kritische Schwachstellen enthalten.

Trotz der Verbreitung von Sicherheitswerkzeugen — einschließlich Image-Scannern, Runtime-Sicherheitsystemen und Admission-Controllern — zeigt sich eine konzeptionelle Fragmentierung und das Fehlen einer einheitlichen Formalisierung des Problems. Die meisten Lösungen verfolgen signaturbasierte Ansätze oder heuristische Regeln, ohne die gewünschten Sicherheitseigenschaften formal zu modellieren.

Daher formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lassen sich Sicherheitseigenschaften in Container-Umgebungen auf überprüfbare und messbare Weise formalisieren?

RQ2: Ist es möglich, multischichtige Telemetrie zu kombinieren, um die Angriffserkennungsrate im Vergleich zu eindimensionalen Ansätzen signifikant zu verbessern?

RQ3: Welchen Einfluss haben dynamische, auf formalen Politiken basierende Mitigationsmechanismen auf die Betriebsleistung von Clustern im großen Maßstab?

Unsere zentralen Beiträge sind:

C1: Eine formale Modellierung der Container-Umgebung als System beschrifteter Transitionen mit mathematisch ausgedrückten Isolations- und Integritätseigenschaften.

C2: Ein probabilistischer Erkennungsmechanismus auf Basis von Markov-Ketten variabler Ordnung, gespeist durch eBPF-Telemetrie.

C3: Eine skalierbare, in Kubernetes integrierte Implementierung mit groß angelegter empirischer Evaluation, die signifikante quantitative Verbesserungen zeigt.

Der restliche Artikel ist wie folgt gegliedert: Abschnitt 2 diskutiert Grundlagen und verwandte Arbeiten; Abschnitt 3 stellt das Bedrohungsmodell vor; Abschnitt 4 beschreibt die vorgeschlagene Methodik; Abschnitt 5 erläutert die Implementierung; Abschnitt 6 präsentiert die experimentelle Evaluation; Abschnitt 7 diskutiert Implikationen und Einschränkungen; und Abschnitt 8 schließt die Arbeit ab.

2. Hintergrund und verwandte Arbeiten

Container basieren auf grundlegenden Mechanismen des Linux-Kernels: Namespaces $N = {pid, net, ipc, mnt, uts, user}$ und cgroups $C$, die Ressourcenbeschränkungen durchsetzen. Formal kann ein Container als Tupel definiert werden:

$$ \mathcal{K} = (P, N, C, I, \Pi) $$

wobei $P$ die Menge der Prozesse, $I$ das Basis-Image und $\Pi$ die Menge der angewendeten Politiken (seccomp, AppArmor, SELinux) darstellt.

Frühere Arbeiten können in drei Hauptkategorien eingeteilt werden:

(i) Statische Image-Analyse: Werkzeuge wie Clair und Trivy analysieren Abhängigkeiten und bekannte CVEs.

(ii) Runtime-Monitoring: Falco verwendet auf Syscalls basierende Regeln; Sysdig Secure setzt Verhaltensdetektion ein.

(iii) Admission-Policies und verstärkte Isolation: PodSecurityPolicies, OPA/Gatekeeper und gVisor.

Aus mathematischer Sicht kann Verhaltensdetektion als Klassifikationsproblem über Sequenzen $S = (s_1, s_2, …, s_n)$ von Systemereignissen modelliert werden. Frühere Ansätze verwenden Markov-Modelle erster Ordnung und nehmen an:

$$ P(s_{i} | s_{i-1}) $$

Solche Modelle ignorieren jedoch höherordentliche Abhängigkeiten und den semantischen Kontext des Orchestrators.

Wiederkehrende Einschränkungen sind:

• Hohe Rate an Fehlalarmen aufgrund der flüchtigen Natur von Containern.
• Fehlende Integration zwischen den Schichten (Kernel und Control Plane).
• Mangel an expliziter Formalisierung der Sicherheitseigenschaften.

Unser Ansatz überwindet diese Einschränkungen durch die Integration formaler Modellierung und kontextualisierter Telemetrie.

3. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen Angreifer an mit der Fähigkeit:

(a) bösartige Container mittels ausgenutzter kompromittierter Zugangsdaten bereitzustellen.
(b) Schwachstellen in der Runtime oder im Kernel auszunutzen.
© laterale Bewegung zwischen Pods durchzuführen.

Wir bezeichnen das globale System als gerichteten Graphen $G = (V, E)$, wobei $V$ Container und $E$ Kommunikationsverbindungen repräsentiert.

Wir definieren starke Isolationseigenschaft als:

$$ \forall v_i, v_j \in V, ; i \neq j \Rightarrow \neg \text{write}(v_i \rightarrow host \rightarrow v_j) $$

Das Problem besteht darin, Ereignissequenzen $S$ zu erkennen, sodass:

$$ P(S | \theta_{normal}) < \epsilon $$

wobei $\theta_{normal}$ das Modell legitimen Verhaltens repräsentiert und $\epsilon$ ein adaptiver Schwellenwert ist.

4. Vorgeschlagene Methodik

Unsere Architektur besteht aus drei Modulen: (1) eBPF-Sammler, (2) probabilistische Modellierungs-Engine, (3) Mitigations-Engine.

Algorithmus 1: Training des Verhaltensmodells

Input: Sequenzen S von Syscalls
Output: Modell M

1: Initialisiere Zähler C_k für k-Gramme
2: Für jede Sequenz S:
3:    Für i = 1 bis |S|-k:
4:        C_k[S_i...S_{i+k}]++
5: Schätze Wahrscheinlichkeiten P unter Verwendung von Laplace-Glättung
6: Gib M zurück

Algorithmus 2: Online-Erkennung

Input: Ereignis e_t, Modell M
Output: Alarm oder Normal

1: Aktualisiere Fenster W
2: Berechne P(W | M)
3: Falls P < ε dann
4:    Löse Alarm aus
5:    Wende restriktive Policy an

Komplexität: Training $O(nk)$; Online-Erkennung $O(k)$ pro Ereignis.

5. Implementierung

Wir implementierten den Sammler mit eBPF, gekoppelt an Kernel 5.15, und exportierten Ereignisse über perf buffers. Das Backend verwendet Apache Kafka für Streaming und Redis für temporäre Speicherung. Das Mitigationsmodul integriert sich in den Kubernetes Admission Controller und in CRI-O.

Wir entschieden uns für eBPF aufgrund des geringen Overheads (<2%) im Vergleich zu ptrace (>15%). Der experimentelle Cluster umfasst 48 Knoten, jeder mit 16 vCPUs und 64GB RAM.

6. Experimentelle Evaluation

Die Szenarien umfassen Escape-Angriffe, Privilege Escalation und Exfiltration. Metriken: Erkennungsrate (TPR), Fehlalarmrate (FPR), mittlere Erkennungszeit (MTTD).

Aggregierte Ergebnisse:

• TPR: 96,4% (±1,8%)
• FPR: 2,1% (±0,6%)
• MTTD: 1,3 s (vs. 1,7 s bei Falco)
• CPU-Overhead: 3,7%
• Speicher-Overhead: 4,2%

Bei T1611-Angriffen erreichte die Erkennung 98,2%. Im Vergleich dazu zeigte Falco eine FPR von 3,4%.

7. Diskussion

Die Ergebnisse zeigen, dass Modellierung variabler Ordnung kontextuelle Abhängigkeiten erfasst, die von vereinfachenden Ansätzen ignoriert werden. Die Reduktion von Fehlalarmen ist besonders relevant in hochgradig dynamischen CI/CD-Umgebungen.

Einschränkungen umfassen die Abhängigkeit von einer anfänglichen Trainingsphase und mögliche Umgehung durch Low-and-Slow-Angriffe.

8. Schlussfolgerung und zukünftige Arbeiten

Wir präsentierten CONTAINERSHIELD, einen formalen und empirischen Rahmen für die Sicherheit von Containern. Wir zeigten substanzielle quantitative Verbesserungen bei der Erkennung und Reduktion von Fehlalarmen bei minimalem Overhead.

Zukünftige Arbeiten umfassen die Integration von föderiertem Lernen über Cluster hinweg sowie formale Verifikation mittels Model Checking.

11. Referenzen

[1] P. Barham et al., “Xen and the Art of Virtualization,” SOSP, 2003.
[2] J. Merkel, “Docker: Lightweight Linux Containers,” Linux J., 2014.
[3] NIST SP 800-190, “Application Container Security Guide,” 2017.
[4] MITRE ATT&CK for Containers, 2023.
[5] A. Kivity et al., “kvm: the Linux Virtual Machine Monitor,” OLS, 2007.
[6] L. Torvalds, “Linux Kernel Documentation,” 2022.
[7] Sysdig, “2023 Cloud-Native Security Report.”
[8] Red Hat, “State of Kubernetes Security,” 2023.
[9] A. Madhavapeddy et al., “Unikernels,” ASPLOS, 2013.
[10] B. Burns et al., “Borg, Omega, and Kubernetes,” ACM Queue, 2016.
[11] CNCF, “Kubernetes Documentation,” 2024.
[12] Aqua Security, “Container Security Report,” 2023.
[13] D. Walsh, “SELinux and Containers,” Red Hat Summit, 2017.
[14] J. Corbet, “Namespaces in Operation,” LWN.net, 2013.
[15] S. Quinlan, “AppArmor,” USENIX, 2006.
[16] Falco Project Documentation, 2024.
[17] C. Kocher et al., “Spectre Attacks,” IEEE S&P, 2019.
[18] D. Borkmann, “eBPF and XDP,” Linux Plumbers, 2018.
[19] Google, “gVisor Documentation,” 2024.
[20] Open Policy Agent Documentation, 2024.