Durcir la configuration SSH
L'hardening (durcissement) d'OpenSSH consiste à appliquer une série de mesures de sécurité pour fortifier un serveur SSH contre diverses formes d'attaques et d'intrusions. Cette démarche vise à minimiser les risques d'accès non autorisés et à renforcer la résilience du serveur face aux vulnérabilités connues et inconnues.
Cette documentation s'inscrit dans la continuité de notre précédent guide destiné aux débutants, où j'avais introduit les fondamentaux d'OpenSSH. Aujourd'hui, nous allons approfondir notre exploration en nous concentrant sur les aspects clés de la configuration et du durcissement de la sécurité d'OpenSSH, en s'appuyant sur les connaissances de base déjà acquises
Pourquoi durcir la configuration d'OpenSSH ?
La sécurité SSH est primordiale, car elle joue un rôle clé dans la protection des données sensibles transmises sur des réseaux potentiellement non sécurisés. Un serveur SSH mal configuré peut être une porte d'entrée pour des attaques, mettant en péril l'intégrité du système et les données confidentielles. De plus, dans de nombreux secteurs, respecter des normes de sécurité strictes est non seulement une bonne pratique, mais aussi une obligation réglementaire.
Les fondations d'un durcissement efficace d'OpenSSH reposent sur le principe du moindre privilège, qui implique d'accorder aux utilisateurs uniquement les droits nécessaires pour accomplir leurs tâches. Il est également crucial de maintenir à jour OpenSSH et le système d'exploitation, en appliquant les derniers correctifs de sécurité pour se prémunir contre les failles connues. Une configuration méticuleuse et réfléchie du serveur SSH, éliminant les paramètres vulnérables par défaut, est également essentielle pour renforcer sa sécurité.
Le durcissement d'OpenSSH implique de naviguer entre la mise en place de mesures de sécurité rigoureuses et la préservation d'une expérience utilisateur fluide pour les utilisateurs légitimes. Il est impératif de rester à jour avec l'évolution constante des menaces de sécurité, nécessitant une veille technologique continue et des ajustements réguliers des stratégies et configurations de sécurité.
Comprendre les Paramètres de Sécurité d'OpenSSH
Lorsque nous cherchons à sécuriser un serveur OpenSSH, il est essentiel de se concentrer sur des paramètres de configuration clés. Ces paramètres sont souvent les premières lignes de défense contre les menaces et les attaques potentielles. Les recommandations suivantes sont issues de l'analyse et des retours d'expérience obtenus grâce à l'utilisation de Lynis, un outil d'audit de sécurité réputé pour les systèmes UNIX. Lynis fournit des aperçus détaillés sur la sécurité du système, y compris OpenSSH et met en évidence les paramètres critiques qui doivent être ajustés pour améliorer la posture de sécurité.
Dans cette section, nous explorerons les paramètres essentiels d'OpenSSH, en expliquant leur rôle, leur importance et les meilleures pratiques pour leur configuration. Ces paramètres ont été soigneusement sélectionnés pour leur impact significatif sur la sécurité globale de votre serveur SSH. En les ajustant correctement, vous pouvez non seulement répondre aux recommandations de Lynis mais aussi établir une base solide pour la sécurité de votre serveur SSH.
Protocol
Signification : Ce paramètre détermine la version du protocole SSH utilisée par le serveur.
Configuration recommandée : Il est conseillé de configurer
Protocol 2, car la version 1 est désuète et contient plusieurs vulnérabilités
de sécurité.
LogLevel
Signification : Définit la quantité d'informations enregistrées dans les journaux du serveur.
Configuration recommandée : Un LogLevel VERBOSE est
suggéré pour obtenir suffisamment de détails pour le suivi et l'analyse des
événements, sans surcharger les journaux.
PermitRootLogin
Signification : Contrôle la possibilité de se connecter en tant qu'utilisateur root via SSH.
Configuration recommandée : Il est recommandé de
définir PermitRootLogin no pour empêcher les tentatives de connexion en tant
qu'utilisateur root, réduisant ainsi le risque d'attaques par force brute.
PasswordAuthentication
Signification : Permet ou interdit l'authentification par mot de passe.
Configuration recommandée : La désactivation de PasswordAuthentication et la
préférence pour l'authentification par clé SSH renforcent la sécurité, car les
clés sont généralement plus robustes que les mots de passe simples.
ChallengeResponseAuthentication
Signification : Active ou désactive l'authentification par défi-réponse.
Configuration recommandée : Il est conseillé de désactiver cette fonctionnalité
(ChallengeResponseAuthentication no) pour limiter les vecteurs d'attaque
possibles.
AllowAgentForwarding
Signification : AllowAgentForwarding contrôle si le serveur SSH permet le transfert de l'agent d'authentification. Lorsqu'il est activé, les utilisateurs peuvent connecter leur agent SSH local à la session SSH distante, permettant ainsi une authentification transparente à d'autres serveurs à partir de la session initiale.
Configuration recommandée : Dans un souci de minimiser les risques, il est
souvent conseillé de définir AllowAgentForwarding no, surtout sur des serveurs
qui ne nécessitent pas explicitement cette fonctionnalité.
PermitTunnel
Signification : Le paramètre PermitTunnel dans la configuration d'OpenSSH
contrôle la possibilité d'établir des tunnels de données SSH. Lorsque cette
fonction est activée, les utilisateurs peuvent créer des tunnels qui encapsulent
d'autres types de trafic (comme le trafic TCP/IP) dans une connexion SSH.
Configuration recommandée : Bien que les tunnels SSH puissent être utiles
pour sécuriser le trafic entre des points distants, ils peuvent également être
utilisés de manière inappropriée pour contourner les politiques de sécurité
réseau. Par exemple, un utilisateur pourrait établir un tunnel SSH pour
contourner un pare-feu ou un filtre de contenu. Si les tunnels SSH ne sont pas
nécessaires pour vos opérations normales, il est recommandé de désactiver cette
fonctionnalité pour réduire la surface d'attaque potentielle. Configurez
PermitTunnel no dans votre fichier de configuration SSH pour désactiver la
création de tunnels.
X11Forwarding
Signification : Détermine si le transfert X11 (interface graphique) est autorisé.
Configuration recommandée : Il est préférable de configurer
X11Forwarding no, car permettre le transfert X11 peut ouvrir des failles de
sécurité supplémentaires.
MaxAuthTries
Signification : Définit le nombre maximum de tentatives d'authentification autorisées par connexion.
Configuration recommandée : Un nombre réduit de
tentatives, comme MaxAuthTries 3, aide à prévenir les attaques par force
brute.
UsePAM
Signification : Active ou désactive l'utilisation des Pluggable Authentication Modules (PAM).
Configuration recommandée : La configuration de
UsePAM yes peut être appropriée pour des environnements où les fonctionnalités
spécifiques de PAM sont souhaitées.
ClientAliveInterval et ClientAliveCountMax
Usage : Ces paramètres aident à détecter les connexions SSH inactives et à les fermer.
Configuration recommandée : ClientAliveInterval 0 et
ClientAliveCountMax 2. Cela ferme la connexion si le client reste inactif
pendant 15 minutes.
AllowUsers et AllowGroups
Usage : Restreint l'accès SSH à certains utilisateurs ou groupes.
Configuration recommandée : Utilisez AllowUsers user1 user2 et/ou
AllowGroups group1 group2 pour limiter l'accès aux utilisateurs ou groupes
spécifiés.
DenyUsers et DenyGroups
Usage : Spécifie les utilisateurs et groupes qui sont explicitement interdits de se connecter via SSH.
Configuration recommandée : DenyUsers user3 user4 et/ou DenyGroups group3 group4 pour bloquer l'accès à des
utilisateurs ou groupes spécifiques.
Récapitulatif des valeurs recommandées
Plus simple à reprendre, je vous propose un tableau des valeurs recommandées :
| Paramètre | Valeur recommandée |
|---|---|
| Protocol | 2 |
| LogLevel | VERBOSE |
| PermitRootLogin | no |
| PasswordAuthentication | no |
| ChallengeResponseAuthentication | no |
| AllowAgentForwarding | no |
| PermitTunnel | no |
| X11Forwarding | no |
| MaxAuthTries | 3 |
| UsePAM | yes |
| ClientAliveInterval | 0 |
| ClientAliveCountMax | 2 |
| LoginGraceTime | 300 |
Attention : Ce sont des valeurs recommandées et elles doivent donc être adaptées au contexte.
Gestion des Ciphers et Algorithmes dans OpenSSH
Dans la quête de sécuriser OpenSSH, un aspect crucial réside dans la gestion appropriée des ciphers et algorithmes. Ce processus implique d'identifier et de désactiver les ciphers et algorithmes obsolètes ou vulnérables, tout en privilégiant ceux qui sont reconnus pour leur robustesse.
Commençons par identifier les ciphers et algorithmes vulnérables. Des ciphers
tels que arcfour et blowfish sont considérés comme faibles et doivent être
évités. De même, les algorithmes de key exchange tels que
diffie-hellman-group1-sha1 ne sont plus sûrs. Il est également essentiel de se
détourner des MACs (Message Authentication Codes) comme hmac-md5 et
hmac-sha1, qui ne répondent plus aux standards de sécurité actuels.
Nous nous orientons donc vers des configurations recommandées plus sûres. Pour
les ciphers, des options robustes comme aes256-gcm@openssh.com ou
chacha20-poly1305@openssh.com devraient être privilégiées. Concernant les
algorithmes de KEX, des choix modernes et sécurisés incluent curve25519-sha256
ou diffie-hellman-group-exchange-sha256. Pour les MACs, opter pour des options
telles que hmac-sha2-512-etm@openssh.com ou umac-128-etm@openssh.com est
préférable.
La mise en œuvre de ces recommandations implique d'ajouter à la configuration
par défaut un fichier de configuration dans le dossier /etc/ssh/sshd_config.d.
Nommez-le ciphers.conf par exemple. Voici un exemple de configuration à
inclure dans ce fichier, en utilisant un éditeur de texte sous privilèges
d'administrateur :
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com
Après avoir effectué ces modifications, il est impératif de redémarrer le service SSH pour que les changements prennent effet. Sur un système utilisant systemd, cela peut être accompli avec :
sudo systemctl restart sshd
Il est important de tester la configuration après ces changements pour s'assurer que le serveur SSH fonctionne comme prévu et que la connectivité n'est pas affectée. En cas de problème, il est important de pouvoir revenir à la configuration précédente. Ne faites pas cela sur de la prod !
La gestion adéquate des ciphers et des algorithmes dans OpenSSH est une étape super important pour assurer la sécurité de votre serveur. En suivant ces recommandations et en effectuant les ajustements nécessaires, vous renforcez considérablement la protection contre diverses menaces de sécurité.
Utilisation de SSH-Audit
Renforcer la configuration de sécurité d'un serveur OpenSSH est une tâche complexe, principalement, car les meilleures pratiques de configuration peuvent varier considérablement selon la distribution et l'environnement spécifique du serveur. C'est dans ce contexte que SSH-Audit devient un outil inestimable. SSH-Audit est conçu pour simplifier ce processus en fournissant une analyse détaillée et des recommandations de configuration adaptées à votre système spécifique. Cet outil analyse la configuration actuelle de votre serveur SSH, identifie les potentielles faiblesses et suggère des améliorations concrètes. Ainsi, même pour les administrateurs moins expérimentés, SSH-Audit est un compagnon indispensable pour naviguer dans les complexités du durcissement d'OpenSSH et assurer une configuration optimale adaptée à votre distribution.
Installation de SSH-Audit
L'installation de SSH-Audit peut être réalisée facilement via pip, le
gestionnaire de paquets pour Python. Pour installer SSH-Audit, ouvrez un
terminal et exécutez la commande suivante :
pip install ssh-audit
Defaulting to user installation because normal site-packages is not writeable
Collecting ssh-audit
Downloading ssh_audit-3.0.0-py3-none-any.whl (101 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 101.2/101.2 KB 1.4 MB/s eta 0:00:00
Installing collected packages: ssh-audit
Successfully installed ssh-audit-3.0.0
Une fois installé, vous pouvez exécuter SSH-Audit pour auditer votre serveur SSH. Si vous souhaitez auditer le serveur SSH sur votre machine locale, utilisez simplement :
ssh-audit localhost
Pour un serveur distant, remplacez localhost par l'adresse IP ou le nom d'hôte
de ce serveur :
ssh-audit 192.168.1.100
...
SSH-Audit produira un rapport détaillé sur la configuration de votre serveur SSH, y compris des informations sur les protocoles, les ciphers, les MACs et les algorithmes de key exchange utilisés. Plus important encore, il mettra en évidence les configurations obsolètes ou vulnérables.
Après avoir reçu le rapport de SSH-Audit, il est crucial d'analyser les
résultats et de prendre des mesures pour résoudre les problèmes identifiés. Par
exemple, si SSH-Audit indique que certains ciphers sont obsolètes, vous devrez
ajouter au fichier de configuration (/etc/ssh/sshd_config.d/ciphers.conf) pour
désactiver ces ciphers spécifiques.
En fin de rapport, vous trouverez ce lien qui contient des fichiers de configuration tout prêt pour chacune des principales distributions Linux.
En intégrant SSH-Audit dans votre routine de maintenance de sécurité, vous pouvez vous assurer que votre serveur SSH reste protégé contre les vulnérabilités connues, contribuant ainsi à la sécurité globale de votre infrastructure réseau.
Pratiques Recommandées pour la Sécurité SSH
Améliorer la sécurité d'un serveur OpenSSH va au-delà de la simple configuration de paramètres techniques. Il implique également l'adoption de pratiques recommandées qui renforcent la sécurité globale.
Mise en Place d'une Authentification à Deux Facteurs (2FA)
L'implémentation de 2FA ajoute une couche supplémentaire de sécurité, en exigeant une preuve d'identité supplémentaire en plus du mot de passe ou de la clé SSH. Pour configurer 2FA sur un serveur SSH, des outils comme Google Authenticator peuvent être utilisés.
Restriction de l'Accès SSH
Limiter l'accès SSH à des utilisateurs ou des adresses IP spécifiques est une autre pratique de sécurité essentielle. Voici comment procéder :
-
Restreindre les Utilisateurs Autorisés : Modifiez
/etc/ssh/sshd_configpour ajouter les directivesAllowUsersouAllowGroupsavec les noms des utilisateurs ou groupes autorisés. Par exemple :AllowUsers user1 user2 AllowGroups group1 -
Limiter l'Accès par Adresse IP : Vous pouvez également restreindre l'accès SSH à certaines adresses IP en utilisant des règles de pare-feu ou en modifiant le fichier
/etc/hosts.allow.
En appliquant ces pratiques, combinées à une configuration de sécurité solide, vous pouvez grandement améliorer la sécurité de votre serveur OpenSSH. Ces méthodes aident à protéger contre les accès non autorisés et les attaques, tout en permettant une gestion flexible pour les utilisateurs légitimes.
Surveillance et Maintenance de la Sécurité SSH
La maintenance de la sécurité d'un serveur OpenSSH ne s'arrête pas à la configuration initiale. Elle requiert une surveillance continue et des mises à jour régulières pour s'adapter aux nouvelles menaces et vulnérabilités.
Surveillance de l'Activité SSH
Une surveillance efficace de l'activité SSH est cruciale pour détecter les tentatives d'intrusion et les comportements anormaux. Voici comment mettre en place une surveillance efficace :
Analyser les Logs SSH : Les fichiers de log SSH, généralement situés dans
/var/log/auth.log, contiennent des informations précieuses sur toutes les
tentatives de connexion. La mise en place d'un système de surveillance des logs,
comme logwatch ou Swatchdog, peut aider à automatiser l'analyse des logs.
Mises à Jour Régulières
Garder le serveur SSH et le système d'exploitation à jour est essentiel pour la sécurité. Voici les étapes à suivre :
- Appliquer les Mises à Jour de Sécurité : Utilisez des commandes
régulières comme
sudo apt-get updateetsudo apt-get upgradesur les systèmes basés sur Debian/Ubuntu pour installer les dernières mises à jour de sécurité.
Gestion des Clés SSH
La gestion des clés SSH implique de surveiller et de mettre à jour régulièrement les clés utilisées pour l'authentification SSH :
- Rotation des Clés : Changez périodiquement les clés SSH, surtout en cas de changement de personnel ou de politique de sécurité.
- Politique de Clés Fortes : Assurez-vous que les clés SSH sont suffisamment robustes (par exemple, en utilisant ED25519
En intégrant ces pratiques de surveillance et de maintenance dans votre routine de gestion de serveur SSH, vous pouvez assurer une sécurité robuste et réactive, capable de s'adapter aux évolutions constantes du paysage des menaces de cybersécurité.
Automatisation
Je vous conseille fortement de mettre en place un outil automatisant le déploiement de la configuration d'OpenSSH sur l'ensemble de vos serveurs. Le plus simple est de recourir à l'outil Rudder qui automatise vérification et réapplique la configuration en cas de changement des paramètres. Ce contrôle est fait plusieurs fois par heure. Autre solution : Ansible
Conclusion
Nous avons vu que le renforcement de la sécurité d'OpenSSH va au-delà de la simple configuration des paramètres. Il englobe une stratégie complète qui inclut la surveillance régulière, les audits de sécurité, la gestion des accès et la mise à jour continue des systèmes. L'utilisation d'outils comme SSH-Audit et Lynis plus l'adoption de pratiques telles que l'authentification à deux facteurs et la restriction de l'accès contribuent de manière significative à la sécurisation de l'environnement SSH.
Il est important de se rappeler que la sécurité SSH est un processus continu et non un événement unique. Les menaces évoluent, tout comme les meilleures pratiques pour les contrer. Restez donc informé, effectuez des audits réguliers, et soyez prêt à ajuster vos configurations et pratiques en réponse aux nouvelles vulnérabilités et aux meilleures pratiques émergentes.
Enfin, gardez à l'esprit que chaque environnement est unique et ce qui fonctionne pour un système peut ne pas être idéal pour un autre. L'évaluation continue des besoins spécifiques et la personnalisation de votre approche de sécurité SSH sont essentielles pour assurer une protection efficace et efficiente.