TP 1 - Audit de Conformité & Hardening

2h30 Intermédiaire

Auteur : Thibaut Fontaine — Kodetis Institution : Université de La Réunion Durée estimée : 2h30

---

Table des matières

1. Objectifs et Contexte
2. Audit avec Lynis
3. CIS Benchmarks avec OpenSCAP
4. Référentiel ANSSI — durcissement GNU/Linux
5. SBOM et scan de vulnérabilités des images Docker
6. Pipeline CI/CD de sécurité
7. Remédiation et Hardening
8. Questions de validation

---

1. Objectifs et Contexte

📡 Poste SOC · La Réunion — Acte 3, Prouver : vous instruisez l’incident du jour J. Poste avancé : Dumont d’Urville (Terre Adélie), ~6 000 km, SATCOM dégradée.

🎯 Objectif métier — mesurer l’écart d’une infra TAAF aux référentiels (CIS, CVE) et le réduire — le préalable à toute homologation.

Contexte

Une infra qui marche n’est pas une infra conforme. Avant d’homologuer la base de Terre Adélie, mesurez l’écart entre ce qu’elle fait et ce que l’ANSSI exige.

Suite à l’alerte de l’ANSSI concernant des menaces ciblant les infrastructures de recherche polaire, le RSSI des TAAF vous demande de réaliser un audit de conformité de l’infrastructure. L’objectif est d’évaluer le niveau de sécurité actuel et de remédier aux vulnérabilités identifiées.

🔴 Au fil de l’enquête

