Erkennung und Verhinderung von Container-Ausbruchsangriffen

Startseite » Python » Erkennung und Verhinderung von Container-Ausbruchsangriffen

Das Ausbrechen aus Containern ist zu einem Thema geworden, das Cloud- und Plattformteams schlaflose Nächte bereitet, denn ein einziger falsch konfigurierter Pod oder ein veralteter Kernel kann eine isolierte Arbeitslast in eine direkte Verbindung zum zugrunde liegenden Host verwandeln. In diesem Fall ist ein Angreifer nicht mehr auf einen einzelnen Container beschränkt: Er kann sich zwischen Knoten bewegen, auf Daten anderer Mandanten zugreifen oder sogar den gesamten Cluster übernehmen.

Das Verständnis der Funktionsweise von Container-Escapes – von Linux-Interna über Laufzeitsignale bis hin zu EDR-Erkennungen – entscheidet darüber, ob es sich nur um ein beängstigendes Schlagwort handelt oder um ein tatsächlich beherrschbares Risiko . In diesem Leitfaden erklären wir, was ein Container auf Betriebssystemebene ist, wie Escapes in der Praxis ablaufen, welche Angriffstechniken am häufigsten vorkommen und wie man sie mithilfe von Capabilities Monitoring, Falco-Regeln, CNAPP-Plattformen sowie bewährten Methoden zur Systemhärtung und -segmentierung erkennt und verhindert.

Was ist ein Container-Escape und warum ist er wichtig?

Ein Container-Escape liegt vor, wenn es einem Angreifer gelingt, die logische Isolation zu durchbrechen, die einen Container vom Host und von anderen Containern trennen soll . Anstatt auf seine eigenen Namespaces und Cgroups beschränkt zu sein, kann der Angreifer Code im Kontext des Hosts ausführen – oft mit hohen oder vollen Berechtigungen.

Container unterscheiden sich von virtuellen Maschinen in einem entscheidenden Punkt: Sie alle nutzen denselben Host-Kernel . Technologien wie Linux-Namespaces (PID, Mount, Netzwerk usw.), Cgroups und Capabilities unterteilen diesen Kernel in viele isolierte Bereiche. Wenn jedoch eine Schwachstelle oder Fehlkonfiguration es einem Angreifer ermöglicht, diese Grenzen zu überwinden, kann sich die Kompromittierung weit über den ursprünglich kompromittierten Container hinaus ausbreiten.

Aus geschäftlicher Sicht liegt die potenzielle Gefahr in den weitreichenden Folgen eines erfolgreichen Angriffs . Ein einziger angreifbarer, mit dem Internet verbundener Container kann zum Diebstahl sensibler Daten, zum großflächigen Einsatz von Kryptominern, zur Störung kritischer Dienste und zu erheblichen Compliance-Problemen in Multi-Tenant- oder regulierten Umgebungen führen.

Angreifer nutzen den Container-Escape typischerweise als einen Schritt in einer umfassenderen Angriffskette : Sie gelangen in einen Container mit geringen Berechtigungen (über Anwendungsfehler, schwache Anmeldeinformationen oder ein Problem in der Lieferkette), eskalieren die Berechtigungen innerhalb des Containers und brechen dann zum Host aus, um sich lateral zu bewegen, Anmeldeinformationen zu sammeln oder eine dauerhafte Persistenz wie ein Rootkit auf Kernel-Ebene herzustellen.

Wie Container im Detail funktionieren

Um Escape-Techniken wirklich zu verstehen, benötigt man zunächst ein mentales Modell davon, wie Linux-Container Prozesse isolieren . Ein Container ist im Wesentlichen ein Prozessbaum, dessen Attribute (Namespaces, Capabilities, Cgroups, Seccomp-Profil usw.) von einer Container-Laufzeitumgebung wie containerd, Docker oder CRI-O und allgemeineren Containerisierungstechnologien angepasst wurden.

Beim Start eines Containers erzeugt die Laufzeitumgebung einen Prozess und macht ihn zum „Init“-Prozess seines eigenen kleinen Universums : Er erhält einen eigenen PID-Namensraum, Mount-Namensraum, Netzwerk-Namensraum und weitere, die alle vom Kernel festgelegt werden. Dieser Prozess führt dann den in der Image-Konfiguration definierten Befehl aus (z. B. den ENTRYPOINT/CMD der Dockerfile).

Capabilities sind Linux' Methode, die traditionelle allmächtige Root-Berechtigung in kleinere Berechtigungsbausteine ​​zu zerlegen.Anstatt „Root kann alles“ definiert der Kernel Flags wie beispielsweise CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_SYSLOG und Dutzende weitere. Jeder Thread verfügt über Sätze von Berechtigungen (zulässige, effektive, vererbbare), die definieren, welche privilegierten Operationen er ausführen darf.

