View a markdown version of this page

Risposta agli incidenti e analisi forensi - Amazon EKS
Esempio di piano di risposta agli incidentiRaccomandazioniStrumenti e risorse

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risposta agli incidenti e analisi forensi

La tua capacità di reagire rapidamente a un incidente può aiutarti a ridurre al minimo i danni causati da una violazione. Disporre di un sistema di allerta affidabile in grado di avvisarti in caso di comportamenti sospetti è il primo passo per un buon piano di risposta agli incidenti. Quando si verifica un incidente, è necessario decidere rapidamente se distruggere e sostituire il contenitore danneggiato oppure isolare e ispezionare il contenitore. Se si sceglie di isolare il contenitore nell'ambito di un'indagine forense e di un'analisi delle cause principali, è necessario seguire la seguente serie di attività:

Esempio di piano di risposta agli incidenti

Identifica il Pod e il nodo di lavoro incriminati

La prima cosa da fare dovrebbe essere quella di isolare il danno. Inizia identificando il punto in cui si è verificata la violazione e isola il Pod e il relativo nodo dal resto dell'infrastruttura.

Identifica i pod e i nodi di lavoro incriminati utilizzando il nome del carico di lavoro

Se conosci il nome e lo spazio dei nomi del pod incriminato, puoi identificare il nodo di lavoro che esegue il pod come segue:

kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'

Se una risorsa del carico di lavoro come una distribuzione è stata compromessa, è probabile che tutti i pod che fanno parte della risorsa del carico di lavoro siano compromessi. Usa il comando seguente per elencare tutti i pod della risorsa Workload e i nodi su cui sono in esecuzione:

selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'

Il comando precedente è per le distribuzioni. È possibile eseguire lo stesso comando per altre risorse del carico di lavoro come replicasets, statefulsets, ecc.

Identifica i pod e i nodi di lavoro incriminati utilizzando il nome dell'account di servizio

In alcuni casi, potresti scoprire che un account di servizio è compromesso. È probabile che i pod che utilizzano l'account di servizio identificato siano compromessi. Puoi identificare tutti i pod utilizzando l'account di servizio e i nodi su cui sono in esecuzione con il seguente comando:

kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'

Identifica i pod con immagini e nodi di lavoro vulnerabili o compromessi

In alcuni casi, potresti scoprire che l'immagine di un contenitore utilizzata nei pod del tuo cluster è dannosa o compromessa. Un'immagine del contenitore è dannosa o compromessa se è stato rilevato che contiene malware, è un'immagine notoriamente errata o presenta un CVE che è stato sfruttato. Dovresti considerare compromessi tutti i pod che utilizzano l'immagine del contenitore. Puoi identificare i pod usando l'immagine e i nodi su cui sono in esecuzione con il seguente comando:

IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'

Isola il pod creando una policy di rete che neghi tutto il traffico in ingresso e in uscita verso il pod

Una regola di negazione di tutto il traffico può aiutare a fermare un attacco già in corso interrompendo tutte le connessioni al pod. La seguente politica di rete si applicherà a un pod con l'etichetta. app=web

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
Importante

Una policy di rete può rivelarsi inefficace se un utente malintenzionato ha ottenuto l'accesso all'host sottostante. Se sospetti che ciò sia accaduto, puoi utilizzare AWS Security Groups per isolare un host compromesso dagli altri host. Quando modifichi il gruppo di sicurezza di un host, tieni presente che avrà un impatto su tutti i contenitori in esecuzione su quell'host.

Revoca le credenziali di sicurezza temporanee assegnate al pod o al nodo di lavoro, se necessario

Se al nodo di lavoro è stato assegnato un ruolo IAM che consente ai Pods di accedere ad altre risorse AWS, rimuovi tali ruoli dall'istanza per prevenire ulteriori danni causati dall'attacco. Allo stesso modo, se al pod è stato assegnato un ruolo IAM, valuta se puoi rimuovere in sicurezza le policy IAM dal ruolo senza influire sugli altri carichi di lavoro.

Circonda il nodo di lavoro

Isolando il nodo di lavoro interessato, stai informando lo scheduler di evitare di programmare i pod sul nodo interessato. Ciò ti consentirà di rimuovere il nodo per lo studio forense senza interrompere gli altri carichi di lavoro.

Nota

Questa guida non è applicabile a Fargate in cui ogni pod Fargate viene eseguito nel proprio ambiente sandbox. Invece di isolarli, isolate i pod Fargate interessati applicando una politica di rete che impedisca tutto il traffico in ingresso e in uscita.

