Como faço para recuperar recursos da AWS que foram afetados pelo atendente CrowdStrike Falcon?

Breve descrição

Em 19 de julho de 2024, às 04:09 UTC, uma atualização no atendente CrowdStrike Falcon (csagent.sys) fez com que dispositivos com Windows apresentassem erros de interrupção inesperados ou tela azul. Os dispositivos afetados incluíram instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e áreas de trabalho virtual pessoais do Amazon WorkSpaces Personal. Esse problema afetou apenas instâncias do Windows do Amazon EC2 e WorkSpaces pessoais com o CrowdStrike instalado.

Para obter mais informações, consulte o Remediation and Guidance Hub: Incidente do Channel File 291 no site CrowdStrike.

Normalmente, reiniciar sua instância ou WorkSpace permite que o atendente CrowdStrike Falcon seja atualizado com sucesso.

Observação: se sua instância usa volumes de armazenamento de instância, os dados armazenados nesses volumes não persistem quando você interrompe, hiberna ou encerra a instância. Quando você interrompe, hiberna ou encerra a instância, o volume do armazenamento de instância é apagado criptograficamente. Para obter mais informações, consulte Armazenamento em bloco temporário do armazenamento de instância para instâncias do EC2.

Resolução

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), consulte Solução de problemas da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

Se uma reinicialização não restaurar a instância para um estado íntegro, use o runbook do AWS Systems Manager Automation para restaurar suas instâncias. Ou restaure-as manualmente.

Para usar o runbook, primeiro consulte os seguintes pré-requisitos:

• Se o volume raiz do Amazon Elastic Block Store (Amazon EBS) estiver criptografado, certifique-se de que a chave de criptografia exista na sua conta. Além disso, verifique se você tem permissão para usá-lo.
• O runbook AWSSupport-StartEC2RescueWorkflow interrompe sua instância. Se sua instância usa volumes de armazenamento de instâncias, use o método de recuperação manual para evitar a perda de dados.
• Antes de iniciar o runbook AWSSupport-StartEC2RescueWorkflow, certifique-se de que seu usuário ou perfil do AWS Identity and Access Management (IAM) tenha as permissões necessárias. Para obter mais informações, consulte a seção Required IAM permissions (Permissões do IAM necessárias) do AWSSupport-StartEC2RescueWorkflow. Você também deve adicionar a permissão kms:CreateGrant ao perfil do IAM.

Identificar instâncias prejudicadas

Para identificar instâncias com falha, execute o comando describe-instance-status da AWS CLI:

aws ec2 describe-instance-status --filters Name=instance-status.status,Values=impaired --query "InstanceStatuses[*].InstanceId" --region your-region

Observação: substitua your-region pela sua região da AWS.

Usar o runbook do Systems Manager Automation para restaurar uma única instância do EC2

Para usar o AWSSupport-StartEC2RescueWorkflow para automatizar a recuperação, abra o runbook no console do Systems Manager. Em seguida, selecione a região e a instância que você deseja recuperar. Se o volume raiz do Amazon EBS estiver criptografado, defina AllowEncryptedVolume como Verdadeiro.

Esse fluxo de trabalho de runbook inicia uma instância temporária do EC2 (instância auxiliar) em uma nuvem privada virtual (VPC). O fluxo de trabalho associa automaticamente a instância auxiliar ao grupo de segurança padrão da VPC. A instância deve permitir a comunicação HTTPS de saída (porta TCP 443) com os endpoints do Amazon Simple Storage Service (Amazon S3) e do Systems Manager.

Você deve executar a instância em uma das seguintes sub-redes para que a instância alcance os serviços da AWS necessários para concluir as tarefas do fluxo de trabalho:

• Sub-rede pública com o parâmetro AssociatePublicIpAddress definido como Verdadeiro.
• Sub-rede privada com acesso à Internet por meio de NAT.

A instância auxiliar monta o volume raiz das instâncias selecionadas e, em seguida, executa o seguinte comando para excluir o arquivo afetado:

get-childitem -path "$env:EC2RESCUE_OFFLINE_DRIVE\Windows\System32\drivers\CrowdStrike\" -Include C-00000291*.sys -Recurse | foreach { $_.Delete()}

Para verificar o conteúdo da carga útil do Base64 OfflineScript do comando anterior, execute o seguinte comando:

PS C:\Windows\system32> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("REPLACE_WITH_BASE64_HERE"))

Usar o runbook do AWS Systems Manager Automation para restaurar várias instâncias do EC2

Para usar o runbook em várias instâncias do EC2, use IDs de instância, tags ou grupos de recursos.

O runbook inicia uma instância auxiliar para cada instância selecionada. Verifique se você tem endereços IP suficientes na sub-rede selecionada para suas instâncias. Além disso, verifique se você possui cotas suficientes de instância e de volume EBS.

