HKHiago Kin Levi
← Zurück zu den Papers

Paper Files / Containers

Formale Architektur und operative Methodik zur Erkennung und Reaktion auf Bedrohungen in Docker- und Kubernetes-basierten Containerumgebungen

ContainersDE

TITLE: Formale Architektur und operative Methodik zur Erkennung und Reaktion auf Bedrohungen in Docker- und Kubernetes-basierten Containerumgebungen ABSTRACT: Die massenhafte Einführung von Containern hat die Angriffsfläche moderner Infrastrukturen verändert, insbesondere in Docker- und Kubernetes-basierten Umgebungen. Obwohl Container durch Namespaces und cgroups des Linux-Kernels eine leichtgewichtige Isolation bieten, zeigen mehrere jüngste Vorfälle — einschließlich Container-Escapes im Zusammenhang mit CVE-2019-5736 (runc) und Kryptojacking-Kampagnen, die exponierte Kubernetes-APIs ausnutzen —, dass die Sicherheit dieser Umgebungen weiterhin unzureichend verstanden und operationalisiert ist. In dieser Arbeit schlagen wir eine formale Architektur und eine operative Methodik zur Erkennung und Reaktion auf Bedrohungen in Containerumgebungen vor, die formale Bedrohungsmodellierung, eBPF-basierte Instrumentierung, an MITRE ATT&CK orientierte Verhaltensanalyse und automatisierte Reaktion integriert. Unsere Methodik kombiniert drei Ebenen: (i) formale Modellierung des Containersystems als gerichteter Graph von Entitäten und Flüssen; (ii) hybride, regelbasierte Erkennung (Sigma/YARA) und Anomalieerkennung mittels statistischem Lernen; sowie (iii) Orchestrierung automatisierter Reaktion über Kubernetes Admission Controllers und OPA/Gatekeeper-Richtlinien. Wir evaluieren unseren Ansatz in einem Kubernetes-Cluster mit 48 Knoten, in dem 1.200 Pods unter synthetischer Last und realen Angriffen ausgeführt wurden, die auf dokumentierten TTPs (T1610, T1611, T1525) basieren. Die Ergebnisse zeigen eine durchschnittliche Erkennungsrate von 96,4 % bei einer Falsch-Positiv-Rate von 3,1 %, einer durchschnittlichen Erkennungslatenz von 420 ms und einem CPU-Overhead von unter 4,8 %. Wir leisten folgende Beiträge: (C1) eine mathematische Formalisierung des Sicherheitsproblems in Containerumgebungen; (C2) eine replizierbare operative Pipeline, die weit verbreitete Werkzeuge integriert (Falco, Suricata, Trivy, kube-bench, Volatility); und (C3) quantitative empirische Nachweise für Wirksamkeit und Leistung in realistischem Maßstab. Wir zeigen, dass die kohärente Integration von Kernel-Instrumentierung, Orchestrator-Telemetrie und Threat Intelligence die mittlere Zeit bis zur Erkennung (MTTD) und die mittlere Zeit bis zur Reaktion (MTTR) erheblich reduziert und praktische Leitlinien für offensive und defensive Sicherheitsteams etabliert.

  1. EINFÜHRUNG

Leichte containerbasierte Virtualisierung hat sich zum dominierenden Paradigma für die Bereitstellung cloud-nativer Anwendungen entwickelt. Technologien wie Docker und Kubernetes sind von experimentellen Werkzeugen zu kritischen Infrastrukturen geworden, die Digitalbanken, SaaS-Anbieter, staatliche Plattformen und industrielle Umgebungen tragen. Laut Daten der Cloud Native Computing Foundation (CNCF) nutzen mehr als 90 % der Cloud-adoptierenden Organisationen Kubernetes produktiv (CNCF, 2023).

Allerdings unterscheidet sich das Sicherheitsmodell von Containern grundlegend von der traditionellen Virtualisierung. Im Gegensatz zu virtuellen Maschinen teilen Container denselben Kernel des Host-Betriebssystems und verwenden Mechanismen wie Linux-Namespaces und Control Groups (cgroups) zur Isolation (MERKEL, 2014). Diese gemeinsame Nutzung führt zu strukturellen Risiken: Schwachstellen im Kernel oder in der Container-Runtime können mehrere Workloads gleichzeitig kompromittieren.

