S'assurer que les comptes système n'exécutent pas de shell à la connexion
Garantit que chaque compte système non-root (UID < 1000) possède un shell sans connexion, refusant les sessions interactives aux comptes de service.
Vérifié sur ce qui est installé ou enregistré, paquets présents/absents, bases de comptes.
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
Les comptes système (UID inférieur à 1000 : daemon, bin, www-data, mysql, …) existent pour posséder des fichiers et faire tourner des services, pas pour qu'on s'y connecte. Si un tel compte conserve un shell de connexion interactif (par ex. /bin/bash), il devient un point d'appui exploitable : un attaquant qui compromet le service correspondant, ou qui devine/casse le compte, peut ouvrir une vraie session. Tout compte système autre que root doit avoir un shell sans connexion (nologin/false) ou un shell à usage spécifique (sync/shutdown/halt).
Ce que vérifie Pavois
Pavois lit l'UID de chaque compte et son shell de connexion effectif (champ 7 de la base passwd) et signale tout compte système (UID < 1000, hors root) dont le shell n'est ni nologin/false ni un shell spécial bénin (sync/shutdown/halt). Évaluer l'entrée passwd résolue reflète exactement ce que le système accorderait à la connexion, y compris les comptes provisionnés par des paquets.
describe command('awk -F: \'($3<1000 && $1!="root" && $7 !~ /nologin|false|sync|shutdown|halt/){print $1}\' /etc/passwd') do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Listez tout compte système ayant un shell interactif :
awk -F: '($3<1000 && $1!="root" && $7 !~ /nologin|false|sync|shutdown|halt/){print $1":"$7}' /etc/passwd, la sortie attendue est vide.getent passwd <compte>, le champ shell (dernière colonne) doit indiquer/usr/sbin/nologinou/bin/false.
Inspecter et investiguer
Les tentatives de session et les changements de shell sont journalisés par la pile d'authentification :
grep -E 'session opened|chsh|usermod' /var/log/auth.log(Debian/Ubuntu) //var/log/secure(RHEL), affiche toute session ouverte pour un compte système et toute modification de shell.getent passwd <compte>est la sonde de référence de l'état courant du shell attribué.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement : pour chaque compte signalé, définissez un shell sans connexion avec usermod -s /usr/sbin/nologin <compte> (utilisez /sbin/nologin sous RHEL). Ne touchez pas à root, et laissez les comptes spéciaux sync/shutdown/halt tels quels.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | awk -F: '($3<1000 && $1!="root" && $7 !~ /nologin|false|sync|shutdown|halt/){print $1}' /etc/passwd | while read u; do usermod -s /usr/sbin/nologin "$u" 2>/dev/null; done; true |
|---|---|
| name | nologin-sysaccounts |
| not_if | test -z "$(awk -F: '($3<1000 && $1!="root" && $7 !~ /nologin|false|sync|shutdown|halt/){print $1}' /etc/passwd)" |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si non appliqué : un compte de service doté d'un vrai shell est un point d'appui tout prêt pour les déplacements latéraux et la persistance.
Précautions avant application : confirmez que le compte est réellement non interactif, certains comptes (par ex. un utilisateur CI ou de sauvegarde, ou un compte de base de données utilisé pour de la maintenance su - <user> -c ... planifiée) nécessitent légitimement un shell. Changer le shell d'un tel compte casserait ces tâches. Vérifiez que le service propriétaire démarre toujours et qu'aucune unité cron/systemd ne s'exécute sous cet utilisateur avec un shell de connexion avant de le basculer en nologin.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.4.2.7, 8.2.2 | direct | per OS, see the benchmark table | haute |
| NIST | AC-6, CM-6, CM-6(a), CM-6(b) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 8.2.2 | 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.