Salut,
SSH est l'une des méthodes les plus courantes pour accéder à des serveurs distants. SSH est également l'une des raisons les plus courantes de la compromission des serveurs Linux.
Ne vous méprenez pas. SSH (Secure Shell) est un protocole assez sûr de par sa conception, mais cela ne signifie pas qu'il faille le laisser dans sa configuration par défaut.
Ne suivez pas aveuglément tous les conseils de sécurisation de SSH mentionnés ici.
Lisez-les tous et voyez 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 par mot de passe, il n'est pas nécessaire d'opter pour une solution de type **Fail2Ban/CrowdSec **.
Si vous connaissez les bases de SSH, vous savez que les fichiers de configuration de SSH se trouvent dans /etc/ssh/sshd_config
nano /etc/ssh/sshd_config pour le modifier, précédé éventuellement de sudo si vous n'êtes pas root
La plupart des astuces de sécurisation de SSH mentionnées ici nécessiteront que vous modifiiez ce fichier de configuration. C'est pourquoi il est conseillé de sauvegarder le fichier original :
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
Vous devrez également redémarrer le service SSH si vous modifiez le fichier de configuration SSH :
systemctl restart ssh
Je vous conseille fortement de tester la connexion via une nouvelle session SSH, avant de quitter la session en cours, afin de pouvoir apporter des corrections si nécessaire, au risque de rester bloqué dehors.
Voyons maintenant les mesures que 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 mot de passe. Si ces utilisateurs essaient d'utiliser SSH, ils n'auront pas besoin de mots de passe pour accéder au serveur via SSH également.
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, veillez à définir l'option PermitEmptyPasswords sur no.
PermitEmptyPasswords no
2. Modifier les ports SSH par défaut
Le port SSH par défaut est le 22 et la plupart des scripts d'attaque sont écrits autour de ce seul port. Changer le port SSH par défaut devrait ajouter une couche de sécurité supplémentaire car le nombre d'attaques (arrivant sur le port 22) pourrait diminuer.
Recherchez les informations relatives au port dans le fichier de configuration et modifiez-les :
Port 2345
Vous devez vous souvenir ou noter le numéro de port, sinon vous ne pourrez pas accéder à vos serveurs avec SSH.
3. Désactiver le login root via SSH
Pour être honnête, l'utilisation du serveur en tant que super-utilisateur devrait être interdite. C'est risqué et cela ne laisse aucune trace d'audit. Des mécanismes tels que sudo existent uniquement pour cette raison.
Si vous avez ajouté des utilisateurs sudo sur votre système, vous devriez utiliser cet utilisateur sudo pour accéder au serveur via SSH au lieu de root.
Vous pouvez désactiver la connexion de l'utilisateur root en modifiant l'option PermitRootLogin et en lui attribuant la valeur no :
PermitRootLogin no
4. Désactiver le protocole ssh 1
Si vous utilisez une ancienne distribution Linux, vous devez désactiver le protocole 1. Il se peut que le protocole SSH 1 soit encore disponible dans certaines versions plus anciennes de SSH. Ce protocole présente des vulnérabilités connues et ne doit pas être utilisé.
Les versions SSH plus récentes activent automatiquement le protocole SSH 2, mais il n'y a pas de mal à le vérifier à nouveau.
Protocole 2
5. Configurer l'intervalle de temps d'inactivité
Le délai 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 l'intervalle de délai d'inactivité.
L'intervalle de temps est compté en secondes et par défaut il est de 0. Vous pouvez le changer à 300 pour garder un intervalle de temps de cinq minutes.
ClientAliveInterval 300
Après cet intervalle, le serveur SSH enverra un message de vie au client. S'il ne reçoit 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 de vie avant de se déconnecter :
ClientAliveCountMax 2
6. Autoriser l'accès SSH aux seuls utilisateurs sélectionnés
En matière de sécurité, il convient de suivre le principe du moindre privilège. Ne donnez pas de droits lorsque cela n'est pas nécessaire.
Vous avez probablement plusieurs utilisateurs sur votre système Linux. Devez-vous autoriser l'accès SSH à chacun d'entre eux ? Peut-être pas.
Dans ce cas, une approche consisterait à autoriser l'accès SSH à quelques utilisateurs sélectionnés et à le restreindre à tous les autres utilisateurs.
AllowUsers User1 User2
Vous pouvez également ajouter des utilisateurs sélectionnés à un nouveau groupe et n'autoriser que ce groupe à accéder à SSH.
AllowGroups ssh_group
Vous pouvez également utiliser les options 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. La redirection X11 vous permet d'utiliser une application GUI via SSH.
En principe, le client exécute l'application GUI sur le serveur, mais grâce à la redirection X11, un canal est ouvert entre les machines et les applications GUI sont affichées sur la machine du client.
Le protocole X11 n'est pas axé sur la sécurité. Si vous n'en avez pas besoin, vous devriez désactiver le transfert X11 dans SSH.
X11Forwarding no
8. Atténuer automatiquement les attaques par force brute
Pour contrecarrer les attaques par force brute de SSH, vous pouvez utiliser un outil de sécurité tel que Fail2Ban/CrowdSec.
Ces outils vérifient les tentatives de connexion échouées à partir de différentes adresses IP. Si ces tentatives échouées dépassent un certain seuil dans un intervalle de temps donné, il interdit à l'adresse IP d'accéder à SSH pendant un certain temps.
Lien vers le tutoriel CrowdSec
9. Désactiver la connexion SSH par mot de passe
Quels que soient vos efforts, 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 en compte les paramètres par défaut des outils de type Fail2Ban.
Pour vous débarrasser des attaques constantes par force brute, vous pouvez opter pour une connexion SSH uniquement basée sur une clé.
Dans cette approche, vous ajoutez la clé publique des systèmes clients distants à la liste des clés connues du serveur SSH. De cette manière, ces machines clientes peuvent accéder à SSH sans saisir le mot de passe du compte d'utilisateur.
Une fois cette configuration mise en place, vous pouvez désactiver la connexion SSH basée sur le 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'adopter cette approche, assurez-vous que vous avez ajouté votre propre clé publique au serveur et qu'elle fonctionne. Sinon, vous vous bloquerez et risquez de perdre l'accès au serveur distant, en particulier si vous utilisez un serveur distant où vous n'avez pas d'accès physique au serveur.
TODO vérifier le tutoriel clef SSH
10. Authentification à deux facteurs avec SSH
Pour porter la sécurité SSH à un 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 portable, par courriel ou par l'intermédiaire d'une application d'authentification tierce.
TODO tuto 2FA
Conclusion
Vous pouvez voir tous les paramètres de votre serveur SSH à l'aide de cette commande :
sshd -T
De cette manière, vous pouvez facilement voir si vous devez modifier un paramètre pour améliorer la sécurité du serveur SSH.
Vous devez également veiller à ce que l'installation et le système SSH soient mis à jour.
J'ai énuméré quelques méthodes pratiques de sécurisation de SSH. Bien entendu, il existe plusieurs autres moyens de sécuriser SSH et votre serveur Linux.
Source : https://linuxhandbook.com/ssh-hardening-tips/
