Durcissement de SSH et bonnes pratiques d’audit

La mesure de renforcement SSH la plus efficace consiste à définir PasswordAuthentication no dans /etc/ssh/sshd_config. Cela oblige tous les utilisateurs à s’authentifier avec des clés publiques, éliminant ainsi les risques liés aux mots de passe faibles ou réutilisés et aux attaques par force brute. Vérifiez qu’au moins une clé autorisée est installée avant de désactiver l’authentification par mot de passe, afin d’éviter de vous verrouiller vous-même hors du serveur.

Les directives AllowUsers et AllowGroups limitent l’accès SSH à des utilisateurs désignés ou aux membres de certains groupes. Par exemple, AllowGroups sshusers autorise uniquement les membres du groupe sshusers. Cela constitue une défense en profondeur : même si un attaquant connaît un nom d’utilisateur et obtient des identifiants, l’accès SSH lui est refusé, sauf si le compte est explicitement autorisé.

Modifier le port SSH de 22 vers un port supérieur relève de la sécurité par l’obscurité, et non de la sécurité véritable. Cependant, cela réduit considérablement le bruit dans les journaux provenant des analyseurs automatisés qui ciblent le port 22. Les journaux sont ainsi plus faciles à analyser pour repérer les menaces réelles. Maintenez toujours les règles du pare-feu comme principal contrôle d’accès ; l’obscurcissement du port ne constitue qu’une mesure complémentaire.

Définir PermitRootLogin no empêche l’authentification directe de root via SSH. Les attaquants qui ciblent root disposent d’un nom d’utilisateur nécessairement valide et de privilèges illimités s’ils réussissent. Le paramètre recommandé est PermitRootLogin prohibit-password, qui autorise la connexion de root uniquement avec une authentification par clé publique, bloquant ainsi les attaques par force brute visant le mot de passe de root tout en conservant un accès d’urgence.

MaxAuthTries 3 limite à trois le nombre de tentatives d’authentification par connexion. Après trois échecs, le serveur interrompt la connexion. Cela ralentit les tentatives par force brute. Associées au ralentissement exponentiel appliqué par fail2ban ou SSHGuard, qui bannissent temporairement les adresses IP après des échecs répétés, les attaques par force brute deviennent irréalisables en pratique.

LoginGraceTime indique combien de temps le serveur attend une authentification réussie avant de se déconnecter. La valeur par défaut est de 120 secondes ; la réduire à 20 secondes empêche les tentatives lentes par force brute et limite les ressources mobilisées par les connexions non authentifiées. ClientAliveInterval et ClientAliveCountMax contrôlent les vérifications de l’état de la connexion afin de déconnecter les sessions inactives ou interrompues.

Les configurations SSH modernes doivent limiter les algorithmes à des options robustes et actuelles. Dans sshd_config, définissez Ciphers sur chacha20-poly1305@openssh.com,aes256-gcm@openssh.com, définissez MACs sur hmac-sha2-256-etm@openssh.com et définissez KexAlgorithms sur curve25519-sha256. Cela élimine les algorithmes obsolètes comme arcfour, DES et les MAC fondés sur MD5, qui peuvent être disponibles pour assurer la compatibilité avec les anciennes versions.

fail2ban surveille les journaux d’authentification et bannit les adresses IP qui dépassent un seuil de tentatives de connexion échouées. Après un nombre configurable d’échecs dans un intervalle donné, fail2ban ajoute une règle iptables qui rejette les paquets suivants provenant de cette adresse IP. Cette réponse automatisée rend les attaques par force brute impraticables sans intervention manuelle.

L’outil ssh-audit se connecte à un serveur SSH et évalue sa configuration : les algorithmes d’échange de clés, les types de clés d’hôte, les chiffrements et les MAC qu’il propose ; il signale également les options obsolètes ou faibles. Exécuter ssh-audit sur vos serveurs avant et après leur renforcement fournit une évaluation objective de la situation avant et après les modifications et permet d’identifier les lacunes de configuration.

Les événements d’authentification SSH sont enregistrés via syslog. Sous Linux, /var/log/auth.log (Debian) ou /var/log/secure (RHEL) consigne chaque connexion réussie ou échouée avec son horodatage, le nom d’utilisateur, l’adresse IP source et l’empreinte de la clé utilisée. L’envoi de ces journaux vers un SIEM centralisé permet de détecter des schémas d’accès inhabituels, comme des connexions depuis des pays inattendus ou à des heures inhabituelles.

Une configuration sshd_config renforcée associe : PasswordAuthentication no, PermitRootLogin prohibit-password, MaxAuthTries 3, LoginGraceTime 20, AllowGroups sshusers, des Ciphers et des MACs restreints, X11Forwarding no et AllowTcpForwarding no (sauf si la tunnellisation est requise). Chaque directive supprime un vecteur d’attaque précis et, ensemble, elles constituent une posture SSH fondée sur la défense en profondeur.

Quel paramètre de sshd_config est le plus efficace pour éliminer les attaques par force brute visant les mots de passe SSH ?

Liste de contrôle du renforcement SSH : désactiver l’authentification par mot de passe, limiter l’accès à AllowGroups/AllowUsers, désactiver la connexion de root ou la restreindre à l’authentification par clé uniquement, définir MaxAuthTries 3, réduire LoginGraceTime, limiter les algorithmes aux seuls chiffrements modernes, déployer fail2ban ou SSHGuard, exécuter ssh-audit pour une évaluation objective et centraliser les journaux afin de détecter les anomalies.