Linux & Cloud Detection Engineering – Erste Schritte mit Defend for Containers (D4C)

Einführung

Linux-Systeme bleiben eine entscheidende Grundlage für moderne Infrastrukturen, insbesondere in Cloud-nativen Umgebungen, in denen Container und Orchestrierungsplattformen die Norm sind. Da sich Arbeitslasten von langlebigen Hosts auf kurzlebige Container verlagern, ändert sich auch die Vorgehensweise der Angreifer. Aktivitäten, die früher dauerhafte Spuren auf der Festplatte hinterließen, beschränken sich zunehmend auf kurzlebige Laufzeitvorgänge, die mit herkömmlichen Protokollierungsmethoden nur schwer zu erfassen sind.

Die Erkennungsentwicklung in diesen Umgebungen hängt daher stark von der Laufzeittransparenz ab. Das Verständnis dafür, wie Prozesse innerhalb von Containern ausgeführt werden, wie auf Dateien zugegriffen wird und wie Workloads mit dem Host interagieren, wird wichtiger als die Abhängigkeit von statischen Indikatoren oder Artefakten nach einem Vorfall.

Elastic stellt mehrere Linux-spezifische Telemetriequellen zur Verfügung, um diese Art von Erkennungsarbeit zu unterstützen. In früheren Beiträgen dieser Reihe haben wir uns auf die Transparenz auf Hostebene mithilfe von Auditd und Auditd Manager konzentriert und gezeigt, wie Systemereignisse auf niedriger Ebene in hochpräzise Erkennungen übersetzt werden können. In diesem Beitrag rückt Elastic's Defend for Containers in den Fokus: eine Laufzeit-Sicherheitsintegration, die speziell für containerisierte Linux-Workloads entwickelt wurde.

Ziel dieses Artikels ist es nicht, jede einzelne Funktion von Defend for Containers zu dokumentieren, sondern den Erkennungsingenieuren einen praktischen Ausgangspunkt zu bieten: welche Daten die Integration erzeugt und wie man diese Daten auswertet. Im nächsten Teil werden wir uns ansehen, wie es auf realistische Containerangriffsszenarien angewendet werden kann.

Optimierte Transparenz mit Defend for Containers

Wir freuen uns, die Veröffentlichung von Defend for Containers in Version 9.3.0 bekanntzugeben. freigeben. Diese Integration ermöglicht einen optimierten Ansatz für die Containersicherheit und bietet eine solide Grundlage für die Transparenz in Cloud-nativen Infrastrukturen. Benutzer können eine Reihe von Erkennungsregeln nutzen, die speziell zum Schutz vor modernen Kubernetes-Bedrohungen und containerspezifischen Schwachstellen entwickelt wurden. Mit der Einführung von Defend for Containers wird ein containerspezifischer Regelsatz zur Erkennung bereitgestellt, der auf realistischen Bedrohungsmodellen für Container und Kubernetes basiert.

Zum Zeitpunkt der Erstellung dieses Dokuments bietet das Defend for Containers-Regelwerk eine grundlegende Abdeckung für gängige Container-Angriffstechniken, einschließlich Aufklärungsaktivitäten, Zugriffsversuche auf Anmeldeinformationen, Kubelet-Angriffe, Missbrauch von Service-Account-Token, interaktive Prozessausführung, Dateierstellung und -änderung, Interpreter-Missbrauch, Ausführung kodierter Nutzdaten, Tool-Installation, Tunneling-Verhalten und mehrere Vektoren zur Rechteausweitung. Wichtig ist, dass alle bestehenden container- und Kubernetes-spezifischen Erkennungsregeln mit Defend for Containers kompatibel gemacht wurden, sodass die zuvor hostzentrierte Logik direkt auf die Laufzeittelemetrie des Containers angewendet werden kann.

Damit wird Defend for Containers zu einer praktischen und sofort nutzbaren Datenquelle für Linux-Erkennungsingenieure, die sich auf verhaltensbasierte Laufzeiterkennung konzentrieren. Im weiteren Verlauf dieses Beitrags wird erläutert, wie diese Telemetrie in der Praxis aussieht und wie sie auf reale Containerangriffsszenarien angewendet werden kann.

Einführung in Defend for Containers

Defend for Containers ist eine Laufzeit-Sicherheitsintegration, die Einblick in Linux-Container während ihrer Ausführung bietet. Anstatt sich auf statisches Image-Scanning oder Protokolle nach der Ausführung zu verlassen, konzentriert es sich auf die Beobachtung des Containerverhaltens in Echtzeit.

Defend for Containers erfasst auf einer übergeordneten Ebene sicherheitsrelevante Laufzeitereignisse von laufenden Containern, wie z. B. die Prozessausführung und den Dateizugriff. Diese Ereignisse werden mit Container- und Orchestrierungskontext angereichert und an Elasticsearch übermittelt, wo sie analysiert und als Eingabe für Erkennungsregeln verwendet werden können.

Aus Sicht der Erkennungstechnik positioniert sich Defend for Containers an der Schnittstelle zwischen dem traditionellen Linux-Verhalten und dem Containerkontext. Prozesse, Systemaufrufe und Dateiaktivität bleiben Kernsignale, sind aber jetzt auf Container, Namensräume und Workloads beschränkt, die möglicherweise nur kurzzeitig existieren.

