View a markdown version of this page

Resposta a incidentes e análise forense - Amazon EKS
Exemplo de plano de resposta a incidentesRecomendaçõesFerramentas e recursos

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Resposta a incidentes e análise forense

Sua capacidade de reagir rapidamente a um incidente pode ajudar a minimizar os danos causados por uma violação. Ter um sistema de alerta confiável que possa alertá-lo sobre comportamentos suspeitos é a primeira etapa de um bom plano de resposta a incidentes. Quando ocorre um incidente, você precisa decidir rapidamente se deseja destruir e substituir o contêiner afetado ou isolar e inspecionar o contêiner. Se você optar por isolar o contêiner como parte de uma investigação forense e análise da causa raiz, o seguinte conjunto de atividades deverá ser seguido:

Exemplo de plano de resposta a incidentes

Identifique o pod ofensivo e o nó de trabalho

Seu primeiro curso de ação deve ser isolar os danos. Comece identificando onde a violação ocorreu e isole esse pod e seu nó do resto da infraestrutura.

Identifique os pods e nós de trabalho ofensivos usando o nome da carga de trabalho

Se você souber o nome e o namespace do pod ofensivo, poderá identificar o node de trabalho que está executando o pod da seguinte forma:

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

Se um recurso de carga de trabalho, como uma implantação, tiver sido comprometido, é provável que todos os pods que fazem parte do recurso de carga de trabalho estejam comprometidos. Use o comando a seguir para listar todos os pods do recurso de carga de trabalho e os nós em que eles estão sendo executados:

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

O comando acima é para implantações. Você pode executar o mesmo comando para outros recursos de carga de trabalho, como replicasets, statefulsets etc.

Identifique os pods e nós de trabalho ofensivos usando o nome da conta de serviço

Em alguns casos, você pode identificar que uma conta de serviço está comprometida. É provável que os pods que usam a conta de serviço identificada estejam comprometidos. Você pode identificar todos os pods usando a conta de serviço e os nós em que estão sendo executados com o seguinte comando:

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

Identifique pods com imagens e nós de trabalho vulneráveis ou comprometidos

Em alguns casos, você pode descobrir que uma imagem de contêiner usada em pods em seu cluster é maliciosa ou está comprometida. Uma imagem de contêiner é maliciosa ou está comprometida se for detectada que contém malware, é uma imagem incorreta conhecida ou tem um CVE que foi explorado. Você deve considerar que todos os pods que usam a imagem do contêiner estão comprometidos. Você pode identificar os pods usando a imagem e os nós em que estão sendo executados com o seguinte 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)"'

Isole o pod criando uma política de rede que negue todo o tráfego de entrada e saída para o pod

Uma regra de negar todo o tráfego pode ajudar a interromper um ataque que já está em andamento ao cortar todas as conexões com o pod. A política de rede a seguir se aplicará a um pod com o rótuloapp=web.

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

Uma política de rede pode se mostrar ineficaz se um invasor tiver acesso ao host subjacente. Se você suspeitar que isso aconteceu, você pode usar os grupos de segurança da AWS para isolar um host comprometido de outros hosts. Ao alterar o grupo de segurança de um host, esteja ciente de que isso afetará todos os contêineres em execução nesse host.

Revogue as credenciais de segurança temporárias atribuídas ao pod ou ao nó de trabalho, se necessário

Se o node de trabalho tiver recebido uma função do IAM que permite que os pods tenham acesso a outros recursos da AWS, remova essas funções da instância para evitar maiores danos causados pelo ataque. Da mesma forma, se o pod tiver recebido uma função do IAM, avalie se você pode remover com segurança as políticas do IAM da função sem afetar outras workloads.

Isole o nó do trabalhador

Ao isolar o nó de trabalho afetado, você está informando o agendador para evitar o agendamento de pods no nó afetado. Isso permitirá que você remova o nó para estudo forense sem interromper outras cargas de trabalho.

nota

Essa orientação não se aplica ao Fargate, onde cada pod Fargate é executado em seu próprio ambiente de sandbox. Em vez de isolar, sequestre os pods Fargate afetados aplicando uma política de rede que nega todo o tráfego de entrada e saída.

Habilite a proteção contra rescisão no nó de trabalho afetado

