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.

Astuce

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 indispensable 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

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, la gestion appropriée des ciphers et algorithmes est essentielle. 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

Attention

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 indispensable 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.

Note

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 :

1. Restreindre les Utilisateurs Autorisés : Modifiez /etc/ssh/sshd_config pour ajouter les directives AllowUsers ou AllowGroups avec les noms des utilisateurs ou groupes autorisés. Par exemple :

   AllowUsers user1 user2
   AllowGroups group1

2. 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 essentielle 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 :

1. Appliquer les Mises à Jour de Sécurité : Utilisez des commandes régulières comme sudo apt-get update et sudo apt-get upgrade sur 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 :

1. Rotation des Clés : Changez périodiquement les clés SSH, surtout en cas de changement de personnel ou de politique de sécurité.
2. 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

Astuce

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.