Directrices para AMI de Linux compartidas - Amazon Elastic Compute Cloud

Directrices para AMI de Linux compartidas

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.

Si crea la AMI para AWS Marketplace, consulte Prácticas recomendadas para crear AMI en la Guía del vendedor de AWS Marketplace en lo que respecta a directrices, políticas y prácticas recomendadas.

Para obtener información adicional sobre cómo compartir AMI de forma segura, consulte los siguientes artículos:

Actualizar las herramientas de AMI antes de usarlas

Para las AMI con el respaldado del almacén de instancias, le recomendamos que descargue y actualice las herramientas de creación de AMI de Amazon EC2 antes de utilizarlas. Esto garantiza que las nuevas AMI basadas en las AMI compartidas tengan las últimas herramientas para AMI.

En Amazon Linux 2, instale el paquete aws-amitools-ec2 y añada las herramientas de la AMI a PATH con el comando siguiente. En Amazon Linux AMI, el paquete aws-amitools-ec2 ya está instalado de forma predeterminada.

[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

Actualice las herramientas de la AMI con el siguiente comando:

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

Para otras distribuciones, asegúrese de tener las últimas herramientas para AMI.

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
  2. 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 lanza 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_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

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.

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 lanzar 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 lanzar 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 el lanzamiento 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.

Deshabilitar 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
  2. 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.

Protéjase

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 ayudarle 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.

  • 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).