Une infra non durcie est ce qui a rendu l’intrusion possible : services exposés, durcissement absent (#9 du threat model). L’audit de conformité, c’est fermer les portes que l’attaquant a trouvées ouvertes — et prouver, baseline en main, qu’elles sont désormais closes.

🎯 Cœur à valider vs ⭐ Pour aller plus loin

TP dense (plusieurs outils en ~2 h 30). Visez le cœur d’abord :

• 🎯 Cœur (livrable minimum) : audit Lynis (§2) + un scan d’image Grype (§5.2) + durcissement SSH avant/après (§7).
• ⭐ Pour aller plus loin : CIS/OpenSCAP complet (§3), cartographie ANSSI + OS durci Sécurix/NixOS (§4.3), SBOM JSON (§5.3), pipeline CI/CD DevSecOps (§6).

Objectifs pédagogiques

À l’issue de ce TP, vous serez capable de :

• Réaliser un audit de conformité Linux avec Lynis
• Appliquer les CIS Benchmarks avec OpenSCAP
• Cartographier les écarts sur le référentiel ANSSI de durcissement GNU/Linux (et découvrir l’approche secure by design avec Sécurix)
• Générer un SBOM (Syft) et scanner les images Docker avec Grype pour détecter les CVE
• Mettre en place un pipeline CI/CD de scan automatique
• Appliquer des mesures de hardening sur un serveur Linux

Architecture

Vous travaillez depuis la VM TAAF-AUDIT-001 (IP_AUDIT) et auditez les VMs :

graph LR
 AUDIT["TAAF-AUDIT-001
IP_AUDIT
Lynis, OpenSCAP, Syft, Grype"]
 MONITOR["TAAF-MONITORING-001
IP_VM2
SI observé + observabilité"]
 SOC["TAAF-SOC-01
IP_SOC
SOC Grafana-natif"]

 AUDIT -->|"Audit SSH"|MONITOR
 AUDIT -->|"Audit SSH"|SOC

---

2. Audit avec Lynis

Lynis est un outil d’audit de sécurité pour les systèmes Unix/Linux. Il effectue des centaines de tests individuels pour évaluer la posture de sécurité d’un système.

2.1 Audit local de la VM Audit

Connectez-vous à la VM d’audit et lancez un scan complet :

vagrant ssh taaf-audit-001

# Lancer un audit complet
sudo lynis audit system

# Lancer un audit et sauvegarder le rapport
sudo lynis audit system --no-colors | tee ~/lynis-audit-001.txt

Lecture du rapport

Lynis produit un score de hardening (sur 100) et classe les résultats en :

• Warning : problèmes de sécurité à corriger
• Suggestion : améliorations recommandées
• OK : tests réussis

2.2 Audit distant des VMs TAAF

Lancez un audit distant sur les VMs de production :

# Audit de TAAF-MONITORING-001 (SI observé + observabilité)
ssh vagrant@IP_VM2 "sudo lynis audit system --no-colors" > ~/lynis-monitoring-001.txt

# Audit de TAAF-SOC-01
ssh vagrant@IP_SOC "sudo lynis audit system --no-colors" > ~/lynis-soc-01.txt

2.3 Analyse comparative

Comparez les scores de hardening des différentes VMs :

# Extraire les scores
grep "Hardening index" ~/lynis-*.txt

Livrable : Tableau comparatif des scores de hardening des 3 VMs avec les 5 warnings les plus critiques pour chacune.

---

3. CIS Benchmarks avec OpenSCAP

Les CIS Benchmarks sont des référentiels de bonnes pratiques de sécurité reconnus internationalement.

3.1 Scan de conformité CIS

# Télécharger le profil CIS pour Debian 12
# (le profil est pré-installé sur TAAF-AUDIT-001)

# Lancer le scan
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results ~/openscap-results.xml \
  --report ~/openscap-report.html \
  /usr/share/xml/scap/ssg/content/ssg-debian12-ds.xml

3.2 Consultation du rapport

Le rapport HTML est généré dans ~/openscap-report.html. Récupérez-le sur votre machine hôte :

# Depuis votre machine hôte
vagrant scp taaf-audit-001:~/openscap-report.html ./openscap-report.html

Comprendre les résultats

OpenSCAP classe chaque règle CIS en :

• Pass : la règle est respectée
• Fail : la règle n’est pas respectée (à remédier)
• Not Applicable : la règle ne s’applique pas à ce système

Livrable : Capture d’écran du rapport OpenSCAP avec le pourcentage de conformité CIS Level 1.

---

4. Référentiel ANSSI — durcissement GNU/Linux

Les CIS Benchmarks sont des référentiels internationaux. Pour une infrastructure étatique française comme les TAAF, le référentiel de durcissement de premier rang est celui de l’ANSSI, cohérent avec la feuille de route de sécurité numérique de l’État (cf. Cadre réglementaire).

Référence officielle

Guide ANSSI « Recommandations de configuration d’un système GNU/Linux » (v2.0) :

• PDF : fr_np_linux_configuration-v2.0.pdf
• Page de publication : cyber.gouv.fr — Recommandations relatives à un système GNU/Linux

Le guide énonce des règles numérotées (R1, R2, …) classées par niveau de durcissement : minimal, intermédiaire, renforcé, élevé. Chaque règle précise le périmètre (partitionnement, comptes, services, noyau sysctl, journalisation, etc.).

4.1 Cartographier vos findings sur les recommandations ANSSI

Reprenez les warnings Lynis (§2) et les fails OpenSCAP (§3), puis associez chacun à la recommandation ANSSI correspondante.

Finding (Lynis / OpenSCAP)	Recommandation ANSSI	Niveau	Statut
PermitRootLogin autorisé en SSH	R… (durcissement SSH)	intermédiaire	❌ à corriger
Paramètres noyau sysctl non durcis	R… (configuration noyau)	renforcé	❌ à corriger
Partition /tmp non isolée	R… (partitionnement)	intermédiaire	⚠️ partiel

Astuce : ouvrez le PDF ANSSI et utilisez la recherche pour retrouver la règle (sysctl, ssh, umask, partition…). Citez le numéro Rxx exact dans votre rapport.

4.2 Définir le niveau de durcissement cible

Choisissez un niveau cible réaliste pour les TAAF (recommandé : intermédiaire, voire renforcé sur les VMs exposées) et justifiez au regard des contraintes opérationnelles (connectivité satellite, équipes réduites, maintenance à distance).

4.3 Aller plus loin — un OS durci par conception (Sécurix)

Dans ce TP vous durcissez a posteriori un système installé. L’approche inverse, secure by design, consiste à partir d’un OS dont le durcissement ANSSI est intégré dès la construction de l’image.

Cas d’étude — Sécurix (NixOS durci ANSSI)

Sécurix est un système d’exploitation fondé sur NixOS avec un noyau Linux personnalisé conforme aux règles de durcissement de l’ANSSI (certaines désactivables selon le besoin). Ses modules de sécurité sont configurés systématiquement selon les recommandations ANSSI pour les systèmes GNU/Linux :

• Authentification matérielle : support avancé de TPM2 et Yubikey pour la gestion des clés.
• Connexion en FIDO2 : le mot de passe n’est qu’un mode de secours.
• Chiffrement des données via age ou un serveur Vault.
• Secure Boot : enrôlement centralisé avec gestion des clés PK/KEK.
• Déchiffrement du poste par clé FIDO2 (une clé de secours est générée à l’installation), en arrière-plan.

L’intérêt pédagogique : Nix rend la configuration reproductible et auditable (l’état du système est décrit en code), exactement ce qu’exige une infrastructure souveraine et critique comme les TAAF. À comparer avec votre durcissement manuel du §7 : que gagne-t-on en robustesse et en reproductibilité ?

Livrable : le tableau de cartographie finding → règle ANSSI Rxx → niveau + le niveau de durcissement cible retenu et sa justification TAAF.

---

5. SBOM et scan de vulnérabilités des images Docker

Vous auditez ici vos propres images Docker — celles que vous avez déployées aux Actes 1 & 2 (Nextcloud, PostgreSQL, la stack de monitoring…). Deux outils complémentaires, standards du marché :

• Syft génère le SBOM (Software Bill of Materials), l’inventaire exhaustif des composants d’une image. C’est l’exigence supply-chain de l’axe 3 du cadre réglementaire.
• Grype scanne ce SBOM (ou l’image directement) pour détecter les vulnérabilités connues (CVE).

Installation sur TAAF-AUDIT-001

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh  | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

5.1 Générer le SBOM de vos images

# Inventaire des composants de vos images
syft nextcloud:latest -o table
syft postgres:16 -o table

# Export du SBOM au format standard CycloneDX (réutilisé par Grype et au TP4)
syft nextcloud:latest -o cyclonedx-json=~/sbom-nextcloud.json
syft postgres:16     -o cyclonedx-json=~/sbom-postgres.json

5.2 Scanner les vulnérabilités avec Grype

# Scan direct de l'image
grype nextcloud:latest
grype postgres:16

# Scan à partir du SBOM déjà généré (plus rapide, exploitable hors-ligne)
grype sbom:~/sbom-nextcloud.json

# Se concentrer sur les CVE corrigeables et sévères
grype postgres:16 --only-fixed -o table | grep -E "High|Critical"

5.3 Export au format JSON

# Export pour traitement automatisé (consommé au TP4 - Rapport & IA)
grype nextcloud:latest -o json > ~/grype-nextcloud.json
grype postgres:16     -o json > ~/grype-postgres.json

Filet de secours

Si Syft/Grype sont indisponibles, Docker Scout (livré avec Docker) fait le scan CVE : docker scout cves nextcloud:latest.

Livrable : pour chaque image, le SBOM (Syft) + un tableau des CVE HIGH/CRITICAL (Grype) avec le lien NVD correspondant.

---

6. Pipeline CI/CD de sécurité

6.1 Concept DevSecOps

L’idée est d’automatiser les scans de sécurité dans votre pipeline CI/CD GitLab pour que chaque modification soit vérifiée automatiquement.

6.2 Création du pipeline

Créez un fichier .gitlab-ci.yml dans votre repo de formation :

stages:
  - security-scan
  - compliance-report

# 1. Génération du SBOM avec Syft (artefact de traçabilité supply-chain)
sbom:
  stage: security-scan
  image:
    name: anchore/syft:latest
    entrypoint: [""]
  script:
    - syft nextcloud:latest -o cyclonedx-json=sbom-nextcloud.json
    - syft postgres:16     -o cyclonedx-json=sbom-postgres.json
  artifacts:
    paths:
      - sbom-*.json
    expire_in: 30 days

# 2. Scan des CVE avec Grype (échoue si une CVE critique est présente)
vuln-scan:
  stage: security-scan
  image:
    name: anchore/grype:latest
    entrypoint: [""]
  script:
    - grype nextcloud:latest --fail-on critical
    - grype postgres:16     --fail-on critical
  allow_failure: true

# Rapport de conformité Lynis
lynis-audit:
  stage: compliance-report
  image: debian:12
  before_script:
    - apt-get update && apt-get install -y lynis
  script:
    - lynis audit system --no-colors --quiet > lynis-report.txt || true
    - grep "Hardening index" lynis-report.txt
  artifacts:
    paths:
      - lynis-report.txt
    expire_in: 30 days

6.3 Analyse du pipeline

Comportement attendu

Le pipeline utilise allow_failure: true car les images publiques (Nextcloud, PostgreSQL) contiennent souvent des CVE connues non corrigées. En production, vous ajusteriez le seuil de tolérance.

Livrable : Capture d’écran du pipeline GitLab CI exécuté avec les résultats des scans.

---

7. Remédiation et Hardening

À partir des résultats de Lynis, OpenSCAP et des recommandations ANSSI (§4), appliquez les mesures de hardening suivantes sur TAAF-MONITORING-001. Citez la règle Rxx ANSSI correspondante pour chaque mesure dans votre rapport :

7.1 Mesures de base

# Désactiver les services inutiles
sudo systemctl disable --now avahi-daemon 2>/dev/null
sudo systemctl disable --now cups 2>/dev/null

# Configurer les permissions des fichiers sensibles
sudo chmod 600 /etc/shadow
sudo chmod 644 /etc/passwd
sudo chmod 600 /etc/gshadow

# Configurer la politique de mots de passe
sudo apt install libpam-pwquality

7.2 Configuration SSH

# Éditer /etc/ssh/sshd_config
sudo tee -a /etc/ssh/sshd_config.d/hardening.conf << 'EOF'
PermitRootLogin no
MaxAuthTries 3
PasswordAuthentication no
X11Forwarding no
AllowTcpForwarding no
EOF

sudo systemctl restart sshd

7.3 Vérification post-hardening

# Relancer Lynis pour mesurer l'amélioration
sudo lynis audit system --no-colors | tee ~/lynis-post-hardening.txt

# Comparer les scores
echo "=== Avant ===" && grep "Hardening index" ~/lynis-monitoring-001.txt
echo "=== Après ===" && grep "Hardening index" ~/lynis-post-hardening.txt

Livrable : Comparaison avant/après des scores Lynis avec les mesures appliquées.

7.4 Posture de sécurité de l’architecture : avant / après

C’est le livrable central de l’Acte 3 : une photographie chiffrée de la posture de votre propre architecture — celle que vous avez construite aux Actes 1 & 2 — avant et après mise en conformité. Consolidez les mesures de tous vos hôtes et images.

Composant	Indicateur	Avant	Après	Delta
TAAF-MONITORING-001	Indice de hardening Lynis	ex. 58	ex. 81	+23
TAAF-SOC-01	Indice de hardening Lynis
Conformité CIS (OpenSCAP)	% de règles conformes
Image nextcloud:latest	CVE HIGH/CRITICAL (Grype)
Image postgres:16	CVE HIGH/CRITICAL (Grype)

Livrable : ce tableau complété + un paragraphe d’interprétation — qu’est-ce qui a le plus progressé, quelles vulnérabilités résiduelles subsistent, et pourquoi (contraintes TAAF : connectivité, ressources). Ce tableau est repris dans le rapport final du TP4.

---

8. Questions de validation

1. [Facile] Quel est le score de hardening Lynis de TAAF-MONITORING-001 avant remédiation ?
2. [Facile] Combien de CVE CRITICAL Grype a-t-il trouvé dans l’image Nextcloud ?
3. [Moyen] Quelle est la différence entre un audit Lynis et un scan CIS OpenSCAP ?
4. [Moyen] À quoi sert l’option --fail-on critical de Grype dans le pipeline CI/CD ? Et à quoi sert un SBOM généré par Syft ?
5. [Moyen] Citez 3 mesures de hardening SSH recommandées par Lynis.
6. [Moyen] Qu’est-ce qu’un CIS Benchmark Level 1 vs Level 2 ?
7. [Avancé] Votre pipeline CI/CD détecte une CVE CRITICAL dans postgres
   . Quelle est votre stratégie de remédiation ?
8. [Avancé] Comment intégreriez-vous les résultats Grype dans un dashboard Grafana ?
9. [Expert] Proposez une politique de scan automatique adaptée aux contraintes TAAF (connectivité satellite limitée).
10. [Expert] Comment automatiseriez-vous la remédiation des findings Lynis avec Ansible ?
11. [Moyen] Quelle différence faites-vous entre un CIS Benchmark et le guide ANSSI « Recommandations de configuration d’un système GNU/Linux » ? Pourquoi le second est-il plus pertinent pour les TAAF ?
12. [Avancé] Citez 3 recommandations ANSSI (Rxx) issues du guide et expliquez, pour chacune, comment vérifier sa mise en œuvre sur une VM Debian 12.
13. [Expert] Qu’apporte une approche secure by design (type Sécurix : NixOS durci, FIDO2, Secure Boot PK/KEK, TPM2) par rapport au hardening a posteriori réalisé dans ce TP ? Quelles limites pour une infrastructure aux ressources contraintes ?