Observação: o tempo necessário para a conclusão do runbook de automação depende do nível de simultaneidade que você selecionou.

Usar IDs de instância

Conclua as etapas a seguir:

1. Abra o runbook AWSSupport-StartEC2RescueWorkflow no console do Systems Manager.
2. Em Executar o runbook de automação, escolha Controle de taxa.
3. Na seção Destinos, em Parâmetro, escolha InstanceId. Em Destinos, escolha Valores de parâmetros.
4. Em Parâmetros de entrada, selecione as instâncias que você deseja restaurar.
5. Em Controle de taxa, escolha a opção de simultaneidade para definir quantos recursos podem executar a automação ao mesmo tempo. Para obter mais informações, consulte Automações de controle em escala.
6. Selecione Executar.

Usar tags

Conclua as etapas a seguir:

1. Crie uma tag nova e exclusiva para usar somente nas instâncias que você deseja restaurar. Todas as instâncias com essa tag são alvo do processo de recuperação, o que pode causar perda de dados não intencional ou afetar a disponibilidade da instância. Para obter mais informações, consulte Marcar com tag os recursos do Amazon EC2 e O que é o Tag Editor?
2. Para verificar se somente as instâncias afetadas compartilham a nova tag, use o Explorador de Recursos da AWS ou o Tag Editor.
3. Abra o runbook AWSSupport-StartEC2RescueWorkflow no console do Systems Manager.
4. Em Executar o runbook de automação, escolha Controle de taxa.
5. Na seção Destinos, em Parâmetro, escolha InstanceId. Em Destinos, escolha Valores de parâmetros.
6. Em Tags, escolha Editar. Insira a chave e o valor da tag e então escolha Salvar.
7. Em Parâmetros de entrada, selecione as instâncias que você deseja restaurar.
8. Em Controle de taxa, escolha a opção de simultaneidade para definir quantos recursos podem executar a automação ao mesmo tempo. Para obter mais informações, consulte Automações de controle em escala.
9. Selecione Executar.

Usar grupos de recursos

Conclua as etapas a seguir:

1. Crie um novo grupo de recursos para usar somente nas instâncias que você deseja restaurar. Todas as instâncias desse grupo de recursos são destinadas à recuperação e podem causar perda não intencional de dados ou afetar a disponibilidade da instância. Para mais informações, consulte Creating query-based groups in AWS Resource Groups (Criar grupos baseados em consultas no AWS Resource Groups).
2. Para verificar se somente as instâncias afetadas pertencem ao novo grupo de recursos, use o console do AWS Resources Groups.
3. Abra o runbook AWSSupport-StartEC2RescueWorkflow no console do Systems Manager.
4. Em Executar o runbook de automação, escolha Controle de taxa.
5. Na seção Destinos, em Parâmetro, escolha InstanceId. Em Destinos, escolha Valores de parâmetros.
6. Em Grupos de recursos, selecione o novo grupo de recursos.
7. Em Parâmetros de entrada, selecione as instâncias que você deseja restaurar.
8. Em Controle de taxa, escolha a opção de simultaneidade para definir quantos recursos podem executar a automação ao mesmo tempo. Para obter mais informações, consulte Automações de controle em escala.
9. Selecione Executar.

Restaurar manualmente as instâncias

Conclua as etapas a seguir:

1. Crie um snapshot do volume raiz do EBS da instância.
2. Crie um novo volume do EBS a partir do snapshot na mesma zona de disponibilidade.
3. Execute uma nova instância do Windows na mesma zona de disponibilidade.
4. Anexe o novo volume do EBS à nova instância como um volume de dados.
5. Faça o download a ferramenta EC2Rescue para Windows Server na instância auxiliar.
6. Clique com o botão direito em EC2Rescue.exe e escolha Executar como administrador.
   Selecione Eu concordo no Contrato de Licença.
   Na tela Boas-vindas, escolha Avançar.
   Na tela Selecionar modo, escolha Instância off-line.
   Selecione o disco off-line e, em seguida, escolha Avançar. Quando o prompt for exibido, escolha Sim e, em seguida, escolha OK.
   Mantenha o EC2Rescue funcionando.
   Observação: se sua instância original usa o BitLocker para criptografar o volume raiz do EBS, siga os prompts na tela para fornecer sua senha ou chave de recuperação do BitLocker. Ou use manage-bde unlock na linha de comandos. Para obter mais informações, consulte manage-bde unlock no site da Microsoft. Depois de desbloquear a unidade, repita a etapa 6.
7. Navegue até a pasta X:\Windows\System32\drivers\CrowdStrike\ no volume anexado e, em seguida, exclua C-00000291*.sys.
   Observação: neste exemplo, X: é a letra da unidade atribuída ao volume secundário do EBS da instância afetada. Pode ser uma letra diferente em seu ambiente.
