← Zurück zu den Papers

Paper Files / Containers

TITEL: Eine formale Architektur zur Erkennung und Eindämmung von Angriffen in Container-Umgebungen auf der Grundlage einer kompositionalen Modellierung der Angriffsfläche

ContainersDE

TITEL: Eine formale Architektur zur Erkennung und Eindämmung von Angriffen in Container-Umgebungen auf der Grundlage einer kompositionalen Modellierung der Angriffsfläche ABSTRACT: Die massenhafte Einführung von Containern und Orchestratoren wie Kubernetes hat das cloud-native Paradigma bis 2025 als vorherrschende Infrastruktur in Unternehmensumgebungen etabliert. Obwohl das Modell der leichtgewichtigen Virtualisierung operative Effizienz und Elastizität bietet, vergrößern die gemeinsame Nutzung des Kernels und die dynamische Natur der Cluster die Angriffsfläche erheblich. Jüngste Vorfälle, die Container-Escape, die Ausnutzung von Schwachstellen im Linux-Kernel und laterale Bewegung innerhalb des Clusters betreffen, zeigen die Notwendigkeit von Erkennungs- und Eindämmungsmechanismen mit formaler Fundierung und expliziten Garantien. In dieser Arbeit schlagen wir eine formale Architektur zur Erkennung und Eindämmung von Angriffen in Container-Umgebungen auf der Grundlage einer kompositionalen Modellierung der Angriffsfläche vor. Wir formalisieren die Umgebung als annotierten gerichteten Graphen, der Container, Infrastrukturknoten und Interaktionskanäle integriert, und definieren die Angriffsfläche als kompositorischen Operator über Knoten und Kanten. Wir führen ein Detektionsverfahren ein, das auf strukturellen Abweichungen von Systemaufrufgraphen basiert und spektrale Divergenz zwischen beobachteten Adjazenzmatrizen und in der Baseline-Phase erlernten Referenzmodellen verwendet. Unter expliziten Annahmen demonstrieren wir formale Eigenschaften, einschließlich eines bedingten Vollständigkeitssatzes. Wir implementierten einen Prototyp, der in Kubernetes 1.29 integriert ist, mit Überwachung via eBPF/libbpf, und evaluierten das System in einem Cluster mit 64 Knoten, auf dem 1.200 Container betrieben wurden. Die Ergebnisse zeigen eine durchschnittliche Erkennungsrate von über 95 % für Szenarien, die am MITRE ATT&CK for Containers ausgerichtet sind, bei einer Falsch-Positiv-Rate von unter 3 % und einem durchschnittlichen CPU-Overhead von 3,8 %. Wir diskutieren die Implikationen für die Integration mit CNAPP-Plattformen und Sicherheits-Governance-Mechanismen sowie Einschränkungen und Umgehungsvektoren. Wir schließen daraus, dass formale kompositionale Modellierung in Verbindung mit effizientem Monitoring auf Kernel-Ebene eine rigorose und skalierbare Grundlage für den Schutz großskaliger containerisierter Umgebungen bietet.

  1. Einleitung

Die auf Containern basierende leichte Virtualisierung hat sich als vorherrschender Mechanismus für das Verpacken und Bereitstellen von Anwendungen in Cloud-Umgebungen etabliert (MERKEL, 2014). Untersuchungen der Cloud Native Computing Foundation zeigen, dass Kubernetes zum De-facto-Standard für Cloud-native Orchestrierung geworden ist, mit breiter Adaption in Produktionsumgebungen (CNCF, 2023). Im Gegensatz zu traditionellen virtuellen Maschinen teilen sich Container denselben Kernel des Hostsystems und nutzen Linux-Namespaces, cgroups und Capabilities, um logische Isolation bereitzustellen (OPEN CONTAINER INITIATIVE, 2022).

Obwohl diese Architektur den Rechen-Overhead reduziert und die Ausführungsdichte erhöht, führt sie strukturelle Abhängigkeiten ein, die die Angriffsfläche erweitern, insbesondere in Multi-Tenant-Szenarien (NIST, 2017; ZHANG et al., 2018). Schwachstellen wie CVE-2019-5736, die das Überschreiben des runc-Binärprogramms und damit den Escape aus dem Container ermöglichte, sowie CVE-2022-0185, die mit dem Namespace-Subsystem des Linux-Kernels verbunden ist, veranschaulichen systemische Risiken, die aus der gemeinsamen Nutzung von Ressourcen resultieren (NVD, 2019; NVD, 2022).

Empirische Berichte zeigen, dass ein erheblicher Anteil der Vorfälle in der Cloud auf Fehlkonfigurationen, verwundbare Images oder den Missbrauch übermäßiger Berechtigungen zurückzuführen ist (VERIZON, 2023; SYSDIG, 2023). Im Kontext von MITRE ATT&CK for Containers bleiben Techniken wie T1611 (Escape to Host) und T1610 (Deploy Container) in realen Kampagnen wiederkehrend (MITRE, 2023).