Namensräume beantworten die Frage „Wo kann ein Prozess seine Befugnisse ausüben?“Beispielsweise bewirkt der PID-Namensraum, dass die Prozess-ID 1 innerhalb des Containers nicht mit der Prozess-ID 1 auf dem Host verknüpft ist, und der Mount-Namensraum gibt dem Container seine eigene Dateisystemansicht. Selbst wenn ein Prozess über eine Berechtigung wie … verfügt. CAP_KILLIn einem begrenzten PID-Namensraum kann es nur Prozesse beenden, die in diesem Namensraum existieren.

Cgroups ergänzen diese Isolation, indem sie die Ressourcennutzung eines Containers steuern – CPU-Anteile, Speicherlimits, E/A und mehr. In Kombination mit seccomp-Filtern (Listen zum Erlauben/Verweigern von Systemaufrufen) und LSMs wie AppArmor oder SELinux ergibt sich die mehrschichtige Isolation, auf der moderne Container-Sicherheit basiert.

Warum Angreifer versuchen, aus Containern zu entkommen

Sobald ein Angreifer einen Container kompromittiert hat, stellt er schnell fest, dass das Leben darin ziemlich eingeschränkt ist : begrenztes Dateisystem, eingeschränkte Netzwerkansicht, möglicherweise kein Root-Zugriff und in der Regel kein direkter Zugriff auf andere Workloads.

Die Flucht zum Host beseitigt diese Schutzmechanismen.Wenn sie Befehle in den ursprünglichen Namensräumen des Hosts ausführen können, können sie alle Prozesse einsehen, jedes Dateisystem einbinden und Anmeldeinformationen von Orten wie … sammeln. /root/.ssh oder Cloud-Metadaten-Agenten und wechseln Sie zu anderen Containern oder VMs.

Escape-Mechanismen ermöglichen zudem schwer zu beseitigende Persistenz . Anstatt eine Hintertür nur in einem temporären Container einzufügen, könnte ein Angreifer ein Kernelmodul installieren, Container-Laufzeitumgebungen wie runc oder containerd manipulieren oder ein DaemonSet bereitstellen, das sicherstellt, dass ein mit einer Hintertür versehener Pod auf jedem Knoten in einem Kubernetes-Cluster ausgeführt wird.

Aus Sicht der Erkennung überschneiden sich viele verräterische Anzeichen für die Flucht aus einem Container mit klassischen Verhaltensweisen zur Rechteausweitung und lateralen Bewegung. – Laden des Kernelmoduls, verdächtig mount/unshare/setns Nutzung, direkter Zugriff auf Laufzeit-Sockets, SUID-Ausnutzung und anormale Dateizugriffe auf Hostpfade, die innerhalb von Containern offengelegt werden.

Hauptwege zur Ausflucht aus Containern: Sicherheitslücken, fehlende Berechtigungen und Fehlkonfigurationen.

Die meisten realen Container-Escape-Szenarien lassen sich in drei große Kategorien einteilen : Ausnutzen von Schwachstellen (Kernel oder Laufzeitumgebung), Missbrauch übermäßig privilegierter Container oder Ausnutzen von Fehlkonfigurationen wie gefährlichen Mounts und exponierten Sockets.

Kernel- und Container-Laufzeit-Schwachstellen

Da jeder Container den Host-Kernel gemeinsam nutzt, kann ein einzelner Kernel-Fehler einen direkten Weg zur Ausnutzung von Sicherheitslücken eröffnen . Bekannte Schwachstellen wie Dirty COW (CVE-2016-5195) und Dirty Pipe (CVE-2022-0847) sind lokale Fehler zur Rechteausweitung, die es Angreifern ermöglichen, schreibgeschützte Mappings und beliebige Dateien zu bearbeiten und so häufig die Binärdateien oder Konfigurationen des Hostsystems aus einem Container heraus zu manipulieren.

Ein besonders kritischer, containerspezifischer Fehler war CVE-2019-5736 in runc . Er ermöglichte es einem Prozess in einem Container, die runc-Binärdatei auf dem Host beim Start oder der Ausführung des Containers zu überschreiben, wodurch Angreifer Code auf Host-Ebene ausführen konnten. Da runc die Grundlage für Docker, Kubernetes und andere Plattformen bildet, waren die Auswirkungen weitreichend.

Neuere Veröffentlichungen wie „Leaky Vessels“ (z. B. CVE-2024-21626) haben gezeigt, dass auch Build-Systeme und Startprozesse ein leichtes Ziel für Angreifer darstellen . Schwachstellen in BuildKit oder der Initialisierungslogik von runc ermöglichen es Angreifern, während des Image-Builds oder beim frühen Start eines Containers auszubrechen, bevor andere Schutzmechanismen vollständig greifen können.

Auch Container-Laufzeitdienste wie containerd, Docker Engine oder CRI‐O hatten ihre Macken.Beispielsweise ermöglichte CVE-2022-23648 im CRI-Plugin von containerd Angreifern, die Container erstellen konnten, sensible Host-Pfade einzubinden (wie z. B. /root/.ssh) in einen Container und lesen Daten, die sie niemals sehen sollten, wodurch der erste Schritt zur vollständigen Flucht ermöglicht wird.

Bekannte CVEs für Container-Escape und wie man sie abmildern kann

