# Recomendações para criar AMIs compartilhadas no Linux
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.
**Topics**
+ [Desabilitar logins remotos com senha para o usuário raiz](#public-amis-disable-password-logins-for-root)
+ [Desabilitar o acesso à raiz local](#restrict-root-access)
+ [Remover pares de chave do host SSH](#remove-ssh-host-key-pairs)
+ [Instalação de credenciais de chave pública](#public-amis-install-credentials)
+ [Desabilitação de verificações de DNS para SSHD (opcional)](#public-amis-disable-ssh-dns-lookups)
+ [Remover dados confidenciais](#public-amis-protect-yourself)
Se você estiver criando AMIs para o AWS Marketplace, consulte [Práticas recomendadas para a criação de AMIs](https://docs.aws.amazon.com/marketplace/latest/userguide/best-practices-for-building-your-amis.html) no *Guia do vendedor do AWS Marketplace* para obter diretrizes, políticas e práticas recomendadas.
## 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
```
1. 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\$1host\$1dsa\$1key
+ ssh\$1host\$1dsa\$1key.pub
+ ssh\$1host\$1key
+ ssh\$1host\$1key.pub
+ ssh\$1host\$1rsa\$1key
+ ssh\$1host\$1rsa\$1key.pub
+ ssh\$1host\$1ecdsa\$1key
+ ssh\$1host\$1ecdsa\$1key.pub
+ ssh\$1host\$1ed25519\$1key
+ ssh\$1host\$1ed25519\$1key.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 de shred](https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html).
**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.
## Desabilitação de verificações de DNS para 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
```
1. 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.
## Remover dados confidenciais
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 obter mais informações, consulte [ec2-bundle-vol](ami-tools-commands.md#ami-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).