Sur bon nombre des systèmes IBM i que je rencontre, SSH a été installé et activé il y a des années. Tout le monde l’utilise, et personne n’a jamais jeté un œil au fichier sshd_config depuis.
Il est compréhensible que, sur la plupart des systèmes IBM i, le 5250 reste le principal moyen d’accès. SSH a tendance à jouer le rôle de « porte de service ». Pourtant, SSH est largement utilisé dans le cadre des efforts de modernisation. La plupart des gens savent que la connexion est chiffrée, ce qui leur donne un sentiment de sécurité. Mais « chiffré » et « renforcé » ne sont pas synonymes.
Après une énième audit de sécurité au cours de laquelle j’ai ouvert le fichier de configuration SSH pour constater, une fois de plus, que rien n’avait été modifié, j’ai pensé qu’il valait la peine de consigner par écrit les mesures à prendre pour renforcer cette configuration. Il s’agit d’un durcissement standard de SSH, appliqué à IBM i.
Point de départ technique
Le fichier de configuration dont vous avez besoin :
Protocol
La version 1 de SSH présentait des problèmes. Des problèmes graves. La communauté de la sécurité l’a abandonnée dès 2001. SSH2 est un protocole totalement différent, doté de contrôles d’intégrité plus rigoureux et d’une meilleure prise en charge des clés.
Définissez-le explicitement :
Je rencontre encore des systèmes où ce paramètre n’est pas explicitement défini, ce qui signifie qu’un client pourrait théoriquement négocier un protocole inférieur, que personne ne devrait utiliser avec des identifiants de production.
Afficher une bannière avant la connexion
Cette mesure surprend souvent, car elle ressemble davantage à une formalité administrative qu’à une mesure de sécurité. Pourtant, une bannière de connexion crée un moment de clarté avant l’authentification, durant lequel l’utilisateur est informé des règles.
Cette mesure surprend souvent, car elle ressemble davantage à une formalité administrative qu’à une mesure de sécurité. Pourtant, une bannière de connexion crée un moment de clarté avant l’authentification, durant lequel l’utilisateur est informé des règles.
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 (host-based authentication) fait confiance à la machine, et non à la personne. Si l’hôte A est approuvé, 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 par mot de passe via SSH sont la première chose que testent les attaquants. Désactivez-les et exigez des clés à la place. Profitez-en pour interdire les mots de passe vides et la connexion en root. (Remarque : configurez et testez d’abord l’accès par clés, faute de quoi vous risquez de vous verrouiller l’accès SSH, ainsi qu’à vos collègues.)
Limiter le nombre de tentatives d’authentification
MaxAuthTries définit le nombre de tentatives d’authentification autorisées sur 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 à écrire dans syslog, ce qui vous donne un signal qu’il se passe quelque chose.
Trente secondes suffisent pour s’authentifier, et trois tentatives par connexion limitent les attaques par force brute sans pour autant bloquer les administrateurs soigneux..
Tout le monde n’a pas besoin d’un accès SSH
C’est le point qui suscite le plus de résistance, et c’est aussi le plus important.
Par défaut, dès lors qu’un profil utilisateur existe sur le système, son titulaire peut probablement se connecter en SSH, sauf indication contraire. OpenSSH sur IBM i met quatre leviers à votre disposition :
| 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 des noms de profils et de groupes plutôt que des identifiants numériques, et évitez les caractères génériques. Ma préférence va généralement à la combinaison AllowUsers et AllowGroups : tous les utilisateurs et groupes qui ne sont pas explicitement définis sont ainsi exclus d’office.
Exemple :
Désactiver le forwarding et les tunnels
À moins que quelqu’un dans votre équipe n’ait réellement besoin de tunnels TCP, désactivez-les. Ils élargissent le périmètre accessible à partir d’une session compromise.
Redémarrer le daemon, sinon rien ne change
Modifier sshd_config n’a aucun effet tant que le démon SSH n’a pas pris en compte les changements. Redémarrez sshd après vos modifications. Si vous préférez, regroupez tous les changements et ne redémarrez qu’une seule fois.
Cela s’effectue côté IBM i :
Pour conclure
Aucun de ces réglages ne requiert un consultant en sécurité ni une semaine de projet. Ce sont des modifications que l’on réalise pendant une fenêtre de maintenance, que l’on teste d’abord sur une partition hors production, puis que l’on déploie.
Si vous avez des questions ou des remarques sur le contenu de cet article, n'hésitez pas à nous contactez.
Bonne chance pour la sécurisation de votre serveur SSH IBM i.
