Vérifier les permissions de la bannière de connexion système pour les connexions distantes
Garantit que /etc/issue.net n'est ni modifiable, ni exécutable, ni setuid/setgid ni sticky pour le groupe ou les autres, afin que seul root puisse modifier la bannière de connexion distante.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
L'affichage d'une notification d'utilisation normalisée et approuvée avant l'accès au système d'exploitation garantit que le texte de notification de confidentialité et de sécurité reste conforme aux lois, directives, politiques, réglementations et normes applicables. La bannière /etc/issue.net est présentée aux clients distants (par exemple SSH) avant l'authentification. Si le fichier est modifiable par le groupe ou par tous, un utilisateur non privilégié pourrait réécrire la bannière pour tromper les utilisateurs, supprimer la mention légale ou injecter un message de hameçonnage ; les bits setuid/setgid/exécutable n'ont aucune utilité légitime sur un fichier texte et ne font qu'élargir la surface d'attaque. Restreindre les permissions garantit que seul root peut modifier la bannière.
Ce que vérifie Pavois
Pavois évalue les bits de mode réels de /etc/issue.net sur la cible (exécutable/setuid/setgid/sticky/modifiable par groupe et autres) plutôt que de se fier à une base documentée. Les permissions font partie de l'inode lui-même, l'audit lit donc l'état effectif sur le disque, aucun mécanisme de drop-in ou d'include ne peut le tromper. La garde only_if ignore le contrôle si le fichier est absent.
only_if { file('/etc/issue.net').exist? }
describe file('/etc/issue.net') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%A %U %G' /etc/issue.net. Attendu : mode -rw-r--r-- (0644) appartenant à root root, sans bit d'écriture pour le groupe/les autres ni bits s/t. Vérification rapide : find /etc/issue.net -perm /0133 ne doit rien renvoyer.
Inspecter et investiguer
Les changements de permissions ne sont pas journalisés par défaut. Pour détecter une altération, surveillez le fichier avec auditd : auditctl -w /etc/issue.net -p wa -k banner, puis consultez les événements avec grep 'key="banner"' /var/log/audit/audit.log. La propriété et le mode actuels s'affichent avec stat /etc/issue.net.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle, elle doit donc être appliquée manuellement : chown root:root /etc/issue.net && chmod 0644 /etc/issue.net. Cela supprime toute écriture groupe/autres et tout bit setuid/setgid/sticky tout en gardant la bannière lisible par tous.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0644 |
|---|---|
| path | /etc/issue.net |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si mal réglé : un utilisateur non-root peut réécrire la bannière distante pré-authentification, supprimant l'avertissement légal ou plaçant un message trompeur vu par chaque utilisateur SSH. Appliquer le correctif est peu risqué : 0644 root:root est le mode conventionnel et la bannière reste lisible. Précaution : ne retirez pas le bit de lecture pour other, sshd et login affichent le fichier aux clients non authentifiés, le rendre illisible viderait la bannière.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 1.2.8, 1.6.6, 1.7.6 | direct | per OS, see the benchmark table | haute |
| PCI DSS | 1.2.8 | support | 4.0.1 | moyenne |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.