Um atacante pode tentar apagar seus delitos encerrando um nó afetado. Ativar a proteção contra rescisão pode impedir que isso aconteça. A proteção de expansão da instância protegerá o nó de um evento de expansão.

Atenção

Você não pode ativar a proteção contra encerramento em uma instância Spot.

Rotule a ofensa Pod/Node com uma etiqueta indicando que ela faz parte de uma investigação ativa

Isso servirá como um aviso para os administradores do cluster não alterarem os afetados Pods/Nodes até que a investigação seja concluída.

Capture artefatos voláteis no nó de trabalho

  • Capture a memória do sistema operacional. Isso capturará o daemon do Docker (ou outro tempo de execução do contêiner) e seus subprocessos por contêiner. Isso pode ser feito usando ferramentas como LiME e Volatility, ou por meio de ferramentas de alto nível, como o Automated Forensics Orchestrator for Amazon EC2, que se baseiam nelas.

  • Execute um dump em árvore netstat dos processos em execução e das portas abertas. Isso capturará o daemon docker e seu subprocesso por contêiner.

  • Execute comandos para salvar o estado no nível do contêiner antes que as evidências sejam alteradas. Você pode usar os recursos do tempo de execução do contêiner para capturar informações sobre os contêineres em execução no momento. Por exemplo, com o Containerd, você pode fazer o seguinte:

    • crictl pspara processos em execução.

    • crictl logs CONTAINERpara registros mantidos em nível de daemon.

      O mesmo pode ser feito com o containerd usando a CLI nerdctl, no lugar de (por exemplo). docker nerdctl inspect Alguns comandos adicionais estão disponíveis dependendo do tempo de execução do contêiner. Por exemplo, o Docker docker diff precisa ver alterações no sistema de arquivos do contêiner ou docker checkpoint salvar todo o estado do contêiner, incluindo memória volátil (RAM). Veja esta postagem no blog do Kubernetes para uma discussão sobre recursos semelhantes com containers ou tempos de execução. CRI-O

  • Pausa o contêiner para captura forense.

  • Capture um instantâneo dos volumes do EBS da instância.

Reimplante o pod ou o recurso de carga de trabalho comprometido

Depois de coletar dados para análise forense, você pode reimplantar o pod ou o recurso de carga de trabalho comprometido.

Primeiro, corrija a vulnerabilidade que foi comprometida e inicie novos pods substitutos. Em seguida, exclua os pods vulneráveis.

Se os pods vulneráveis forem gerenciados por um recurso de carga de trabalho do Kubernetes de nível superior (por exemplo, uma implantação ou DaemonSet), excluí-los agendará novos pods. Portanto, os pods vulneráveis serão lançados novamente. Nesse caso, você deve implantar um novo recurso de carga de trabalho substituto depois de corrigir a vulnerabilidade. Em seguida, você deve excluir a carga de trabalho vulnerável.

Recomendações

Leia o whitepaper de resposta a incidentes de segurança da AWS

Embora esta seção forneça uma breve visão geral, juntamente com algumas recomendações para lidar com suspeitas de violações de segurança, o tópico é abordado exaustivamente no white paper, AWS Security Incident Response.

Pratique dias de jogos de segurança

Divida seus profissionais de segurança em duas equipes: vermelha e azul. A equipe vermelha se concentrará em investigar vulnerabilidades em diferentes sistemas, enquanto a equipe azul será responsável por se defender contra elas. Se você não tem profissionais de segurança suficientes para criar equipes separadas, considere contratar uma entidade externa que tenha conhecimento das explorações do Kubernetes.

O Kubesploit é uma estrutura de teste de penetração CyberArk que você pode usar para conduzir dias de jogo. Ao contrário de outras ferramentas que examinam seu cluster em busca de vulnerabilidades, o kubesploit simula um ataque real. Isso dá à sua equipe azul a oportunidade de praticar sua resposta a um ataque e avaliar sua eficácia.

Execute testes de penetração em seu cluster

Atacar periodicamente seu próprio cluster pode ajudar você a descobrir vulnerabilidades e configurações incorretas. Antes de começar, siga as diretrizes do teste de penetração antes de realizar um teste em seu cluster.

Ferramentas e recursos