GuardDuty Resultados do teste em contas dedicadas

Use este documento para executar um script de testador que gera GuardDuty descobertas em relação aos recursos de teste que serão implantados em seu. Conta da AWS Você pode realizar essas etapas quando quiser entender e aprender sobre determinados tipos de GuardDuty descoberta e como os detalhes da descoberta procuram recursos reais em sua conta. Essa experiência é diferente de gerar Descobertas de exemplo. Para obter mais informações sobre a experiência de testar GuardDuty os resultados, consulteConsiderações.

Considerações

Antes de continuar, leve em conta as seguintes considerações:

• GuardDuty recomenda implantar o testador em um local dedicado que não seja de produção. Conta da AWS Essa abordagem garantirá que você seja capaz de identificar adequadamente GuardDuty as descobertas geradas pelo testador. Além disso, o GuardDuty testador implanta uma variedade de recursos que podem exigir permissões do IAM além das permitidas em outras contas. O uso de uma conta exclusiva garante que as permissões possam ter o escopo adequado com um limite de conta claro.

• O script do testador gera mais de 100 GuardDuty descobertas com diferentes combinações AWS de recursos. Atualmente, isso não inclui todos os GuardDuty tipos de descoberta. Para obter uma lista dos tipos de descoberta que você pode gerar com esse script de testador, consulte GuardDuty descobertas que o script do testador pode gerar.

  Observação

  O script do testador é gerado somente AttackSequence:S3/CompromisedData para tipos de busca de sequência de ataque. Para visualizar e entenderAttackSequence:IAM/CompromisedCredentials, você pode gerar Descobertas de exemplo em sua conta.

• Para que o GuardDuty testador funcione conforme o esperado, ele GuardDuty precisa estar habilitado na conta em que os recursos do testador são implantados. Dependendo dos testes que serão executados, o testador avalia se os planos de GuardDuty proteção apropriados estão habilitados ou não. Para qualquer plano de proteção que não esteja habilitado, GuardDuty solicitará permissão para habilitar os planos de proteção necessários por tempo suficiente GuardDuty para realizar os testes que gerarão resultados. Posteriormente, GuardDuty desativará o plano de proteção quando o teste for concluído.

  Ativando GuardDuty pela primeira vez

  Quando GuardDuty for ativada em sua conta dedicada pela primeira vez em uma região específica, sua conta será automaticamente inscrita em um teste gratuito de 30 dias.

  GuardDuty oferece planos de proteção opcionais. No momento da ativação GuardDuty, alguns planos de proteção também são ativados e incluídos no teste gratuito GuardDuty de 30 dias. Para obter mais informações, consulte Usando o GuardDuty teste gratuito de 30 dias.

  GuardDuty já está habilitado em sua conta antes de executar o script do testador

  Quando já GuardDuty estiver ativado, com base nos parâmetros, o script do testador verificará o status da configuração de determinados planos de proteção e outras configurações no nível da conta necessárias para gerar as descobertas.

  Ao executar esse script de teste, determinados planos de proteção podem ser habilitados pela primeira vez em sua conta exclusiva em uma região. Esse procedimento iniciará a avaliação gratuita de 30 dias para esse plano de proteção. Para obter informações sobre o teste gratuito associado a cada plano de proteção, consulte Usando o GuardDuty teste gratuito de 30 dias.

• Desde que a infraestrutura do GuardDuty testador esteja implantada, você poderá ocasionalmente receber UnauthorizedAccess:EC2/TorClient descobertas da PenTest instância.

GuardDuty descobertas que o script do testador pode gerar

Atualmente, o script do testador gera os seguintes tipos de descoberta relacionados aos registros de auditoria da EC2 Amazon, Amazon EKS, Amazon S3, IAM e EKS:

• AttackSequence:S3/CompromisedData

• Backdoor:EC2/C&CActivity.B!DNS

• Backdoor:EC2/DenialOfService.Dns

• Backdoor:EC2/DenialOfService.Udp

