10 conseils de renforcement SSH exploitables pour sécuriser votre serveur Linux

SSH est l'une des méthodes les plus courantes d'accès aux serveurs distants. SSH est également l'une des raisons les plus courantes derrière les serveurs Linux compromis.

Ne vous méprenez pas. SSH (Secure Shell) est un protocole assez sécurisé de par sa conception, mais cela ne signifie pas que vous devez le laisser à la configuration par défaut.

Dans cet article, je vais partager quelques moyens pratiques pour améliorer la sécurité SSH et ainsi sécuriser vos serveurs Linux.

Conseils pour sécuriser SSH sur les serveurs Linux

N'allez pas suivre aveuglément tous les conseils de renforcement SSH mentionnés ici. Lisez-les tous et voyez ensuite ceux qui correspondent à vos besoins. Gardez également à l'esprit que certains conseils peuvent ne pas être compatibles avec d'autres.

Par exemple, si vous désactivez la connexion SSH basée sur un mot de passe, il n'est pas nécessaire d'opter pour le type de solution Fail2Ban.

Si vous connaissez les bases de SSH, vous savez que les fichiers de configuration SSH se trouvent dans /etc/ssh/sshd_config .

La plupart des conseils de renforcement SSH mentionnés ici vous obligeront à modifier ce fichier de configuration. C'est pourquoi ce sera une bonne idée de sauvegarder le fichier d'origine. Vous devrez également redémarrer le service SSH si vous apportez des modifications au fichier de configuration SSH.

Voyons quelles mesures vous pouvez prendre pour sécuriser votre serveur SSH.

1. Désactiver les mots de passe vides

Oui. Il est possible d'avoir des comptes d'utilisateurs sous Linux sans aucun mot de passe. Si ces utilisateurs essaient d'utiliser SSH, ils n'auront pas non plus besoin de mots de passe pour accéder au serveur via SSH.

C'est un risque pour la sécurité. Vous devez interdire l'utilisation de mots de passe vides. Dans le fichier /etc/ssh/sshd_config, assurez-vous de définir l'option PermitEmptyPasswords sur no.

PermitEmptyPasswords no

2. Modifier les ports SSH par défaut

Le port SSH par défaut est 22 et la plupart des vérifications de scripts d'attaque sont écrites autour de ce port uniquement. La modification du port SSH par défaut devrait ajouter une couche de sécurité supplémentaire, car le nombre d'attaques (venant du port 22) peut réduire.

Recherchez les informations de port dans le fichier de configuration et remplacez-les par quelque chose de différent :

Port 2345

Vous devez vous rappeler ou noter le numéro de port, sinon vous ne pourrez pas non plus accéder à vos serveurs avec SSH.

Pour être honnête, utiliser le serveur en tant que root lui-même devrait être interdit. C'est risqué et ne laisse aucune trace d'audit. Des mécanismes comme sudo n'existent que pour cette raison.

Si vous avez ajouté des utilisateurs sudo sur votre système, vous devez utiliser cet utilisateur sudo pour accéder au serveur via SSH au lieu de root.

Vous pouvez désactiver la connexion root en modifiant l'option PermitRootLogin et en la définissant sur no :

PermitRootLogin no

4. Désactiver le protocole ssh 1

C'est si vous utilisez une ancienne distribution Linux. Certaines anciennes versions de SSH peuvent encore avoir le protocole SSH 1 disponible. Ce protocole a des vulnérabilités connues et ne doit pas être utilisé.

Les nouvelles versions de SSH ont automatiquement le protocole SSH 2 activé, mais il n'y a aucun mal à le vérifier.

Protocol 2

5. Configurer l'intervalle de délai d'inactivité

L'intervalle de temporisation d'inactivité est la durée pendant laquelle une connexion SSH peut rester active sans aucune activité. Ces sessions inactives constituent également un risque pour la sécurité. C'est une bonne idée de configurer un délai d'inactivité.

L'intervalle de temporisation est compté en secondes et par défaut, il est de 0. Vous pouvez le modifier à 300 pour conserver un intervalle de temporisation de cinq minutes.

ClientAliveInterval 300

Après cet intervalle, le serveur SSH enverra un message vivant au client. S'il n'obtient pas de réponse, la connexion sera fermée et l'utilisateur final sera déconnecté.

Vous pouvez également contrôler le nombre de fois qu'il envoie le message d'activité avant de se déconnecter :

ClientAliveCountMax 2

6. Autoriser l'accès SSH aux utilisateurs sélectionnés uniquement

