Bonnes pratiques de configuration SSH
Le SSH est un outil très pratique pour gérer et administrer nos serveurs Linux à distance dans un environnement contenant de multiples serveurs. Bien que le SSH chiffre les échanges pour les sécuriser, nous pouvons ajouter des sécurité supplémentaires aux accès SSH afin de rendre les tentatives d’attaque plus complexes. C’est ce que nous allons voir dans ce tutoriel.
Plusieurs bonnes pratiques sont en effet à suivre dans le cadre de la mise en place d’un accès SSH. Notez que la plupart des configurations vues ici ont été déjà vues dans le cours, cette partie vise à réunir les bonnes pratiques en terme d'utilisation de SSH.
Sommaire
I. Désactiver le login root
Il peut être utile et pertinent de désactiver l’accès en SSH pour l’utilisateur root. Cela empêcherait le fait qu’on puisse tenter des attaques de type "brute-force" (tentatives d’essais de plusieurs milliers ou millions de mots de passe) avec le login "root". On passe pour cela par le fichier de configuration SSH qui se situe dans "/etc/ssh/sshd_config", on ira y trouver cette option pour lui mettre la variable "no" :
Cela pose bien sûr un souci logistique supplémentaire. Il faut s’assurer, avant de faire cette manipulation, que l’on puisse se connecter en SSH via un autre utilisateur qui passera en root une fois connecté en SSH. Les attaquants devront alors trouver le login de cet utilisateur, puis son mot de passe. Il convient bien évidemment de mettre des droits restreints à cet utilisateur afin que, si son mot de passe est trouvé, les attaquants ne puissent pas faire grand chose avec.
Nous avons vu dans le cours que depuis Debian 8 et CentOS 7, c'est cette configuration qui est par défaut activée, ce qui n'était pas le cas avant.
II. Changer le port d’accès SSH
Comme tout accès distant à sécuriser, il convient de changer le port d’accès SSH standard (qui est 22) pour un port non standard. Cela rendra la tâche un peu plus difficile aux attaquants car pour attaquer notre accès SSH, ils devront d’abord trouver son port. Cela permet aussi d’éviter les robots qui scannent certaines IP pour voir si le port 22 est ouvert afin d’y tenter des attaques. Un robot ne trouvant pas de port 22 ouvert conclura qu’il n’y a pas d’accès SSH alors qu’il est en fait sur un autre port.
Il est important de savoir qu’il ne faut pas mettre un port en dessous 1024 car les ports 0-1024 sont réservés. On a donc le choix entre un numéro de port entre 1025 et ~65000. Nous choisirons par exemple ici 8022. On doit donc à nouveau aller modifier notre fichier de configuration pour y modifier ce paramètre :
Lors de la connexion, cela va se traduire par l’utilisation d’une option supplémentaire afin de préciser que nous n’utilisons pas le port par défaut (22). On utilisera l’option "-p" comme suivant :
ssh user@host -p 8022
Il faut bien sûr retenir le port non standard utilisé afin de ne pas se voir couper notre accès.
III Forcer l’utilisation de la version 2 du protocole
Le SSH en est actuellement à sa deuxième version. La version 1 souffrait de problèmes de sécurité dans la vérification de l’intégrité des données envoyées ou reçues, la rendant vulnérable à des attaques. Il convient donc par sécurité de n’autoriser que la deuxième version du protocole. Par défaut cette option est normalement activée mais il convient de la connaître et de vérifier son activation. On trouvera donc cette option dans le fichier de configuration SSH :
Il sera alors impossible de démarrer une connexion SSH si le client utilise la version 1 du protocole.
IV. Écouter une seule interface
Si votre serveur dispose de plusieurs interfaces, dont certaines sur des réseaux dangereux (DMZ ou autre…), il peut être intéressant de n’écouter et permettre les connexions SSH que depuis le réseaux de confiance (LAN). Cela passe par l’option "ListenAddress" :
Par défaut, ces options sont grisées, cela veut dire que le serveur SSH écoute sur toutes les interfaces disponibles. On peut donc n’écouter que sur une seule interface en spécifiant celle voulue. Cela entraîne l’arrêt de l’écoute sur les autres interfaces. On peut y préciser des interfaces IPv4 et IPv6.
V. Authentification par clés
Au lieu d’avoir une authentification par mot de passe SSH qui peut être facilement contournée à partir du moment où le mot de passe est trouvé, on peut mettre en place une authentification par clés.
Cette spécificité a été étudié plus longuement durant le cours, pour rappel, référez-vous au chapitre sur l'authentification par clés. Authentification SSH par clé
VI. Autoriser/interdire l’accès à certains utilisateurs spécifiques
On peut préciser la liste des utilisateurs habilités à se connecter en SSH (mis à part l’utilisateur root comme vu plus haut où cela passe par une autre option). Il faut en effet ajouter une option (elle n’est pas présente par défaut) dans le fichier de configuration comme suivant :
AllowUser neaj neoflow@linux_center
Par exemple ici, on utilise seulement l’utilisateur neaj à se connecter depuis partout (sans précision du poste client) ainsi que l’utilisateur neoflow depuis le poste client "linux_center". Cette option ferme directement toute possibilité d’accès aux autres utilisateurs. On peut également passer par des groupes avec l’option "AllowGroups". À l’inverse, on peut mettre une liste d’utilisateurs qui n’auront explicitement pas le droit de se connecter en SSH. Ce qui veut dire que tous les utilisateurs qui n’y sont pas précisés auront droit à un accès SSH :
DenyUsers user1 user2@poste1
Il convient de fonctionner seulement avec l’une ou l’autre des méthodes. De même que pour les autoriser, on peut fonctionner avec les groupes de par l’option "DenyGroups".
VII. Faire attention aux logs
De manière moins précise, il convient de vérifier de temps à autres les logs de vos serveurs afin de voir si de trop nombreuses tentatives infructueuses de connexion n’y sont pas présentes, ce qui pourrait révéler des tentatives d’attaques. Les logs de connexions SSH sont présents dans "/var/log/auth.log" et nous pouvons utiliser une commande pour n’y extraire que les échecs de connexion :
grep "Invalid" /var/log/auth.log
On aura ainsi rapidement une liste des échecs de connexion SSH.
VIII. Bien quitter son accès SSH
Les connexions distantes SSH faites avec des outils fenêtrés tels que Putty se voient souvent fermées par un clic pour fermer la fenêtre en question. Cela est cependant dangereux car le processus SSH peut mal se terminer créant ainsi une faille dans l’accès SSH. Il convient donc de fermer le SSH de façon plus propre avec les commandes suivantes :
logout
Ou encore :
exit
