5 bonnes pratiques pour prévenir les attaques de connexion SSH Brute-Force

Les serveurs exécutant SSH sont généralement une cible facile pour les attaques par force brute. Les pirates informatiques proposent constamment des outils logiciels et des robots innovants pour automatiser les attaques par force brute, ce qui augmente encore le risque d'intrusion.

Dans ce guide, nous explorons certains des conseils que vous pouvez mettre en œuvre pour protéger vos serveurs SSH contre les attaques par force brute sur les distributions Linux basées sur RHEL et les dérivés Debian.

Désactivez l'authentification par mot de passe SSH et activez l'authentification par clé SSH

La méthode d'authentification par défaut pour SSH est l'authentification par nom d'utilisateur/mot de passe. Mais comme nous l’avons vu, l’authentification par mot de passe est sujette aux attaques par force brute. Par mesure de sécurité, il est recommandé de mettre en œuvre une authentification SSH basée sur une clé où l'authentification est rendue possible par des paires de clés SSH publiques et privées. La clé privée reste sur le PC du client tandis que la clé publique est copiée sur le serveur.

Lors de l'authentification par clé SSH, le serveur vérifie si le PC client possède la clé privée. Si la vérification réussit, une session shell est créée ou la commande envoyée au serveur distant est exécutée avec succès. Nous avons un guide complet sur la façon de configurer l’authentification par clé SSH.

Même après avoir configuré l'authentification par clé, votre serveur est toujours sensible aux attaques par force brute pour la simple raison que l'authentification par mot de passe est toujours active. Cela doit être désactivé.

Par conséquent, modifiez le fichier de configuration SSH par défaut.

$ sudo vim /etc/ssh/sshd_config

Définissez le paramètre PasswordAuthentication sur no comme indiqué.

PasswordAuthentication no

Enregistrez ensuite le fichier et rechargez SSH pour appliquer les modifications.

$ sudo systemctl reload ssh

Implémenter l'outil de prévention des intrusions Fail2ban

Écrit en Python, Fail2ban est un framework open source de prévention des intrusions qui analyse les fichiers journaux des services à la recherche d'échecs d'authentification et bannit les adresses IP qui échouent à plusieurs reprises aux vérifications d'authentification par mot de passe pendant une durée spécifiée.

Fail2ban surveille en permanence les fichiers journaux du serveur pour détecter les tentatives d'intrusion et autres activités néfastes. Après un nombre prédéfini d'échecs d'authentification (dans la plupart des cas, 3 tentatives de connexion infructueuses), Fail2ban bloque automatiquement l'accès de l'hôte distant au serveur. l'hôte est détenu dans une « Prison » pendant une durée déterminée.

Ce faisant, Fail2ban réduit considérablement le taux de tentatives d'authentification par mot de passe incorrect. Consultez notre guide sur la façon dont vous pouvez installer et configurer Fail2ban sur Linux pour sécuriser votre serveur contre les attaques Bruteforce.

Limiter le nombre maximum de tentatives d'authentification SSH

Un autre moyen simple de protéger votre serveur contre les attaques par force brute consiste à limiter le nombre de tentatives de connexion SSH. Par défaut, cette valeur est 3, mais si par hasard cette valeur est supérieure, définissez-la sur 3 tentatives de connexion au maximum.

Par exemple, pour définir le nombre maximum de tentatives de connexion sur 3, définissez le paramètre MaxAuthTries sur 3 comme indiqué.

MaxAuthTries = 3

Encore une fois, enregistrez les modifications et rechargez le service SSH.

$ sudo systemctl reload ssh

Implémenter des wrappers TCP pour limiter l'accès SSH des clients

Les wrappers TCP sont une bibliothèque qui fournit une liste de contrôle d'accès (ACL) basée sur l'hôte qui restreint l'accès aux services TCP par les clients distants en fonction de leur Adresses IP

Les hôtes distants ne peuvent pas accéder aux services du système. Les wrappers TCP utilisent les fichiers de configuration /etc/hosts.allow et /etc/hosts.deny (dans cet ordre) pour déterminer si le client distant est autorisé à accéder à un serveur spécifique. service ou pas.

Habituellement, ces fichiers sont commentés et tous les hôtes sont autorisés via la couche des wrappers TCP. Les règles permettant d'autoriser l'accès à un service donné sont placées dans le fichier /etc/hosts.allow et ont priorité sur les règles du fichier /etc/hosts.deny.

La meilleure pratique recommande de bloquer toutes les connexions entrantes. Par conséquent, ouvrez le fichier /etc/hosts.deny.

$ sudo vim /etc/hosts.deny

Ajoutez la ligne suivante.

ALL: ALL

Enregistrez les modifications et quittez le fichier.

Accédez ensuite au fichier /etc/hosts.allow.

$ sudo vim /etc/hosts.allow

Configurez les hôtes ou domaines pouvant se connecter au serveur via SSH comme indiqué. Dans cet exemple, nous autorisons seulement deux hôtes distants à se connecter au serveur (173.82.227.89 et 173.82.255.55) et refusons le reste.

sshd: 173.82.227.89 173.82.255.55
sshd: ALL: DENY

Enregistrez les modifications et quittez le fichier de configuration.

Pour le tester, essayez de vous connecter au serveur à partir d'un hôte qui ne fait pas partie de ceux auxquels vous avez autorisé l'accès. Vous devriez obtenir une erreur d’autorisation comme indiqué.

$ ssh [email 

kex_exchange_identification: read: Connection reset by peer
Connection reset by 173.82.235.7 port 22
lost connection

Implémenter l'authentification à deux facteurs SSH

L'Authentification à deux facteurs fournit une couche de sécurité supplémentaire à l'authentification par mot de passe, rendant ainsi votre serveur plus sécurisé contre les attaques par force brute. L'application Google Authenticator est une solution d'authentification à deux facteurs largement utilisée. Nous disposons d'un guide bien documenté expliquant comment configurer l'authentification à deux facteurs.

Conclusion

Ceci est un résumé de 5 bonnes pratiques que vous pouvez mettre en œuvre pour empêcher les attaques de connexion SSH Brute Force et garantir la sécurité de votre serveur. Vous pouvez également lire Comment sécuriser et renforcer le serveur OpenSSH.