Cet article concerne le renforcement de la configuration SSH
Présentation
SSH est devenu l'outil standard pour la gestion à distance des systèmes basés sur UNIX. Le démon SSH (sshd ) est installé sur presque tous les principaux systèmes par défaut. De plus, sshd fournit également de nombreuses options de configuration pour nous.
Remarque :Cet article est la suite de mon sujet précédent sur Lynis. Bien que j'ai essayé de rendre cela lisible par lui-même. Vous voudrez peut-être envisager de lire le précédent pour obtenir un peu de contexte.
Les paramètres par défaut de openssh (la version de SSH développée par le projet OpenBSD) suit la philosophie "sécurisé par défaut" de sorte que la plupart des configurations sont sûres par elles-mêmes. Cependant, lors de l'exécution de l'analyse d'audit lynis, j'ai reçu des suggestions concernant les configurations. Passons donc en revue les suggestions afin de renforcer davantage notre démon SSH. Je préciserai également si la désactivation/activation de certains d'entre eux améliore la sécurité.
Renforcement de la configuration SSH
Les suggestions incluent la modification de notre sshd configuration. Comme chemin par défaut pour le sshd la configuration est /etc/ssh/sshd_config , c'est là qu'il faut chercher.
TCP et transfert d'agent
Comme on peut le voir sur la capture d'écran, lynis recommande de définir AllowTCPForwarding et AllowAgentForwarding sur no. C'est un bon conseil de n'utiliser que ce qui est nécessaire, nous devons donc désactiver cette option si nous ne l'utilisons pas. Cependant, la désactiver n'améliorera pas la sécurité si un utilisateur a un accès au shell, auquel cas il peut configurer ses propres redirecteurs (comme indiqué par le sshd_config(5) page de manuel).
ClientAliveCountMax
ClientAliveCountMax et ClientAliveInterval sont deux options liées. Le nombre maximal, multiplié par l'intervalle de vie du client en secondes, détermine le moment où une connexion ne répond plus. Je ne vois pas en quoi cela affecterait la sécurité. Peut-être que j'ai besoin de faire plus de recherches. Néanmoins, baisser la valeur ne devrait pas faire de mal.
Compression
SSH nous permet de compresser les données envoyées après authentification via cette option. Sur les modems lents, la compression peut améliorer les vitesses de connexion. Cependant, sur la plupart des systèmes modernes, cette activation ne devrait pas avoir d'effet. En outre, cela peut également nous présenter des attaques BREACH, comme indiqué dans ce commentaire GitHub. Par conséquent, prenons lynis' proposition.
Niveau de journal
sshd consigne les messages dans journald par défaut sur la plupart des distributions GNU/Linux. Cette option contrôle le niveau de détails à consigner. lynis recommande de passer de INFO à VERBOSE, ce qui peut aider au dépannage, etc. La page de manuel de sshd_config(5) souligne cependant que le réglage à un niveau supérieur (par exemple DEBUG) peut violer la vie privée de ses utilisateurs. Donc, je ne vois vraiment aucune amélioration de la sécurité en modifiant ce paramètre.
MaxAuthTries
Cette valeur détermine le nombre de tentatives d'authentification à autoriser par connexion. De plus, lorsque les échecs de tentative de connexion atteignent la moitié de cette valeur, alors sshd commencera à consigner les échecs. Par conséquent, il est logique de réduire cette valeur.
Sessions max
La valeur de cette option spécifie le nombre de sessions shell autorisées par connexion. Je ne pense pas que l'on puisse avoir besoin de ssh dans un seul serveur plusieurs fois à la fois. De plus, il y a aussi tmux ce qui nous permet de faire le multiplexage que nous voulons sans ouvrir plusieurs sessions. Il est donc logique de suivre cette suggestion.
Port
Mon interprétation de cette suggestion est que nous devrions définir le sshd port d'écoute à une autre valeur. Cela s'avérera utile pour se défendre contre la plupart des botnets qui analysent Internet à la recherche de machines vulnérables sur les ports par défaut. Cependant, toute personne connaissant les bases du mappage réseau (des outils comme nmap ) saura que cela n'aidera pas. Néanmoins, définissons-le sur une valeur autre que celle par défaut.
TCPKeepAlive
Définir cette option sur OUI aidera le serveur à remarquer qu'une connexion est interrompue. De cette façon, les sessions ne se bloquent pas indéfiniment sur le serveur. Par conséquent, je pense qu'il vaut mieux ne pas désactiver cette option.
Transfert X11
Bien que la plupart des ssh les sessions sont censées être uniquement basées sur du texte. Cependant, openssh fournit également la fonctionnalité permettant d'ouvrir des applications GUI sur le serveur qui seront affichées sur le client. La façon dont cela fonctionne est que le serveur X ouvre un canal vers le client. Le problème avec ceci est que X11 n'a jamais été conçu avec la sécurité à l'esprit. Il suppose que tous les programmes sont dignes de confiance puisqu'ils ont été exécutés par nous. Mais, comme le souligne cette réponse, avec X11Forwarding, le serveur peut contrôler le client et ainsi pouvoir exécuter des commandes shell sur le client. Donc, nous ferions mieux d'activer cette fonctionnalité si nous n'en avons pas besoin.
Conclusion
Comme toujours, la sécurité est un sujet très compliqué. Nous ne pouvons pas toujours savoir quand un système est sécurisé. De plus, l'apparence de sécurité est encore pire que l'absence de sécurité.
Dans cet article, j'ai passé en revue les différentes configurations, y compris même les détails très mineurs qui pourraient aider à améliorer la sécurité de notre serveur ssh. Mais comme toujours, renforcez votre système selon votre modèle de menace.
Vous connaissez donc le renforcement de la configuration SSH