• CryptoCurrency:EC2/BitcoinTool.B!DNS

• Impact:EC2/AbusedDomainRequest.Reputation

• Impact:EC2/BitcoinDomainRequest.Reputation

• Impact:EC2/MaliciousDomainRequest.Reputation

• Impact:EC2/SuspiciousDomainRequest.Reputation

• Recon:EC2/Portscan

• Trojan:EC2/BlackholeTraffic!DNS

• Trojan:EC2/DGADomainRequest.C!DNS

• Trojan:EC2/DNSDataExfiltration

• Trojan:EC2/DriveBySourceTraffic!DNS

• Trojan:EC2/DropPoint!DNS

• Trojan:EC2/PhishingDomainRequest!DNS

• UnauthorizedAccess:EC2/MaliciousIPCaller.Custom

• UnauthorizedAccess:EC2/RDPBruteForce

• UnauthorizedAccess:EC2/SSHBruteForce

• PenTest:IAMUser/KaliLinux

• Recon:IAMUser/MaliciousIPCaller.Custom

• Recon:IAMUser/TorIPCaller

• Stealth:IAMUser/CloudTrailLoggingDisabled

• Stealth:IAMUser/PasswordPolicyChange

• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS

• UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom

• UnauthorizedAccess:IAMUser/TorIPCaller

• Discovery:Kubernetes/MaliciousIPCaller.Custom

• Discovery:Kubernetes/SuccessfulAnonymousAccess

• Discovery:Kubernetes/TorIPCaller

• Execution:Kubernetes/ExecInKubeSystemPod

• Impact:Kubernetes/MaliciousIPCaller.Custom

• Persistence:Kubernetes/ContainerWithSensitiveMount

• Policy:Kubernetes/AdminAccessToDefaultServiceAccount

• Policy:Kubernetes/AnonymousAccessGranted

• PrivilegeEscalation:Kubernetes/PrivilegedContainer

• UnauthorizedAccess:Lambda/MaliciousIPCaller.Custom

• Discovery:S3/MaliciousIPCaller.Custom

• Discovery:S3/TorIPCaller

• PenTest:S3/KaliLinux

• Policy:S3/AccountBlockPublicAccessDisabled

• Policy:S3/BucketAnonymousAccessGranted

• Policy:S3/BucketBlockPublicAccessDisabled

• Policy:S3/BucketPublicAccessGranted

• Stealth:S3/ServerAccessLoggingDisabled

• UnauthorizedAccess:S3/MaliciousIPCaller.Custom

• UnauthorizedAccess:S3/TorIPCaller

• Backdoor:Runtime/C&CActivity.B!DNS

• CryptoCurrency:Runtime/BitcoinTool.B!DNS

• DefenseEvasion:Runtime/ProcessInjection.Ptrace

• DefenseEvasion:Runtime/ProcessInjection.VirtualMemoryWrite

• Execution:Runtime/ReverseShell

• Impact:Runtime/AbusedDomainRequest.Reputation

• Impact:Runtime/BitcoinDomainRequest.Reputation

• Impact:Runtime/MaliciousDomainRequest.Reputation

• Impact:Runtime/SuspiciousDomainRequest.Reputation

• PrivilegeEscalation:Runtime/ContainerMountsHostDirectory

• PrivilegeEscalation:Runtime/DockerSocketAccessed

• Trojan:Runtime/BlackholeTraffic!DNS

• Trojan:Runtime/DGADomainRequest.C!DNS

• Trojan:Runtime/DriveBySourceTraffic!DNS

• Trojan:Runtime/DropPoint!DNS

• Trojan:Runtime/PhishingDomainRequest!DNS

Mostrar maisMostrar menos

Etapa 1: pré-requisitos

Para preparar seu ambiente de teste, é preciso ter os seguintes itens:

• Git — Instale a ferramenta de linha de comando git com base no sistema operacional usado. Isso é necessário para clonar o amazon-guardduty-testerrepositório.