• CVE-2019-5736 (runc) : Ermöglichte das Überschreiben der runc-Binärdatei des Hosts aus einem Container heraus und beeinträchtigte Docker, Kubernetes und andere runc-basierte Systeme. Zu den Abhilfemaßnahmen gehören das Einspielen von Patches, das Scannen von Images nach Exploit-Tools und die Laufzeitüberwachung von Änderungen an der runc-Binärdatei.

• CVE-2016-5195 (Dirty COW) : Eine Race Condition in Copy-on-Write ermöglicht es unprivilegierten Prozessen, Schreibzugriff auf schreibgeschützte Mappings zu erlangen . Innerhalb eines Containers kann dies ausgenutzt werden, um Hostdateien zu verändern, sofern diese über Mounts zugänglich sind.

• CVE-2022-0847 (Dirty Pipe) : Ein weiterer Kernel-Fehler, der unautorisierte Schreibvorgänge in Dateien ermöglicht, einschließlich solcher, die schreibgeschützt in Container eingebunden sind . Er gewährt keine automatische Ausnahme, lässt sich aber gut mit privilegierten Einbindungen oder Laufzeitfehlkonfigurationen kombinieren.

• CVE‑2024‑21626 und verwandte „Leaky Vessels“-Probleme : Schwachstellen in BuildKit und runc, die Host-Ressourcen während des Image-Builds oder des Container-Starts offenlegten und damit bewiesen, dass die Build-Pipeline selbst Teil der Angriffsfläche sein kann.

Die Gegenmaßnahmen für diese ganze Problemklasse drehen sich um Patch-Hygiene und Architekturentscheidungen : Host-Kernel müssen gepatcht bleiben, minimale oder distrolose Basis-Images sollten verwendet werden, um die Angriffsfläche zu verkleinern, für hochsensible Workloads sollten sandboxed oder VM-basierte Laufzeitumgebungen bevorzugt werden, und es muss kontinuierlich auf verdächtige Systemaufrufe und Dateischreibvorgänge überwacht werden, die wie Versuche zur Ausnutzung von Kernel-Schwachstellen aussehen.

Übermäßige Berechtigungen und privilegierte Container

Es wurden Fähigkeiten entwickelt, um die Macht der Wurzel zu reduzieren, aber in der Praxis werden die „kleinen Teile“ oft wieder zusammengefügt.Entwickler, die unter Druck stehen, „es einfach zum Laufen zu bringen“, gewähren häufig CAP_SYS_ADMIN oder einfach Container ausführen als --privileged, wodurch die wurzelähnliche Kraft im Inneren des Behälters effektiv wiederhergestellt wird.

CAP_SYS_ADMIN ist bekanntermaßen übermächtigEs ermöglicht das Einbinden von Dateisystemen, das Erstellen oder Zusammenführen von Namensräumen (unshare, setns), das Anpassen von cgroups und mehr. Mit der richtigen Kombination aus Mounts und Namespaces kann ein Angreifer mit diesen Fähigkeiten in den ursprünglichen Namespace des Hosts eindringen und globale Sichtbarkeit erlangen.

CAP_NET_ADMIN ist aus Netzwerkperspektive ähnlich breit gefächert.Es kann verwendet werden, um Schnittstellen neu zu konfigurieren, iptables-Regeln zu manipulieren und den Promiscuous-Modus zu aktivieren. In einer Escape-Chain könnte es missbraucht werden, um Datenverkehr abzufangen, Netzwerkrichtlinien zu umgehen oder Segmentierungen zu umgehen.

Einen Container im vollprivilegierten Modus auszuführen, bedeutet im Grunde: „Behandelt ihn wie einen Teil des Hostsystems .“ Er erhält alle Berechtigungen, kann auf Hostgeräte zugreifen und umgeht häufig Sicherheitsprofile. Bei vielen Angriffsketten besteht die größte Herausforderung darin, einen solchen falsch konfigurierten Container zu finden und ihn dann als Ausgangspunkt zu nutzen.

Moderne Tools wie Falco bieten mittlerweile Funktionen auf Thread-Ebene zur Erkennung von Thread-Verknüpfungen.Sie können nun Felder wie beispielsweise thread.cap_effective, thread.cap_permitted und thread.cap_inheritable zur Laufzeit und lösen Warnmeldungen aus, sobald ein Prozess mit riskanten Fähigkeiten verdächtige Aktionen ausführt.

Fehlkonfigurationen: Mounts, Sockets und Log-Tricks

Ein überraschend großer Anteil von Container-Ausbrüchen beruht nicht auf exotischen Zero-Day-Schwachstellen, sondern auf einfachen Fehlkonfigurationen . Wenn Betreiber sensible Host-Pfade in Container einbinden oder interne Unix-Sockets offenlegen, können Angreifer diese oft problemlos ausnutzen.

Gefährliche Hostpfade oder Volume-Mounts sind ein klassisches Beispiel.Wenn ein Container Lese- und Schreibzugriff auf Verzeichnisse wie /etc, /proc, /sys or /var/run Vom Wirt ausgehend bricht das Isolationsmodell weitgehend zusammen. Schreiben an /proc/sys oder sysfs kann Kernelparameter ändern; Zugriff auf Host-Konfigurationsdateien wie /etc/shadow können Zugangsdaten preisgeben.