En matière de sécurité, vous devez suivre le principe du moindre privilège. Ne donnez pas de droits lorsque ce n'est pas nécessaire.

Vous avez probablement plusieurs utilisateurs sur votre système Linux. Avez-vous besoin d'autoriser l'accès SSH à chacun d'eux ? Peut-être pas.

Une approche ici serait d'autoriser l'accès SSH à quelques utilisateurs sélectionnés et donc de restreindre pour tous les autres utilisateurs.

AllowUsers User1 User2

Vous pouvez également ajouter des utilisateurs sélectionnés à un nouveau groupe et autoriser uniquement ce groupe à accéder à SSH.

AllowGroups ssh_group

Vous pouvez également utiliser DenyUsers et DenyGroups pour refuser l'accès SSH à certains utilisateurs et groupes.

7. Désactiver le transfert X11

Le serveur d'affichage X11 ou X est le cadre de base d'un environnement graphique. Le transfert X11 vous permet d'utiliser une application graphique via SSH.

Fondamentalement, le client exécute l'application graphique sur le serveur mais grâce au transfert X11, un canal est ouvert entre les machines et les applications graphiques sont affichées sur la machine cliente.

Le protocole X11 n'est pas orienté sécurité. Si vous n'en avez pas besoin, vous devez désactiver le transfert X11 dans SSH.

X11Forwarding no

8. Atténuez automatiquement les attaques par force brute

Pour contrecarrer les attaques par force brute SSH, vous pouvez utiliser un outil de sécurité comme Fail2Ban.

Fail2Ban vérifie les tentatives de connexion infructueuses à partir de différentes adresses IP. Si ces mauvaises tentatives franchissent un seuil dans un intervalle de temps défini, il interdit à l'IP d'accéder à SSH pendant une certaine période de temps.

Vous pouvez configurer tous ces paramètres selon vos goûts et vos besoins. J'ai écrit un guide d'introduction détaillé sur l'utilisation de Fail2Ban que vous devriez lire.

Peu importe combien vous essayez, vous verrez toujours de mauvaises tentatives de connexion via SSH sur votre serveur Linux. Les attaquants sont intelligents et les scripts qu'ils utilisent prennent souvent soin des paramètres par défaut de Fail2Ban comme des outils.

Pour vous débarrasser des attaques par force brute constantes, vous pouvez opter uniquement pour une connexion SSH basée sur une clé.

Dans cette approche, vous ajoutez la clé publique des systèmes clients distants à la liste des clés connues sur le serveur SSH. De cette façon, ces machines clientes peuvent accéder à SSH sans entrer le mot de passe du compte utilisateur.

Lorsque vous avez cette configuration, vous pouvez désactiver la connexion SSH basée sur un mot de passe. Désormais, seules les machines clientes disposant des clés SSH spécifiées peuvent accéder au serveur via SSH.

Avant d'opter pour cette approche, assurez-vous que vous avez ajouté votre propre clé publique au serveur et que cela fonctionne. Sinon, vous vous verrouillerez et risquez de perdre l'accès au serveur distant, en particulier si vous utilisez un serveur cloud comme Linode où vous n'avez pas d'accès physique au serveur.

Lisez ce didacticiel détaillé pour savoir comment désactiver l'authentification SSH basée sur un mot de passe.

10. Authentification à deux facteurs avec SSH

Pour faire passer la sécurité SSH au niveau supérieur, vous pouvez également activer l'authentification à deux facteurs. Dans cette approche, vous recevez un mot de passe à usage unique sur votre téléphone mobile, par e-mail ou via une application d'authentification tierce.

Vous pouvez en savoir plus sur la configuration de l'authentification à deux facteurs avec SSH ici.

Conclusion

Vous pouvez voir tous les paramètres de votre serveur SSH en utilisant cette commande :

sshd -T

De cette façon, vous pouvez facilement voir si vous devez modifier un paramètre pour améliorer la sécurité du serveur SSH.

Vous devez également maintenir à jour l'installation et le système SSH.

J'ai énuméré quelques façons pratiques de renforcer SSH. Bien sûr, il peut y avoir plusieurs autres façons de sécuriser SSH et votre serveur Linux. Il n'est pas possible de tous les lister dans un seul article.

J'espère que vous trouverez ces conseils utiles. Faites-moi savoir quels conseils vous trouvez utiles.

Connaissez-vous des conseils supplémentaires sur la sécurité SSH ? Pourquoi ne pas le partager avec nous dans la section des commentaires ?