Recommandations pour créer un système Linux partagé AMIs

Suivez les instructions suivantes pour réduire la surface d'attaque et améliorer la fiabilité de ce AMIs que vous créez.

Important

Aucune liste de consignes de sécurité ne peut être exhaustive. Créez votre partage AMIs avec soin et prenez le temps de réfléchir aux endroits où vous pourriez exposer des données sensibles.

Si vous créez AMIs pour cela AWS Marketplace, consultez la section Meilleures pratiques en matière de construction AMIs dans le Guide du AWS Marketplace vendeur pour connaître les directives, les politiques et les meilleures pratiques.

Pour plus d'informations sur le partage AMIs sécurisé, consultez les articles suivants :

• Comment partager et utiliser le public AMIs de manière sécurisée

• AMIPublication publique : exigences de renforcement et de nettoyage

Désactivation des connexions distantes basées sur un mot de passe pour l’utilisateur root

L'utilisation d'un mot de passe root fixe pour un public AMI constitue un risque de sécurité qui peut rapidement être connu. Même le fait de compter sur les utilisateurs pour changer le mot de passe après leur première connexion laisse une petite place à une opportunité d’abus potentiel.

Pour résoudre ce problème, désactivez les connexions à distance basées sur mot de passe pour l’utilisateur racine.

Pour désactiver les connexions à distance basées sur un mot de passe pour l’utilisateur root

1. Ouvrez le fichier /etc/ssh/sshd_config dans un éditeur de texte et localisez la ligne suivante :

   #PermitRootLogin yes

2. Changez la ligne en :

   PermitRootLogin without-password

   L'emplacement de ce fichier de configuration peut être différent selon votre distribution ou si vous n'exécutez pas OpenSSH. Si tel est le cas, consultez la documentation appropriée.

Désactivation de l’accès local à la racine

Lorsque vous travaillez avec le partageAMIs, il est recommandé de désactiver les connexions root directes. Pour ce faire, connectez-vous à votre instance en cours d’exécution et entrez la commande suivante :

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

Note

Cette commande n’a pas d’impact sur l’utilisation de sudo.

Supprimer les paires de clés d'SSHhôte

Si vous envisagez de partager un AMI dérivé d'un publicAMI, supprimez les paires de clés SSH d'hôte existantes qui se trouvent dans/etc/ssh. Cela oblige SSH à générer de nouvelles paires de SSH clés uniques lorsque quelqu'un lance une instance en utilisant la vôtreAMI, ce qui améliore la sécurité et réduit le risque man-in-the-middle d'attaques.

Supprimez tous les fichiers clés suivants présents dans votre système.

• 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

Vous pouvez supprimer tous ces fichiers en toute sécurité avec la commande suivante.

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

Avertissement

Les utilitaires de suppression sécurisée tels que shred peuvent ne pas supprimer toutes les copies d’un fichier de vos supports de stockage. Des copies masquées de fichiers peuvent être créées en journalisant des systèmes de fichiers (y compris le fichier ext4 par défaut d'Amazon Linux), des instantanésRAID, des sauvegardes et une mise en cache temporaire. Pour plus d’informations, consultez la documentation shred.

Important

Si vous oubliez de supprimer les paires de clés SSH d'hôte existantes de votre publicAMI, notre processus d'audit de routine vous informe, ainsi que tous les clients utilisant vos instances, AMI du risque de sécurité potentiel. Après une courte période de grâce, nous marquons la AMI confidentialité.

Installation d’informations d’identification publiques

Après avoir configuré le AMI pour empêcher la connexion à l'aide d'un mot de passe, vous devez vous assurer que les utilisateurs peuvent se connecter à l'aide d'un autre mécanisme.

Amazon EC2 permet aux utilisateurs de spécifier un nom de paire de clés publique-privée lors du lancement d'une instance. Lorsqu'un nom de paire de clés valide est fourni à l'RunInstancesAPIappel (ou via les API outils de ligne de commande), la clé publique (la partie de la paire de clés qu'Amazon EC2 conserve sur le serveur après un appel à CreateKeyPair ouImportKeyPair) est mise à la disposition de l'instance par le biais d'une HTTP requête portant sur les métadonnées de l'instance.