• AWS Command Line Interface— Uma ferramenta de código aberto que permite que você interaja Serviços da AWS usando comandos em seu shell de linha de comando. Para obter mais informações, consulte Conceitos básicos do AWS CLI no Manual do usuário do AWS Command Line Interface .

• AWS Systems Manager— Para iniciar sessões do Gerenciador de Sessões com seus nós gerenciados usando, AWS CLI você deve instalar o plug-in do Gerenciador de Sessões em sua máquina local. Para obter mais informações, consulte Install the Session Manager Plugin for the AWS CLI no Guia do usuário do AWS Systems Manager .

• Node Package Manager (NPM) — Instale o NPM para instalar todas as dependências.

• Docker: é necessário ter o Docker instalado. Para obter instruções de instalação, consulte o site do Docker.

  Para verificar se o Docker foi instalado, execute o comando a seguir e confirme se há uma saída semelhante à seguinte saída:

  $ docker --version
  Docker version 19.03.1

• Assine a imagem do Kali Linux no AWS Marketplace.

Etapa 2 - Implantar AWS recursos

Esta seção fornece uma lista dos principais conceitos e as etapas para implantar determinados recursos do AWS em sua conta dedicada.

Conceitos

A lista a seguir fornece os principais conceitos relacionados aos comandos que ajudam a implantar os recursos:

• AWS Cloud Development Kit (AWS CDK)— O CDK é uma estrutura de desenvolvimento de software de código aberto para definir a infraestrutura de nuvem em código e provisioná-la por meio dela. AWS CloudFormation Você pode usar qualquer uma dessas linguagens de programação compatíveis para definir componentes de nuvem reutilizáveis conhecidos como constructos. Você os compõe em pilhas e aplicativos. Em seguida, você pode implantar seus aplicativos CDK AWS CloudFormation para provisionar ou atualizar seus recursos. Para obter mais informações, consulte O que é o AWS CDK? no Guia do AWS Cloud Development Kit (AWS CDK) desenvolvedor.

• Bootstrapping — É o processo de preparar seu AWS ambiente para uso com. AWS CDK Antes de implantar uma pilha de CDK em um AWS ambiente, o ambiente deve primeiro ser inicializado. Esse processo de provisionamento de AWS recursos específicos em seu ambiente que são usados por AWS CDK faz parte das etapas que você executará na próxima seção -. Etapas para implantar recursos do AWS

  Para obter mais informações sobre inicialização, consulte Inicialização no Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) .

Etapas para implantar recursos do AWS

Execute as etapas a seguir para começar a implantar os recursos:

1. Configure sua conta e região AWS CLI padrão, a menos que as variáveis de região da conta dedicada sejam definidas manualmente no bin/cdk-gd-tester.ts arquivo. Para obter mais informações, consulte Ambientes no Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) .

2. Para implantar os recursos, execute os seguintes comandos:

   git clone https://github.com/awslabs/amazon-guardduty-tester && cd amazon-guardduty-tester
   npm install
   cdk bootstrap
   cdk deploy

   O último comando (cdk deploy) cria uma AWS CloudFormation pilha em seu nome. O nome dessa pilha é GuardDutyTesterStack.

   Como parte desse script, GuardDuty cria novos recursos para gerar GuardDuty descobertas em sua conta. Ele também adiciona o seguinte par de tags chave-valor às instâncias da Amazon EC2 :

   CreatedBy:GuardDuty Test Script

   As EC2 instâncias da Amazon também incluem as EC2 instâncias que hospedam nós EKS e clusters ECS.

   Tipos de instância

   GuardDuty foi projetado para usar tipos de instância econômicos que fornecem o desempenho mínimo necessário para realizar testes com êxito. Devido aos requisitos de vCPU, o grupo de nós do Amazon EKS exiget3.medium, e devido ao aumento da capacidade de rede necessária para DenialOfService encontrando testes, o nó do driver exigem6i.large. Para todos os outros testes, GuardDuty usa o tipo de t3.micro instância. Para obter mais informações sobre os tipos de instância, consulte Tamanhos disponíveis no Guia de tipos de EC2 instâncias da Amazon.

