Durcis comptes, PAM, sudo et SSH sans perdre l'accès

01Établis le chemin avant de le réduire

Le bastion synthétique possède :

user-ops    compte quotidien
admin-ops   compte administratif nommé
breakglass-linux compte d'urgence verrouillé
sshd        service requis

La séparation des identités vient du Lot 2. Ici, tu vérifies que la configuration Linux conserve le chemin autorisé.

02Manipule les copies de travail

lab=/tmp/soria-hardening-linux-$USER
bash module3-linux-hardening.sh setup "$lab"
bash module3-linux-hardening.sh run "$lab"

column -s, -t "$lab/output/account-hardening-review.csv"
column -s, -t "$lab/output/ssh-review.csv"
column -s, -t "$lab/output/sudo-review.csv"

Le script transforme uniquement work/target. Il ne contacte aucun démon SSH et ne lit aucun compte de l’hôte.

03Observe la cible SSH

PermitRootLogin no
PasswordAuthentication no
AllowUsers admin-ops
MaxAuthTries 3

Le fragment généré commence par :

# SYNTHETIC — DO NOT APPLY

Il sert à discuter la décision. Il n’est pas une configuration prête à copier.

04Comprends le test à deux faces

Test positif

admin-ops reste :

• propriétaire identifié ;
• non verrouillé ;
• associé au bastion ;
• autorisé par AllowUsers ;
• accompagné d’un service sshd requis.

Test négatif

Root et le mot de passe sont refusés dans la cible.

Les deux tests sont nécessaires. Le refus seul peut masquer une perte totale d’accès.

05Réduis sudo sans retirer la fonction

État source :

admin-ops → ALL

État cible représenté :

admin-ops → systemctl-restart-soria-web

La ligne conserve justification, propriétaire, méthode de révocation et test. Elle ne prétend pas être une syntaxe sudoers importable.

06Traite PAM comme une chaîne critique

Le dossier représente :

verrouillage après cinq échecs
qualité de mot de passe
verrouillage après inactivité

Une modification PAM réelle exige :

• console ou accès de secours vérifié ;
• validation de syntaxe et ordre des modules ;
• session administrative existante conservée ;
• nouveau login testé avant fermeture de l’ancienne session ;
• rollback immédiatement disponible.

Le lab ne peut prouver aucun de ces comportements réels. Il conserve donc EXC-PAM-REAL.

07Observe le test négatif de verrouillage

Le validateur crée une variante où :

admin-ops est verrouillé
AllowUsers ne contient plus admin-ops

Elle doit échouer avec :

administrative access path lost

Ce rejet empêche une baseline qui serait stricte mais inexploitable.

08Observe le test négatif sudo

Une autre variante remplace la cible bornée par ALL. Elle doit être refusée avec :

sudo rule remains overbroad

Le contrôle ne dépend pas uniquement de NOPASSWD. Une portée illimitée reste excessive même avec authentification.

09Prépare révocation et rollback

Pour une règle sudo ou un compte administratif :

retirer la règle
révoquer les groupes associés
fermer les sessions selon la procédure autorisée
restaurer la configuration connue
valider le compte de secours
rejouer le test fonctionnel

Le lab produit le plan, mais ne termine aucune session réelle.

10Rends une preuve honnête

Les artefacts démontrent que le chemin cible est cohérent dans les fixtures. Ils ne démontrent pas :

• une syntaxe PAM ou sudoers acceptée par un hôte ;
• un rechargement sshd réussi ;
• un login par clé ;
• une politique MFA ;
• une révocation de session.