Como automatizar o isolamento de instâncias Amazon EC2 com comportamento suspeito

Por Henrique Souza é um Arquiteto de Soluções

Segurança é prioridade máxima na AWS. No ciclo de atividades para respostas a incidentes, é importante monitorar constantemente para poder atuar caso haja alguma vulnerabilidade ou problema detectado. Essa prática desempenha um papel fundamental na proteção da integridade de informações confidenciais.

Isolamento de instâncias refere-se à separação estratégica de sistemas com com comportamento suspeito do restante da infraestrutura. Esse isolamento serve como medida de contenção, evitando a potencial propagação de ameaças e minimizando os danos causados por acesos não autorizados. Após a etapa de isolamento será possível conduzir uma análise forense mais aprofundada para entender a natureza e o escopo da possível violação.

Para que este processo todo seja efetivo, precisamos que seja automatizado para que as respostas a incidentes sejam quase em tempo real, seguindo os padrões estabelecidos e com menor propensão a erros por ter sido criado e validado antes de um momento de crise. E é isso que veremos neste blogpost – como automatizar o isolamento de instâncias do Amazon EC2 para análise forense.

Visão geral da Solução

Figura 1 – Arquitetura da solução

No Amazon VPC temos a funcionalidade dos Security Groups. Eles controlam o tráfego de entrada e saída aos recursos que são aplicados. Por exemplo: ao associar uma instância EC2 a um Security Group, ele atuará como um firewall stateful para permitir ou não a comunicação externa àquela instância. As regras de entrada controlam o tráfego de entrada para a instância e as regras de saída controlam o tráfego de saída da instância. E é através do Security Group da instância que for detectada com comportamento suspeito, que será feita a ação de isolamento.

Agora vamos entender melhor como funciona o monitoramento, remediação automática e análise forense da solução:

• Pipeline de Resposta a Incidente: este componente é responsável por detectar as vulnerabilidades e anomalias no workload e dessa forma acionar o processo de isolamento de instância, através dos seguintes serviços:
  • Amazon GuardDuty: é um serviço inteligente que utiliza inteligência artificial para detectar potenciais ameaças. Ele monitora continuamente as atividades mal-intencionadas nas contas da AWS, inclusive as instâncias do Amazon EC2. Se uma potencial atividade mal-intencionada for detectada, como por exemplo comportamentos anômalos, exfiltração de credenciais ou comunicação de infraestrutura de comando e controle (C2), o GuardDuty gera descobertas de segurança detalhadas que podem ser usadas para dar visibilidade da segurança e atuar na remediação;
  • Amazon EventBridge: é um serviço que integra produtores e consumidores de evento ponto a ponto sem precisar escrever código personalizado nem gerenciar e provisionar servidores. Com isso facilita e agiliza a criação de aplicativos escaláveis orientados à eventos. O EventBridge envia o payload com as descobertas do GuardDuty para uma função AWS Lambda que será responsável por executar as ações de isolamento da instância;
  • AWS Lambda: é um serviço Serverless que permite que você execute código sem provisionar ou gerenciar servidores. Você pode executar o código (em 6 linguagens mais as customizadas) para praticamente qualquer tipo de aplicação ou serviço de backend. Por meio do EventBridge o seu código é acionado automaticamente para executar ações em outros serviços da AWS. Ou seja, é no AWS Lambda que está contida a lógica de negócio para esta solução, que será detalhada na seção de Metodologia

• Forense: após a instância potencialmente comprometida ter passado por todo processo de isolamento, realizado pela AWS Lambda, a instância estará apartada da internet ou do resto do ambiente da aplicação, pronta para iniciar o processo de investigação e forense, utilizando o seguinte serviço:
  • AWS Systems Manager Session Manager: o Session Manager é uma capacidade do AWS Systems Manager totalmente gerenciada que permite conexão remota interativa (por shell ou RDP) às instâncias EC2, pelo console AWS ou pelo AWS CLI. Ele ajuda a fornecer gerenciamento de instâncias seguro e auditável sem a necessidade de abrir portas de entrada, manter bastion hosts ou gerenciar chaves Secure Shell (SSH). Confira como configurar o Session Manager para suas instâncias EC2: Configurar o Session Manager.

O desenho de arquitetura da figura 1, possui a mesma instância EC2 em dois estágios diferentes:

• Estágio 1: o momento onde o GuardDuty detecta uma atividade mal-intencionada gerando uma descoberta e iniciando o pipeline de resposta a incidente;
• Estágio 2: onde a instância passou pelo processo de isolamento e agora só pode ser acessada através do Session Manager. Ou seja, representando qualquer instância EC2 em seu ambiente. Caso seja gerado uma descoberta do GuardDuty, referente alguma instância, a mesma irá passar pelo processo de isolamento.

Metodologia

