Vérifier le propriétaire de la bannière de connexion système pour les connexions distantes
Garantit que /etc/issue.net (la bannière de pré-connexion distante) appartient à root (UID 0).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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
Le fichier /etc/issue.net contient la bannière de pré-connexion affichée aux utilisateurs distants (notamment par sshd via la directive Banner). Si un compte non-root le possède, cet utilisateur peut modifier ou supprimer l'avis légal/d'usage, ce qui affaiblit l'opposabilité de la politique d'utilisation et permet d'injecter du texte trompeur. Définir root (UID 0) comme propriétaire garantit que seuls les utilisateurs privilégiés peuvent changer la bannière, conformément aux lois, politiques et normes applicables.
Ce que vérifie Pavois
Pavois inspecte le système de fichiers réel via la ressource InSpec file('/etc/issue.net') et vérifie uid == 0, protégé par only_if afin d'ignorer le test si le fichier est absent. Lire le propriétaire réel de l'inode (plutôt que de se fier à un manifeste de gestion de configuration ou à un modèle copié) reflète l'état effectif sur le disque, y compris tout chown post-déploiement effectué par un opérateur ou un processus compromis.
only_if { file('/etc/issue.net').exist? }
describe file('/etc/issue.net') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %u %n' /etc/issue.net. Sortie attendue : root 0 /etc/issue.net. Le 0 numérique confirme la règle même si le service de noms associe l'UID 0 à un libellé inhabituel.
Inspecter et investiguer
Les changements de propriétaire ne sont pas journalisés par défaut. Avec le framework d'audit, ajoutez une surveillance (auditctl -w /etc/issue.net -p wa -k banner) puis consultez /var/log/audit/audit.log (filtrez avec grep 'key="banner"'). La bannière elle-même est émise par SSH à la connexion, visible dans journalctl -u ssh / /var/log/auth.log.
Remédiation
Aucune remédiation automatisée n'est fournie pour cette règle. Appliquez-la manuellement avec chown root /etc/issue.net (en root ou via sudo) ; le fichier doit rester en groupe root et mode 0644.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| owner | root |
|---|---|
| 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
Un mauvais propriétaire permet à un utilisateur non privilégié de réécrire l'avis légal vu avant authentification. Risque à l'application : quasi nul, /etc/issue.net est un fichier texte statique sans dépendance de service, donc chown root n'interrompt ni les connexions ni SSH. Par précaution, vérifiez ensuite que le fichier reste lisible (0644) pour que la bannière continue de s'afficher.
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.