Sur de nombreux systèmes IBM i que je rencontre, SSH a été installé et activé il y a plusieurs années. Tout le monde l’utilise, mais depuis, personne n’a vraiment regardé le fichier sshd_config.
C’est compréhensible : sur la plupart des systèmes IBM i, 5250 reste encore le principal moyen d’accès. SSH fait plutôt office de porte secondaire. Pourtant, SSH est largement utilisé dans le cadre des projets de modernisation. La plupart des gens savent que la connexion est chiffrée et ont donc tendance à la considérer comme sécurisée. Mais une connexion chiffrée n’est pas nécessairement une connexion correctement sécurisée.
Après avoir ouvert la configuration SSH lors d’un audit de sécurité de trop et constaté, une nouvelle fois, que rien n’avait été modifié depuis des années, je me suis dit qu’il serait utile de détailler les étapes nécessaires pour renforcer une configuration SSH. Il s’agit des bonnes pratiques classiques de sécurisation SSH, appliquées à IBM i.
Point de départ technique
Le fichier de configuration dont vous avez besoin :
Protocol
SSH version 1 présentait des problèmes. Des problèmes critiques. La communauté de la cybersécurité l’a abandonné dès 2001. SSH2 est un protocole totalement différent, avec des contrôles d’intégrité plus robustes et une meilleure prise en charge des clés.
Définissez-le explicitement :
Je rencontre encore des systèmes sur lesquels ce paramètre n’est pas défini explicitement. En théorie, cela signifie qu’un client pourrait négocier une version inférieure du protocole, une version que personne ne devrait plus utiliser en production.
Afficher une bannière avant la connexion
Ce point surprend parfois, car il semble davantage relever de l’administratif que de la sécurité. Pourtant, une bannière de connexion crée un moment clair avant l’authentification, durant lequel l’utilisateur est informé des règles applicables.
Vous créez vous-même le fichier de bannière et pouvez faire preuve de créativité, ou simplement utiliser le texte recommandé par votre équipe juridique ou conformité. La directive se contente de pointer vers ce fichier. Lors d’un audit, c’est typiquement le genre de petit élément qui est soit présent, soit absent. Personnellement, je préfère qu’il soit présent.
Voici la bannière de connexion de l’un de nos systèmes de développement :
Désactiver l’authentification basée sur l’hôte
L’authentification basée sur l’hôte fait confiance à la machine, et non à la personne. Si l’hôte A est considéré comme fiable, n’importe quel utilisateur de l’hôte A pourrait potentiellement se connecter à l’hôte B sans passer par l’authentification utilisateur habituelle.
Imposer l’authentification par clé
Les connexions SSH par mot de passe figurent parmi les premières choses que les attaquants testent. Désactivez-les et imposez l’utilisation de clés à la place. Profitez-en également pour bloquer les mots de passe vides et les connexions root. (Attention : configurez et testez d’abord l’accès par clé, sous peine de vous bloquer vous-même, ainsi que vos collègues, hors de SSH.)
Limiter le nombre de tentatives d’authentification
MaxAuthTries limite le nombre de tentatives d’authentification autorisées au sein d’une même connexion avant que celle-ci ne soit interrompue.
Dès que le nombre d’échecs atteint la moitié de cette valeur, le système commence à enregistrer les événements dans syslog, ce qui vous permet de détecter une activité inhabituelle et d'agir rapidement
Trente secondes suffisent pour s’authentifier. Trois tentatives par connexion permettent de limiter les attaques par force brute sans bloquer inutilement les administrateurs prudents.
Tout le monde n’a pas besoin d’un accès SSH
C’est généralement le point qui suscite le plus de résistance, mais c’est également l’un des plus importants.
Par défaut, si un profil utilisateur existe sur le système, il peut se connecter via SSH, sauf si vous définissez explicitement le contraire. IBM i OpenSSH met à votre disposition quatre directives :
| Directive | Fonction |
| AllowUsers | Seuls ces utilisateurs peuvent se connecter |
| AllowGroups | Seuls les membres de ces groupes peuvent se connecter |
| DenyUsers | Bloque certains utilisateurs spécifiques |
| DenyGroups | Bloque certains groupes spécifiques |
Vous devez en configurer au moins une. Utilisez les noms de profils et de groupes, pas les identifiants numériques, et évitez les caractères génériques. Ma préférence est généralement de définir AllowUsers et AllowGroups. Cela bloque automatiquement tous les utilisateurs et groupes qui ne sont pas explicitement autorisés.
Exemple :
Désactiver le forwarding et les tunnels
À moins qu’un membre de votre équipe ait réellement besoin de tunnels TCP, désactivez-les. Ils augmentent le nombre de ressources auxquelles une session compromise peut accéder.
Redémarrer le daemon, sinon rien ne change
Modifier sshd_config n’a aucun effet tant que le daemon SSH n’a pas pris en compte les changements. Redémarrez sshd après vos modifications. Vous pouvez évidemment regrouper plusieurs changements et ne redémarrer qu’une seule fois.
Cela s’effectue côté IBM i :
Pour conclure
Aucun de ces paramètres ne nécessite l’intervention d’un consultant en cybersécurité ni une semaine entière de projet. Ce sont des changements que vous pouvez effectuer pendant une fenêtre de maintenance, tester d’abord sur une partition hors production, puis déployer progressivement.
Si vous avez des questions ou des remarques concernant le contenu de cet article, contactez-nous directement.
Bonne sécurisation de votre serveur SSH IBM i.
