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/

Je ne saurais que trop conseiller l'utilisation de crowdsec au lieu de fail2ban. Le principe est le même (bloquer des ip avant qu'elles n'essayent de se connecter), mais il prend plusieurs sources :

  • les tentatives locales d'accès à la machine
  • les IP reportées par la communauté pour des tentatives d'accès sur d'autres machines.

Ainsi, si une IP fait du bruteforce sur laquelle crowdsec est installé, non seulement elle se fera bannir de la machine en question, mais aussi de TOUTES les machines sur lesquelles crowdsec est installé. Il existe également multitude de plugins pour analyser plein de logs différents (et pas que le log ssh) : apache, nginx, npm, traefik, ...

https://www.crowdsec.net/ (promis j'ai pas d'action chez eux)

    8 mois plus tard

    Merrick Je ne saurais que trop conseiller l'utilisation de crowdsec au lieu de fail2ban

    Surtout que depuis Debian 12 plus de fichier auth.log par défaut donc fail2ban ne peu plus fonctionner sans réinstaller rsyslog (qui est en doublon de journald de systemd).

    Autre avantage de Crowdsec que j'utilise, avec un routeur (OPNsense dans mon cas) en amont des machines le blocage s'applique globalement à toutes les machines de façon fiable, l'unique pare-feu utilisé étant sur le routeur. Ce qui évite d'avoir un pare-feux sur chaque machine.

    spider1163 et il est la https://mondedie.fr/d/12102-tuto-installer-crowdsec-linux 😉

      julienth37 fail2ban est parfaitement capable de lire les logs de systemd, il suffit de spécifier le backend voulu dans le jail.

        channouze Effectivement j'ai pas plus cherché que ça, il en reste moins efficient que Crowdsec qui peux agir en amont de la machine et de façon centralisé pour tout le réseau (ce qui est toujours préférable).
        Fai2ban est pas mauvais, juste dépassé.

        Chacun ses choix de sécurité, personnellement je ne confie pas le filtrage des IPs à un tiers dont je ne connais pas la boite noire. Le jour où il se fera toucher par un zero-day tu seras bien content d'avoir fail2ban en backup.

          channouze Crowdsec ne dépends pas de tiers pour les blocage fait depuis des alertes locales, uniquement pour les listes publiques (qui sont facultatives). Et c'est absolument pas une boite noire puisque c'est un logiciel Libre !

          Fail2ban te portègera absolument pas depuis de te faire attaquer une machine après l 'autre. Par exemple pour un cluster web c'est tout l'intéret de Crowdsec, l'attaquant est banis de tout le cluster pas que d'un seul membre, donc il peux pas continuer son attaque sur les autres membres du cluster. Ou plus simplement pour proteger des conteneurs (où il est impensalbe d'installer fail2ban).

          14 jours plus tard

          Exact je me suis trompé. Par contre il me semble que le site web d'analyse de logs lui (crowdsec.net), n'est pas open source.

          2 mois plus tard

          Je déterre ce topic par rapport à une récente attaque que mon serveur a subie. En effet le service Teamcity de JetBrains était impacté par les vulnérabilités CVE-2024-27198 et CVE-2024-27199 qui ont été publiquement dévoilées le
          4 Mars 2024. Vous pouvez voir ici tous les détails sur comment exploiter la faille, et on notera qu'entre la communication officielle de JetBrains et la publication de l'exploit il s'est écoulé à peine 24h, autant dire que beaucoup de sysadmins doivent grincer des dents.

          Mon setup est comme suit:

          • CrowdSec est installé avec le bouncer qui utilise directement iptables
          • Fail2ban monitore les logs de mon reverse proxy et bannit préemptivement toutes les IPs appartenant à certains pays (au cas où CrowdSec laisse passer des mauvais acteurs)

          J'ai patché mon serveur 2 jours après la divulgation de la faille, et j'ai ainsi pu monitorer l'intégralité des attaques dans l'intervalle. J'ai donc fait des références croisées pour déterminer à quel point CrowdSec est efficace dans le cadre d'une attaque ciblé utilisant un exploit très récent.
          La réponse ne va pas vous plaire...

          Voici les ips identifiées et bloquées par Crowdsec (j'utilise les 3 blocklists de la version gratuite, à savoir Firehol BotScout, Firehol cruzit.com et Free proxies list)

          • 161.35.155.246
          • 167.71.185.75
          • 188.166.87.88
          • 170.130.75.10
          • 199.45.154.17
          • 199.45.155.33
          • 199.45.155.48

          Voici les ips des acteurs qui ont tenté d'exploiter la faille de Teamcity:

          • 185.174.137.26
          • 103.253.73.99
          • 146.0.228.66

          Voici les ips des acteurs qui ont, en plus, tenté de déployer un malware

          Il n'y a aucune correspondance entre les IPs détectées par CrowdSec et celles, bien plus dangereuses, qui exploitent activement la faille. D'où l'intérêt d'avoir d'autres méthodes de mitigation en place.

          Répondre…