Etapa 3 - Executar scripts do testador

Esse é um processo de duas etapas em que você primeiro precisa iniciar uma sessão com o driver de teste e, em seguida, executar scripts para gerar GuardDuty descobertas com combinações de recursos específicas.

Parte A - Iniciar sessão com o driver de teste

1. Depois que seus recursos forem implantados, salve o código da região em uma variável na sessão atual do terminal. Use o comando a seguir e us-east-1 substitua pelo código da região em que você implantou os recursos:

   $ REGION=us-east-1

2. O script do testador está disponível somente por meio do AWS Systems Manager (SSM). Para iniciar um shell interativo na instância do host do testador, consulte o host InstanceId.

3. Use o comando a seguir para iniciar sua sessão para o script do testador:

   aws ssm start-session 
     --region $REGION 
     --document-name AWS-StartInteractiveCommand 
     --parameters command="cd /home/ssm-user/py_tester && bash -l" 
     --target $(aws ec2 describe-instances 
       --region $REGION 
       --filters "Name=tag:Name,Values=Driver-GuardDutyTester" 
       --query "Reservations[].Instances[?State.Name=='running'].InstanceId" 
       --output text)

Parte B - Gerar descobertas

O script do testador é um programa baseado em Python que cria dinamicamente um script bash para gerar descobertas com base em sua entrada. Você tem flexibilidade para gerar descobertas com base em um ou mais tipos de AWS recursos, planos de GuardDuty proteção OBJETIVO DA AMEAÇA (táticas) ouGuardDuty descobertas que o script do testador pode gerar. Fontes de dados fundamentais

Use os exemplos de comandos a seguir como referência e execute um ou mais comandos para gerar as descobertas que deseja explorar:

python3 guardduty_tester.py 
python3 guardduty_tester.py --all 
python3 guardduty_tester.py --s3 
python3 guardduty_tester.py --tactics discovery 
python3 guardduty_tester.py --ec2 --eks --tactics backdoor policy execution 
python3 guardduty_tester.py --eks --runtime only 
python3 guardduty_tester.py --ec2 --runtime only --tactics impact 
python3 guardduty_tester.py --log-source dns vpc-flowlogs 
python3 guardduty_tester.py --finding 'CryptoCurrency:EC2/BitcoinTool.B!DNS'

Para obter mais informações sobre parâmetros válidos, execute o comando de ajuda a seguir:

python3 guardduty_tester.py --help

Parte C - Analisar as descobertas geradas

Escolha um método de sua preferência para visualizar as descobertas geradas em sua conta.

GuardDuty console

1. Faça login no AWS Management Console e abra o GuardDuty console em https://console.aws.amazon.com/guardduty/.

2. No painel de navegação, selecione Descobertas.

3. Na tabela de descobertas, selecione uma descoberta cujos detalhes deseja visualizar. Isso abrirá o painel de detalhes da descoberta. Para ter mais informações, consulte Entendendo e gerando GuardDuty descobertas da Amazon.

4. Caso queira filtrar essas descobertas, use a chave e o valor da tag do recurso. Por exemplo, para filtrar as descobertas geradas para as EC2 instâncias da Amazon, useCreatedBy: par GuardDuty Test Script tag key:value para Instance tag key e Instance tag key.

API

• Corra ListFindingspara ver as descobertas de um ID de detector específico. É possível usar parâmetros específicos para filtrar as descobertas.

  Para encontrar o detectorId para sua conta e região atual, consulte a página de configurações no https://console.aws.amazon.com/guardduty/console ou execute o ListDetectorsAPI.

AWS CLI

