Vérifier que tous les hachages de mots de passe sont dans shadow
Garantit qu'aucun vrai hachage de mot de passe n'est stocké dans /etc/passwd (lisible par tous) ; tous les hachages doivent être dans /etc/shadow.
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 hachages de mots de passe doivent résider dans /etc/shadow, lisible uniquement par root, et jamais dans /etc/passwd qui est lisible par tous. Le deuxième champ de chaque entrée de /etc/passwd doit donc être un marqueur (x, * ou !). Un vrai hachage stocké à cet endroit expose les identifiants de chaque utilisateur à un cassage hors ligne par force brute ou dictionnaire depuis n'importe quel compte local.
Ce que vérifie Pavois
Pavois utilise awk pour lister toute entrée de /etc/passwd dont le champ mot de passe n'est pas un marqueur (x, *, !). Le contrôle réussit uniquement si la liste est vide. Inspecter directement la base de comptes résolue est le seul moyen fiable de confirmer que les identifiants ont bien été migrés vers /etc/shadow et non laissés exposés.
describe command('awk -F: \'($2!="x" && $2!="*" && $2!="!"){print $1}\' /etc/passwd') do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez awk -F: '($2!="x" && $2!="*" && $2!="!"){print $1}' /etc/passwd. Sortie attendue : rien. Tout nom affiché possède un champ mot de passe non transféré dans shadow, à migrer avec pwconv.
Inspecter et investiguer
- Vérifier une migration propre :
pwck -rpuis recontrôler/etc/passwd. - Comparer les entrées :
getent passwd <nom>vsgetent shadow <nom>. - Événements d'authentification :
/var/log/auth.log(Debian/Ubuntu) ou/var/log/secure(famille RHEL).
Remédiation
Aucune remédiation automatique n'est fournie. Corrigez manuellement en exécutant pwconv, qui déplace tout hachage présent dans /etc/passwd vers /etc/shadow et le remplace par le marqueur x, puis relancez le scan pour confirmer.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | grep -E '^[^:]+:[^:!*x]' /etc/passwd # accounts with a hash still in /etc/passwd pwconv # migrate them to /etc/shadow |
|---|---|
| reason | moving passwords to /etc/shadow with pwconv is safe but verify no app reads /etc/passwd hashes |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un hachage laissé dans /etc/passwd (lisible par tous) permet à n'importe quel utilisateur local de le copier et de le casser hors ligne, menant au vol d'identifiants et à l'élévation de privilèges. Le correctif (pwconv) est peu risqué et standard, mais sauvegardez d'abord /etc/passwd et /etc/shadow et vérifiez ensuite que les connexions fonctionnent toujours.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 7.2.1, 8.3.2 | direct | per OS, see the benchmark table | haute |
| NIST | 3.5.10, CM-6(a), IA-5(h) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 8.3.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.