Vérifier que la date du dernier changement de mot de passe est dans le passé pour tous les utilisateurs
Aucun compte ne doit porter une date de dernier changement de mot de passe située dans le futur. Une date future dans le troisième champ de /etc/shadow fait croire au système que le mot de passe vient d'être changé, ce qui neutralise l'expiration PASS_MAX_DAYS pour ce compte.
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
Si la date de changement de mot de passe enregistrée pour un utilisateur est située dans le futur, celui-ci peut contourner toute politique d'expiration des mots de passe.
Ce que vérifie Pavois
Pavois calcule le numéro de jour epoch du jour courant (d=$(( $(date +%s) / 86400 ))) et le compare, avec awk, au troisième champ (lastchg) de chaque ligne de /etc/shadow. Tout compte dont le lastchg est strictement supérieur à la date du jour fait échouer le contrôle. On audite ici la base shadow telle que le système la lit réellement, compte par compte, et non un fichier de politique : une seule entrée falsifiée ou décalée par l'horloge suffit à faire échouer.
describe command('d=$(( $(date +%s) / 86400 )); awk -v d="$d" \'BEGIN{FS=":"}($3 ~ /^[0-9]+$/ && $3+0>d){c++} END{print c?"ko":"ok"}\' /etc/shadow') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Listez directement les comptes fautifs :
awk -F: -v d=$(( $(date +%s) / 86400 )) '($3 ~ /^[0-9]+$/ && $3+0 > d){print $1, $3}' /etc/shadow
Sortie attendue : rien. Pour un utilisateur donné, chage -l <utilisateur> doit afficher une date Dernier changement de mot de passe égale à aujourd'hui ou antérieure.
Inspecter et investiguer
Une valeur lastchg future ne génère aucun log propre : c'est un état silencieux de /etc/shadow. L'écriture qui l'a produite est visible si la surveillance des fichiers d'identité est active, dans le journal d'audit :
grep 'key="usergroup_modification"' /var/log/audit/audit.log
(Grepez le journal brut plutôt que de faire confiance à ausearch, qui renvoie de faux « aucun résultat ».) Un changement légitime via chage ou passwd laisse également une ligne dans /var/log/auth.log, par exemple chage[2345]: changed password expiry for alice.
Remédiation
Pavois classe cette remédiation en manuelle : une date future est une anomalie propre à chaque compte, et la réécrire aveuglément pourrait réinitialiser une fenêtre d'expiration légitime. Le script livré se contente de lister les comptes concernés avec le même test awk, puis vous laisse appliquer, après analyse, chage -d $(date +%F) <utilisateur> sur chacun, ce qui fixe la date du dernier changement à aujourd'hui.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | d=$(( $(date +%s) / 86400 )); awk -F: -v d="$d" '($3 ~ /^[0-9]+$/ && $3+0>d){print $1}' /etc/shadow # for each listed user: chage -d $(date +%F) <user> (set last change to today) |
|---|---|
| reason | a future last-change date is per-user, fix each with chage after review |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un compte dont le lastchg est dans le futur n'expire jamais : un mot de passe volé reste valide au-delà de toute fenêtre de rotation, et l'anomalie est souvent la signature d'un fichier shadow falsifié ou d'un hôte dont l'horloge a sauté. Avant de lancer chage -d, cherchez la cause (vérifiez timedatectl : une horloge système erronée recréera simplement le constat). Attention à l'erreur inverse : mettre lastchg à 0 force un changement de mot de passe à la prochaine connexion, et le faire sur un compte de service ou d'automatisation le verrouille immédiatement, car il ne peut pas répondre à l'invite interactive. Utilisez la date du jour, jamais 0, et gardez une session root ouverte pendant la correction des comptes d'administration.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.4.1.6 | direct | per OS, see the benchmark table | haute |
| PCI DSS | 8.3.5 | 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.