View a markdown version of this page

Reaktion auf Vorfälle und Forensik - Amazon EKS
Beispiel für einen Plan zur Reaktion auf VorfälleEmpfehlungenTools und Ressourcen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Reaktion auf Vorfälle und Forensik

Ihre Fähigkeit, schnell auf einen Vorfall zu reagieren, kann dazu beitragen, den durch eine Sicherheitsverletzung verursachten Schaden zu minimieren. Ein zuverlässiges Warnsystem, das Sie vor verdächtigem Verhalten warnen kann, ist der erste Schritt in einem guten Notfallplan. Wenn ein Vorfall eintritt, müssen Sie schnell entscheiden, ob Sie den betroffenen Container zerstören und austauschen oder den Container isolieren und inspizieren möchten. Wenn Sie sich dafür entscheiden, den Container im Rahmen einer forensischen Untersuchung und Ursachenanalyse zu isolieren, sollten Sie die folgenden Maßnahmen ergreifen:

Beispiel für einen Plan zur Reaktion auf Vorfälle

Identifizieren Sie den Pod- und Worker-Knoten, bei denen die Störung vorliegt

Ihre erste Vorgehensweise sollte darin bestehen, den Schaden einzugrenzen. Identifizieren Sie zunächst, wo der Verstoß aufgetreten ist, und isolieren Sie diesen Pod und seinen Knoten vom Rest der Infrastruktur.

Identifizieren Sie die betroffenen Pods und Worker-Knoten anhand des Workload-Namens

Wenn Sie den Namen und den Namespace des betreffenden Pods kennen, können Sie den Worker-Knoten, auf dem der Pod ausgeführt wird, wie folgt identifizieren:

kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'

Wenn eine Workload-Ressource wie eine Bereitstellung kompromittiert wurde, ist es wahrscheinlich, dass alle Pods, die Teil der Workload-Ressource sind, gefährdet sind. Verwenden Sie den folgenden Befehl, um alle Pods der Workload-Ressource und die Knoten aufzulisten, auf denen sie ausgeführt werden:

selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'

Der obige Befehl gilt für Bereitstellungen. Sie können denselben Befehl für andere Workload-Ressourcen wie Replicasets, Statefulsets usw. ausführen.

Identifizieren Sie die fehlerhaften Pods und Worker Nodes anhand des Dienstkontonamens

In einigen Fällen stellen Sie möglicherweise fest, dass ein Dienstkonto kompromittiert ist. Es ist wahrscheinlich, dass Pods, die das identifizierte Dienstkonto verwenden, gefährdet sind. Sie können alle Pods mithilfe des Dienstkontos und der Knoten, auf denen sie ausgeführt werden, mit dem folgenden Befehl identifizieren:

kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'

Identifizieren Sie Pods mit anfälligen oder kompromittierten Images und Worker-Knoten

In einigen Fällen stellen Sie möglicherweise fest, dass ein Container-Image, das in Pods in Ihrem Cluster verwendet wird, bösartig oder gefährdet ist. Ein Container-Image ist bösartig oder kompromittiert, wenn festgestellt wurde, dass es Malware enthält, ein bekanntes schlechtes Image ist oder eine CVE enthält, die ausgenutzt wurde. Sie sollten davon ausgehen, dass alle Pods, die das Container-Image verwenden, gefährdet sind. Sie können die Pods anhand des Images und der Knoten, auf denen sie ausgeführt werden, mit dem folgenden Befehl identifizieren:

IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'

Isolieren Sie den Pod, indem Sie eine Netzwerkrichtlinie erstellen, die den gesamten ein- und ausgehenden Verkehr zum Pod ablehnt

Eine Regel zum Ablehnen des gesamten Datenverkehrs kann helfen, einen bereits laufenden Angriff zu stoppen, indem alle Verbindungen zum Pod unterbrochen werden. Die folgende Netzwerkrichtlinie gilt für einen Pod mit dem Labelapp=web.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
Wichtig

Eine Netzwerkrichtlinie kann sich als unwirksam erweisen, wenn sich ein Angreifer Zugriff auf den zugrunde liegenden Host verschafft hat. Wenn Sie vermuten, dass dies passiert ist, können Sie AWS-Sicherheitsgruppen verwenden, um einen gefährdeten Host von anderen Hosts zu isolieren. Wenn Sie die Sicherheitsgruppe eines Hosts ändern, sollten Sie sich bewusst sein, dass sich dies auf alle Container auswirkt, die auf diesem Host ausgeführt werden.

Widerrufen Sie bei Bedarf die temporären Sicherheitsanmeldedaten, die dem Pod- oder Worker-Knoten zugewiesen wurden

Wenn dem Worker-Knoten eine IAM-Rolle zugewiesen wurde, die es Pods ermöglicht, auf andere AWS-Ressourcen zuzugreifen, entfernen Sie diese Rollen aus der Instance, um weiteren Schaden durch den Angriff zu verhindern. Wenn dem Pod eine IAM-Rolle zugewiesen wurde, sollten Sie ebenfalls prüfen, ob Sie die IAM-Richtlinien sicher aus der Rolle entfernen können, ohne andere Workloads zu beeinträchtigen.

Sperren Sie den Worker-Knoten ab

Indem Sie den betroffenen Worker-Knoten sperren, informieren Sie den Scheduler, um zu vermeiden, dass Pods auf dem betroffenen Knoten eingeplant werden. Auf diese Weise können Sie den Knoten für forensische Untersuchungen entfernen, ohne andere Workloads zu unterbrechen.

Anmerkung