Der Docker-Socket (/var/run/docker.sock) und andere Laufzeit-Sockets stellen eine weitere schmerzhafte Fehlkonfiguration dar.Durch die Einbindung in einen Container erhält derjenige, der den Container kontrolliert, nahezu die vollständige Kontrolle über den Docker-Daemon. curl --unix-socket Bei diesen Aufrufen kann ein Angreifer Container auflisten, einen neuen privilegierten Container erstellen, der das Host-Root-Verzeichnis einbindet, und aus diesem Hilfscontainer entkommen.

In Kubernetes wurden auch die Protokollverarbeitung von kubelet und die Host-Protokolleinbindungen missbraucht.Wenn ein Pod die Daten des Hosts enthält /var/log Wenn ein Angreifer Log-Symlinks manipulieren und Logs über die API lesen kann, ist es ihm möglicherweise möglich, einen Log-Symlink auf beliebige Host-Dateien zu verweisen und kubelet dazu zu bringen, beispielsweise Folgendes zurückzugeben: /etc/shadow Inhalte.

Selbst scheinbar einfaches SUID-Verhalten kann eine Rolle spielen . In Umgebungen, in denen der Container den Benutzer-Namensraum mit dem Host teilt, kann das Setzen des SUID-Bits einer Binärdatei in einem gemeinsam genutzten Verzeichnis innerhalb des Containers später von einem Host-Benutzer mit geringen Berechtigungen verwendet werden, um dieses Programm mit Root-Rechten auf dem Host auszuführen.

Ausbruchstechniken aus Betonbehältern in freier Wildbahn

Die detaillierte Betrachtung spezifischer Techniken anstelle von Kategorien hilft Ihnen, Muster in Telemetrie- und Bedrohungsberichten zu erkennen . Mehrere Methodenfamilien wurden von Forschern wiederholt demonstriert und in Penetrationstests oder realen Angriffen eingesetzt.

Benutzermodus-Hilfsfunktionen und die release_agent Trick

Der Linux-Kernel stellt eine Funktion bereit, call_usermodehelper, um Benutzerprogramme mit erhöhten Berechtigungen als Reaktion auf Ereignisse im Kernelbereich zu starten.Unter den richtigen Bedingungen können vom Benutzer kontrollierte Dateien Einfluss darauf nehmen, welches Programm ausgeführt wird, wodurch ein legitimer Mechanismus zu einem Ausweg wird.

Cgroups v1 release_agent ist das bekannteste Beispiel für dieses MusterWenn eine Cgroup leer wird und notify_on_release Wenn diese Option aktiviert ist, führt der Kernel die Binärdatei aus, auf die der Pfad verweist. release_agent Wenn ein Angreifer innerhalb eines Containers das cgroup-Dateisystem mit ausreichenden Berechtigungen einbinden und manipulieren kann, kann er darauf hinweisen release_agent bei einer beliebigen ausführbaren Datei auf dem Host.

Eine typische Exploit-Sequenz verläuft in etwa so:: Erstellen und Einbinden eines Cgroup-Verzeichnisses, Aktivieren notify_on_release, einstellen release_agent Anschließend wird der Pfad eines schädlichen Skripts im Host-Namensraum aufgerufen und die Prozessliste der Cgroup geleert. Der Kernel führt das Skript des Angreifers daraufhin bereitwillig mit root-ähnlichen Rechten auf dem Host aus.

Die Erkennung erfordert sowohl ein semantisches Verständnis der Pfade der Benutzermodus-Hilfsroutinen als auch Kontextinformationen darüber, woher die Änderungen stammen.Ein robuster Ansatz bildet alle ab call_usermodehelper Die Plattform erkennt Aufrufstellen, identifiziert solche, die von Benutzermodusdateien beeinflusst werden können, und überwacht dann Schreibvorgänge in diese Dateien, wenn sie aus Containern stammen, wobei verdächtige Änderungen gekennzeichnet werden.

Rechteausweitung auf den Host über SUID-Bits

Die SUID-Technik ist kein „reiner“ Container-Escape, da sie voraussetzt, dass der Angreifer bereits über gewisse Host-Zugriffe verfügt . Sie wird jedoch häufig mit Container-Zugriffen kombiniert, um von eingeschränkten Host-Benutzern zu Root-Rechten zu gelangen.

Der Trick beruht auf gemeinsam genutzten Verzeichnissen zwischen Host und Container sowie einem gemeinsamen Benutzer-Namespace.Aus einem als Root ausgeführten Container heraus legt ein Angreifer eine ausführbare Datei in ein für beide Seiten sichtbares Verzeichnis (z. B. ein gemeinsam genutztes Volume) ab und setzt das SUID-Bit. chmod u+s.