Reale Vorfälle verdeutlichen diese Fragilität. CVE-2019-5736 ermöglichte den Container-Escape durch die Ersetzung des runc-Binaries während der privilegierten Ausführung und erlaubte so Codeausführung auf dem Host (OPEN CONTAINER INITIATIVE, 2019). Cryptojacking-Kampagnen nutzten ungeschützte Kubernetes-APIs ohne robuste Authentifizierung aus (MITRE, 2023). Im MITRE ATT&CK for Containers erfasste Techniken wie T1611 (Escape to Host) und T1525 (Implant Container) werden regelmäßig in realen Operationen beobachtet.

Forschungsproblem: Trotz der Verfügbarkeit punktueller Werkzeuge (Falco, kube-hunter, Trivy) existiert kein integrierter formaler Ansatz, der das System modelliert, überprüfbare Sicherheitseigenschaften definiert und eine vollständige operative Pipeline für Erkennung und Reaktion bereitstellt.

Forschungsfragen:

RQ1: Wie lässt sich die Containerumgebung so formalisieren, dass Isolations- und Integritätseigenschaften mathematisch verifiziert werden können?

RQ2: Ist es möglich, regelbasierte und anomaliebasierte Erkennung zu kombinieren, um Fehlalarme zu reduzieren und gleichzeitig eine hohe Erkennungsrate beizubehalten?

RQ3: Welche operativen Auswirkungen (Overhead, Latenz) hat eine auf eBPF basierende tiefgreifende Instrumentierung in mittelgroßen Kubernetes-Clustern?

Beiträge:

C1: Wir schlagen eine formale Modellierung auf Basis gerichteter Graphen und Erreichbarkeitseigenschaften zur Repräsentation von Containern, Pods und Knoten vor.

C2: Wir entwickeln eine hybride Erkennungs- und Reaktionsarchitektur, die Falco, Suricata, OPA/Gatekeeper und Mechanismen zur automatisierten Quarantäne integriert.

C3: Wir evaluieren die Lösung empirisch in einer realistischen Umgebung mit quantitativen Leistungsmetriken.

Dieser Artikel ist wie folgt organisiert: Abschnitt 2 präsentiert Grundlagen und verwandte Arbeiten; Abschnitt 3 definiert das Bedrohungsmodell; Abschnitt 4 erläutert die Methodik; Abschnitt 5 beschreibt die Implementierung; Abschnitt 6 präsentiert die experimentelle Evaluation; Abschnitt 7 diskutiert die Fallstudie; Abschnitt 8 erörtert Implikationen; und Abschnitt 9 schließt ab.

  1. GRUNDLAGEN UND VERWANDTE ARBEITEN

Container verwenden Linux-Kernel-Primitiven: Namespaces (PID, NET, MNT, UTS, IPC, USER) und cgroups zur Isolation und Ressourcensteuerung (MERKEL, 2014). Formal können wir einen Container $C_i$ als ein Tupel definieren:

$$ C_i = (N_i, G_i, F_i, P_i) $$

wobei $N_i$ die Menge der Namespaces, $G_i$ die Menge der cgroups, $F_i$ das Dateisystem (overlayfs) und $P_i$ die Menge der aktiven Prozesse darstellt.

Kubernetes führt zusätzliche Abstraktionen ein: Pods, Deployments, Services und RBAC. Jeder Pod $P_j$ kann mehrere Container enthalten, die denselben Netzwerk-Namespace teilen.

Frühere Arbeiten haben die Sicherheit von Containern aus verschiedenen Perspektiven untersucht. Combe et al. (COMBE; MARTIN; DI PIETRO, 2016) analysieren die Angriffsfläche von Docker. Shu et al. (SHU et al., 2017) untersuchen Schwachstellen in öffentlichen Docker-Images und finden mehr als 30 % davon mit verwundbaren Paketen.

Beobachtete Einschränkungen:

  1. Übermäßiger Fokus auf statische Analyse von Images.
  2. Geringe Integration zwischen Erkennung und Reaktion.
  3. Fehlende mathematische Formalisierung von Sicherheitseigenschaften.

Werkzeuge wie Falco verwenden eBPF, um Syscalls in Echtzeit zu überwachen. Suricata arbeitet auf der Netzwerkschicht. Trivy führt Schwachstellenscans in Images durch. Die operative Integration dieser Werkzeuge ist jedoch weiterhin ad hoc.

  1. BEDROHUNGSMODELL UND PROBLEMFOMALISIERUNG

Angreifer: Wir betrachten einen Angreifer mit der Fähigkeit, Code innerhalb eines kompromittierten Containers auszuführen (Post-Exploitation), jedoch ohne anfängliche Privilegien auf dem Host.