• Execute o AWS CLI comando a seguir para visualizar as descobertas geradas us-east-1 e 12abc34d567e8fa901bc2d34EXAMPLE substituí-las por valores adequados:

  aws guardduty list-findings --region us-east-1 --detector-id 12abc34d567e8fa901bc2d34EXAMPLE

  Para encontrar o detectorId para sua conta e região atual, consulte a página de configurações no https://console.aws.amazon.com/guardduty/console ou execute o ListDetectorsAPI.

  Para obter mais informações sobre os parâmetros que você pode usar para filtrar descobertas, consulte list-findings na Referência de Comandos AWS CLI .

Etapa 4 - Limpe os recursos AWS de teste

As configurações em nível de conta e outras atualizações de status de configuração feitas durante o retorno Etapa 3 - Executar scripts do testador ao estado original quando o script do testador é concluído.

Depois de executar o script do testador, você pode optar por limpar os recursos de AWS teste. Isso pode ser feito usando um dos seguintes métodos.

• Execute o seguinte comando:

  cdk destroy

• Exclua a AWS CloudFormation pilha com o nome GuardDutyTesterStack. Para obter informações sobre as etapas, consulte Excluindo uma pilha no AWS CloudFormation console.

Solução de problemas comuns do

GuardDuty identificou problemas comuns e recomenda etapas de solução de problemas:

• Cloud assembly schema version mismatch— Atualize a AWS CDK CLI para uma versão compatível com a versão de montagem em nuvem necessária ou para a versão mais recente disponível. Para obter mais informações sobre a compatibilidade da CLI AWS CDK.

• Docker permission denied— Adicione o usuário da conta dedicada ao docker ou docker-users para que a conta dedicada possa executar os comandos. Para obter mais informações sobre as etapas, consulte a opção de soquete Daemon.

• Your requested instance type is not supported in your requested Availability Zone— Algumas zonas de disponibilidade não oferecem suporte a tipos específicos de instância. Para identificar quais zonas de disponibilidade oferecem suporte ao seu tipo de instância preferido e tentar implantar AWS recursos novamente, execute as seguintes etapas:

  1. Selecione um método de sua preferência para determinar quais zonas de disponibilidade são compatíveis com seu tipo de instância:

     Console

     Para identificar as zonas de disponibilidade compatíveis com o tipo de instância preferencial

     1. Faça login no AWS Management Console e abra o EC2 console da Amazon em https://console.aws.amazon.com/ec2/.

     2. Ao usar o seletor de AWS região no canto superior direito da página, escolha a região em que você deseja iniciar a instância.

     3. No painel de navegação, em Instâncias, escolha Tipos de Instâncias.

     4. Na tabela Tipos de instância, escolha um tipo de instância preferencial.

     5. Em Rede, veja as regiões listadas em Zonas de disponibilidade.

        Com base nessas informações, talvez seja necessário escolher uma nova região onde se possa implantar os recursos.

     AWS CLI

     Execute o comando a seguir para visualizar uma lista de zonas de disponibilidade. Certifique-se de especificar o tipo de instância de sua preferência e a região (us-east-1).

     aws ec2 describe-instance-type-offerings --location-type availability-zone  --filters Name=instance-type,Values=Preferred instance type --region us-east-1 --output table

     Para obter mais informações sobre esse comando, consulte describe-instance-type-offeringsna Referência de AWS CLI Comandos.

     Ao executar esse comando, se você receber um erro, verifique se está usando a versão mais recente da AWS CLI. Para obter mais informações, consulte Troubleshooting no Guia do usuário do AWS Command Line Interface .

  2. Tente implantar os AWS recursos novamente e especifique uma zona de disponibilidade compatível com seu tipo de instância preferido.

     Para tentar implantar AWS recursos novamente

     1. Configure a região padrão no arquivo bin/cdk-gd-tester.ts.

     2. Para especificar a zona de disponibilidade, abra o arquivo amazon-guardduty-tester/lib/common/network/vpc.ts.

     3. Nesse arquivo, substitua maxAzs: 2, por availabilityZones: ['us-east-1a', 'us-east-1c'], onde você deve especificar as zonas de disponibilidade para seu tipo de instância.

     4. Continue com as etapas restantes em Etapas para implantar recursos do AWS.