Defend for Containers wird als Teil des Elastic Agent bereitgestellt und integriert sich direkt in Elastic Security. Nach der Aktivierung stellt es einen dedizierten Datenstrom von Container-Laufzeitereignissen bereit, der mit KQL oder ES|QL abgefragt oder direkt von Erkennungsanalysen genutzt werden kann. Dies ermöglicht es den Erkennungsingenieuren, vertraute Analysetechniken anzuwenden und gleichzeitig die betrieblichen Gegebenheiten cloudnativer Workloads zu berücksichtigen.

In den folgenden Abschnitten werden wir die Defend for Containers-Ereignisse genauer untersuchen und verschiedene Container-Angriffsszenarien durchgehen, um zu veranschaulichen, wie diese Daten in der Praxis genutzt werden können.

Einrichtung von Defend for Containers

Bevor Sie die Laufzeit-Transparenz und Analysefunktionen von Defend for Containers nutzen können, müssen Sie die Integration bereitstellen und eine Richtlinie konfigurieren, die definiert, welche Ereignisse beobachtet und welche Aktionen bei entsprechenden Aktivitäten ausgeführt werden sollen. Weitere Informationen zur Integration und deren Einrichtung finden Sie hier. Im Wesentlichen besteht dieses Setup aus Folgendem:

1. Bereitstellung der Defend for Containers-Integration über Elastic Agent in Ihrer Kubernetes-Umgebung.
2. Die Konfiguration oder Anpassung der Defend for Containers-Richtlinie, die aus Selektoren besteht, welche Operationen übereinstimmen sollen, und Antworten, die festlegen, welche Aktionen ausgeführt werden sollen.
3. Validierung und Verfeinerung der Richtlinie auf Basis des beobachteten Arbeitslastverhaltens.

Bereitstellungsmethoden

Defend for Containers wird als Elastic Agent-Integration bereitgestellt und nutzt Elastic Agent, um Container-Laufzeittelemetrie zu erfassen und an Ihren Elastic Stack weiterzuleiten. Bei Kubernetes-Workloads installieren Sie die Integration über die Elastic Security-Benutzeroberfläche und registrieren dann Agenten auf Ihren Clusterknoten.

Der grundlegende Bereitstellungsablauf ist wie folgt:

Navigieren Sie in der Elastic Security-Benutzeroberfläche zu Fleet und erstellen Sie eine neue Agentenrichtlinie (oder fügen Sie die Integration zu einer bestehenden hinzu). Sobald die Agentenrichtlinie erstellt ist, können wir die „Defend for Containers“-Integration zur Richtlinie hinzufügen.

Geben Sie der Integration einen Namen und passen Sie optional die Standardselektoren und -antworten an (wir werden die verfügbaren Optionen weiter unten in dieser Veröffentlichung genauer betrachten). Sobald „Integration hinzufügen“ ausgewählt ist, sollte eine neue Agentenrichtlinie mit der korrekten Integration verfügbar sein.

Für diese Demonstration werden wir die Kubernetes-Bereitstellungsmethode nutzen. Um diese Richtlinie für eine Arbeitslast bereitzustellen, können wir zu Aktionen → Agent hinzufügen → Kubernetes navigieren. Hier sehen wir Anweisungen zum Kopieren oder Herunterladen des Kubernetes-Manifests.

Wichtiger Hinweis: „ Das folgende Manifest enthält Ressourcenbeschränkungen, die für eine Produktionsumgebung möglicherweise nicht geeignet sind. Lesen Sie vor der Bereitstellung dieses Manifests unseren Leitfaden zum Skalieren des Elastic Agent auf Kubernetes .“

Damit der Dienst funktioniert, müssen Sie Folgendes capabilities unter securityContext in Ihre Kubernetes-YAML-Datei einfügen:

securityContext:
    runAsUser: 0
    capabilities:
      add:
        - BPF ## Enables both BPF & eBPF
        - PERFMON
        - SYS_RESOURCE

Nach dem Kopieren oder Herunterladen des bereitgestellten elastic-agent-managed-kubernetes.yml -Manifests können Sie das Manifest nach Bedarf bearbeiten und anschließend anwenden mit:

kubectl apply -f elastic-agent-managed-kubernetes.yml

Wie auch im Manifest erwähnt, finden Sie weitere Informationen zur Bereitstellung im Leitfaden „ Ausführen des Elastic Agent auf einem von Fleet verwalteten Kubernetes-System“.

Warten Sie, bis die Elastic Agent-Pods eingeplant sind und die Daten in Elasticsearch fließen.

Nach der Bereitstellung stellt Elastic Agent eine Verbindung zu Fleet her, registriert sich gemäß der ausgewählten Richtlinie und beginnt mit der Ausgabe von Defend for Containers-Telemetriedaten, die Elastic Security verarbeiten kann.

Im nächsten Abschnitt werden wir uns die Konfigurationsoptionen für die Integration ansehen und untersuchen, welche Funktionen zur Verfügung stehen.

Richtlinien zur Verteidigung von Containern

Das Herzstück der Konfiguration von Defend for Containers ist die Richtlinie. Richtlinien legen fest, welche Aktivitäten beobachtet werden und wie bei entsprechenden Ereignissen reagiert wird. Politische Maßnahmen bestehen aus zwei grundlegenden Bausteinen:

• Selektoren: Sie definieren, welche Ereignisse von Interesse sind, indem sie Operationen und Bedingungen festlegen;
• Antworten: Definieren Sie, welche Aktionen ausgeführt werden sollen, wenn die Bedingungen eines Selektors erfüllt sind.

