Diretrizes para AMIs em Linux compartilhadas

Use as diretrizes a seguir para reduzir a superfície de ataque e melhorar a confiabilidade das AMIs criadas.

Importante

Nenhuma lista de diretrizes de segurança consegue ser exaustiva. Crie suas AMIs compartilhadas cuidadosamente e tire um tempo para considerar onde é possível expor dados confidenciais.

Se você estiver criando AMIs para o AWS Marketplace, consulte Práticas recomendadas para a criação de AMIs no Guia do vendedor do AWS Marketplace para obter diretrizes, políticas e práticas recomendadas.

Para obter informações adicionais sobre compartilhamento de AMIs com segurança, consulte os seguintes artigos:

• Como compartilhar e usar AMIs públicas de forma segura

• Public AMI Publishing: Hardening and Clean-up Requirements

Atualização das ferramentas de AMI antes do uso

Para AMIs com armazenamento de instâncias, recomendamos que suas AMIs façam download e atualizem as ferramentas de criação de AMI do Amazon EC2 antes de usá-las. Isso garante que as novas AMIs baseadas nas suas AMIs compartilhadas tenham as ferramentas de AMI mais recentes.

No Amazon Linux 2, instale o pacote aws-amitools-ec2 e adicione as ferramentas de AMI no seu caminho com o comando a seguir. No Amazon Linux AMI, o pacote aws-amitools-ec2 já vem instalado por padrão.

[ec2-user ~]$ sudo yum install -y aws-amitools-ec2 && export PATH=$PATH:/opt/aws/bin > /etc/profile.d/aws-amitools-ec2.sh && . /etc/profile.d/aws-amitools-ec2.sh

Atualize as ferramentas de AMI com o comando a seguir:

[ec2-user ~]$ sudo yum upgrade -y aws-amitools-ec2

Para outras distribuições, tenha as ferramentas de AMI mais recentes.

Desabilitar logins remotos com senha para o usuário raiz

Usar uma senha de raiz fixa com uma AMI pública é um risco de segurança que pode rapidamente ficar conhecido. Até mesmo depender dos usuários para alterar a senha depois do primeiro login abre uma pequena janela de oportunidade para potencial abuso.

Para resolver esse problema, desabilite logins remotos com senha para o usuário raiz.

Para desabilitar logins remotos com senha para o usuário raiz

1. Abra o arquivo /etc/ssh/sshd_config com um editor de texto e localize a seguinte linha:

   #PermitRootLogin yes

2. Altere a linha para:

   PermitRootLogin without-password

   O local desse arquivo de configuração pode diferir para sua distribuição ou se você não estiver executando OpenSSH. Se esse for o caso, consulte a documentação apropriada.

Desabilitar o acesso à raiz local

Quando você trabalha com AMIs compartilhadas, a prática recomendada é desabilitar logins diretos na raiz. Para isso, faça login na sua instância em execução e emita o seguinte comando:

[ec2-user ~]$ sudo passwd -l root

nota

Esse comando não afeta o uso de sudo.

Remover pares de chave do host SSH

Se você pretende compartilhar uma AMI derivada de uma AMI pública, remova os pares de chaves do host SSH existentes localizadas em /etc/ssh. Isso força o SSH a gerar novos pares de chaves SSH exclusivos quando alguém executar uma instância usando sua AMI, melhorando a segurança e reduzindo a probabilidade de ataques "man-in-the-middle".

Elimine todos os arquivos de chave a seguir presentes no seu sistema.

• ssh_host_dsa_key

• ssh_host_dsa_key.pub

• ssh_host_key

• ssh_host_key.pub

• ssh_host_rsa_key

• ssh_host_rsa_key.pub

• ssh_host_ecdsa_key

• ssh_host_ecdsa_key.pub

• ssh_host_ed25519_key

• ssh_host_ed25519_key.pub

É possível remover com segurança todos esses arquivos com o comando a seguir.

[ec2-user ~]$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub

Atenção

Utilitários de exclusão segura, como shred, podem não remover todas as cópias de um arquivo da sua mídia de armazenamento. Podem ser criadas cópias ocultas de arquivos ao criar registros dos sistemas de arquivos (incluindo Amazon Linux padrão ext4), snapshots, backups, RAID e cache temporário. Para obter mais informações, consulte a documentação do shred.

Importante

Se você se esquecer de remover o par de chaves existente do host SSH da AMI pública, nosso processo de auditoria de rotina notificará você e todos os clientes que executam instâncias da sua AMI sobre o risco potencial à segurança. Após um breve período de carência, marcamos a AMI como privada.

Instalação de credenciais de chave pública

Depois de configurar a AMI para impedir o login usando uma senha, é necessário garantir que os usuários possam fazer login usando outro mecanismo.