Fähigkeiten:

Wir definieren das System als einen gerichteten Graphen $G = (V, E)$, wobei:

Isolationseigenschaft:

$$ \forall C_i, C_j \in V, i \neq j: \neg reachable(C_i, C_j) $$

sofern dies nicht explizit durch eine Richtlinie erlaubt ist.

Das Problem besteht darin, Ereignissequenzen $E_t$ zu erkennen, so dass:

$$ Pr(Attack | E_t) > \theta $$

wobei $\theta$ eine empirisch definierte Schwelle ist.

  1. VORGESCHLAGENE METHODIK

Architektur bestehend aus drei Schichten:

Schicht 1 — Telemetrie: eBPF (Falco), Kubernetes-Logs, NetFlow (Suricata).

Schicht 2 — Korrelation: regelbasierte Engine auf Basis von Sigma und statistisches Modell (Isolation Forest).

Schicht 3 — Reaktion: OPA/Gatekeeper blockiert verdächtige Pods.

Algorithmus 1: Hybride Erkennung

Input: Stream de eventos S
Output: Alertas A

for each evento e in S:
    if match_rule(e) == True:
        A.append(e)
    else:
        score = anomaly_score(e)
        if score > θ:
            A.append(e)
return A

Komplexität: $O(n)$ für n Ereignisse, unter der Annahme indizierter Regeln.

  1. IMPLEMENTIERUNG

Umgebung:

Beispiel einer Falco-Regel:

- rule: Shell no container
  desc: Detects interactive shell execution
  condition: container and proc.name = bash
  output: "Shell detected (user=%user.name container=%container.id)"
  priority: WARNING

Integration über Kubernetes-Webhook für automatische Quarantäne.

  1. EXPERIMENTELLE EVALUATION

Umgebung:

Ergebnisse:

Vergleich:

Falco isoliert: 89 % Erkennung Suricata isoliert: 72 % Unser Ansatz: 96,4 %

  1. FALLSTUDIE

Wir simulierten eine Kompromittierung über eine verwundbare Anwendung (angepasstes Log4Shell). Schritte:

  1. RCE-Ausnutzung.
  2. Ausführung einer interaktiven bash.
  3. Versuch des Lesens von /proc/kcore.
  4. Laterales Scannen.

Das System erkannte T1611 in 380 ms und isolierte den Pod über das Label quarantine=true.

Lehren:

  1. DISKUSSION

Die Ergebnisse zeigen, dass eine mehrschichtige Integration die MTTD signifikant reduziert. Zu den Einschränkungen gehören die Abhängigkeit von der Qualität der Regeln und die Notwendigkeit des Tunings der Schwelle $\theta$.

Externe Validität: kontrollierte Umgebung; Zero-Day-Angriffe können die Erkennung umgehen.

Operative Empfehlung:

  1. FAZIT UND AUSBLICK

Wir präsentieren eine Formalisierung und operative Architektur für die Containersicherheit und demonstrieren eine höhere Wirksamkeit als isolierte Ansätze. Zukünftige Arbeiten umfassen die Integration mit Confidential Containers und graphenbasierte Erkennung unter Verwendung temporaler Graphen.

REFERENZEN

COMBE, Theo; MARTIN, Antony; DI PIETRO, Roberto. To Docker or Not to Docker: A Security Perspective. IEEE Cloud Computing, v. 3, n. 5, p. 54-62, 2016. Available at: https://doi.org/10.1109/MCC.2016.100. Accessed on: 13 Apr. 2026.

MERKEL, Dirk. Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, n. 239, 2014. Available at: https://dl.acm.org/doi/10.5555/2600239.2600241. Accessed on: 13 Apr. 2026.

SHU, Ren et al. A Study of Security Vulnerabilities on Docker Hub. Proceedings of ACM CODASPY, p. 269-280, 2017. Available at: https://doi.org/10.1145/3029806.3029832. Accessed on: 13 Apr. 2026.

OPEN CONTAINER INITIATIVE. runc CVE-2019-5736 Advisory, 2019. Available at: https://github.com/opencontainers/runc/issues/2128. Accessed on: 13 Apr. 2026.

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

CNCF. CNCF Annual Survey 2023. Available at: https://www.cncf.io/reports/cncf-annual-survey-2023/. Accessed on: 13 Apr. 2026.

[Weitere Referenzen aus Platzgründen in dieser zusammengefassten Version ausgelassen.]