Später führt ein Benutzer ohne Root-Rechte auf dem Host diese Binärdatei aus und erlangt Root-Rechte , da das SUID-Bit im Host-Kontext interpretiert wird. Der Container dient als geeigneter Ort, um die SUID-Payload ohne die für diesen Host-Benutzer möglicherweise geltenden Einschränkungen vorzubereiten.

Die Überwachung von SUID-Missbrauch konzentriert sich auf drei Momente : das Erstellen einer ausführbaren Datei in einem freigegebenen Pfad, das Setzen der SUID/SGID-Bits aus einem Container und die Ausführung dieser Datei auf dem Host durch ein Benutzerkonto ohne Root-Rechte. EDR- und Laufzeitsicherheitstools können diese Schritte korrelieren, um hochpräzise Warnmeldungen auszulösen.

Laufzeit-Socket-Missbrauch: Docker und containerd

Containerumgebungen basieren häufig auf einer Client/Server-Architektur, bei der CLI-Tools oder Orchestratoren über Unix-Sockets mit Daemons kommunizieren.. Beispiele beinhalten /var/run/docker.sock für Docker oder /run/containerd/containerd.sock für containerd.

Wenn diese Socket-Dateien in einem Container eingebunden sind, kann dieser Container effektiv als Administrationsclient fungieren . Ein Angreifer, der den Container kompromittiert, kann API-Anfragen direkt an die Laufzeitumgebung senden, Container auflisten, Workloads starten und stoppen oder einen neuen privilegierten Container mit Host-Mounts erstellen.

Verwendung eines generischen Tools wie curlEs ist trivial, die Docker-Remote-API über einen Unix-Socket anzusprechen.: Abfrage /containers/json Um Container aufzulisten, senden Sie eine Nachricht an /containers/create mit einer JSON-Definition zum Erstellen eines privilegierten Helfers, dann aufrufen /containers/{id}/start Um es zu starten. Dieser Hilfscontainer kann das Root-Dateisystem des Hosts einbinden und dem Angreifer interaktiven Zugriff gewähren.

