« Le changement est réussi lorsque les commandes se terminent sans erreur. »
Un durcissement est réussi lorsque la cible est atteinte, les refus attendus sont observés, les fonctions restent disponibles et le retour arrière est prouvé.
01Prépare la décision de changement
Le dossier CHG-LNX-001 contient :
périmètre
propriétaire
fenêtre
préchecks
critères d'arrêt
jeu de tests
rollback
limite de preuve
Sa décision est AUTHORIZED_WITH_ACTIONS, car le lab ne dispose d’aucun hôte Linux réel.
02Exécute le cycle complet
lab=/tmp/soria-hardening-linux-$USER
bash module3-linux-hardening.sh setup "$lab"
bash module3-linux-hardening.sh status "$lab"
bash module3-linux-hardening.sh run "$lab"
bash module3-linux-hardening.sh validate "$lab"
Le cycle produit work/before, work/target, des fragments non importables, les rapports, les variantes négatives et une copie de rollback.
03Observe les préchecks
column -s, -t "$lab/output/precheck-report.csv"
Le validateur exige :
sauvegarde de configuration disponible
chemin administratif nommé
espace disponible
carte des dépendances
baseline fonctionnelle enregistrée
Un précheck bloquant absent ou non réussi fait échouer le changement.
04Applique uniquement au périmètre autorisé
Le lab transforme les copies :
work/before → état déclaré initial
work/target → état cible représenté
Il ne modifie aucun fichier sous source/ et vérifie leurs checksums pendant validate.
05Observe le delta effectif
column -s, -t "$lab/output/effective-delta.csv"
Le delta réunit contrôles, sudo, SSH, modes, montages, paquets et services. Il distingue la baseline générale du changement réellement représenté.
Une baseline sans delta ne prouve pas qu’un changement a été appliqué.
06Combine trois familles de tests
Positifs
admin-ops reste autorisé
nginx reste installé et actif
postgresql reste disponible
backup-agent reste disponible
Négatifs
root SSH refusé
mot de passe SSH refusé
sudo ALL refusé
fichier sensible world-writable refusé
Fonctionnels
portail représenté disponible
stockage des commandes représenté disponible
administration par bastion représentée disponible
sauvegarde représentée disponible
Aucune famille ne remplace les deux autres.
07Observe les huit variantes négatives
column -s, -t "$lab/output/negative-test-report.csv"
Le lab bloque :
- contrôle de baseline orphelin ;
- perte du chemin administratif ;
- sudo surautorisé ;
- fichier sensible dangereux ;
- montage incompatible avec la fonction ;
- retrait d’un paquet requis ;
- privilège d’exécution excessif ;
- changement sans rollback.
Une variante acceptée fait échouer tout le lab.
08Utilise les critères d’arrêt
Le changement doit s’arrêter lorsque :
admin-access-fails
mission-test-fails
Sur un environnement réel, il faudrait aussi fixer durée maximale, seuil d’erreurs, perte de supervision, échec du redémarrage et divergence de configuration.
09Vérifie le rollback
Le lab copie work/before vers rollback/restored, puis produit deux manifestes :
relative_path
sha256
Il exige leur égalité avec cmp et écrit :
result=PASS
verification=manifest-match
Cette preuve concerne les fixtures, pas un système de fichiers Linux réel.
10Rends la décision
cat "$lab/output/final-decision.txt"
cat "$lab/output/validation-summary.txt"
Résultat de référence :
LINUX_HARDENING_WITH_ACTIONS
Les actions restantes portent sur l’application par anneaux et les preuves réelles.
LINUX_HARDENING_READY
Réservé à un périmètre où les contrôles, accès, fonctions, redémarrage et rollback requis ont été réellement testés.
LINUX_HARDENING_WITH_ACTIONS
La conception et les preuves synthétiques sont cohérentes, mais des validations réelles restent nécessaires.
LINUX_HARDENING_BLOCKED
Obligatoire si accès, fonction, contrôle, précheck ou rollback échoue.
11Nettoie le périmètre
bash module3-linux-hardening.sh reset "$lab"
test ! -e "$lab"
Le reset exige .soria-hardening-linux, rend les fixtures supprimables dans la seule racine autorisée, puis vérifie sa disparition.
12Respecte les preuves non établies
Le cycle ne prouve pas :
- l’application de PAM, sudo ou SSH ;
- un montage actif ;
- un paquet retiré ;
- un service arrêté ;
- une capability supprimée ;
- une unité systemd durcie ;
- un redémarrage ou rollback réel.
Défends la décision Linux
Exécute le cycle complet, présente baseline, delta, tests, variantes négatives et rollback. Explique pourquoi la décision reste avec actions, puis propose un déploiement pilote sur un hôte autorisé sans dépasser les preuves disponibles.
✓Lot 3 terminé
Tu sais concevoir une baseline Linux par rôle, réduire les accès et surfaces d’exécution, préserver la fonction, vérifier les refus et préparer un rollback contrôlé.