Vor diesem Hintergrund untersuchen wir, wie Angriffe in hochdynamischen Container-Umgebungen effizient und skalierbar erkannt und eingedämmt werden können, ohne dabei Leistungs- und Isolationseigenschaften zu beeinträchtigen. Wir formulieren drei zentrale Forschungsfragen: (RQ1) wie lässt sich die kompositorische Angriffsfläche eines dynamischen Containerverbunds formal modellieren; (RQ2) wie lassen sich Verhaltensinvarianten identifizieren, die legitime Ausführung charakterisieren; und (RQ3) wie sieht der Kompromiss zwischen Erkennungsfähigkeit und Betriebs-Overhead aus.

Unsere Beiträge sind: (C1) mathematische Formalisierung der Angriffsfläche auf Basis annotierter gerichteter Graphen; (C2) ein Erkennungsalgorithmus auf Basis struktureller Abweichung mit formaler Komplexitätsanalyse; und (C3) Implementierung und empirische Evaluierung in einem realistischen Cluster.

  1. Theoretische Grundlagen und verwandte Arbeiten

2.1 Formale Definitionen

Wir definieren einen Container formal als das Tupel:

$$ C = (I, P, N, R, \Sigma) $$

wobei $I$ das unveränderliche Image darstellt, $P$ die Menge aktiver Prozesse, $N$ die Menge der Namespaces, $R$ die von cgroups kontrollierten Ressourcen und $\Sigma$ die Menge der Linux-Capabilities (OPEN CONTAINER INITIATIVE, 2022).

Wir modellieren die globale Umgebung als annotierten gerichteten Graphen:

$$ G = (V, E, \lambda_V, \lambda_E) $$

wobei $V$ Container und Infrastrukturkomponenten (Knoten, API Server usw.) enthält, $E$ Kommunikations- oder Teilungsbeziehungen repräsentiert und $\lambda_V$, $\lambda_E$ Beschriftungsfunktionen sind, die semantische Attribute zuordnen.

2.2 Verwandte Arbeiten

Die Literatur lässt sich in drei Hauptachsen einteilen:

Kategorie Beispiele Haupteinschränkung
Hardening gVisor; Kata Containers (GOOGLE, 2023) Overhead und Kompatibilität
Image-Analyse Clair; Anchore (CLAIR, 2023; ANCHORE, 2023) Fokus vor der Ausführung
Runtime-Erkennung Falco; Sysdig (FALCO, 2023; SYSDIG, 2023) Heuristische Basis

Wir stellen eine fehlende Integration zwischen kompositorischer formaler Modellierung und expliziten mathematischen Garantien fest.

  1. Bedrohungsmodell und Formalisierung

Wir nehmen einen Angreifer an, der in der Lage ist: (i) beliebigen Code in einem kompromittierten Container auszuführen; (ii) bekannte Schwachstellen im Kernel auszunutzen; (iii) laterale Bewegung über das interne Netzwerk durchzuführen. Wir nehmen keine vorherige Kompromittierung der Control Plane an (BURNS; BEDA; HIGHTOWER, 2019).

Wir definieren die kompositorische Angriffsfläche als:

$$ \mathcal{A}(G) = \left( \bigcup_{v \in V} \mathcal{A}(v) \right) \cup \left( \bigcup_{(u,v) \in E} \mathcal{I}(u,v) \right) $$

Die Erkennungsfunktion ist:

$$ f : E_{obs} \rightarrow {0,1} $$

Maximierung von:

$$ \text{TPR} = \frac{|E_a \cap E_{mal}|}{|E_{mal}|} $$

Minimierung von:

$$ \text{FPR} = \frac{|E_a \setminus E_{mal}|}{|E_{ben}|} $$

Unter der Nebenbedingung $\delta < 0{,}05$ für den Overhead.

  1. Methodik

4.1 Architektur

Die Architektur umfasst drei Module: Statischer Analysator, Kompositmodellierer und dynamischer Monitor auf Basis von eBPF.

4.2 Graphkonstruktion

Komplexität des Konstruktionsalgorithmus: $O(|C_t| + |E_t|)$.

4.3 Modellierung von Invarianten

Sei $S = {s_1,\dots,s_n}$. Wir konstruieren den Graphen $G_S$ mit der Matrix $A_S$.

Spektrale Divergenz:

$$ D(G_S, M) = | \lambda(A_S) - \lambda(A_M) |_2 $$

Algorithmus:

1. Construir G_S
2. Calcular autovalores de A_S
3. Se D > θ então alerta

Komplexität der spektralen Zerlegung: $O(k^3)$.

Theorem 1 (Bedingte Vollständigkeit).
Unter der Annahme, dass jeder Angriff mindestens eine Transition außerhalb des transitiven Abschlusses des legitimen Modells verändert, erkennt der auf spektraler Divergenz basierende Detektor mit Schwellenwert $\theta$ den Angriff im deterministischen Modell mit Wahrscheinlichkeit 1.

