Connexions root directes interdites
Garantit que /etc/securetty est vide afin que root ne puisse se connecter directement sur aucune console ; les administrateurs doivent s'authentifier puis élever leurs droits via su/sudo.
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
Lorsque les utilisateurs peuvent se connecter directement en root sur les consoles et terminaux, toutes les actions d'administration se fondent dans une seule identité partagée et anonyme, on ne peut savoir qui a fait quoi. Le modèle sûr est : chaque administrateur s'authentifie en son nom, puis élève ses droits avec su/sudo, ce qui produit une piste d'audit traçable, compatible multi-facteurs et par commande. Le fichier /etc/securetty liste les TTY sur lesquels root peut se connecter ; un fichier vide signifie qu'aucun terminal n'autorise une connexion root directe. Ce contrôle est requis pour les socles FISMA Low et Moderate.
Ce que vérifie Pavois
Pavois vérifie que /etc/securetty existe mais ne contient aucune entrée (taille nulle). Un securetty vide est le signal effectif consulté par pam_securetty.so au moment de la connexion : PAM refuse une connexion root directe sur tout TTY non listé, et une liste vide les refuse tous.
describe command('[ -s /etc/securetty ] && echo ko || echo ok') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Confirmez que le fichier est vide :
[ -s /etc/securetty ] && echo populated || echo empty, la sortie attendue est empty.wc -l /etc/securetty, attendu0 /etc/securetty. Une tentative de connexion root en console doit alors être rejetée parLogin incorrectmême avec le bon mot de passe.
Inspecter et investiguer
Les tentatives de connexion sont enregistrées par la pile d'authentification :
grep -E 'securetty|root' /var/log/auth.log(Debian/Ubuntu) //var/log/secure(RHEL), affichepam_securetty(login:auth): access denied: tty 'ttyN'lorsqu'une connexion root directe est correctement bloquée.journalctl -t login -t sshdcorrèle les tentatives en console et en SSH.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement : videz le fichier avec : > /etc/securetty (ou supprimez toutes ses lignes) tout en le conservant présent pour que pam_securetty.so continue de refuser root. Notez que ceci régit les connexions console/TTY ; les connexions root via SSH sont régies séparément par PermitRootLogin.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | : > /etc/securetty |
|---|---|
| name | empty-securetty |
| not_if | test ! -s /etc/securetty |
| 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é : les connexions root anonymes partagées effacent la traçabilité et suppriment une couche d'authentification.
Précautions avant application : assurez-vous qu'au moins un compte non-root peut atteindre root via un sudo/su fonctionnel avant de retirer l'accès root direct, sinon un administrateur sans autre voie se retrouve privé d'opérations privilégiées. Gardez une session privilégiée ouverte pendant la modification, et rappelez-vous que le mode mono-utilisateur/secours permet toujours de récupérer la console. L'accès root par SSH doit être désactivé séparément.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R33 | direct | 2.0 | haute |
| CIS | 8.6.1, 5.4.2.4 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.1, CM-6(a), IA-2 | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 8.6.1 | 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.