Vérifier le groupe propriétaire du fichier de configuration du serveur SSH
Garantit que /etc/ssh/sshd_config appartient au groupe root (GID 0) afin que seul le groupe root puisse modifier la configuration du démon SSH.
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
/etc/ssh/sshd_config contrôle toutes les fonctions de sécurité du démon SSH, méthodes d'authentification, connexion root, algorithmes, port. Si un groupe non root le possède, un compte de ce groupe pourrait affaiblir ces réglages (par exemple réactiver la connexion par mot de passe ou la connexion root) et ouvrir un accès distant. Définir le groupe sur root (GID 0) garantit que seul le groupe le plus privilégié peut modifier la configuration du démon.
Ce que vérifie Pavois
Pavois lit le GID numérique résolu de /etc/ssh/sshd_config via la ressource InSpec file et vérifie qu'il vaut 0. Il inspecte les métadonnées réelles de l'inode au moment de l'audit, de sorte que le résultat reflète la propriété réelle du fichier plutôt qu'une valeur par défaut de paquet ou une attente documentée.
only_if { file('/etc/ssh/sshd_config').exist? }
describe file('/etc/ssh/sshd_config') do
its('gid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%g %G' /etc/ssh/sshd_config. La sortie attendue est :
0 root
Affichez-le avec ls -l /etc/ssh/sshd_config pour confirmer que la colonne du groupe indique root.
Inspecter et investiguer
Les changements de configuration SSH apparaissent au redémarrage du démon : consultez journalctl -u ssh (ou journalctl -u sshd sur la famille RHEL) et /var/log/auth.log. Pour tracer les modifications de propriétaire, ajoutez une surveillance auditd (auditctl -w /etc/ssh/sshd_config -p wa -k sshd_conf) et recherchez key="sshd_conf" dans /var/log/audit/audit.log.
Remédiation
Cette règle n'a pas de plan de durcissement automatisé dans Pavois. Appliquez-la manuellement en définissant le groupe sur root : chgrp root /etc/ssh/sshd_config (ou chown :root /etc/ssh/sshd_config).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| path | /etc/ssh/sshd_config |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Si le mauvais groupe possède ce fichier, ses membres pourraient discrètement assouplir le durcissement SSH et créer une porte dérobée d'accès distant. La correction ne modifie que le groupe propriétaire et n'altère pas le comportement du démon, donc il n'y a pas d'interruption de service. Précaution : assurez-vous qu'aucune automatisation légitime ne modifie sshd_config sous un groupe non root ; après correction, validez la configuration avec sshd -t avant de redémarrer le démon pour éviter de vous verrouiller hors de la machine.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| CIS | 5.1.1, 5.1.2 | direct | per OS, see the benchmark table | haute |
| NIST | AC-17(a), AC-6(1), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | 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.