Attiva la protezione dalle interruzioni sul nodo di lavoro interessato

Un utente malintenzionato può tentare di cancellare i propri misfatti chiudendo un nodo interessato. L'attivazione della protezione dalla terminazione può impedire che ciò accada. La protezione scale-in dell'istanza proteggerà il nodo da un evento di scale-in.

avvertimento

Non è possibile abilitare la protezione dalla terminazione su un'istanza Spot.

Etichetta l'autore del reato Pod/Node con un'etichetta che indichi che fa parte di un'indagine attiva

Ciò servirà da avvertimento agli amministratori del cluster affinché non alterino i dati interessati Pods/Nodes fino al termine dell'indagine.

Cattura gli artefatti volatili sul nodo di lavoro

  • Acquisisci la memoria del sistema operativo. Questo catturerà il demone Docker (o un altro runtime del contenitore) e i relativi sottoprocessi per contenitore. Ciò può essere ottenuto utilizzando strumenti come LiME e Volatility o strumenti di livello superiore come Automated Forensics Orchestrator per Amazon EC2 che si basano su di essi.

  • Esegui un dump ad albero netstat dei processi in esecuzione e delle porte aperte. Questo catturerà il demone docker e il relativo sottoprocesso per contenitore.

  • Esegui i comandi per salvare lo stato a livello di contenitore prima che le prove vengano alterate. È possibile utilizzare le funzionalità del runtime del contenitore per acquisire informazioni sui contenitori attualmente in esecuzione. Ad esempio, con Containerd, puoi fare quanto segue:

    • crictl psper i processi in esecuzione.

    • crictl logs CONTAINERper i log conservati a livello di demone.

      Lo stesso potrebbe essere ottenuto con containerd utilizzando la CLI nerdctl, al posto di (ad es.). docker nerdctl inspect Sono disponibili alcuni comandi aggiuntivi a seconda del runtime del contenitore. Ad esempio, Docker deve visualizzare docker diff le modifiche al filesystem del contenitore o docker checkpoint salvare tutto lo stato del contenitore, inclusa la memoria volatile (RAM). Consulta questo post sul blog di Kubernetes per discutere di funzionalità simili con containerd o runtime. CRI-O

  • Metti in pausa il contenitore per l'acquisizione forense.

  • Effettua un'istantanea dei volumi EBS dell'istanza.

Ridistribuisci il pod o la risorsa di carico di lavoro compromessi

Una volta raccolti i dati per l'analisi forense, puoi ridistribuire il pod o la risorsa del carico di lavoro compromessi.

Per prima cosa implementa la correzione della vulnerabilità compromessa e avvia nuovi pod sostitutivi. Quindi elimina i pod vulnerabili.

Se i pod vulnerabili sono gestiti da una risorsa di carico di lavoro Kubernetes di livello superiore (ad esempio, una distribuzione o DaemonSet), la loro eliminazione ne pianificherà di nuovi. Quindi i pod vulnerabili verranno lanciati nuovamente. In tal caso, dovresti distribuire una nuova risorsa sostitutiva per il carico di lavoro dopo aver risolto la vulnerabilità. Quindi dovresti eliminare il carico di lavoro vulnerabile.

Raccomandazioni

Consulta il white paper di AWS Security Incident Response

Sebbene questa sezione fornisca una breve panoramica insieme ad alcuni consigli per la gestione di sospette violazioni della sicurezza, l'argomento è trattato in modo esauriente nel white paper AWS Security Incident Response. https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html

Esercitati, giornate di gioco sulla sicurezza

Dividi i professionisti della sicurezza in 2 squadre: rossa e blu. La squadra rossa si concentrerà sull'analisi delle vulnerabilità nei diversi sistemi, mentre la squadra blu sarà responsabile della difesa contro di esse. Se non hai abbastanza professionisti della sicurezza per creare team separati, valuta la possibilità di assumere un'entità esterna a conoscenza degli exploit di Kubernetes.

Kubesploit è un framework di test di penetrazione che puoi utilizzare per condurre giornate di gioco. CyberArk A differenza di altri strumenti che analizzano il cluster alla ricerca di vulnerabilità, kubesploit simula un attacco reale. Ciò offre alla tua squadra blu l'opportunità di mettere in pratica la sua risposta a un attacco e di valutarne l'efficacia.

Esegui test di penetrazione sul tuo cluster

Attaccare periodicamente il tuo cluster può aiutarti a scoprire vulnerabilità e configurazioni errate. Prima di iniziare, segui le linee guida per i penetration test prima di eseguire un test sul tuo cluster.

Strumenti e risorse