8. Retorne ao EC2 Rescue.
   Selecione Diagnosticar e resgatar e, em seguida, escolha Avançar.
   Mantenha todas as opções como padrão.
   Selecione Avançar e, em seguida, escolha Avançar novamente.
   Quando o prompt for exibido, escolha Resgatar. Selecione OK e, em seguida, escolha Avançar.
   Selecione Concluir.
   Na janela pop-up, escolha Corrigir assinatura de disco e, em seguida, OK.
   Se a opção Corrigir assinatura do disco estiver acinzentada, escolha OK.
9. Separe o volume do EBS da nova instância.
10. Crie um snapshot do volume EBS desanexado.
11. Selecione o mesmo tipo de volume (por exemplo, gp2 ou gp3) da instância afetada e, em seguida, crie uma imagem de máquina da Amazon (AMI) a partir do snapshot.
12. Substitua o volume raiz na instância original do EC2 e especifique a AMI.

WorkSpaces

Se várias reinicializações não retornarem seu WorkSpace a um estado íntegro, restaure o WorkSpace para um snapshot anterior. Se a restauração do WorkSpace não retornar seu WorkSpace ao estado íntegro, reconstrua-o.

Resolução de problemas

Se as etapas anteriores não resolverem seus problemas de conectividade, siga as etapas de solução de problemas a seguir:

Usar o runbook do Systems Manager Automation

Problema: a instância auxiliar não pode se conectar aos endpoints de serviço da AWS. Esse problema pode causar uma falha na etapa do fluxo de trabalho de automação waitForEc2RescueInstanceToBeManaged.

Solução: confirme se o grupo de segurança padrão permite que o tráfego de saída (porta TCP 443) alcance o Systems Manager e os endpoints do S3. Além disso, certifique-se de que a sub-rede selecionada possa se conectar a esses endpoints. Para usar um grupo de segurança personalizado, atualize o valor do parâmetro HelperInstanceSecurityGroupId com seu ID de grupo de segurança. Se você escolher uma sub-rede pública, defina o parâmetro AssociatePublicIpAddress como Verdadeiro. Também é possível definir o parâmetro SubnetId como CreateNewVPC para que a automação crie uma nova VPC com a conectividade necessária.

Problema: a instância afetada não é interrompida porque a proteção de interrupção está ativada.

Solução: desative a proteção de interrupção para a instância afetada e execute novamente a automação.

Observação: se sua instância usa volumes de armazenamento de instância, os dados armazenados nesses volumes não persistem quando você interrompe a instância.

Problema: a instância auxiliar falha ao executar.

Solução: o tipo de instância selecionado para a instância EC2Rescue pode não estar disponível na Zona de Disponibilidade da sub-rede da instância auxiliar. Use um tipo de instância compatível na mesma zona de disponibilidade da instância auxiliar.

Problema: quando a automação verifica que a criação da pilha do AWS CloudFormation foi concluída, ela falha com o erro: "Stack AWSSupport-EC2Rescue-{UUID} entered unexpected state: DELETE_IN_PROGRESS".

Solução: para determinar o que causou a falha da pilha, obtenha o UUID e use o console do CloudFormation. A falha na pilha pode ocorrer se você não tiver permissões para criar os recursos da pilha. Para obter mais informações, consulte a seção Required IAM permissions (Permissões IAM necessárias) do AWSSupport-StartEC2RescueWorkflow e Como solucionar erros de acesso negado ou operação não autorizada em uma política do IAM?

Problema: o runbook falha na etapa assertInstanceRootVolumeIsNotEncrypted do fluxo de trabalho de automação devido a um volume EBS criptografado.

Solução: se o volume usar criptografia do EBS, defina o parâmetro AllowEncryptedVolume como Verdadeiro.

Problema: a VPC padrão foi excluída.

Solução: defina o parâmetro SubnetId como CreateNewVPC para criar uma nova VPC que permita que a instância se recupere.

Problema: a etapa detachInstanceRootVolume do fluxo de trabalho de automação falha com a mensagem de erro "error occurred (IncorrectState) when calling the DetachVolume operation: Unable to detach root volume".

Solução: ao executar a automação, mantenha a instância no estado Parado.

Restauração manual de instâncias

Problema: a instância falha ao inicializar com o erro "the application or operating system couldn't be loaded because a registered file is missing or contains errors".

Solução: se você não selecionou Corrigir assinatura de disco, é possível ter uma colisão de assinatura de disco. Para resolver esse problema, siga a etapa 8 nas etapas de restauração manual. Se você restaurou a instância sem o EC2Rescue, consulte Solucionar problemas com instâncias do Windows do Amazon EC2.

Observação: se as etapas anteriores de solução de problemas não resolverem a conectividade com sua instância do EC2, entre em contato com o AWS Support. Certifique-se de fazer uma captura de tela da instância inacessível.

Informações relacionadas

Executar a ferramenta EC2Rescue em instâncias inacessíveis