Empêcher la connexion aux comptes sans mot de passe
Retire l'option nullok de toutes les lignes pam_unix.so de /etc/pam.d/. Avec nullok, PAM accepte un mot de passe vide comme authentification valide : tout compte dont le champ d'empreinte shadow est vide devient accessible sans rien saisir.
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
Si un compte a un mot de passe vide, n'importe qui peut s'y connecter et exécuter des commandes avec les privilèges de ce compte. Les comptes sans mot de passe ne doivent jamais être utilisés dans un environnement de production.
Ce que vérifie Pavois
Pavois recherche récursivement dans toute la pile /etc/pam.d/ (grep -RlE '^[^#]*\bpam_unix\.so\b[^#]*\bnullok') toute ligne pam_unix.so non commentée portant l'option nullok, et échoue dès qu'un fichier correspond. C'est le balayage du répertoire entier, et non du seul common-auth ou system-auth, qui permet de détecter un nullok réintroduit dans une pile de service secondaire (login, sshd, su, un drop-in fournisseur). La pile sssd-shadowutils est exclue : nullok y a une signification différente et ne constitue pas un contournement par mot de passe vide.
describe command('grep -RlE \'^[^#]*\bpam_unix\.so\b[^#]*\bnullok\' /etc/pam.d/ 2>/dev/null | grep -qv \'sssd-shadowutils\' && echo ko || echo ok') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Relancez la même recherche et attendez aucune sortie :
grep -RE '^[^#]*pam_unix\.so.*nullok' /etc/pam.d/
Une ligne fautive ressemble à auth [success=1 default=ignore] pam_unix.so nullok ; une fois corrigée, elle devient auth [success=1 default=ignore] pam_unix.so. Vérifiez en complément qu'aucun compte ne porte réellement une empreinte vide : sudo awk -F: '($2 == ""){print $1}' /etc/shadow ne doit rien afficher.
Inspecter et investiguer
Une connexion à mot de passe vide acceptée grâce à nullok ressemble à un succès ordinaire dans /var/log/auth.log (ou via journalctl -u sshd), sans rien qui signale l'absence de mot de passe, ce qui explique précisément la dangerosité de l'option :
sshd[5678]: Accepted password for backup from 203.0.113.10 port 55012 ssh2
Une fois l'option retirée, la tentative est rejetée et PAM journalise l'échec :
sshd[5678]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.10 user=backup
auditd enregistre le même rejet sous forme d'évènement USER_AUTH ... res=failed dans /var/log/audit/audit.log.
Remédiation
Le plan de durcissement Pavois exécute une remédiation exec nommée pam-unix-remove-nullok : elle liste les fichiers de /etc/pam.d/ dont les lignes pam_unix.so portent nullok et supprime le jeton sur place avec sed -ri '/pam_unix\.so/ s/[[:space:]]*\bnullok\b//g', sans toucher au reste de la ligne (aucun réordonnancement de modules). Une garde not_if saute l'étape lorsqu'il ne reste aucune correspondance, ce qui rend l'application idempotente. Sur Debian et Ubuntu, /etc/pam.d/common-auth et common-password sont générés par pam-auth-update à partir des profils de /usr/share/pam-configs/ : une édition directe ne tient que jusqu'à la prochaine exécution de pam-auth-update (mise à niveau ou reconfiguration de libpam-runtime), qui restaure nullok. Rejouez pavois harden apply après une telle mise à niveau, ou retirez nullok du profil unix pour que le changement survive à la régénération.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | grep -rlE '^[^#]*pam_unix\.so.*nullok' /etc/pam.d/ | while read -r f; do sed -ri '/pam_unix\.so/ s/[[:space:]]*\bnullok\b//g' "$f"; done; true |
|---|---|
| name | pam-unix-remove-nullok |
| not_if | ! grep -rqE '^[^#]*pam_unix\.so.*nullok' /etc/pam.d/ |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Conserver nullok transforme tout compte laissé avec une empreinte vide (compte de service mal provisionné, utilisateur créé sans mot de passe) en point d'entrée sans mot de passe, éventuellement doté de sudo. Retirer l'option est normalement sans danger : les comptes disposant d'un vrai mot de passe ne sont pas affectés et aucune session en cours n'est coupée. Le risque de verrouillage se concentre sur les comptes qui s'appuyaient sur le mot de passe vide : ils sont refusés immédiatement, y compris en console. Avant d'appliquer, listez-les avec sudo awk -F: '($2 == ""){print $1}' /etc/shadow ; si un compte d'administration y figure, définissez-lui un vrai mot de passe (passwd <utilisateur>) ou installez une clé SSH au préalable, et gardez une seconde session privilégiée ouverte pendant l'application. Modifier PAM reste la manière classique de s'enfermer dehors : validez donc l'accès depuis une nouvelle session avant de fermer la session courante. Enfin, retirer nullok ne corrige pas les comptes eux-mêmes : complétez par le verrouillage de chaque compte à mot de passe vide (passwd -l <utilisateur>).
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.3.3.4.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.