← Toutes les règles
SOCLE-CLD-GEN-044// Hardening (misc)moyenneconfig persistante

S'assurer que le shell nologin n'est pas listé dans /etc/shells

Garantit que nologin et /bin/false ne sont pas listés dans /etc/shells, afin qu'ils restent de vrais shells sans connexion.

Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.

Un PASS prouve? actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 1 norme

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/shells est la liste des shells de connexion valides, consultée par des programmes comme chsh, les démons FTP et divers modules PAM pour déterminer si un compte est un véritable utilisateur interactif. nologin et /bin/false sont des shells non interactifs délibérément attribués aux comptes de service/système pour leur refuser une session. Les lister dans /etc/shells les déclare comme shells de connexion valides, ce qui peut réactiver l'accès interactif (par ex. via FTP ou chsh) pour des comptes censés n'en avoir aucun. Ils doivent être absents du fichier.

Ce que vérifie Pavois

Pavois recherche dans le /etc/shells en vigueur toute entrée nologin ou /bin/false et n'en attend aucune. Ce fichier est lui-même la source de vérité effective consultée par chsh/FTP/PAM ; l'inspecter directement reflète exactement ce que ces programmes accepteront comme shell de connexion valide.

describe command('grep -qE \'nologin|/bin/false\' /etc/shells 2>/dev/null && echo ko || echo ok') do
  its('stdout.strip') { should eq 'ok' }
end

Comment vérifier qu’elle est appliquée

Confirmez qu'aucun shell sans connexion n'est listé :

  • grep -E 'nologin|/bin/false' /etc/shells, la sortie attendue est vide (aucune correspondance).
  • cat /etc/shells, ne doit lister que de vrais shells interactifs comme /bin/bash, /bin/sh, /usr/bin/zsh.

Inspecter et investiguer

Les modifications de la configuration des shells de connexion laissent des traces :

  • grep -E 'chsh|shells' /var/log/auth.log (Debian/Ubuntu) / /var/log/secure (RHEL), affiche les appels à chsh qui lisent /etc/shells.
  • cat /etc/shells est la vue de référence de l'état courant des shells de connexion acceptés.

Remédiation

Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement : éditez /etc/shells et supprimez toute ligne référençant nologin ou /bin/false. Les retirer de la liste des shells valides ne change pas le shell réellement utilisé par chaque compte (celui-ci reste dans /etc/passwd) ; cela empêche seulement ces shells sans connexion d'être traités comme des shells de connexion valides.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

commandsed -ri '\#(nologin|/bin/false)#d' /etc/shells
namestrip-nologin-from-shells
not_if! grep -qE 'nologin|/bin/false' /etc/shells
resourceexec
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Risque si non appliqué : des comptes de service affectés à nologin//bin/false peuvent regagner un accès interactif via des programmes qui se basent sur /etc/shells (FTP, chsh).

Précautions avant application : retirer ces entrées présente peu de risque et n'affecte pas les connexions existantes des utilisateurs réels. Vérifiez simplement qu'aucun outil interne n'exige explicitement la présence de nologin dans /etc/shells (rare). Après la modification, vérifiez que les comptes de service ne peuvent toujours pas ouvrir de session interactive.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS5.4.3.1directper OS, see the benchmark tablehaute

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.

Sources & références