Diese Anleitung gilt nicht für Fargate, wo jeder Fargate-Pod in seiner eigenen Sandbox-Umgebung ausgeführt wird. Anstatt abzusperren, sperren Sie die betroffenen Fargate-Pods ab, indem Sie eine Netzwerkrichtlinie anwenden, die jeglichen ein- und ausgehenden Verkehr ablehnt.

Aktivieren Sie den Kündigungsschutz auf dem betroffenen Worker-Knoten

Ein Angreifer kann versuchen, seine Missetaten auszulöschen, indem er einen betroffenen Knoten schließt. Wenn Sie den Kündigungsschutz aktivieren, kann dies verhindert werden. Der Instanz-Scale-In-Schutz schützt den Knoten vor einem Scale-In-Ereignis.

Warnung

Sie können den Kündigungsschutz für eine Spot-Instance nicht aktivieren.

Versehen Sie den Verstoß Pod/Node mit einer Kennzeichnung, die darauf hinweist, dass er Teil einer laufenden Untersuchung ist

Dies dient als Warnung für Cluster-Administratoren, die betroffenen Personen nicht zu manipulieren, Pods/Nodes bis die Untersuchung abgeschlossen ist.

Erfassen Sie flüchtige Artefakte auf dem Worker-Knoten

  • Erfassen Sie den Betriebssystemspeicher. Dadurch werden der Docker-Daemon (oder eine andere Container-Laufzeit) und seine Unterprozesse pro Container erfasst. Dies kann mithilfe von Tools wie LiME und https://www.volatilityfoundation.org/ Volatility oder mithilfe übergeordneter Tools wie Automated Forensics Orchestrator für Amazon EC2 erreicht werden, die darauf aufbauen.

  • Führen Sie einen Netstat-Tree-Dump der laufenden Prozesse und der offenen Ports durch. Dadurch werden der Docker-Daemon und sein Subprozess pro Container erfasst.

  • Führen Sie Befehle aus, um den Status auf Containerebene zu speichern, bevor Beweise geändert werden. Sie können die Funktionen der Container-Runtime verwenden, um Informationen über aktuell ausgeführte Container zu erfassen. Mit Containerd könnten Sie beispielsweise Folgendes tun:

    • crictl psfür laufende Prozesse.

    • crictl logs CONTAINERfür Protokolle, die auf Daemon-Ebene gespeichert werden.

      Das Gleiche könnte mit containerd erreicht werden, indem die https://github.com/containerd/nerdctl nerdctl-CLI anstelle von docker (z. B.) verwendet wird. nerdctl inspect Je nach Container-Laufzeit sind einige zusätzliche Befehle verfügbar. Docker muss docker diff beispielsweise Änderungen am Container-Dateisystem sehen oder docker checkpoint den gesamten Containerstatus einschließlich des flüchtigen Speichers (RAM) speichern. In diesem Kubernetes-Blogbeitrag finden Sie eine Diskussion über ähnliche Funktionen mit Containerd oder Runtimes. CRI-O

  • Halten Sie den Container für die forensische Erfassung an.

  • Erstellen Sie einen Snapshot der EBS-Volumes der Instance.

Stellen Sie die kompromittierte Pod- oder Workload-Ressource erneut bereit

Sobald Sie Daten für die forensische Analyse gesammelt haben, können Sie den gefährdeten Pod oder die Workload-Ressource erneut bereitstellen.

Führen Sie zunächst den Fix für die Sicherheitslücke aus, die kompromittiert wurde, und starten Sie neue Ersatz-Pods. Löschen Sie dann die anfälligen Pods.

Wenn die anfälligen Pods von einer übergeordneten Kubernetes-Workload-Ressource verwaltet werden (z. B. einem Deployment oder DaemonSet), werden beim Löschen der Pods neue erstellt. Daher werden anfällige Pods erneut gestartet. In diesem Fall sollten Sie nach der Behebung der Sicherheitsanfälligkeit eine neue Ersatz-Workload-Ressource bereitstellen. Anschließend sollten Sie den anfälligen Workload löschen.

Empfehlungen

Lesen Sie das Whitepaper zu AWS Security Incident Response

Dieser Abschnitt bietet zwar einen kurzen Überblick sowie einige Empfehlungen zum Umgang mit vermuteten Sicherheitsverletzungen, das Thema wird jedoch im Whitepaper AWS Security Incident Response ausführlich behandelt.

Üben Sie an Spieltagen im Bereich Sicherheit

Teilen Sie Ihre Sicherheitsexperten in 2 Teams ein: rote und blaue. Das rote Team wird sich darauf konzentrieren, verschiedene Systeme auf Sicherheitslücken zu untersuchen, während das blaue Team für die Verteidigung gegen diese verantwortlich ist. Wenn Sie nicht über genügend Sicherheitsexperten verfügen, um separate Teams zusammenzustellen, sollten Sie erwägen, eine externe Stelle einzustellen, die sich mit Kubernetes-Exploits auskennt.

Kubesploit ist ein Framework für Penetrationstests CyberArk , mit dem Sie Spieltage durchführen können. Im Gegensatz zu anderen Tools, die Ihren Cluster nach Sicherheitslücken durchsuchen, simuliert Kubesploit einen realen Angriff. Dies gibt Ihrem blauen Team die Möglichkeit, seine Reaktion auf einen Angriff zu üben und seine Effektivität zu messen.

Führen Sie Penetrationstests für Ihren Cluster durch

Regelmäßige Angriffe auf Ihren eigenen Cluster können Ihnen dabei helfen, Sicherheitslücken und Fehlkonfigurationen zu entdecken. Bevor Sie beginnen, befolgen Sie die Richtlinien für Penetrationstests, bevor Sie einen Test mit Ihrem Cluster durchführen.

Tools und Ressourcen