Pour vous connecterSSH, vous AMI devez récupérer la valeur de la clé au démarrage et l'ajouter /root/.ssh/authorized_keys (ou l'équivalent pour tout autre compte utilisateur sur leAMI). Les utilisateurs peuvent lancer vos instances à l'AMIaide d'une paire de clés et se connecter sans avoir besoin d'un mot de passe root.

De nombreuses distributions, dont Amazon Linux et Ubuntu, utilisent le package cloud-init pour injecter des informations d’identification de clé publiques pour un utilisateur configuré. Si votre distribution ne prend pas en charge cloud-init, vous pouvez ajouter le code suivant à un script de démarrage système (tel que /etc/rc.local) pour extraire la clé publique que vous avez spécifiée au lancement pour l’utilisateur racine.

Note

Dans l’exemple suivant, l’adresse IP http://169.254.169.254/ est une adresse lien-local et elle n’est valide que depuis l’instance.

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

Cela peut être appliqué à n’importe quel utilisateur. Il n’est pas nécessaire de la limiter à l’utilisateur root.

Note

Le regroupement d'une instance sur cette base AMI inclut la clé avec laquelle elle a été lancée. Pour éviter l’inclusion de la clé, vous devez vider (ou supprimer) le fichier authorized_keys ou exclure ce fichier du nouveau bundle.

Désactiver les DNS vérifications SSHD (facultatif)

La désactivation des DNS vérifications SSHD affaiblit légèrement votre sécurité SSHD. Toutefois, si DNS la résolution échoue, SSH les connexions fonctionnent toujours. Si vous ne désactivez pas les vérifications SSHD, les échecs de DNS résolution empêcheront toutes les connexions.

Pour désactiver les vérifications SSHD DNS

1. Ouvrez le fichier /etc/ssh/sshd_config dans un éditeur de texte et localisez la ligne suivante :

   #UseDNS yes

2. Changez la ligne en :

   UseDNS no

Note

L'emplacement de ce fichier de configuration peut varier selon votre distribution ou si vous n'exécutez pas OpenSSH. Si tel est le cas, consultez la documentation appropriée.

Supprimer les données sensibles

Nous vous déconseillons de stocker des données ou des logiciels sensibles sur AMI ceux que vous partagez. Les utilisateurs qui lancent un partage AMI peuvent être en mesure de le regrouper et de l'enregistrer comme leur propre compte. Suivez ces consignes pour vous permettre d’éviter de vous exposer à des risques de sécurité facilement négligés :

• Nous recommandons d’utiliser l’option --exclude directory sur ec2-bundle-vol pour éviter tout répertoire et sous-répertoire contenant des informations secrètes que vous ne souhaiteriez pas inclure dans votre regroupement. En particulier, excluez toutes les paires de clés SSH publiques/privées et tous les SSH authorized_keys fichiers appartenant à l'utilisateur lors du regroupement de l'image. Le public Amazon les AMIs stocke /root/.ssh pour l'utilisateur root et /home/user_name/.ssh/ pour les utilisateurs réguliers. Pour de plus amples informations, veuillez consulter ec2-bundle-vol.

• Supprimez toujours l’historique shell avant la création d’un bundle. Si vous tentez de télécharger plusieurs lots simultanémentAMI, l'historique du shell contient votre clé d'accès. L’exemple ci-après devrait être la dernière commande que vous avez exécutée avant de créer un bundle depuis l’instance.

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

  Avertissement

  Les limites de shred décrites dans l’avertissement ci-dessus s’appliquent également ici.

  Ayez à l’esprit que bash inscrit l’historique de la session en cours sur le disque au moment de quitter. Si vous vous déconnectez de votre instance après avoir supprimé ~/.bash_history et si vous vous reconnectez ensuite, vous constaterez que ~/.bash_history a été recréé et contient toutes les commandes que vous avez exécutées durant votre session précédente.

  D’autres programmes en dehors de bash inscrivent les historiques sur le disque. Soyez prudent et retirez ou excluez tous les fichiers et répertoires dot superflus.

• Le regroupement d'une instance en cours d'exécution nécessite votre clé privée et X.509 certificat. Mettez ces éléments et toutes les autres informations d’identification dans un endroit qui n’est pas regroupé (comme par exemple le stockage d’instances).