Guide de durcissement de la sécurité OpenSSH pour Linux

SSH est l’un des protocoles les plus utilisés pour l’administration système sur les plateformes Linux. Il est disponible pour de nombreux systèmes d’exploitation basés sur Unix, Linux et MacOS. Il est basé sur le modèle client-serveur, où une machine exécute le composant serveur et l’autre utilise un outil client pour y accéder.

Comment fonctionne SSH ?

Le client (ssh) initie la connexion en envoyant une demande au serveur. Le serveur écoute les demandes entrantes en utilisant le démon serveur (sshd). Il utilise sa clé publique pour s’authentifier auprès du client essayant de se connecter :

De cette manière, le client est assuré qu’il se connecte au bon serveur SSH. Une fois cela fait, le client peut accéder au serveur. Si vous êtes sur un client Windows, vous devrez utiliser des outils comme putty pour vous connecter au serveur. Le client et le serveur peuvent être installés sur le même système, ce qui signifie que vous pouvez utiliser l’outil client pour accéder à d’autres machines ou que votre système peut être le serveur lui-même, accessible par d’autres. Dans ce cas, le fichier de configuration est placé dans le même répertoire mais avec un nom légèrement différent. L’emplacement du répertoire est ‘/etc/ssh’ et le nom du fichier de configuration du client ssh est ‘ssh_config’ et celui du fichier de configuration du serveur est ‘sshd_config’ :

En cas de présence des deux fichiers sur votre système, vous devez choisir judicieusement lequel vous devez configurer. Dans la plupart des cas, c’est le serveur que nous devons configurer pour la sécurité, car il ouvre la porte à un accès potentiel au système.

Nous commençons d’abord par vérifier l’état du démon SSH ou sshd sur notre serveur. De cette manière, nous pouvons voir s’il fonctionne et s’il est activé pour démarrer automatiquement au démarrage. La commande ci-dessous vérifiera l’état de sshd :

$ systemctl status ssh.service

Ou utilisez celle-ci :

$ systemctl status sshd.service

D’après la capture d’écran, nous pouvons voir que le service est actif et activé. Il fonctionne depuis les 6 dernières heures. Lorsque vous développez la vue du terminal en appuyant sur la flèche droite, vous remarquerez qu’il écoute sur le port par défaut 22.

Parfois, nous apportons des modifications au fichier de configuration SSH du système distant alors que nous y sommes connectés en utilisant le SSH lui-même. Dans ce cas, nous devrions utiliser la commande reload au lieu de restart. De cette manière, nous sommes moins susceptibles d’être déconnectés.

Configurer SSH en utilisant les meilleures pratiques

Je pense qu’il est maintenant temps de commencer à configurer la configuration du serveur SSH. Avant de nous salir les mains avec le fichier de configuration SSH, nous devrions faire une sauvegarde du fichier avec les paramètres par défaut :

$ sudo cp /etc/ssh/sshd_config ~/sshd_config.bkp

Après avoir effectué la sauvegarde, nous sommes assurés que si nous gâchons le fichier principal et cassons notre SSH, nous pouvons utiliser le fichier de sauvegarde pour revenir à la normalité.

1. Changer le port par défaut

Le démon sshd écoute par défaut sur le port 22 du serveur. Il est recommandé de changer cette valeur pour un autre numéro afin de réduire la portée des attaques automatisées utilisant des scripts. Cette approche est appelée sécurité par l’obscurité. Pour cela, ouvrez le fichier ci-dessous et recherchez la ligne contenant le texte ‘#Port 22’.

$ sudo nano /etc/ssh/sshd_config

Décommentez la ligne ‘#Port 22’ et changez ‘22’ pour un autre numéro de port, non utilisé sur votre système. Nous devons le changer en ‘222’ et redémarrer le service. Maintenant, utilisez la commande ssh avec l’option ‘p’ pour spécifier le nouveau port :

$ ssh user@system_ip -p 222

2. Désactiver la connexion en tant qu’utilisateur Root

Root est l’utilisateur ultime sur tout système Linux avec accès à toutes les ressources de votre système. Si vous n’avez pas besoin d’un accès root strict, vous devriez désactiver la possibilité de connexion root sur votre serveur. Pour cela, ouvrez le même fichier ci-dessus :

$ sudo nano /etc/ssh/sshd_config

et définissez le paramètre ‘PermitRootLogin’ sur ‘no’. Cela garantira que le serveur sera protégé contre les attaques aléatoires ciblant le compte root. L’option par défaut est ‘prohibit-password’ qui permet la connexion basée sur l’authentification par clé publique mais refuse les connexions basées sur mot de passe.

3. Définir la version du protocole

La version de protocole SSH la plus ancienne est 1 et elle est moins sécurisée par rapport à SSH2 et elles ont des implémentations réseau différentes et ne sont pas compatibles entre elles. Pour vérifier quelle version de protocole est active sur votre serveur, ouvrez à nouveau le fichier sshd_config et recherchez la ligne ‘Protocol’ :

$ cat /etc/ssh/sshd_config | grep ‘Protocol’

En cas de sortie vide, OpenSSH utilise probablement la version 2 comme c’était le cas pour nous. Une autre façon est d’utiliser l’utilitaire de commande netcat :

$ nc localhost 22

Sortie d’exemple :

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4

D’après la sortie, nous pouvons voir que SSH2 est actif sur notre système.

Pour vérifier quelles versions de protocoles un serveur distant exécute, essayez de vous y connecter en utilisant un client ssh avec l’option -Q (requête) :

$ ssh -Q protocol-version user@server_name

L’image ci-dessus montre une version SSH 2 lors de l’accès à un serveur ssh Ubuntu depuis un Kali Linux.

4. Complexité des mots de passe

Les mots de passe faibles sont toujours vulnérables à l’exploitation, donc les mots de passe vides sont plus susceptibles d’être exploités. L’option PermitEmptyPasswords doit donc être définie sur ‘no’ dans le fichier sshd_config. De la même manière, le nombre de tentatives de connexion avec un mot de passe incorrect doit être limité pour réduire les chances d’attaque par force brute. Cela peut être réalisé avec l’option ‘MaxAuthTries’ définie sur une valeur plus petite comme 3.

D’après l’image ci-dessus, nous pouvons voir que lorsque nous définissons la valeur ‘MaxAuthTries’ à 3, nous sommes refusés SSH après trois mots de passe incorrects. Un autre aspect majeur de la sécurité est d’utiliser l’authentification par clé publique pour la connexion. Les modèles d’authentification basés sur des clés sont moins vulnérables aux attaques par force brute. De même, nous pouvons utiliser le module d’authentification PAM pour renforcer encore plus le serveur SSH.

Conclusion

Dans ce guide, nous avons essayé de couvrir les points les plus importants pour sécuriser un serveur SSH et de les résumer en quatre points majeurs. Bien que ce guide ne soit pas complet, vous pouvez même trouver d’autres domaines pour renforcer davantage votre serveur SSH. Par exemple, vous pouvez essayer d’ajouter un message d’avertissement pour alerter les utilisateurs sur l’utilisation de votre système via SSH. Vous pouvez également refuser la connexion avec un mot de passe et utiliser l’authentification par clé pour une connexion sans mot de passe. Une autre chose intéressante est que vous pouvez limiter le nombre d’utilisateurs SSH et leur temps de connexion.