Vérifier les permissions du répertoire de configuration du serveur SSH
Garantit que le répertoire de drop-ins /etc/ssh/sshd_config.d appartient à root sans accès pour le groupe ou les autres, afin que les fragments de configuration SSH ne puissent être ajoutés ni lus par des utilisateurs non privilégiés.
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
Le répertoire /etc/ssh/sshd_config.d héberge des fragments drop-in inclus par le sshd_config principal et pouvant activer ou désactiver des fonctionnalités SSH critiques (méthodes d'authentification, chiffrements, connexion root). Si le répertoire est modifiable par le groupe ou les autres, un utilisateur non privilégié pourrait ajouter un drop-in qui affaiblit ou piège le démon SSH au prochain rechargement ; s'il est lisible au-delà de root, la surface de configuration est divulguée. Le répertoire doit appartenir à root sans lecture/écriture/exécution pour le groupe ou les autres afin que seul l'administrateur contrôle la configuration SSH effective.
Ce que vérifie Pavois
Pavois lit le mode effectif du répertoire /etc/ssh/sshd_config.d et vérifie l'absence de lecture/écriture/exécution pour le groupe ou les autres et l'absence de bits setuid/setgid/sticky. Protégé par only_if { file('/etc/ssh/sshd_config.d').exist? }. Comme sshd assemble sa politique effective à partir de chaque fragment de ce répertoire, sécuriser le répertoire est ce qui empêche réellement un attaquant d'injecter une surcharge Include, vérifier l'inode réel reflète cette surface d'attaque réelle.
only_if { file('/etc/ssh/sshd_config.d').exist? }
describe file('/etc/ssh/sshd_config.d') do
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_readable.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_readable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a %U %G' /etc/ssh/sshd_config.d. La sortie attendue est 700 root root (ou plus strict) : aucune lecture, écriture ou exécution pour le groupe ou les autres. Confirmez la configuration effective résultante avec sshd -T après un rechargement.
Inspecter et investiguer
stat /etc/ssh/sshd_config.d affiche le mode du répertoire. La politique SSH effective assemblée depuis ses fragments est affichée par sshd -T. Les événements du service SSH sont dans journalctl -u sshd (RHEL/Fedora) et les tentatives d'authentification dans /var/log/secure. Les modifications du répertoire apparaissent dans /var/log/audit/audit.log si surveillées.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle, appliquez-la donc manuellement : chown root:root /etc/ssh/sshd_config.d puis chmod 0700 /etc/ssh/sshd_config.d.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0700 |
|---|---|
| path | /etc/ssh/sshd_config.d |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un sshd_config.d modifiable par le groupe ou tous permet à un utilisateur non privilégié d'y déposer une surcharge (par ex. PermitRootLogin yes, des chiffrements faibles, une porte dérobée autorisée) prenant effet au prochain rechargement de sshd, une compromission sérieuse de l'accès distant. Précautions : modifier uniquement les permissions du répertoire n'affecte pas les sessions SSH actives, c'est donc sûr ; conservez simplement le répertoire propriété de root et en 0700, et validez avec sshd -t (test de configuration) avant de recharger pour éviter un sshd qui ne redémarre pas.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.1.1 | direct | per OS, see the benchmark table | haute |
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.