Recommandations pour la création des AMI Linux partagées - Amazon Elastic Compute Cloud
Désactivation des connexions distantes basées sur un mot de passe pour l’utilisateur rootDésactivation de l’accès local à la racineSuppression des paires de clés de l’hôte SSHInstallation d’informations d’identification publiquesDésactiver les vérifications DNS sshd (facultatif)Supprimer les données sensibles

Recommandations pour la création des AMI Linux partagées

Utilisez les consignes suivantes pour réduire la surface d’attaque et améliorer la fiabilité des AMI que vous créez.

Important

Aucune liste de consignes de sécurité ne peut être exhaustive. Créez vos AMI partagées avec soin et prenez le temps d’étudier où vous exposez peut-être des données sensibles.

Si vous créez des AMI pour AWS Marketplace, consultez Bonnes pratiques de création d’AMI dans le AWS Marketplace Guide du vendeur pour obtenir des consignes, des stratégies et les bonnes pratiques.

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

En utilisant un mot de passe racine fixe pour une AMI publique, un risque de sécurité peut rapidement apparaître. 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 varier pour 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 des AMI partagées, une bonne pratique consiste à désactiver les connexions directes à la racine. 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.

Suppression des paires de clés de l’hôte SSH

Si vous prévoyez de partager une AMI issue d’une AMI publique, supprimez les paires de clés de l’hôte SSH existantes situées dans /etc/ssh. Cela force SSH à générer de nouvelles paires de clés SSH uniques lorsque quelqu’un lance une instance utilisant votre AMI, ce qui améliore la sécurité et réduit la probabilité d’attaques MITM.

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 votre support de stockage. Des copies cachées de fichiers peuvent être crées par les systèmes de fichiers de journalisation (dont Amazon Linux default ext4), les instantanés (snapshots), les sauvegardes, RAID et la mise en cache temporaire. Pour plus d’informations, consultez la documentation shred.

Important

Si vous oubliez de supprimer les paires de clés de l’hôte SSH existantes de votre AMI publique, notre processus routinier d’audit vous informe ainsi que tous les clients exécutant des instances de votre AMI du risque de sécurité potentiel. Au terme d’une courte période de grâce, nous marquons l’AMI comme privée.

Installation d’informations d’identification publiques

Après avoir configuré l’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 au moment de lancer une instance. Lorsqu’un nom de paire de clés valide est fourni à l’appel de l’API RunInstances (ou par les outils API de ligne de commande), la clé publique (la portion de la paire de clés qu’Amazon EC2 conserve sur le serveur après un appel à CreateKeyPair ou ImportKeyPair) est rendue disponible pour l’instance via une requête HTTP sur les métadonnées d’instance.

Pour se connecter via SSH, votre AMI doit récupérer la valeur clé au moment du démarrage et la joindre à /root/.ssh/authorized_keys (ou l’équivalent pour tout autre compte utilisateur sur l’AMI). Les utilisateurs peuvent lancer des instances de votre AMI avec votre paire de clés et se connecter sans avoir besoin de mot de passe racine.

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

La création d’un nouveau bundle d’une instance basée sur cette 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 vérifications DNS sshd (facultatif)

Désactiver les vérifications DNS sshd affaiblit quelque peu votre sécurité sshd. Toutefois, si la résolution DNS échoue, les connexions SSH continuent de fonctionner. Si vous ne désactivez pas les vérifications sshd, les échecs de résolution DNS empêchent toutes les connexions.

Pour désactiver les vérifications DNS sshd

  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 pour 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 déconseillons de stocker des données ou logiciels sensibles sur toute AMI que vous partagez. Les utilisateurs qui lancent une AMI partagée peuvent être en mesure de la regrouper et de l’enregistrer comme étant la leur. 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. Excluez notamment toutes les paires de clés publiques/privées SSH appartenant à l’utilisateur, et les fichiers SSH authorized_keys lorsque vous créez un bundle de l’image. Les AMI publiques Amazon stockent ces éléments dans /root/.ssh pour l’utilisateur root et dans /home/user_name/.ssh/ pour les utilisateurs réguliers. Pour de plus amples informations, consultez ec2-bundle-vol.

  • Supprimez toujours l’historique shell avant la création d’un bundle. Si vous essayez de réaliser plusieurs téléchargements de regroupement dans une même AMI, l’historique 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.

  • La création d’une offre groupée pour une instance en cours d’exécution nécessite votre clé privée et un certificat X.509. 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).