Bannières de connexion et MOTD

La menace

Le texte affiché autour de l'invite login: passe facilement inaperçu, et pourtant il joue contre vous de deux manières distinctes.

D'abord, la fuite d'informations. Sur de nombreuses distributions, les bannières par défaut interpolent des séquences d'échappement : \s affiche le nom de l'OS, \r la version du noyau, \m l'architecture, \v la version, \l la ligne du terminal. /etc/issue.net est le pire cas : il est envoyé sur le réseau, avant toute authentification ; ainsi un attaquant non authentifié qui se contente d'ouvrir une connexion TCP vers sshd (lorsque Banner /etc/issue.net est défini) obtient une empreinte gratuite : "Ubuntu 24.04, noyau 6.8". C'est exactement l'information nécessaire pour choisir un exploit ciblé, et elle est offerte gratuitement.

Ensuite, l'avertissement légal manquant. Sans avis explicite d'utilisation autorisée, un intrus peut prétendre que le système semblait ouvert à l'accès. De nombreuses juridictions et référentiels (CIS, et la politique d'entreprise) exigent une bannière indiquant que l'accès est restreint et surveillé avant que l'utilisateur ne s'authentifie ; sans quoi poursuivre un accès non autorisé devient plus difficile.

Pourquoi le durcir

Aucun de ces problèmes n'est une faille d'exécution de code à distance, alors les bannières sont négligées, mais les deux sont peu coûteux à corriger et tous deux comptent. Supprimer les échappements OS/version retire un cadeau de reconnaissance à tout scanner qui touche le port ou la console. Mettre en place un avis clair d'utilisation autorisée établit l'intention et soutient la réponse à incident. Le coût est un fichier texte d'une ligne avec les bons droits ; le bénéfice est une empreinte de moins et une posture juridique défendable.

Cela couvre chaque point d'entrée : le TTY local (/etc/issue, lu par getty avant l'invite), la bannière distante pré-authentification (/etc/issue.net, servie par SSH lorsqu'elle est configurée) et le message post-connexion (/etc/motd, rendu par pam_motd). L'objectif est un avis neutre et cohérent sur les trois.

Principes de défense appliqués

• Minimiser la divulgation d'information : retirer tout échappement \s/\m/\r/\v/\l afin qu'aucun détail d'OS, de noyau ou d'architecture ne soit diffusé avant authentification. Les utilisateurs autorisés obtiennent ces faits délibérément via uname -a après connexion ; aucune raison de les divulguer plus tôt.
• Défense en profondeur : couvrir les trois surfaces (locale, distante, post-connexion), pas seulement SSH ; un attaquant devant une console physique ou une ligne série voit aussi /etc/issue.
• Moindre surprise / traçabilité : un unique avis d'accès autorisé neutre, propriétaire root:root et mode 0644, indiquant que le système est surveillé et l'accès restreint.
• L'effectif plutôt que le nominal : la bannière ne dissuade à distance que si SSH la sert réellement (sshd -T doit indiquer banner /etc/issue.net) ; écrire le fichier est nécessaire mais pas suffisant.

Ce que Pavois audite

Pavois fournit trois règles dans ce domaine, une par surface, toutes mappées sur CIS :

• banner-issue : lit /etc/issue (la bannière pré-connexion de la console locale) et vérifie qu'elle est non vide et exempte des échappements \[smrvlSMRVL].
• banner-issue-net : lit /etc/issue.net (la bannière proposée aux connexions distantes/SSH) avec les deux mêmes vérifications : présente, et sans échappement OS/version fuitant sur le réseau.
• banner-motd : lit /etc/motd (le message post-connexion rendu par pam_motd) et applique les mêmes contrôles.

Ce sont des fichiers statiques consommés directement par getty, sshd et pam_motd ; lire le fichier représente donc bien la configuration effective ici : aucune commande d'état résolu ne s'intercale entre le fichier et ce qu'affiche le terminal. Le volet SSH complémentaire (savoir si sshd -T indique réellement banner /etc/issue.net) relève du contrôle SSH de config effective de Pavois, de sorte que la vue du handbook relie le contenu du fichier au fait qu'il soit véritablement servi. pavois harden apply écrit chaque fichier avec un avis d'accès autorisé neutre, la propriété root:root et le mode 0644, et aucun échappement dynamique : sans redémarrage ni relance de service, puisque chaque consommateur lit le fichier à la connexion suivante.

Comment le poser et vérifier ?

1. Écrivez un avis neutre (sans échappement OS/version) dans /etc/issue, /etc/issue.net et /etc/motd, propriétaire root:root, mode 0644.
2. Pointez SSH dessus : Banner /etc/issue.net dans sshd_config, puis systemctl reload sshd.
3. Confirmez que la bannière distante est réellement servie : sshd -T | grep -i banner doit indiquer banner /etc/issue.net, et ssh -o PreferredAuthentications=none user@host affiche le texte avant toute invite.
4. Confirmez l'absence de fuite : grep -E '\\[smrvlSMRVL]' /etc/issue /etc/issue.net ne renvoie rien.

Que doit dire la bannière ?

Un avis d'utilisation autorisée court et neutre : le système est réservé aux utilisateurs autorisés, l'activité peut être surveillée et journalisée, et l'accès non autorisé est interdit. N'incluez pas le nom d'hôte, l'OS, la version, des détails internes de l'organisation, ni un bienvenue amical (qui affaiblit la posture juridique).

FAQ

Pourquoi /etc/issue.net est-il pire que /etc/issue ? Parce que SSH peut le servir avant authentification, sur le réseau ; ses échappements divulguent donc l'OS et le noyau à quiconque se connecte. /etc/issue ne s'affiche qu'à un TTY local.

J'ai écrit la bannière mais SSH ne l'affiche pas. SSH ne sert une bannière que si Banner /etc/issue.net est défini dans sshd_config ; vérifiez sshd -T | grep banner et rechargez sshd.

La bannière doit-elle souhaiter la bienvenue ? Non. Un bienvenue peut être interprété comme une invitation ; utilisez plutôt un avis d'accès restreint et de système surveillé.