O Amazon EC2 permite que os usuários especifiquem um nome de par de chaves público-privado ao executarem uma instância. Quando um nome válido de par de chaves for fornecido para a chamada de API RunInstances (ou pelas ferramentas de API da linha de comando), a chave pública (a parte do par de chaves que o Amazon EC2 retém no servidor depois de uma chamada para CreateKeyPair ou ImportKeyPair) será disponibilizada para a instância por meio de uma consulta HTTP contra os metadados de instância.

Para fazer login com SSH, sua AMI deve recuperar o valor da chave na inicialização e anexá-la a /root/.ssh/authorized_keys (ou o equivalente para qualquer outra conta de usuário na AMI). Os usuários podem executar instâncias da sua AMI com um par de chaves e fazer login sem exigir uma senha raiz.

Muitas distribuições, inclusive Amazon Linux e Ubuntu, usam o pacote cloud-init para injetar credenciais de chave pública a um usuário configurado. Se sua distribuição não oferecer suporte a cloud-init, é possível adicionar o código a seguir a um script de inicialização do sistema (como /etc/rc.local) para puxar a chave pública especificada na execução para o usuário raiz.

nota

No exemplo a seguir, o endereço IP do http://169.254.169.254/ é um endereço local de link e é válido apenas a partir da instância.

IMDSv2

if [ ! -d /root/.ssh ] ; then
        mkdir -p /root/.ssh
        chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
        cat /tmp/my-key >> /root/.ssh/authorized_keys
        chmod 700 /root/.ssh/authorized_keys
        rm /tmp/my-key
fi

IMDSv1

if [ ! -d /root/.ssh ] ; then
        mkdir -p /root/.ssh
        chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
        cat /tmp/my-key >> /root/.ssh/authorized_keys
        chmod 700 /root/.ssh/authorized_keys
        rm /tmp/my-key
fi

Isso pode se aplicar a qualquer usuário; não precisa ficar restrito ao root.

nota

Reempacotar uma instância baseada nessa AMI inclui a chave com a qual ela foi executada. Para evitar a inclusão de chaves, é necessário desmarcar (ou excluir) o arquivo authorized_keys ou excluir esse arquivo do reempacotamento.

Desabilitar as verificações DNS sshd (opcional)

Desabilitar as verificações de DNS sshd enfraquece levemente a segurança de sshd. Contudo, se uma solução de DNS falhar, o login de SSH continuará funcionando. Se você não desabilitar verificações de sshd, falhas de resolução de DNS impedirão todos os logins.

Para desabilitar as verificações de DNS sshd

1. Abra o arquivo /etc/ssh/sshd_config com um editor de texto e localize a seguinte linha:

   #UseDNS yes

2. Altere a linha para:

   UseDNS no

nota

O local desse arquivo de configuração pode diferir para sua distribuição ou se você não estiver executando OpenSSH. Se esse for o caso, consulte a documentação apropriada.

Proteja-se

Não recomendamos armazenar dados confidenciais ou software em nenhuma AMI compartilhada. Os usuários que executarem uma AMI compartilhada podem ser capazes de reempacotá-la e registrá-la como própria. Siga estas diretrizes para ajudá-lo a evitar alguns riscos de segurança facilmente negligenciados:

• Recomendamos usar a opção --exclude directory em ec2-bundle-vol para ignorar todos os diretórios e subdiretórios que contêm informações secretas que você não gostaria de incluir no seu pacote. Mais especificamente, exclua todos os arquivos authorized_keys de pares de chaves públicas/privadas e SSH de propriedade do usuário ao empacotar a imagem. As AMIs públicas da Amazon os armazenam na /root/.ssh do usuário raiz e /home/user_name/.ssh/ para os usuário regulares. Para ter mais informações, consulte ec2-bundle-vol.

• Sempre exclua o histórico do shell antes de empacotar. Se você tentar fazer mais de um upload de bundle na mesma AMI, o histórico do shell conterá sua chave de acesso. O exemplo a seguir deve ser o último comando executado antes de empacotar na instância.

  [ec2-user ~]$ shred -u ~/.*history

  Atenção

  As limitações de shred descritas no alerta acima aplicam-se aqui também.

  Esteja ciente de que, ao sair, o bash grava o histórico da sessão atual no disco. Se você fizer logout da sua instância após a exclusão de ~/.bash_history, e depois fizer login de volta, descobrirá que ~/.bash_history foi recriado e contém todos os comandos executados durante a sessão anterior.

  Outros programas além do bash também gravam históricos no disco. Use com cuidado e remova ou exclua arquivos-ponto ou diretórios-ponto desnecessários.

• O empacotamento de uma instância em execução requer sua chave privada e o certificado X.509. Coloque essas e outras credenciais em um local que não seja empacotado (como armazenamento de instâncias).