TP – Auditer, corriger, prouver
BTS SIO SISR 2e année – Bloc 3 – S10 – en binôme : un tape, l'autre lit ; on échange les rôles à chaque partie
Note
But. Mesurer la conformité d'un serveur Debian avec l'outil d'audit Lynis, trier le rapport, corriger quelques points, re-mesurer, documenter les écarts acceptés et décrire un processus de correctifs.
Durée : 3 h 10. Prérequis : cours S10 lu ; S01 (durcissement SSH).
Note
Comment ce TP fonctionne. Tu anticipes (« J'anticipe »), tu manipules, tu notes ce que tu constates, puis tu expliques (« Je comprends »). Un bilan de compétences clôt la séance.
Binôme : ____________ / ____________
Contraintes
- Une machine virtuelle Debian avec un compte
sudo(celle des séances précédentes convient : ne pas reprendre une machine déjà durcie si tu veux voir des écarts). Instantané avant de commencer. - Paquet
lynis. L'audit est local (il n'envoie rien) et ne modifie rien : il lit la configuration. - Tu notes la sortie de chaque commande (capture d'écran datée).
Partie A – Avant l'audit (≈ 15 min)
J'anticipe. Sans lancer l'outil, indique cinq points que tu t'attends à voir signalés sur ton serveur (parmi : mots de passe, droits, services, pare-feu, mises à jour, journaux…) : ______________________
Je comprends. Un score qui monte indique-t-il forcément que la sécurité s'améliore ? ______________________
Partie B – La mesure de départ (≈ 40 min)
B1 – Installer et lancer l'audit
L'option --quick évite les pauses à chaque section. L'audit dure environ une minute ou deux.
B2 – Lire le résultat
À la fin, l'outil affiche un résumé. Relève aussi les chiffres dans le rapport :
sudo grep -E '^(hardening_index|lynis_version)' /var/log/lynis-report.dat
sudo grep -c '^warning\[\]' /var/log/lynis-report.dat
sudo grep -c '^suggestion\[\]' /var/log/lynis-report.dat
| Mesure | Valeur de départ |
|---|---|
| Indice de durcissement | |
| Nombre d'avertissements | |
| Nombre de suggestions |
B3 – Lister les avertissements et les suggestions
sudo grep '^warning\[\]' /var/log/lynis-report.dat | cut -d'|' -f1,2
sudo grep '^suggestion\[\]' /var/log/lynis-report.dat | cut -d'|' -f1,2 | head -30
Je comprends. Chaque ligne commence par un identifiant de test (par exemple AUTH-9328). Pour comprendre un test, demande le détail : sudo lynis show details AUTH-9328.
Point de contrôle : capture des valeurs de B2 et de la liste des avertissements.
Partie C – Trier (≈ 35 min)
Parmi les suggestions, choisis au moins six points et classe-les avec les échelles de la séance S02 :
| Identifiant | Description | Risque visé | Gravité (1-4) | Effort (faible, moyen, élevé) | Effet de bord possible | Décision (corriger, planifier, accepter) |
|---|---|---|---|---|---|---|
Je comprends. Pourquoi ne corrige-t-on pas toutes les suggestions ? Cite un exemple où appliquer la suggestion serait inutile ou dangereux pour ton serveur : ______________________
Partie D – Corriger (≈ 50 min)
Applique au moins trois corrections parmi celles de la liste ci-dessous (celles présentes dans ton rapport), ou d'autres de ton tri. Pour chacune, note la commande et le test.
D1 – Droits par défaut des nouveaux fichiers (si la suggestion « Default umask » est présente)
sudo grep -E '^UMASK' /etc/login.defs
sudo sed -i 's/^UMASK.*/UMASK 027/' /etc/login.defs
sudo grep -E '^UMASK' /etc/login.defs
Je comprends. 027 : les nouveaux fichiers ne sont ni lisibles ni modifiables par les « autres ». L'effet s'applique aux nouvelles sessions.
D2 – Âge des mots de passe (si les suggestions sur l'âge minimal et maximal sont présentes)
sudo sed -i 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS 90/; s/^PASS_MIN_DAYS.*/PASS_MIN_DAYS 1/' /etc/login.defs
sudo grep -E '^PASS_(MAX|MIN)_DAYS' /etc/login.defs
Warning
Ces réglages ne s'appliquent qu'aux comptes créés ensuite. Pour un compte existant : sudo chage -M 90 -m 1 NOM_DU_COMPTE. Les durées sont des valeurs de laboratoire : la politique réelle se décide d'après la recommandation à jour (séance S06) et peut ne pas imposer de changement périodique.
D3 – Outils de vérification et de suivi (si les suggestions « debsums » et « apt-show-versions » sont présentes)
Je comprends. debsums -s ne signale que les fichiers de paquets dont le contenu a changé par rapport au paquet d'origine : s'il affiche quelque chose, un fichier a été modifié (légitimement ou non). Aucun affichage = tout est conforme.
D4 – Une correction de ton choix
Choisis un point de ton tri (partie C), corrige-le, et note : commande, fichier modifié, test de vérification, retour arrière : ______________________
Point de contrôle : captures avant et après de chaque correction.
Partie E – Re-mesurer (≈ 20 min)
sudo lynis audit system --quick --no-colors
sudo grep -E '^hardening_index' /var/log/lynis-report.dat
sudo grep -c '^suggestion\[\]' /var/log/lynis-report.dat
| Mesure | Départ | Après |
|---|---|---|
| Indice de durcissement | ||
| Nombre d'avertissements | ||
| Nombre de suggestions |
Je comprends. Les suggestions que tu as traitées ont-elles disparu du nouveau rapport ? Lesquelles restent, et pourquoi ? L'indice a-t-il augmenté autant que la gravité des points corrigés le laissait penser ? ______________________
Partie F – Écarts acceptés et processus de correctifs (≈ 30 min)
F1 – Le registre des écarts acceptés
Pour trois suggestions que tu n'appliques pas, remplis le registre :
| Identifiant | Pourquoi on n'applique pas | Risque accepté | Mesure compensatoire | Responsable | Date de revue |
|---|---|---|---|---|---|
F2 – Les mises à jour de ton serveur
Simule d'abord une mise à jour, sans rien installer :
J'anticipe. Combien de paquets seraient mis à jour ? Parmi eux, y a-t-il des mises à jour de sécurité ? ______________________ (Aide : apt list --upgradable indique le dépôt d'origine de chaque paquet, par exemple « security ».)
F3 – Un processus de correctifs pour l'Atelier Verdier
Reprends le dossier de la séance S02. Décris en huit lignes le processus de correctifs que tu proposes (inventaire, sources d'alerte, évaluation, test, déploiement, vérification, trace, retour arrière), et indique ce que tu fais des PC sous Windows 7 qui ne reçoivent plus de correctifs : ______________________
Retour en entreprise (si ta situation le permet)
- Observer : comment ton entreprise sait-elle que ses serveurs sont à jour ? Existe-t-il un inventaire, une fenêtre de maintenance, un délai fixé ?
- Documenter : compare le processus de ton entreprise à celui de F3.
Rendu
Compte rendu PDF, nommé RENDU-B3A2-S10-NOM.pdf, contenant les captures datées des parties B à E, le tri de la partie C, le registre de F1 et le processus de F3.
Prolongement dans InfraLab (facultatif)
Un logiciel non autorisé, ou installé sans licence, est un écart de conformité que l'inventaire doit faire apparaître.
Le simulateur InfraLab propose des TP guidés sur ce thème : vue TP, choisis le TP. Ils s'ajoutent à la séance (en classe si le temps le permet, sinon en autonomie) ; ils ne remplacent pas la manipulation sur machine réelle ci-dessus.
| TP | Titre | Durée |
|---|---|---|
| 26 | Logiciels et installations non autorisées | 40 min |
Note
InfraLab simule : le score ne valide aucune compétence. Exporte le rapport du TP (HTML) et joins-le à ton compte rendu.
Bilan de la séance
| Compétence du référentiel | Ce que j'ai fait dans cette séance | Niveau |
|---|---|---|
| B3.3 – Sécuriser les équipements et les usages des utilisateurs | ||
| B3.4 – Garantir la disponibilité, l'intégrité et la confidentialité des services informatiques et des données de l'organisation face à des cyberattaques | ||
| B3.5A – Assurer la cybersécurité d'une infrastructure réseau, d'un système, d'un service |
Note
Je sais faire, sans aide :
- Lancer un audit de conformité et lire un rapport ;
- Trier des suggestions selon gravité, effort et effet de bord ;
- Corriger un point et prouver l'effet par une nouvelle mesure ;
- Tenir un registre des écarts acceptés ;
- Décrire un processus de gestion des correctifs.
Ce que je dois reprendre : ______________________