Sécurisation des systèmes et des réseaux · Étape 16

Déploie, vérifie et annule un changement Linux

Ordonne préchecks, application bornée, tests d'accès et métier, critères d'arrêt, preuves et rollback.

Durée indicative · ~2 h 10Niveau intermédiairePrérequis conseillé · Leçon 15 — réduire paquets, services et privilèges d'exécutionPratique · TP
L’idée reçue

« 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 :

  1. contrôle de baseline orphelin ;
  2. perte du chemin administratif ;
  3. sudo surautorisé ;
  4. fichier sensible dangereux ;
  5. montage incompatible avec la fonction ;
  6. retrait d’un paquet requis ;
  7. privilège d’exécution excessif ;
  8. 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.
Évaluation du Lot 3

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é.

Ta progression

Chargement de l’état… Se connecter pour synchroniser.