# Recomendaciones para crear AMI compartidas de Linux
Utilice las siguientes directrices para reducir la superficie de ataque y mejorar la fiabilidad de las AMI que cree.
**importante**
Ninguna lista de directrices de seguridad es exhaustiva. Cree sus AMI compartidas con precaución y piense bien en qué casos podría estar exponiendo información confidencial.
**Topics**
+ [Deshabilitación de los inicios de sesión remotos mediante contraseña para el usuario raíz](#public-amis-disable-password-logins-for-root)
+ [Deshabilitar el acceso local de la raíz](#restrict-root-access)
+ [Eliminar los pares de claves del host SSH](#remove-ssh-host-key-pairs)
+ [Instalar credenciales de clave pública](#public-amis-install-credentials)
+ [Desactivación de la verificación de DNS de sshd (opcional)](#public-amis-disable-ssh-dns-lookups)
+ [Eliminación de datos confidenciales](#public-amis-protect-yourself)
Si crea la AMI para AWS Marketplace, consulte [Prácticas recomendadas para crear AMI](https://docs.aws.amazon.com/marketplace/latest/userguide/best-practices-for-building-your-amis.html) en la *Guía del vendedor de AWS Marketplace* en lo que respecta a directrices, políticas y prácticas recomendadas.
## Deshabilitación de los inicios de sesión remotos mediante contraseña para el usuario raíz
El uso de una contraseña raíz fija para una AMI pública supone un riesgo para la seguridad que puede darse a conocer rápidamente. Incluso pedir a los usuarios que cambien la contraseña tras el primer inicio de sesión abre la puerta a un potencial abuso.
Para solucionar este problema, deshabilite los inicios de sesión remotos mediante contraseña para el usuario raíz.
**Deshabilitar los inicios de sesión remotos mediante contraseña para el usuario raíz**
1. Abra el archivo `/etc/ssh/sshd_config` con un editor de texto y localice la siguiente línea:
```
#PermitRootLogin yes
```
1. Cambie la línea a:
```
PermitRootLogin without-password
```
La ubicación de este archivo de configuración podría diferir para su distribución o si no está ejecutando OpenSSH. En ese caso, consulte la documentación pertinente.
## Deshabilitar el acceso local de la raíz
Cuando trabaja con AMI compartidas, es una práctica recomendada deshabilitar los inicios de sesión directos de la raíz. Para ello, inicie sesión en la instancia en ejecución e introduzca el siguiente comando:
```
[ec2-user ~]$ sudo passwd -l root
```
**nota**
Este comando no afecta al uso de `sudo`.
## Eliminar los pares de claves del host SSH
Si tiene previsto compartir una AMI derivada de una AMI pública, elimine los pares de claves del host de SSH existentes ubicados en `/etc/ssh`. Esto obliga a SSH a generar nuevos pares de claves de SSH únicos cuando alguien inicia una instancia usando la AMI, lo que mejora la seguridad y reduce la probabilidad de ataques "man-in-the-middle" (MITM).
Elimine los siguientes archivos de claves presentes en el 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
Puede eliminar de forma segura todos esos archivos con el comando siguiente.
```
[ec2-user ~]$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
```
**aviso**
Los servicios de eliminación segura, como **shred**, podrían no eliminar todas las copias de un archivo del medio de almacenamiento. Los sistemas de archivos de registro en diario (incluidos Amazon Linux default ext4), las instantáneas, las copias de seguridad, los RAID y el almacenamiento temporal en caché podrían crear copias ocultas de archivos. Para obtener más información, consulte la [documentación de shred](https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html).
**importante**
Si olvida eliminar los pares de claves del host de SSH existentes de la AMI pública, nuestro proceso de auditoría rutinario le notifica a usted y a todos los clientes que ejecuten instancias de la AMI acerca del posible riesgo para la seguridad. Tras un breve periodo de gracia, marcamos la AMI como privada.
## Instalar credenciales de clave pública
Tras configurar la AMI para evitar el inicio de sesión mediante contraseña, debe asegurarse de que los usuarios pueden iniciar sesión utilizando otro mecanismo.
Amazon EC2 permite a los usuarios especificar un nombre de par de claves pública y privada para iniciar la instancia. Cuando se proporciona un nombre de par de claves válido durante la llamada a la API `RunInstances` (o a través de las herramientas de la API de la línea de comandos), la clave pública (la parte del par de claves que Amazon EC2 conserva en el servidor tras llamar a `CreateKeyPair` o a `ImportKeyPair`) se pone a disposición de la instancia a través de una consulta HTTP a los metadatos de dicha instancia.
Para iniciar sesión mediante SSH, la AMI debe recuperar el valor de la clave al arrancar y adjuntarlo a `/root/.ssh/authorized_keys` (o el equivalente para cualquier otra cuenta de usuario de la AMI). Los usuarios pueden iniciar instancias de la AMI con un par de claves e iniciar sesión sin necesidad de una contraseña raíz.
Muchas distribuciones, como Amazon Linux y Ubuntu, usan el paquete `cloud-init` para introducir credenciales de clave pública para un usuario configurado. Si su distribución no admite `cloud-init`, puede añadir el siguiente código a un script de arranque del sistema (como `/etc/rc.local`) para obtener la clave pública que especificó durante la inicialización para el usuario raíz.
**nota**
En el ejemplo siguiente, la dirección IP http://169.254.169.254/ es una dirección local del vínculo y solo es válida desde la instancia.
------
#### [ 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
```
------
Esto se puede aplicar a cualquier usuario; no es necesario restringirlo al usuario `root`.
**nota**
La reagrupación de una instancia basada en esta AMI incluye la clave con la que se lanzó. Para evitar que se incluya esta clave, debe borrar (o eliminar) el archivo `authorized_keys` o excluirlo de la reagrupación.
## Desactivación de la verificación de DNS de sshd (opcional)
Deshabilitar la verificación de DNS de sshd debilita ligeramente la seguridad sshd. No obstante, si la resolución de DNS falla, los inicios de sesión SSH siguen funcionando. Si no deshabilita la verificación de sshd, los errores de resolución de DNS impedirán cualquier inicio de sesión.
**Para deshabilitar la verificación de DNS de sshd**
1. Abra el archivo `/etc/ssh/sshd_config` con un editor de texto y localice la siguiente línea:
```
#UseDNS yes
```
1. Cambie la línea a:
```
UseDNS no
```
**nota**
La ubicación de este archivo de configuración puede diferir para su distribución o si no está ejecutando OpenSSH. En ese caso, consulte la documentación pertinente.
## Eliminación de datos confidenciales
Desaconsejamos el almacenamiento de información confidencial o software en cualquier AMI que comparta. Los usuarios que lancen una AMI compartida podrían reagruparla y registrarla como propia. Siga estas directrices para ayudarlo a evitar ciertos riesgos para la seguridad que suelen pasarse por alto.
+ Le recomendamos que utilice la opción `--exclude directory` en `ec2-bundle-vol` para omitir cualquier directorio y subdirectorio que contenga información secreta que no desearía incluir en el paquete. En particular, excluya todos los pares de claves pública y privada SSH propiedad de los usuarios y los archivos SSH `authorized_keys` cuando realice la agrupación de la imagen. Las AMI públicas de Amazon los almacenan en `/root/.ssh` para el usuario raíz y en `/home/user_name/.ssh/` para usuarios normales. Para obtener más información, consulte [ec2-bundle-vol](ami-tools-commands.md#ami-bundle-vol).
+ Elimine siempre el historial del shell antes de realizar la agrupación. Si intenta cargar más de una agrupación en la misma AMI, el historial del shell contiene la clave de acceso. El siguiente ejemplo debería ser el último comando que ejecute antes de realizar la agrupación desde la instancia.
```
[ec2-user ~]$ shred -u ~/.*history
```
**aviso**
Las limitaciones de **shred** descritas en la advertencia anterior también son aplicables aquí.
Tenga en cuenta que bash escribe el historial de la sesión actual en el disco al salir. Si cierra sesión en la instancia después de eliminar `~/.bash_history` y, a continuación, vuelve a iniciar sesión, verá que `~/.bash_history` se ha vuelto a crear y que contiene todos los comandos que ejecutó durante la sesión anterior.
Además de bash, otros programas también escriben el historial en el disco. Tenga precaución y elimine o excluya los dot-files y dot-directories que no sean necesarios.
+ La agrupación de una instancia en ejecución requiere la clave privada y el certificado X.509. Guarde estas y otras credenciales en un lugar que no forme parte de la agrupación (como, por ejemplo, el almacén de instancias).