A lógica de negócio para esta solução tem como requisitos, que, assim que for detectada alguma instância comprometida, a mesma deve ser reconhecida em qual VPC está hospedada, ser desassociada de qualquer grupo de Amazon EC2 Auto Scaling e Load Balancer, impedir que a instância seja desligada e deve ser isolada através dos Security Groups para não ter qualquer comunicação externa ou interna. Desta forma, a lógica contida na AWS Lambda segue o seguinte fluxo:

1. Capturar os metadados da instância Amazon EC2, para descobrir qual VPC está hospedada, antes de realizar qualquer mudança no ambiente;
2. Desassociar de qualquer AWS Auto Sacaling groups;
3. Ativar a proteção de terminação da instância, para evitar desligamentos;
4. Isolar a instância por Security Groups.

Entendendo o isolamento por Security Groups

Compreender os Security Groups na nuvem é essencial. Por padrão negam todo tráfego, exigindo regras específicas para permitir acesso. As respostas ao tráfego de entrada são permitidas independentemente das regras de saída (stateful), graças às conexões com estado. É possível atribuir vários Security Groups a uma instância, e em casos de regras conflitantes, a mais permissiva prevalece. A Adição e remoção de regras de tráfego são imediatas, porém, o impacto de algumas mudanças depende do monitoramento do tráfego.

Existem dois tipos de conexões que passam pelos Security Groups: conexões tracked (monitoradas) e untracked (não monitoradas). O monitoramento acontece no tráfego de/para uma instância, implementando conexões com estado. No entanto, é importante notar que nem todos os fluxos de tráfego são monitorados, com exceção do tráfego ICMP, que é sempre controlado. Para mais detalhes acesse a documentação aqui.

Se uma regra do grupo de segurança permitir fluxos TCP ou UDP para todo o tráfego (0.0.0.0/0 ou ::/0) e houver uma regra correspondente na outra direção que permita todo o tráfego de resposta (0.0.0.0/0 ou ::/0) para todas as portas (0-65535), o fluxo do tráfego não será monitorado, a menos que seja parte de uma conexão automaticamente monitorada. Se um fluxo não monitorado for interrompido, isso ocorrerá imediatamente ao remover ou alterar a regra que permitia o fluxo. Por exemplo, se uma regra de saída permitir todo o tráfego e for removida, as conexões existentes serão interrompidas. No entanto, se uma regra de entrada mais restrita permitir uma conexão específica inicialmente monitorada e for alterada para não permitir mais novas conexões, as conexões existentes não serão interrompidas pela alteração da regra.

Desta forma, para executar o isolamento de uma instância via Security Group, e interromper todas as conexões ativas – inclusive e principalmente as que tem comportamento suspeito – devemos executar os seguintes passos:

1. Identificar o Security Group associado à instância;
2. Eliminar todas as regras existentes nesse grupo;
3. Criar uma única regra de 0.0.0.0/0 (0-65535) para todo o tráfego nas regras de entrada e de saída;

1. Essa ação converte todo o tráfego existente e futuro em untracked.

4. Remover as regras de entrada e de saída 0.0.0.0/0 (0-65535) para interromper todas as conexões, que agora estão todas marcadas como untracked.

Implementação

Um exemplo de como implementar essa solução pode ser encontrado no seguinte repositório no GitHub: automated-ec2-isolation-for-incident-response.

Conclusão

Através deste artigo vimos como é importante ter processos de respostas a incidentes automatizados em nosso ambiente, funcionando como mais uma camada de proteção de Segurança. O caso de uso abordado foi referente ao isolamento de instâncias EC2 que foram detectadas com alguma atividade mal-intencionada.

A metedologia utilizada para o isolamento foi através dos Security Groups da instância comprometida, o qual foi mostrado os passos para executar o isolamento de maneira efetiva, cautelosa e rápida, para não impactar o resto do ambiente.

Desta forma, concluí-se, que, foi construída uma solução de fácil deploy com arquitetura baseada em eventos e com finalidade de automatizar um processo de resposta a incidentes. Contribuindo com a postura de Segurança na AWS.

Sobre o autor

Henrique Souza é um Arquiteto de Soluções em Digital Native Business e membro da Comunidade de Segurança na AWS. Apoiando clientes de todas as regiões do Brasil em suas jornadas de inovação e transformação digital na nuvem.

Revisores

Pedro Rosinholi é Arquiteto de Soluções na AWS com mais de 12 anos de experiência em soluções de Tecnologia. Ajuda empresas nativas digitais na construção de seus negócios na nuvem de maneira segura, escalável e resiliente. No tempo livre coloca uns discos de vinil para tocar.

Gustavo Barbosa é arquiteto de soluções na AWS, ajuda clientes nativos digitais a desenvolver soluções escaláveis e seguras na nuvem.