Die Richtlinien von Defend for Containers können vor der Bereitstellung bearbeitet oder nach der Bereitstellung über den Richtlinieneditor der Elastic Security-Benutzeroberfläche geändert werden.

Politikstruktur

Jede Richtlinie muss mindestens einen Selektor und mindestens eine Antwort enthalten. Ein typischer Selektor gibt eine oder mehrere Operationen (wie Prozessereignisse oder Dateiaktivitäten) an und verwendet Bedingungen (wie Container-Image-Name, Namespace oder Pod-Label), um den Umfang einzugrenzen. Die Antworten beziehen sich auf Selektoren und geben an, welche Aktion bei Übereinstimmung der Ereignisse ausgeführt werden soll.

Die Standardrichtlinie „Defend for Containers“ umfasst zwei Selektor-Antwort-Paare: „Bedrohungserkennung“ und „Drift-Erkennung und -Prävention“.

Bedrohungserkennung: Ein selector mit dem Namen allProcesses entspricht allen fork und exec Ereignissen aus Containern.

Und dem zugehörigen response ist die Aktion auf Log gesetzt, wodurch sichergestellt wird, dass Ereignisse erfasst und analysiert werden können.

Drifterkennung und -vermeidung: Ein Selektor mit dem Namen executableChanges entspricht den Operationen createExecutable und modifyExecutable .

Die Antwort ist so konfiguriert, dass Warnmeldungen erzeugt werden (und kann so angepasst werden, dass diese Vorgänge blockiert werden).

Diese können über die Benutzeroberfläche geändert werden, aber im Hintergrund handelt es sich bei diesen Richtlinien um einfache YAML-Konfigurationsdateien, die leicht geändert und in beliebigen CI/CD-Abläufen verwendet werden können:

process:
  selectors:
    - name: allProcesses
      operation:
        - fork
        - exec
  responses:
    - match:
        - allProcesses
      actions:
        - log
file:
  selectors:
    - name: executableChanges
      operation:
        - createExecutable
        - modifyExecutable
  responses:
    - match:
        - executableChanges
      actions:
        - alert

Als nächstes werden wir uns einige Beispielselektoren und -antworten ansehen und die Möglichkeiten besprechen, die Ihnen zur Verfügung stehen, um die Integration nach Ihren Wünschen einzurichten.

Beispiel-Selektor-Snippet

Selektoren ermöglichen eine detaillierte Übereinstimmung mithilfe von Bedingungen für Felder wie zum Beispiel:

• containerImageFullName: vollständige Bildnamen wie docker.io/nginx;
• containerImageName: Teilbildnamen;
• containerImageTag: spezifische Schlagwörter wie neueste;
• kubernetesClusterId: Kubernetes-Cluster-IDs;
• kubernetesClusterName: Kubernetes-Clusternamen;
• kubernetesNamespace: Namensräume, in denen die Arbeitslast ausgeführt wird;
• kubernetesPodName: Pod-Namen, mit Unterstützung für nachfolgende Wildcards;
• kubernetesPodLabel: Beschriftung von Schlüssel/Wert-Paaren mit Unterstützung für Platzhalter.

selectors:
  - name: nodeExports
    file:
      operations:
        - createExecutable
        - modifyExecutable
      containerImageName:
        - "nginx"
      kubernetesNamespace:
        - "prod-*"

In diesem Beispiel entspricht der Selektor mit der Bezeichnung nodeExports Dateiereignissen, die ausführbare Dateien in Containern erstellen oder ändern, deren Image-Namen „nginx“ enthalten und deren Kubernetes-Namespace mit “prod-” beginnt.

Beispiel eines Antwortausschnitts

Die Reaktionen bestimmen, was passiert, wenn die Selektorbedingungen erfüllt sind. Übliche Maßnahmen sind:

• log: Das Ereignis als Telemetrie zur Analyse senden;
• alert: Erstellen einer Warnung in Elastic Security;
• block: Die Operation verhindern (für unterstützte Typen).

responses:
  - name: alertAndBlockNodeExports
    matchSelectors:
      - nodeExports
    actions:
      - alert
      - block

Hierbei bezieht sich die Antwort mit dem Namen alertAndBlockNodeExports auf den zuvor definierten Selektor nodeExports und wird sowohl eine Warnung auslösen als auch den Vorgang blockieren.

Wildcards und passende

Die Selektoren in Defend for Containers unterstützen nachfolgende Wildcards in zeichenkettenbasierten Bedingungen (wie Pod-Namen oder Image-Tags). Dies ermöglicht eine breite Übereinstimmung, ohne jeden möglichen Wert einzeln aufzählen zu müssen. Beispielsweise findet ein Pod-Selektor von backend-* alle Pods, deren Namen mit backend- beginnen, während eine Label-Bedingung wie role:api* Label-Werte findet, die mit api beginnen.

Diese Wildcard-Funktion ist in dynamischen Umgebungen unerlässlich, in denen Arbeitslasten schnell skalieren und sich verändern.

Zusätzlich zur einfachen Zeichenkettenübereinstimmung unterstützen die Selektoren von Defend for Containers auch pfadbasierte Wildcard-Semantik beim Abgleich von Dateipfaden. Betrachten Sie das folgende Selektorbeispiel:

- name:
  targetFilePath:
    - /usr/bin/echo
    - /usr/sbin/*
    - /usr/local/**

Dieses Beispiel umfasst Folgendes:

• /usr/bin/echo Passt nur zum echo -Binärwert an genau diesem Pfad.
• /usr/sbin/* Passt zu allem, was ein direktes Kind von /usr/sbin ist.
• /usr/local/** Passt rekursiv auf alles unter /usr/local, einschließlich Pfaden wie /usr/local/bin/something.

Durch diese Unterscheidungen ist es möglich, dateibasierte Selektoren präzise einzugrenzen und dabei Abdeckung und Rauschen in Einklang zu bringen. In der Praxis ermöglichen sie es Erkennungsingenieuren, je nach Anwendungsfall gezielt bestimmte Binärdateien, ganze Verzeichnisse oder tief verschachtelte Verzeichnisstrukturen zu identifizieren, ohne auf übermäßig permissive Regeln zurückgreifen zu müssen.

Das Ganze zusammenfassen

Bis hierhin haben wir uns mit den Selektoren von Defend for Containers, der Wildcard-Semantik, den Ereignistypen und der Art und Weise, wie sie das Verhalten von Angreifern zur Laufzeit sichtbar machen, beschäftigt. Der letzte Schritt besteht darin, zu verstehen, wie diese einzelnen Elemente innerhalb einer Richtlinie zusammenwirken, um eine reale Erkennungslogik auszudrücken.

Betrachten Sie den folgenden Politikabschnitt:

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

Diese Richtlinie definiert drei Selektoren. Zwei Selektoren (binDirExeMods und etcFileChanges) beschreiben die Dateisystemaktivität von Interesse, während der dritte Selektor (nginx) einen auszuschließenden Containerkontext beschreibt.

Der Antwortteil verknüpft diese Selektoren. Die unter match aufgeführten Selektoren sind logisch OR'd, was bedeutet, dass jede der beiden Bedingungen ausreicht, um die Antwort auszulösen. Der unter exclude aufgeführte Selektor fungiert als logischer NOT und entfernt übereinstimmende Ereignisse, wenn das Container-Image nginx ist.

In einfachen Worten ausgedrückt, drückt die Richtlinie folgende Logik aus:

Wenn eine ausführbare Datei irgendwo unter /usr/bin erstellt oder geändert wird oder eine Datei unter /etc erstellt, geändert oder gelöscht wird und die Aktivität nicht von einem nginx -Container ausgeht, dann generieren Sie eine Warnung und blockieren Sie die Aktion.

In boolescher Form lässt sich dies wie folgt ausdrücken:

IF (binDirExeMods OR etcFileChanges) AND NOT nginx
→ alert + block

Hier entfalten die Richtlinien von Defend for Containers ihre volle Wirkung. Anstatt komplexe Erkennungslogik in einer Abfragesprache zu schreiben, ermöglichen Selektoren es, das Verhalten in kleine, wiederverwendbare Bausteine zu zerlegen und diese dann deklarativ zu kombinieren. Durch die Kombination von pfadbasierten Selektoren, Operationstypen, Containerkontext und Ausschlüssen lässt sich eine differenzierte Erkennungslogik ausdrücken, die lesbar und wartbar bleibt.

In der Praxis ermöglicht dieses Modell den Erkennungsingenieuren, Bedrohungshypothesen direkt in Richtlinienlogik zu übersetzen: welches Verhalten relevant ist, wo es auftritt, in welchen Arbeitslasten, und was dann geschehen soll .

Richtlinienvalidierung und -verfeinerung

Sobald eine Richtlinie implementiert ist, ist es entscheidend, sie anhand des tatsächlichen Arbeitslastverhaltens zu validieren, bevor aggressive Reaktionen wie das Blockieren aktiviert werden. Zu restriktive Richtlinien können den normalen Containerbetrieb stören; zu permissive Richtlinien können dazu führen, dass unerwünschte Aktivitäten unbemerkt bleiben.

Ein empfohlener Arbeitsablauf ist:

1. Die Standardrichtlinie im Überwachungsmodus bereitstellen (z. B. mit Selektoren, die Ereignisse protokollieren).
2. Beobachten Sie die Ereignisse, die in Elasticsearch auftreten, um normale Arbeitslastmuster zu verstehen.
3. Die Selektoren und Reaktionen schrittweise verschärfen, beginnend mit „Nur protokollieren“ → „Warnung“ → „Blockieren“, wobei in jeder Phase Tests durchgeführt werden.
4. Verwenden Sie einen Staging- oder Testcluster, um blockierende Verhaltensweisen zu validieren, bevor Sie sie in der Produktionsumgebung anwenden.

Defend for Containers Beta-Einschränkungen

Zum jetzigen Zeitpunkt ist Defend for Containers als Beta-Integration verfügbar, und die aktuellen Funktionen und die Plattformunterstützung spiegeln diesen Status wider.

Defend for Containers unterstützt offiziell Amazon EKS und Google GKE. Die Integration kann zwar auf Azure AKS bereitgestellt werden, diese Konfiguration wird jedoch nicht offiziell unterstützt. Insbesondere fehlt es AKS-Implementierungen derzeit an Dateiereignis-Telemetrie, was die Erkennungsabdeckung für dateibasierte Angriffstechniken in diesen Umgebungen einschränkt.

Die aktuelle Beta-Version erfasst auch keine Netzwerkereignisse. Daher müssen Erkennungen im Zusammenhang mit ausgehenden Verbindungen, lateraler Netzwerkbewegung oder Datenexfiltration auf ergänzende Datenquellen wie die Network Packet Capture-Integration oder Packetbeat- Integrationen zurückgreifen und dürfen sich nicht allein auf die Telemetrie von Defend for Containers stützen.

Bei Dateiaktivitäten protokolliert Defend for Containers absichtlich nur dann Dateiöffnungsereignisse, wenn die Datei mit Schreibabsicht geöffnet wird. Diese Designentscheidung reduziert das Rauschen und konzentriert sich auf Verhaltensweisen, die den Systemzustand verändern. Dies bedeutet jedoch auch, dass der Lesezugriff auf sensible Dateien, wie etwa die Ermittlung von Geheimnissen, das Auslesen von Konfigurationen oder fehlgeschlagene Zugriffsversuche, derzeit nicht beobachtbar ist.

Diese Einschränkung wirkt sich auf Anwendungsfälle der Erkennung aus, wie zum Beispiel:

• Suchen und Lesen von Kubernetes-Dienstkonto-Tokens,
• Suche nach .env -Dateien oder Anmeldeinformationen.

Dies sind Bereiche, in denen zukünftige Iterationen von Defend for Containers detailliertere Telemetriedaten liefern könnten, um fortgeschrittene Anwendungsfälle im Bereich der Erkennungstechnik zu unterstützen.

Aktivieren der vordefinierten Erkennungsregeln von Defend for Containers

Defend for Containers wird mit einer Reihe vordefinierter Erkennungsregeln ausgeliefert, die eine grundlegende Abdeckung gängiger Container-Angriffstechniken bieten. Sobald die Integration aktiviert ist, können diese Regeln direkt von Elastic Security aus ohne zusätzliche Konfiguration aktiviert werden.

Es wird empfohlen, zunächst die vordefinierten Regeln zu aktivieren, da diese auf die Laufzeittelemetrie von Defend for Containers abgestimmt sind und die Ausführung, Dateimodifikation, Persistenz und das Verhalten nach einer Kompromittierung innerhalb von Containern abdecken. Von dort aus können die Regeln erweitert oder verfeinert werden, um umgebungsspezifischen Arbeitslasten und Bedrohungsmodellen gerecht zu werden.

Durch Filtern nach „Datenquelle: Elastic Defend for Containers“ können Sie alle Regeln finden, die mit dieser Integration verknüpft sind.

Hinweis: Falls keine Regeln angezeigt werden, stellen Sie sicher, dass auf Ihrem Stack Version 9.3.0 ausgeführt wird. da diese Regeln nur auf Version 9.3.0+ implementiert sind.

Nachdem alle wichtigen Beta-Beschränkungen erfasst, die Integration bereitgestellt, die vordefinierten Erkennungsregeln installiert und aktiviert sowie eine funktionierende Richtlinie eingerichtet wurden, besteht der nächste Schritt darin, die Ereignissemantik von Defend for Containers zu untersuchen, einschließlich der Felder, die üblicherweise in der Erkennungslogik verwendet werden, der Leistungsaspekte und der Unterschiede zwischen diesen Ereignissen und Elastic Defend-Ereignissen.

Analysieren von Defend for Containers-Ereignissen

Nachdem Defend for Containers nun implementiert und die Richtlinien eingerichtet sind, besteht der nächste Schritt darin, die von ihm generierten Ereignisse zu verstehen. Ähnlich wie bei der Arbeit mit Elastic Defend oder Auditd Manager wird die Telemetrie von Defend for Containers erst dann wirklich wertvoll, wenn man ein mentales Modell davon entwickelt hat, wie Ereignisse strukturiert sind und welche Felder für die Erkennungstechnik am relevantesten sind.

Defend for Containers erzeugt mehrere Ereignistypen, insbesondere Prozessereignisse und Dateiereignisse, die jeweils mit Container-, Host- und Orchestrierungskontext angereichert sind. Während die zugrundeliegenden Signale weiterhin im Linux-Verhalten verankert bleiben, ermöglichen die zusätzlichen Kubernetes- und Container-Metadaten eine Analyse der Aktivitäten, die mit reiner Host-Telemetrie nicht möglich ist.

In den folgenden Abschnitten werden die wichtigsten Feldgruppen und Ereignistypen anhand realer Defend for Containers-Ereignisse erläutert.

Gemeinsame Felder

Bevor wir uns mit spezifischen Ereigniskategorien befassen, ist es hilfreich, die Felder zu verstehen, die in der Telemetrie von Defend for Containers regelmäßig auftreten. Diese Felder liefern den Kontext, der einzelne Laufzeitaktionen mit Richtlinien, Selektoren und den zugrunde liegenden Ausführungspunkten innerhalb des Kernels verknüpft.

Obwohl sich Prozess- und Dateiereignisse in ihren Details unterscheiden, sind die nachstehend beschriebenen Felder in allen Defend for Containers-Datenströmen vorhanden und stellen oft den ersten Anlaufpunkt dar, wenn es um die Überprüfung von Erkennungen oder die Fehlerbehebung beim Verhalten von Richtlinien geht.

Verteidigung im Container-spezifischen Kontext

Defend for Containers fügt mehrere Felder hinzu, die speziell darauf abzielen, wie Ereignisse erfasst und Richtlinien angewendet werden.

Das Feld cloud_defend.hook_point gibt an, an welcher Stelle im Kernel das Ereignis erfasst wurde. Im gezeigten Beispiel zeigen Werte wie tracepoint__sched_process_fork und tracepoint__sched_process_exec , dass das Ereignis aus Kernel-Tracepoints generiert wurde, die mit der Erstellung und Ausführung eines Prozesses verbunden sind.

Das Feld cloud_defend.matched_selectors zeigt an, welche Selektoren in der aktiven Richtlinie mit dem Ereignis übereinstimmten. Im Beispiel zeigt der Wert allProcesses an, dass dieses Ereignis mit einem breiten Selektor übereinstimmt, der die gesamte Prozessaktivität erfasst. Bei der Anpassung von Richtlinien oder der Untersuchung von Warnmeldungen ist dieses Feld unerlässlich, um zu verstehen, warum ein Ereignis erfasst wurde.

Die Felder cloud_defend.package_policy_id und cloud_defend.package_policy_revision verknüpfen das Ereignis mit einer bestimmten Elastic Agent-Richtlinie und deren Revision. Dadurch ist es möglich, Ereignisse mit Konfigurationsänderungen im Laufe der Zeit zu korrelieren und zu überprüfen, welche Version einer Richtlinie aktiv war, als das Ereignis auftrat.

Ereignis-Metadaten

Defend for Containers-Ereignisse folgen den Konventionen des Elastic Common Schema und beinhalten Standard-Ereignismetadaten, die den Typ und den Lebenszyklus der Aktivität beschreiben.

Das Feld event.category kennzeichnet den übergeordneten Aktivitätstyp, z. B. process oder file, und ist typischerweise das erste Feld, das beim Filtern von Defend for Containers-Daten verwendet wird. Das Feld event.action beschreibt, was geschehen ist, zum Beispiel fork oder exec für Prozessaktivitäten oder open, creation, modification und deletion für Dateiereignisse.

Das Feld event.type fügt Kontextinformationen zum Lebenszyklus hinzu, wie z. B. start für die Prozessausführung, und wird oft zusammen mit event.action verwendet, um verschiedene Phasen der Aktivität zu unterscheiden. Das Feld event.dataset gibt den ursprünglichen Defend for Containers-Datenstrom an, z. B. cloud_defend.process, was beim Erstellen von datensatzbezogenen Abfragen oder Erkennungen nützlich ist.

Zusätzliche Metadatenfelder wie event.id, event.ingested und event.kind werden primär für Korrelation, Ordnung und Fehlerbehebung und weniger für Erkennungslogik verwendet.

Host-Informationen

Defend for Containers-Ereignisse beinhalten den vollständigen Host-Kontext, ähnlich wie Elastic Defend und Auditd Manager. Dadurch wird es möglich, die Container-Laufzeitaktivität mit dem zugrunde liegenden Kubernetes-Knoten zu korrelieren.

Das Feld host.name identifiziert den Knoten, auf dem der Container ausgeführt wird, während host.os.* Details zum Betriebssystem wie Distribution und Kernelversion angibt. Das Feld host.architecture gibt die CPU-Architektur an, was bei der Analyse der Binärausführung oder des kernelspezifischen Verhaltens relevant sein kann.

Ein besonders nützliches Feld ist host.pid_ns_ino, das den PID-Namensraum identifiziert. Dieses Feld ermöglicht die Korrelation von Containeraktivitäten mit Telemetriedaten von Hostprozessen und Kerneln und ist besonders wertvoll bei der Untersuchung von Container-Escape-Versuchen oder Auswirkungen auf Knotenebene.

Dieser Hostkontext ist bei der Analyse von Cloud-nativen Angriffen von entscheidender Bedeutung, da mehrere Container oft denselben Host und Kernel nutzen und das Laufzeitverhalten eines Containers Auswirkungen haben kann, die über seine Grenzen hinausgehen.

Container- und Orchestrator-Kontext

Die größte Stärke von Defend for Containers liegt in ihrem Container-Know-how. Jedes Laufzeitereignis wird mit Container- und Orchestrierungsmetadaten angereichert, sodass die Aktivität im Kontext dessen analysiert werden kann, was ausgeführt wird, wo es ausgeführt wird und mit welchen Berechtigungen.

Auf Containerebene identifizieren Felder wie container.id und container.name den laufenden Container eindeutig, während container.image.name, container.image.tag und der Image-Hash Einblick in Ursprung und Version der Workload geben. Dies ist besonders nützlich, um zwischen erwarteten Utility-Images und unerwarteten oder Ad-hoc-Workloads zu unterscheiden.

Ein Schlüsselfeld für die Risikobewertung ist container.security_context.privileged. Dieses Feld gibt explizit an, ob ein Container im privilegierten Modus ausgeführt wird. Wenn privilegierte Ausführung mit anderen Signalen wie interaktiven Shells oder umfassenden Linux-Funktionen kombiniert wird, erhöht sich das Risikoprofil jeder erkannten Aktivität erheblich.

Defend for Containers reichert Ereignisse außerdem mit Orchestrierungskontext an. Felder wie orchestrator.cluster.name, orchestrator.namespace, und orchestrator.resource.name (typischerweise der Pod-Name) verknüpfen das Laufzeitverhalten mit Kubernetes-Workloads. Über orchestrator.resource.label bereitgestellte Labels ermöglichen es außerdem, dass Erkennungen die Absicht und die Zuständigkeit für die Arbeitslast berücksichtigen.

Für die Erkennungstechnik ermöglicht dieser Kontext eine präzise Eingrenzung der Erkennungen auf:

• spezifische Namensräume (zum Beispiel kube-system),
• privilegierte oder risikoreiche Container,
• Arbeitslasten mit sensiblen Labels,
• oder bekannte Hilfssymbole wie netshoot, kubectl, oder curl.

Diese Anreicherungsebene ermöglicht es, containerbasierte Erkennungslogik direkt auszudrücken, ohne die Absicht indirekt aus Dateisystempfaden, Cgroups oder Namespace-Bezeichnern ableiten zu müssen.

Prozessereignisse

Die Prozessausführung ist eine der wichtigsten Signalarten, die Defend for Containers bereitstellt. Prozessereignisse erfassen die Aktivitäten fork, exec und end innerhalb von Containern und liefern detaillierte Herkunftsinformationen, die für das Verständnis des Ausführungsablaufs zur Laufzeit von entscheidender Bedeutung sind.

Für die Detektionstechnik sind mehrere Bereiche von besonderer Bedeutung. Die Kombination aus process.name und process.executable gibt an, was ausgeführt wurde und von wo, während process.args Aufschluss darüber gibt, wie es aufgerufen wurde. Felder wie process.pid, process.start, process.end, und process.exit_code beschreiben den Prozesslebenszyklus und sind nützlich für die Zeitanalyse und die Rekonstruktion des Ausführungsablaufs. Die process.entity_id stellt eine stabile Kennung dar, die es ermöglicht, Prozesse über mehrere zusammenhängende Ereignisse hinweg zu verfolgen.

Defend for Containers erfasst auch umfangreiche Abstammungsinformationen. Die Felder unterhalb von process.parent.* beschreiben den unmittelbaren Elternprozess und ermöglichen so die Erkennung verdächtiger Eltern-Kind-Beziehungen, wie beispielsweise Shells, die von unerwarteten Binärdateien erzeugt werden. Darüber hinaus bieten process.entry_leader.* und process.session_leader.* übergeordnete Anker innerhalb des Prozessbaums.

Ähnlich wie Elastic Defend modelliert Defend for Containers Prozesse als Graph und nicht als isolierte Ereignisse. Der Entry Leader ist besonders in Containerumgebungen nützlich, da er oft den ersten Prozess repräsentiert, der von der Container-Laufzeitumgebung gestartet wird (zum Beispiel containerd, runc, oder eine Shell, die als Container-Einstiegspunkt angegeben ist). Durch die Verankerung von Erkennungen am Einstiegsleiter können Prozessbäume konsistent interpretiert werden, selbst wenn Container viele kurzlebige Kindprozesse erzeugen.

Die Session-Leader-Felder liefern zusätzlichen Kontext zur interaktiven Ausführung und zu den Session-Grenzen und helfen so, Hintergrunddienste von interaktiven oder angreifergesteuerten Aktivitäten zu unterscheiden.

Zusammen ermöglichen diese Felder die Formulierung einer Erkennungslogik, die über einzelne Ausführungen hinausgeht und stattdessen Ausführungsketten, Herkunft und Absicht berücksichtigt, was für die Erkennung realer Containerangriffstechniken unerlässlich ist.

Fähigkeiten- und Berechtigungskontext

Einer der leistungsstärksten Aspekte der Defend for Containers-Prozessereignisse ist die Einbeziehung von Linux-Funktionsinformationen. Defend for Containers stellt für jeden Prozess sowohl die effektiven als auch die zulässigen Fähigkeitssätze über Folgendes dar:

• process.thread.capabilities.effective
• process.thread.capabilities.permitted

Diese Felder beschreiben, was ein Prozess zur Laufzeit tatsächlich tun darf, unabhängig von seiner Benutzer-ID oder Containergrenze.

In privilegierten Containern legen Prozesse oft eine breite Palette effektiver Fähigkeiten offen, darunter auch hochsensible Fähigkeiten wie CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_SYS_RAWIO und CAP_BPF. Das Vorhandensein dieser Fähigkeiten verändert das Risikoprofil jedes ausgeführten Befehls erheblich, da sie Aktionen ermöglichen, die sich direkt auf den Host-Kernel oder andere Workloads auswirken können.

Aus Sicht der Detektionstechnik ist dieser Kontext von entscheidender Bedeutung. Es ermöglicht, dass Erkennungen über einfache Prozessnamenabgleiche hinausgehen und stattdessen die Auswirkungen berücksichtigen. Die Ausführung desselben Binärprogramms kann völlig unterschiedliche Auswirkungen haben, je nachdem, ob es mit einem minimalen Funktionsumfang oder mit nahezu Host-Level-Berechtigungen ausgeführt wird.

In der Praxis ermöglichen Fähigkeitsdaten den Erkennungsingenieuren Folgendes:

• Identifizieren Sie verdächtige Tools, die in übermäßig permissiven Containern ausgeführt werden.
• Korrelation des Laufzeitverhaltens mit gefährlichen Fähigkeitskombinationen.
• Priorisieren Sie Warnmeldungen anhand des tatsächlichen Ausnutzungspotenzials und nicht anhand oberflächlicher Aktivitäten.

Dies ist insbesondere für die Forschung zu Container-Breakouts relevant, da das Vorhandensein oder Fehlen bestimmter Fähigkeiten oft darüber entscheidet, ob ein Exploit durchführbar ist.

Interaktive Ausführung

Das Feld process.interactive gibt an, ob ein Prozess mit einer interaktiven Sitzung verknüpft ist. In Containerumgebungen ist die interaktive Ausführung bei Produktionsworkloads relativ selten und korreliert oft stark mit Aktivitäten nach einer Kompromittierung oder mit manueller Tastatureingabe.

Defend for Containers ermöglicht Interaktivität nicht nur auf Prozessebene, sondern auch über verwandte Ausführungskontexte hinweg, einschließlich process.parent.interactive, process.entry_leader.interactive und process.session_leader.interactive. Dadurch wird es möglich festzustellen, ob eine gesamte Ausführungskette interaktiv ist, anstatt sich isoliert auf ein einzelnes Prozessflag zu verlassen.

Gängige Beispiele für interaktive Ausführung innerhalb von Containern sind das Erzeugen einer bash oder sh -Shell, das Ausführen interaktiver Hilfsprogramme wie curl, kubectl oder busybox oder die operatorgesteuerte Aufklärung innerhalb eines kompromittierten Pods. Während solche Aktionen beim Debuggen legitim sein können, sind sie im regulären Produktionsbetrieb unüblich.

In Kombination mit Container-Image, Namespace und Privilegienkontext wird die interaktive Ausführung zu einem starken Anomaliesignal. Es ermöglicht der Erkennungslogik, zwischen erwartetem automatisiertem Containerverhalten und Aktivitäten zu unterscheiden, die eher einem manuellen Eingriff oder einer von Angreifern gesteuerten Erkundung entsprechen.

Dateiereignisse

Defend for Containers-Dateiereignisse erfassen die Dateisystemaktivität innerhalb von Containern und werden für eine Vielzahl von Operationen ausgegeben. Im Gegensatz zur herkömmlichen Dateiintegritätsüberwachung sind diese Ereignisse laufzeitorientiert und auf Container-Workloads beschränkt. Sie liefern Kontextinformationen darüber, wie und warum Dateiänderungen auftreten.

Defend for Containers kann Dateiaktivitäten wie das Öffnen von Dateien mit Schreibabsicht, Inhaltsänderungen, Dateierstellungen, Umbenennungen, Berechtigungsänderungen und Löschungen erkennen. Durch die Fokussierung auf schreiborientierte Operationen legt Defend for Containers den Schwerpunkt auf Verhaltensweisen, die den Systemzustand verändern, anstatt auf passiven Dateizugriff.

Dies ermöglicht es den Erkennungsingenieuren, Dateinutzungsmuster zur Laufzeit zu analysieren und nicht nur die Auswirkungen einer Änderung zu betrachten.

Bei der Entwicklung dateibasierter Erkennungssysteme sind einige Felder von besonderer Bedeutung. Die Felder file.path und file.name identifizieren die betroffene Datei und ihren Speicherort, während file.extension dabei helfen kann, Binärdateien, Skripte und Konfigurationsdateien zu unterscheiden. Die Felder event.action und event.type beschreiben, welche Operation stattgefunden hat und wie sie im Ereignislebenszyklus interpretiert werden soll.

Zusammen ermöglichen diese Felder Defend for Containers, harmlose Dateizugriffe von verdächtigen Änderungsmustern zu unterscheiden, wie etwa dem Schreiben von Binärdateien oder dem Ändern von Berechtigungen in sensiblen Verzeichnissen.

Zusammenführen

Wie bei jeder anderen Datenquelle werden die Telemetriedaten von Defend for Containers erst dann wirklich wertvoll, wenn man versteht, wie man Felder aus den Bereichen Prozess, Datei, Container und Orchestrierung kombiniert. Anstatt sich auf statische Indikatoren zu verlassen, ermöglicht Defend for Containers die Erkennungsentwicklung auf Basis des Laufzeitverhaltens, des Berechtigungskontexts und der Workload-Identität.

Fazit

Defend for Containers in Elastic Stack 9.3.0 beinhaltet die Container-Laufzeiterkennung als Kernkomponente der Linux-Erkennungstechnik. Es zeichnet sich durch einen klaren Anwendungsbereich, ein richtlinienbasiertes Konfigurationsmodell und eine speziell für containerisierte Workloads entwickelte Laufzeittelemetrie aus.

In diesem Beitrag haben wir untersucht, wie man Defend for Containers bereitstellt, wie das zugehörige Richtlinienmodell aufgebaut ist und wie Laufzeitereignisse generiert und mit Container- und Orchestrierungskontext angereichert werden. Wir untersuchten die Struktur von Prozess- und Dateiereignissen, Metadaten zu Fähigkeiten, interaktiven Ausführungssignalen und containerspezifischen Feldern, die es ermöglichen, Erkennungen arbeitslastbewusst auszudrücken.

Die wichtigste Erkenntnis ist, dass eine effektive Containererkennung das Laufzeitverhalten im Kontext berücksichtigen muss: Prozesse, Dateimodifikationen, Berechtigungen und die Identität der Arbeitslast müssen gemeinsam ausgewertet werden. Defend for Containers liefert die notwendigen Telemetriedaten, um dies zu ermöglichen.

Im nächsten Artikel werden wir auf dieser Grundlage aufbauen, indem wir ein realistisches Container-Angriffsszenario durchgehen und demonstrieren, wie die Telemetrie von Defend for Containers in der Praxis jede Phase einer Kompromittierung aufdeckt.