Vos credentials (login/password) sont précieux !

Pour se connecter à un serveur Linux, on utilise généralement le protocole SSH couplé identifiant/mot de passe (login/password) car c’est la méthode par défaut qui est proposée. Le protocole SSH permettant de chiffrer les communications de façon native, il est un bon élément pour garantir la sécurité. Cependant, il peut s’avérer dangereux de se connecter directement avec ses credentials…

Schéma classique d’une ouverture de session SSH

Attaque par Brute Force

Ce type d’attaque est vraiment fréquent sur Internet. Ceci est essentiellement dû à des bots programmés pour sonder aléatoirement les différents équipements connectés à Internet.

Cette attaque, très basique en soit, consiste à tester toutes les combinaisons possibles afin de déterminer le mot de passe d’un compte. Le pirate va soit utiliser un dictionnaire (contenant des mots prédéfinis) soit générer lui-même les différentes combinaisons. Je vous laisse imaginer le temps de survie de votre mot de passe s’il ressemble à quelque chose comme « azerty » (moins de 10 secondes…).

Attaque Man-in-the-Middle

Cette attaque, parfois complexe à détecter, consiste en la chose suivante : Le pirate va agir comme un tampon entre vous et votre serveur. Son objectif est simple, se faire passer pour l’hôte distant pour chacun des acteurs de la communication (c’est à dire qu’il se fera passer pour le serveur quand il échangera avec vous, et il se fera passer pour vous lorsqu’il échangera avec le serveur). Bien que cette attaque ai peu de chances de réussir sur une connexion SSH, le Man-in-the-Middle reste une « plaie » et il faut toujours rester vigilant lorsque l’on se connecte à un hôte distant.

Comment réagir ?

Tout d’abord ne perdons pas notre objectif de vue : sécuriser la connexion à notre serveur. Dans cet exemple, ce n’est pas le protocole SSH (déjà sécurisé) qui est en cause mais bien la méthode de connexion.

1. Ne pas se connecter avec le compte « root ».

Le compte « root » c’est le superutilisateur sur Linux et donc, de ce fait, il possède l’ensemble des privilèges sur votre système. Il est donc très dangereux de directement se connecter à distance avec lui.

On va donc créer un utilisateur (avec très peu de droits) qui nous permettra de se connecter sur le serveur et interdire la connexion via « root » :

# Création d'un utilisateur
adduser user01

# Edition du fichier de configuration du serveur SSH
nano /etc/ssh/sshd_config

# Modifier cette ligne de la façon suivante
PermitRootLogin no

# Redémarrer le service SSH pour appliquer les changements
/etc/init.d/ssh restart

Pourquoi faire cela ? Car au pire, si quelqu’un trouve le mot de passe de ce compte, il n’aura pas celui du compte « root » (donc la compromission est moins importante).

2. Utiliser des clés SSH et désactiver la connexion par mot de passe

Le mieux c’est de ne plus utiliser des login/password mais des clés SSH pré-générées.

Comment cela fonctionne ? On génère une paire de clés publiques/privées sur son poste (Linux) de la façon suivante :

ssh-keygen -t rsa -b 4096 -C "mon_email@example.com"

Note : « mon_email@example.com » est un label, cela permet d’identifier la clé. Cela n’a pas d’importance sur la génération en elle-même mais permet de savoir à qui appartient la clé. Je vous recommande d’associer une « Passphrase » à votre clé privée. Cela permet de s’assurer que seul vous et vous seul pourrez utiliser votre clé privée.

Vous allez ensuite vous retrouver avec une paire de clé publique/privée. C’est paire est étroitement liée car seule la clé privée peut déchiffrer les données chiffrées par la clé publique et seule la clé publique peut déchiffrer les données chiffrée par la clé privée.

Il vous suffira ensuite d’ajouter la clé publique sur votre serveur afin qu’il reconnaisse votre clé privée. Le schéma de connexion prendra la forme suivante :

Voici comment procéder sur votre serveur :

# Editer le fichier ".ssh/authorized_keys"
cd /home/$USER
nano .ssh/authorized_keys

# Ajoutez votre clé privée (qui doit ressembler à quelque chose comme cela)
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDGsyAIFos7dkVDly2cRaK2V6dpt8L6nLk+T0lUnY/u7fmL5rDUrm4/gb+BoTbdlJevyzziXKoiQ57Gmeq2AePtggQZmju/hu1U8X+pDQmrdqneJ4X9gvYSJBzr3DlO6exTjtCGtsyIoXPeqFYPAPDtOhov5IxzXB6c4V6FtfIn9dSC3Q3SK1+atOh8iv68Yh6D9IfeYmL3jcTHXQ4bm406jZ+1Pspc5oq53QFPgXevNCLo3ZTn6JHighhqtjmT2J2lWJbJ4s0LVeWtuoStsvmmYp7NNGDIipWeq5HuwpUrQPKTb12NK4t06wI2prAAgz/mNIzlszREv+A8TMutom2LN0Qq1JanpXGg4z/65Pofa25bFRzlHRAl0g27AVesZV4Ac5GiJrZRZ+cbB1ltKrEr8HiFlSVmsUKb8myBR0fSHXpjfgs+fgFsFruru2ht+UU9yUMjwItO9lFC7iIGFDPQO/F8ZdbeVw1qwbUYRvkQlLBanp/3xajNXHte0Auphu6VO728IMY4oAuvX1u451iDLUexBXlVJFlHL2dvcfGs5TzYHSztM/pk8CWcBGDDKsx/XAuZPRmAxipIAkgf4386IocSCpGu+z0mLBWSUkyal5zn6b2l6ZALyr+VcjwHqkmPWsjqI2Wy0W9bCR/ClilWLjUCSxe0JVW6qd4+I0UrAw== mon_email@example.com

# Edition du fichier de configuration du serveur SSH
nano /etc/ssh/sshd_config

# Modifier cette ligne de la façon suivante
PasswordAuthentication no

# Redémarrer le service SSH pour appliquer les changements
/etc/init.d/ssh restart

Note : Le fichier « .ssh/authorized_keys » est unique à un utilisateur système il faut donc être rigoureux. Si vous devez vous connecter avec le compte « user01 », il faut ajouter la clé dans « /home/user01/.ssh/authorized_keys ». Adaptez selon votre besoin.

Pourquoi faire cela ? Car en interdisant la connexion par mot de passe on empêche toute tentative de Brute Force (connexion par mot de passe désactivée) et il devient très difficile pour quelqu’un en Man-in-the-Middle de récupérer vos clés.

Sur Linux, il faudra utiliser la commande suivante pour vous connecter à votre serveur avec votre clé privée :

ssh user01@monserveur.com -i chemin/clé_privée