Die Verteidiger können dies auf verschiedene Weisen aufspüren.Überwachung des Zugriffs von containerisierten Prozessen auf Unix-Sockets zur Laufzeit und Erkennung verdächtiger Zugriffe curl --unix-socket oder Laufzeit-CLI-Aufrufe, die auf diese Sockets abzielen, und Warnungen bei ungewöhnlichen Container-Erstellungsmustern (z. B. HostPath-Mounts auf /, --privileged (in Kubernetes-Spezifikationen).

Kubernetes-spezifische Tricks: Log-Mounts und Pod-Escapes

In Kubernetes zielen einige Angriffe eher auf das Verhalten von Kubelets und Kubernetes-Abstraktionen als auf die grundlegenden Docker-Konzepte ab.Pods, die Hostverzeichnisse wie /var/log or /var/lib/docker sind für Gegner besonders interessant.

Eine demonstrierte Methode nutzt die Art und Weise aus, wie kubelet symbolische Links beim Zurückgeben von Protokollen auflöst.Jeder Pod erhält eine Protokolldatei unter /var/log das symbolische Links in das Verzeichnis des Containers unter /var/lib/docker/containersWenn ein Angreifer symbolische Links erstellen oder ändern kann in /var/log Über eine HostPath-Einbindung können sie ein „Log“ so umleiten, dass es auf eine beliebige Datei verweist (zum Beispiel, /etc/shadow).

Wenn ein Benutzer- oder Dienstkonto mit Leseberechtigungen für Protokolldateien aufruft kubectl logs oder der entsprechenden API, folgt kubelet dem symbolischen Link und gibt den Inhalt dieses Ziels zurück.Mit etwas Kreativität kann der Angreifer über eine Reihe solcher symbolisch verlinkter „Protokolldateien“ große Teile des Host-Dateisystems offenlegen.

Die hier angewandten Erkennungsmethoden kombinieren Netzwerk- und Dateisystemanalysen.: Überwachung der HTTP-Anfragen an die Kubernetes-Logs auf ungewöhnliche Pfadmuster und gleichzeitige Überwachung der Erstellung oder Änderung von Symlinks im Hostsystem /var/log die aus containerisierten Prozessen stammen.

Sensible Host-Mounts und direkter Datendiebstahl

Manchmal besteht ein Sicherheitsausbruch lediglich darin, Hostdaten aus einem Container heraus zu lesen oder zu verändern, ohne jemals Code auf Hostebene auszuführen . Fehlkonfigurierte Mounts, die sensible Verzeichnisse offenlegen, reichen aus, um schwerwiegende Folgen zu haben.

Ein Container könnte beispielsweise eine Mount-Anweisung wie diese haben: /host_etc auf den Gastgeber zeigend /etc VerzeichnisEin Angreifer, der auf diesen Pfad stößt, kann ihn einfach öffnen. /host_etc/passwd or /host_etc/shadow und sie lesen effektiv Host-Authentifizierungsdateien aus dem Container heraus.

Die Erkennung des Missbrauchs solcher Mounts ist schwierig, da viele Zugriffsmuster normalen Dateivorgängen ähneln.Man kann nicht einfach nur zusehen /etc/shadow Innerhalb von Containern bezieht sich dies üblicherweise auf die Datei des Containers selbst, nicht auf die des Hosts. Sie benötigen eine Mapping-Schicht, die den „Containerpfad“ für jede Einbindung in den „zugrunde liegenden Hostpfad“ umwandelt.

Moderne EDR- und CNAPP-Tools lösen dieses Problem, indem sie Mount-Punkte auflösen und Zugriffe anhand des Pfads auf dem Hostsystem verfolgen . Dadurch kann jeder Lese- oder Schreibvorgang, der letztendlich eine hostsensitive Datei betrifft – selbst über einen harmlos erscheinenden Pfad innerhalb des Containers – in Echtzeit erkannt werden.

Erkennung von Container-Ausbruchsversuchen zur Laufzeit

Präventive Härtung ist unerlässlich, aber Sie benötigen auch eine genaue Überwachung der Vorgänge während der Containerausführung . Moderne Angriffe bestehen oft aus mehreren aufeinanderfolgenden Schritten, und eine robuste Laufzeitüberwachung ermöglicht es Ihnen, diese Angriffskette zu erkennen, bevor sie den Host erreicht.

Moderne Erkennungsmethoden kombinieren typischerweise Telemetriedaten auf niedriger Ebene (z. B. eBPF-basierte Systemaufrufprotokolle) mit Verhaltensanalysen und Cloud-Kontextinformationen . Die Rohdaten stammen aus Systemaufrufen, Dateivorgängen, Prozessstrukturen und Socket-Aktivitäten; die Analyseschicht korreliert diese mit Identitäten, Netzwerkzugriffen und Cloud-Ressourcen, um harmlose Administratoraktionen von echten Ausbruchsversuchen zu unterscheiden.

Wichtige Indikatoren auf Systemaufrufebene

Bestimmte Systemaufrufe sind eng mit grenzüberschreitenden Aktivitäten verknüpft und sollten bei Aufruf durch Container besonders sorgfältig geprüft werden:

• mount, umount, pivot_root – Manipulation von Dateisystem-Mounts oder Drehung von Root-Verzeichnissen, oft verwendet, um Host-Pfade in einen Container einzubinden oder Chroots zu entkommen.

• setns, unshare – das Hinzufügen oder Erstellen neuer Namensräume, was ein Kernschritt bei Techniken ist, die in den ursprünglichen Namensraum des Hosts springen.

• ptrace – Debugging oder Einschleusen in andere Prozesse; verdächtig beim Überschreiten von Containergrenzen oder beim Angreifen von Systemdiensten.

• capset – Laufzeitmodifikation von Funktionen, die möglicherweise dazu genutzt werden, während der Ausführung neue, leistungsstarke Flags zu erhalten.

• init_module, finit_module – Das Laden von Kernelmodulen aus einem Container ist ein risikoreiches Vorgehen, das in legitimen Arbeitslasten selten erforderlich ist.

Regelbasierte Systeme wie Falco ermöglichen es, Erkennungslogik für diese Systemaufrufe containerbewusst auszudrücken.Beispielsweise können Sie eine Benachrichtigung einrichten, sobald ein containerisierter Prozess mit CAP_SYS_ADMIN öffnet eine Datei mit dem Namen release_agent zum Schreiben, was ein äußerst starker Indikator für einen auf Benutzermodus-Hilfen basierenden Ausstiegsversuch ist.

Verdächtige Dateizugriffsmuster

Die Überwachung der Dateiintegrität und des Zugriffs ergänzt Systemaufrufe, indem sie genau aufzeigt, welche Pfade ein Angreifer manipuliert . Betrachtet man dies im Kontext der Container-/Host-Zuordnung, wird es zu einem leistungsstarken Mechanismus zur Erkennung von Sicherheitslücken.

• Schreibt an /proc/sys or /sys Ein Containersignal versucht, Kernelparameter oder Geräteeinstellungen zu ändern.

• Zugriff auf Container-Runtime-Sockets wie /var/run/docker.sock or /run/containerd/containerd.sock ist ein Warnsignal, wenn es aus allgemeinen Anwendungscontainern stammt.

• Änderungen an /etc/passwd, /etc/shadow or /etc/sudoers auf dem Host über container-sichtbare Pfade Sieht nach Schritten zur Rechteausweitung und -persistenz aus.

• Liest aus /proc/*/environ or /proc/*/cmdline über Namensräume hinweg kann auf eine Aufzählung von Prozessen und das Sammeln von Anmeldeinformationen jenseits des eigenen Prozessbaums des Containers hinweisen.

Die zuverlässigsten Warnmeldungen kombinieren mehrere Faktoren – Pfad, Systemaufruf, Fähigkeiten und Container-Metadaten.. Zum Beispiel a mount Systemaufruf, der von einem nicht-administrativen, mit dem Internet verbundenen Anwendungscontainer stammt mit CAP_SYS_ADMIN und zielen /proc/sys ist weitaus alarmierender als derselbe Vorgang bei einem bekanntermaßen privilegierten Wartungsauftrag.

Prozessbezogene und Verhaltenssignale

Über reine Systemaufrufe und Dateiereignisse hinaus liefert das Verhalten übergeordneter Prozesse Aufschluss darüber, was vor sich geht . Bestimmte Aktivitäten sind in normalen Microservices äußerst selten, treten aber in der Phase nach einem Angriff häufig auf.

• Interaktive Hüllen, die aus nicht-interaktiven Containern erzeugt wurden (z.B, /bin/bash (die unter einem Webserverprozess erscheinen) deuten auf aktive Tastaturnutzung hin.

• Nutzung von Werkzeugen zur Rechteausweitung wie sudo, su or newgrp innerhalb von Behältern, insbesondere solche, die nicht für die interaktive Nutzung gedacht sind, sind höchst verdächtig.

• Netzwerkscanning, Werkzeuge zur lateralen Bewegung und ungewöhnliche ausgehende Verbindungen von Containern, die eigentlich nur mit einer kleinen Anzahl von Diensten kommunizieren sollten, deuten auf Aufklärungs- oder Ausbreitungsversuche hin.

• Signaturen von Kryptominern, unerwartet lange laufende, CPU-intensive Prozesse oder Spitzenwerte bei der GPU-Auslastung können darauf hindeuten, dass der Angreifer bereits seinen Zugriff auf Host-Ebene genutzt hat, um Ressourcen zu monetarisieren.

EDR- und CNAPP-Plattformen, die eine „Kausalitätskette“ (Prozessbaum mit Hierarchie und Umgebung) verwalten, spielen hier ihre Stärken aus . Sie ermöglichen es Analysten, verdächtige Vorgänge bis zum ursprünglichen Container-Image, der Kubernetes-Workload, dem Cloud-Konto oder der CI/CD-Pipeline zurückzuverfolgen, wodurch die Ursachenanalyse und langfristige Behebung effektiver werden.

Verhinderung von Containerausbrüchen: Tiefenverteidigung

Keine einzelne Kontrollmaßnahme kann garantieren, dass Sie niemals einem Ausbruchsversuch aus einem Container ausgesetzt sind. Daher benötigen Sie mehrschichtige Schutzmechanismen, die vom Code bis zur Cloud reichen . Dazu gehören Image-Hygiene, das Prinzip der minimalen Berechtigungen, gehärtete Konfigurationen, Netzwerkkontrollen und ein starker Laufzeitschutz.

Führen Sie Container mit den geringsten Berechtigungen aus

Beginnen Sie damit, unnötige Berechtigungen aus Containern konsequent zu entfernen . Vermeiden Sie den privilegierten Modus außer in sehr seltenen, streng kontrollierten Fällen und bevorzugen Sie rootlose Container oder Benutzer-Namespaces, sodass „root inside“ einem unprivilegierten Benutzer auf dem Host entspricht.

Nutzen Sie auf Kubernetes die SecurityContext-Einstellungen sinnvoll. Google Trends, Amazons Bestseller runAsNonRoot, runAsUser, allowPrivilegeEscalation: false und readOnlyRootFilesystem: trueDiese Einschränkungen begrenzen die Möglichkeiten eines Angreifers, selbst wenn er die Laufzeitumgebung der Anwendung vollständig kompromittiert.

Die Fähigkeiten sollten genau definiert sein.: Alles standardmäßig entfernen und nur die für die Arbeitslast minimal erforderlichen Komponenten hinzufügen. Wenn ein Container wirklich benötigt CAP_SYS_ADMIN or CAP_NET_ADMINBehandeln Sie es wie ein risikoreiches Asset und umgeben Sie es mit zusätzlicher Überwachung und Netzwerkisolierung.

Erkennungsregeln, die die Fähigkeitsfelder von Falco nutzen, können als Sicherheitsnetz für Fehlkonfigurationen dienen, die unbemerkt bleiben.Eine Regel könnte beispielsweise immer dann ausgelöst werden, wenn ein containerisierter Thread mit CAP_SYS_ADMIN und CAP_DAC_OVERRIDE schreibt in eine Datei namens release_agent, wodurch eine große Anzahl von Ausbruchsversuchen mit sehr geringem Rauschen erfasst werden konnte.

Sichern Sie die Container-Lieferkette

Die meisten Sicherheitslücken entstehen vor der Laufzeit, etwa durch anfällige oder manipulierte Images . Robuste Image-Sicherheit erschwert es Angreifern von vornherein, sich zuverlässigen Zugriff zu verschaffen.

Verwenden Sie gehärtete, minimale Basis-Images aus vertrauenswürdigen Registries und halten Sie diese aktuell . Kleinere Images mit weniger Paketen bedeuten weniger Bibliotheken, die potenziell ausnutzbare CVEs enthalten könnten, und Anbieter wie Wiz oder Distributionsbetreiber stellen mittlerweile „distrolose“ Basis-Images bereit, die nur das absolut Notwendige enthalten.

Integrieren Sie Schwachstellenscans und Software-Stücklisten (SBOMs) in CI/CD . Jeder Build sollte vor dem Hochladen in eine Registry gescannt werden, und Images mit ungepatchten, schwerwiegenden oder kritischen Fehlern, die für ihre Gefährdung und Berechtigungen relevant sind, sollten von der Bereitstellung ausgeschlossen werden.

Image-Vertrauensrichtlinien schließen den Kreislauf . Signieren Sie Images kryptografisch, konfigurieren Sie Zulassungscontroller so, dass sie unsignierte oder nicht vertrauenswürdige Images ablehnen, und behalten Sie im Laufe der Zeit den Überblick darüber, welche Images tatsächlich in Clustern ausgeführt werden, damit Sie riskante Artefakte umgehend entfernen können.

Schließlich sollte die Priorisierung der Behebung auf dem tatsächlichen Risiko und nicht auf der reinen Anzahl von CVEs basieren . Eine kritische Schwachstelle in einem ruhenden, nicht vernetzten Batch-Job, der ohne zusätzliche Berechtigungen läuft, ist weniger dringlich als ein „mittelschwerer“ Fehler in einem privilegierten, mit dem Internet verbundenen Pod, der sensible Daten verarbeitet.

Netzwerksegmentierung und Laufzeitschutz

Selbst wenn ein Angreifer in einen einzelnen Container eindringt, kann ein intelligentes Netzwerkdesign verhindern, dass er daraus einen vollständigen Clusterangriff entwickelt . Granulare Netzwerkrichtlinien, Firewalls und Service-Meshes tragen dazu bei, die laterale Ausbreitung einzuschränken.

Implementieren Sie in Kubernetes Netzwerkrichtlinien im Stil von Zulassungslisten , damit Pods nur mit den Diensten kommunizieren können, die sie tatsächlich benötigen. Dies schränkt die Möglichkeiten eines Angreifers ein, den Cluster zu scannen oder interne Management-APIs wie den Docker-Socket oder den Kubernetes-API-Server aufzurufen.

Laufzeitschutzsysteme fügen die Echtzeitbremsen hinzu.Wenn sie ein Verhalten feststellen, das auf einen Ausbruch aus einem Behälter hindeutet (zum Beispiel verdächtiges Verhalten), nsenter Verwendung, hostPath wird eingebunden an / oder Manipulation von containerd-Sockets), können sie Prozesse blockieren oder beenden, Container isolieren oder automatisch Vorfälle mit vollständiger forensischer Protokollierung öffnen.

Plattformen wie Wiz CNAPP kombinieren diese Laufzeiterkennungen mit Cloud-Kontext und einem Sicherheitsgraphen . Durch die Abbildung von Beziehungen zwischen Containern, Hosts, Identitäten und Datenspeichern zeigen sie nicht nur, dass ein Sicherheitsvorfall stattfindet, sondern auch, welche sensiblen Assets sich im Gefahrenbereich befinden, sodass Teams ihre Reaktion priorisieren können.

Kontinuierliche Überwachung und Einsatzbereitschaft

Container sind nur kurzlebig, was klassische forensische Analysen und Protokollauswertungen erschwert . Wird dies nicht von vornherein berücksichtigt, können die Beweise, die zum Verständnis eines Ausbruchs benötigt werden, beim erneuten Einplanen des Containers verloren gehen.

Richten Sie eine zentrale Protokollierung und Metrikenerfassung für Container-Laufzeitumgebungen, Orchestratoren und Hosts ein . Tools wie ELK, Prometheus und Cloud-native Protokollierungsdienste gewährleisten, dass Prozessaktivitäten, Sicherheitsereignisse und Konfigurationsänderungen auch bei kurzlebigen Workloads erfasst werden.

Erstellen Sie Playbooks speziell für Container-Escape-Szenarien . Diese sollten definieren, wie Knoten schnell isoliert, Festplatten-Snapshots erstellt, Container-Metadaten gesammelt und die Koordination mit Cloud-Anbietern oder Incident-Response-Teams sichergestellt werden kann, wenn ein Escape oder eine Kompromittierung auf Host-Ebene vermutet wird.

Anbieter wie Palo Alto Networks (Cortex XDR, Prisma Cloud) und andere haben umfangreiche Erkennungsinhalte rund um die hier beschriebenen Techniken entwickelt , von der Missbrauchserkennung von Benutzermodus-Hilfsprogrammen bis hin zur Ausnutzung von Socket-Laufzeitfehlern und dem Zugriff auf sensible Mount-Dateien. Dadurch erhalten die Verteidiger umsetzbare, kontextbezogene Warnmeldungen anstelle von allgemeinem Rauschen über „verdächtige Aktivitäten“.

Durch das Zusammenfügen all dieser Elemente – solide Linux-Isolationsgrundlagen, strenge Berechtigungen, gehärtete Images, Netzwerkkontrollen und umfassende Laufzeittransparenz – wird das Entkommen aus Containern von einer existenziellen Bedrohung zu einem beherrschbaren Risiko, das Ihr Team frühzeitig erkennen, effektiv eindämmen und aus dem es lernen kann, um Ihre Cloud-native Sicherheitslage im Laufe der Zeit weiter zu stärken.