Votre connexion SSH est-elle sûre ?

Dans cet article, nous nous intéressons à la sécurité des connexions SSH.

SSH (Secure Shell) est un protocole de communication sécurisé. Il est fréquemment utilisé pour se connecter à distance à un shell (ligne de commande), en général sur des machines Linux.

Le plus souvent, le protocole SSH est mis en place à l’aide des outils libres OpenSSH (OpenBSD Secure Shell). On peut également utiliser Dropbear pour les systèmes embarqués, et d’autres outils existent.

Sécurité des algorithmes

Vous ne le savez peut-être pas, mais lorsque vous installez OpenSSH (le plus courant) sous Linux, de nombreux algorithmes sont utilisés pour les échanges de clés (“kex”), les clés de l’hôte (“key”), les chiffrements (“ciphers”) et les codes d’authentification de message (“mac”). Cela assure une compatibilité maximale avec les différents clients existants.

Oui mais… Certains de ces algorithmes sont obsolètes voire non sûrs ! Geonov vous conseille donc de ne conserver que les algorithmes les plus sûrs voire mieux, le plus sûr de chaque catégorie.

Comment différencier les algorithmes sûrs ou pas ?

Nous allons utiliser deux méthodes. Pour cela, prenons l’exemple du site postgis.net. Une commande ping nous indique l’adresse IP du serveur hébergeant le site : “45.58.41.142” :

Avec un peu de chance, le serveur en question dispose d’une connexion SSH sur le port 22 (port par défaut). Vérifions si ce port 22 est ouvert avec la commande nc :

Parfait ! Le port 22 est ouvert, il y a donc certainement un serveur SSH à l’écoute.

Méthode 1 : sshcheck.com

Le site Internet sshcheck.com permet de tester une connexion SSH. Il n’y a pas besoin d’indiquer des informations confidentielles (comme un login ou pire un mot de passe), en effet le site ne fait qu’interroger un serveur SSH pour connaître les algorithmes qu’il propose.

Nous indiquons donc l’IP “45.58.41.142” et le port “22” avant de cliquer sur le bouton “Test”.

Quelques secondes plus tard, le résultat s’affiche :

C’est donc la liste de tous les algorithmes (“kex”, “key”, “ciphers”, “mac”) qu’accepte ce serveur SSH. Alors qu’un seul de chaque serait suffisant, on remarque tout de suite que ce serveur “ratisse large” (ce qui est la configuration par défaut d’OpenSSH).

Mais surtout ce qui saute aux yeux, ce sont les algorithmes marqués “weak” (faible) en orange ou ces remarques “Possible NSA backdoor” (“Porte dérobée éventuelle par la NSA”). Tous ces algorithmes devraient être refusés par le serveur SSH.

Méthode 2 : ssh-audit

Une autre méthode consiste à utiliser le script Python ssh-audit. Il suffit de le télécharger puis de l’exécuter de cette façon :

ssh-audit.py [-parametres] <host>

Là aussi, il n’y a pas besoin d’indiquer des informations confidentielles, le script ne fait qu’interroger le serveur SSH.

Faisons le test avec postgis.net :

Cette fois nous obtenons 3 couleurs pour nous alerter sur les problèmes : vert, jaune et rouge.

Mais le résultat est similaire à celui obtenu par la méthode précédente : des algorithmes sont à retirer, par exemple les “kex” nommés “ecdh-sha2”, tout comme la “key” “ecdsa-sha2”.

Comment supprimer les algorithmes non sûrs ?

Pour supprimer les algorithmes indésirables, il faut modifier le fichier de configuration du serveur SSH (par exemple “/etc/ssh/sshd_config” pour OpenSSH) et ne pas oublier de redémarrer le service ensuite.

On limite les algorithmes au niveau des paramètres “KexAlgorithms”, “HostKeyAlgorithms”, “Ciphers” et “MACs”, respectivement pour les algorithmes des “kex”, “key”, “ciphers” et “mac”.

Attention toutefois, plus vous limiterez les algorithmes disponibles, plus votre serveur SSH sera strict avec les clients qui s’y connecteront. Dans la pratique, nous n’avons pas eu de problème chez Geonov avec des outils à jour (notamment avec Putty en version 0.7 pour avoir le support des clés elliptiques).

Autres réglages de sécurité

Une fois la liste des algorithmes réduite aux plus sûrs, n’oubliez pas les réglages de sécurité fondamentaux de toute connexion SSH que nous allons rappeler ici.

Interdire “root”

Un utilisateur “root” (super administrateur du système) ne devrait jamais être autorisé à se connecter en SSH. Cela se configure via le paramètre “PermitRootLogin” du fichier “sshd_config”.

Autoriser uniquement certains utilisateurs

Tous les utilisateurs ne devraient pas être autorisés à se connecter en SSH sur le serveur. Les paramètres “AllowUsers”, “AllowGroups”, “DenyGroups”, “DenyUsers” permettent un réglage fin.

Changer le port par défaut

On l’a vu, le protocole SSH utilise par défaut le port 22. Cela nous a d’ailleurs permis de tester sans difficultés le serveur hébergeant le site postgis.net.

Des “robots” sur Internet “scannent” systématiquement le port 22 des serveurs et tentent de s’y connecter, typiquement avec l’utilisateur “root” et un mot de passe aléatoire (on parle d’attaque par force brute).

Une bonne pratique est donc de modifier le port par défaut du serveur SSH à l’aide du paramètre “Port”. Cela n’empêchera pas certains robots de trouver le bon port via un balayage des ports ouverts, mais cela bloquera les plus simples.

Utiliser une paire de clés

Pour éviter les attaques par force brute, il faut également bannir la connexion SSH à l’aide d’un simple mot de passe mais plutôt utiliser une paire de clés : l’hôte dispose d’une liste de clés publiques autorisées, les utilisateurs s’identifient avec leur clé privée correspondante.

Installer Fail2ban

Une dernière chose est de prévoir un outil de surveillance sur le serveur. Chez Geonov, nous préconisons et utilisons Fail2ban qui permet de bannir les IP après x tentatives de connexion infructueuse sur le serveur.

Chez Geonov

Chez Geonov, tous nos conteneurs prennent en compte les remarques précédentes et nous permettent de proposer des serveurs à un haut niveau de sécurité.

D’ailleurs essayons un ssh-audit sur le serveur web de Geonov (sur un port qui n’est pas le 22…) :

Comme vous pouvez le constater, tout est vert. Le script nous propose même d’ajouter certains algorithmes, mais nous n’en avons pas la nécessité.

Conclusion

Sécuriser un serveur SSH est primordial, car c’est une porte d’entrée directe sur le serveur.

Si des mesures de précaution élémentaires s’imposent (interdire “root”, préférer une paire de clés, etc.), une sécurité méconnue consiste à se soucier des algorithmes utilisés par le serveur SSH.