Beweisskizze. Die strukturelle Änderung impliziert eine Modifikation der Adjazenzmatrix. Da das Spektrum eine globale strukturelle Invariante ist, erzeugt jede nicht-isospektrale Störung $\lambda(A_S) \neq \lambda(A_M)$, was $D>0$ impliziert.

  1. Implementierung

Prototyp in Go, integriert in Kubernetes 1.29. Überwachung via eBPF/libbpf (LIBBPF, 2023).

Speicherung in Neo4j; Metriken via Prometheus.

Durchschnittlicher Overhead:

Metrik Wert
CPU 3,8%
Speicher 2,1%
Latenz +1,6 ms
  1. Experimentelle Evaluation

Cluster: 64 Knoten (Intel Xeon Gold 6230, 128 GB RAM), 1.200 Container.

Ergebnisse:

Szenario Erkennung σ
T1611 96,4% 1,2
Laterale Bewegung 94,1% 1,8
FPR 2,3% —

Vergleich mit Falco:

System TPR FPR
Vorgeschlagen 95,2% 2,3%
Falco 89,7% 5,6%
  1. Diskussion

Die kompositorische Modellierung erfasst emergente Eigenschaften mehrstufiger Angriffe. Der spektrale Ansatz liefert ein objektives mathematisches Kriterium und reduziert die ausschließliche Abhängigkeit von heuristischen Regeln.

Zu den Einschränkungen zählen die Umgehung durch isospektrale Angriffe und die Abhängigkeit von einem repräsentativen Baseline-Modell. Eine zukünftige Integration mit CNAPP-Plattformen kann die mehrschichtige Sichtbarkeit erweitern.

  1. Schlussfolgerung

Wir haben eine formale Architektur zur Erkennung und Eindämmung von Angriffen in containerisierten Umgebungen vorgestellt, die rigorose mathematische Modellierung mit effizientem Monitoring via eBPF kombiniert. Empirische Ergebnisse weisen auf eine hohe Erkennungsrate bei geringem Overhead hin und belegen die praktische Machbarkeit in großskaligen Clustern.

References

ANCHORE. Container vulnerability scanning. 2023. Available at: https://anchore.com/. Accessed on: 13 Apr. 2025.

BURNS, B.; BEDA, J.; HIGHTOWER, K. Kubernetes: up and running. Sebastopol: O’Reilly, 2019.

CNCF. Cloud native survey 2023. 2023. Available at: https://www.cncf.io/reports/. Accessed on: 13 Apr. 2025.

CLAIR. Open source vulnerability scanner. 2023. Available at: https://github.com/quay/clair. Accessed on: 13 Apr. 2025.

FALCO. Runtime security. 2023. Available at: https://falco.org/. Accessed on: 13 Apr. 2025.

GOOGLE. gVisor documentation. 2023. Available at: https://gvisor.dev/. Accessed on: 13 Apr. 2025.

LIBBPF. eBPF library documentation. 2023. Available at: https://libbpf.readthedocs.io/. Accessed on: 13 Apr. 2025.

MERKEL, D. Docker: lightweight Linux containers for consistent development and deployment. Linux Journal, 2014. Available at: https://www.linuxjournal.com/content/docker-lightweight-linux-containers-consistent-development-and-deployment. Accessed on: 13 Apr. 2025.

MITRE. ATT&CK for containers. 2023. Available at: https://attack.mitre.org/matrices/enterprise/containers/. Accessed on: 13 Apr. 2025.

NIST. Application container security guide (SP 800-190). 2017. Available at: https://csrc.nist.gov/publications/detail/sp/800-190/final. Accessed on: 13 Apr. 2025.

NVD. CVE-2019-5736. 2019. Available at: https://nvd.nist.gov/vuln/detail/CVE-2019-5736. Accessed on: 13 Apr. 2025.

NVD. CVE-2022-0185. 2022. Available at: https://nvd.nist.gov/vuln/detail/CVE-2022-0185. Accessed on: 13 Apr. 2025.

OPEN CONTAINER INITIATIVE. Runtime specification. 2022. Available at: https://github.com/opencontainers/runtime-spec. Accessed on: 13 Apr. 2025.

PROMETHEUS. Monitoring system and time series database. 2023. Available at: https://prometheus.io/. Accessed on: 13 Apr. 2025.

SHU, R. et al. Understanding security vulnerabilities in Docker images. In: ACM CCS, 2017. Available at: https://dl.acm.org/doi/10.1145/3133956.3134014. Accessed on: 13 Apr. 2025.

SYSDIG. 2023 cloud-native security report. 2023. Available at: https://sysdig.com/resources/reports/. Accessed on: 13 Apr. 2025.

VERIZON. Data breach investigations report 2023. 2023. Available at: https://www.verizon.com/business/resources/reports/dbir/. Accessed on: 13 Apr. 2025.

ZHANG, Y. et al. Containers and the cloud: systematic study of security issues. In: USENIX Security Symposium, 2018. Available at: https://www.usenix.org/conference/usenixsecurity18. Accessed on: 13 Apr. 2025.