Quelles sont les bonnes pratiques pour accéder en toute sécurité à mon instance Linux EC2 à l'aide de SSH tout en évitant les accès non autorisés ?

Lecture de 5 minute(s)
0

Je souhaite accéder à mon instance Amazon Elastic Compute Cloud (Amazon EC2) à l'aide de SSH. Quelles sont les bonnes pratiques pour assurer la protection de mon instance et éviter les accès non autorisés lors de l'utilisation de SSH ?

Solution

Utilisez les meilleures pratiques suivantes pour sécuriser vos instances lorsque vous utilisez SSH. Pour les étapes impliquant des commandes, veillez à exécuter des commandes avec des privilèges racines. Exécutez la commande sudo -i pour devenir l'utilisateur racine.

Utiliser le Gestionnaire de session AWS Systems Manager pour un accès shell aux instances EC2

Session Manager permet aux utilisateurs d'AWS Identity and Access Management (IAM) de se connecter à vos instances grâce à des fonctionnalités de chiffrement et de journalisation. Le trafic de Systems Manager passe par le point de terminaison de Systems Manager, ce qui permet un accès facile et sécurisé aux instances privées sans ouvrir de ports entrants. Pour plus d'informations sur Session Manager, consultez le Gestionnaire de session AWS Systems Manager pour un accès shell aux instances EC2.

Utiliser EC2 Instance Connect pour un accès shell aux instances EC2

Amazon EC2 Instance Connect vous permet de vous connecter à vos instances Linux à l'aide de Secure Shell (SSH) grâce à des rôles et des stratégies IAM. Pour plus d'informations sur EC2 Instance Connect, consultez Connexion à votre instance Linux à l'aide d'EC2 Instance Connect.

Remarque : EC2 Instance Connect est prise en charge dans les distributions suivantes :

  • Amazon Linux 2 (n'importe quelle version)
  • Ubuntu 16.04 ou version ultérieure

Ne pas autoriser l'utilisateur racine à utiliser un terminal SSH

Par défaut, les AMI fournies par Amazon et la plupart des fournisseurs d'AWS Marketplace n'autorisent pas l'utilisateur racine à se connecter à partir d'un terminal SSH. Si votre instance permet à l'utilisateur racine de se connecter, procédez alors comme suit pour refuser l'accès.

1.    Ajoutez un * (astérisque) au champ réservé au mot de passe dans le fichier /etc/shadow pour invalider le mot de passe de l'utilisateur racine :

Modifiez le fichier avec vipw -s.

La première ligne est généralement la ligne de l'utilisateur racine. Modifiez la ligne de l'utilisateur racine comme suit :

root:*LOCK*:14600::::::

2.    Modifiez le fichier de configuration du démon SSH à l'aide d'un éditeur tel que l'éditeur vi :

vi /etc/ssh/sshd_config

Assurez-vous que la ligne suivante est présente et non commentée. Cette ligne refuse l'autorisation de connexion à l'utilisateur racine.

PermitRootLogin no

3.    Redémarrez le démon SSH :

systemctl restart sshd

Pour plus d'informations sur les autres paramètres de l'option PermitRootLogin, consultez sshd_config sur OpenBSD.

Assurez-vous que tous les utilisateurs se connectent à l'aide d'une paire de clés SSH, puis désactivez l'authentification par mot de passe

La configuration par défaut pour des AMI fournies par Amazon est la connexion à l'aide d'une paire de clés SSH avec l'authentification par mot de passe désactivée. En effet, l'utilisation d'un mot de passe expose votre instance à des risques de sécurité tels que les attaques par force brute. Les mots de passe faibles peuvent être déchiffrés pour y accéder.

Si vous avez donc modifié votre instance pour utiliser un mot de passe, revenez à la configuration par défaut à l'aide des commandes suivantes :

1.    Utilisez l'éditeur vi ou l'éditeur de votre choix pour accéder au fichier sshd_config :

vi /etc/ssh/sshd_config

2.    Vérifiez que la ligne suivante est présente et non commentée :

PasswordAuthentication no

3.    Redémarrez le démon SSH :

systemctl restart sshd

Remarque : assurez-vous que les paires de clés sont installées avant de désactiver l'authentification par mot de passe. Cela vous évite de perdre l'accès SSH à l'instance EC2. Chaque utilisateur doit insérer ses clés publiques dans le chemin ~/.ssh/authorized_keys. Pour plus d'informations à propos des connexions par clé, consultez Paires de clés Amazon EC2 et instances Linux.

Restreindre l'accès à partir de sources inconnues

Pour les instances publiques, laisser le port SSH ouvert et sans restriction peut permettre des intrusions en cas de mauvaise configuration ou de vulnérabilités logicielles inattendues. Pour éviter ces intrusions, suivez les bonnes pratiques suivantes :

1.    Gardez le démon SSH à jour vers la dernière version fournie par votre responsable de distribution Linux. Le démon SSH reçoit souvent des mises à jour de backport provenant de versions ultérieures du fournisseur en amont. Pour plus d'informations sur le backporting, consultez l'article Correctifs de sécurité relatifs au backporting sur le site Web Red Hat Customer Portal.

yum -y install openssh-server # for Amazon Linux, RHEL, Centos
apt update && apt install openssh-server # For Ubuntu, Debian

2.    Limitez votre groupe de sécurité de façon à autoriser les connexions entrantes au port 22 uniquement à partir d'adresses IP approuvées, telles que les adresses IP d'un réseau d'entreprise. Pour plus d'informations, consultez Autoriser le trafic entrant pour vos instances Linux.

3.    Certains intrus peuvent essayer de deviner les noms d'utilisateur et les mots de passe, ou tenter de déborder votre démon SSH si le port 22 est ouvert au monde. L'utilitaire fail2ban surveille vos fichiers journaux à la recherche de tentatives constantes de connexion à votre instance, puis bloque ces dernières après quelques tentatives infructueuses. Pour installer fail2ban**:**

Ubuntu :

apt -y install fail2ban

Amazon Linux, CentOS, RHEL :

Installez le référentiel EPEL.

Exécutez les commandes suivantes :

yum -y install fail2ban
systemctl enable fail2ban
systemctl start fail2ban

Pour plus d'informations sur la configuration de fail2ban, consultez l'article Sécurité Linux : Protégez votre système à l'aide de fail2ban sur le site Web de Red Hat.


AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an