Suivi du TP — Lab pfSense / Proxmox

Document de pilotage : ce qu’il reste à faire, où j’en suis, où je vais. La procédure détaillée est dans Documentation-pfSense.md. Les règles de pare-feu sont dans Matrice-de-flux.md. Les incidents rencontrés sont dans Troubleshooting.md. Les schémas de l’infrastructure sont dans Architecture.md. Les procédures réutilisables : MO-1 Clonage de VM · MO-2 Cluster Galera · MO-3 HAProxy · MO-4 Clés SSH · MO-5 Git et GitHub · MO-6 Windows Server Core · MO-7 Termix · MO-8 Tailscale · MO-9 Comptes Active Directory · MO-10 Pangolin · MO-11 Sauvegarde Proxmox · MO-12 Proxmox Backup Server · MO-13 Prometheus · MO-14 HAProxy local · MO-15 rsyslog · MO-16 Fluent Bit · MO-17 Grafana · MO-18 Ajouter une machine · MO-19 Wazuh et Suricata · MO-20 GPO · MO-22 LogAnalyzer · MO-21 GLPI · MO-23 Alertes → tickets GLPI. Exercice d’incident : fiches réflexes · modèle de rapport. Version diffusable, sans théorie : Tuto Tailscale + pfSense. Dernière mise à jour : 12/11/2026 (soir : étape 76, limitation de débit VISITEURS mesurée (T21, phase 15 terminée) ; étape 75, charte et liste des logiciels autorisés (phase 24 terminée) ; envoi ac17810 au formateur ; relecture de toute la documentation ; étape 74 ; T30 terminé) ; 11/11/2026 (phase 19 terminée : portail GLPI des salariés)

Avancement global

██████████████████░░  89 %     195 / 218 tâches

Le total passe de 62 à 95 tâches : la phase 10 ajoute la haute disponibilité — cluster Galera à 3 nœuds, répartiteur HAProxy, deux serveurs web. Le pourcentage chute de 84 à 55 %, non pas parce qu’on a reculé, mais parce que le périmètre a grandi. (05/11 : 6.20 close, 139/161 ; puis 4 tâches écartées par Axel : 7.14 (exercice d’incident, préparé pendant les révisions et documenté à part) et 12.1, 12.3, 12.4 (accès externe : l’accès Termix du formateur suffit) → 139/157 ; puis 5.7 et 6.9 supprimées (poste-debian, jamais créé : inutile pour le lab, décision d’Axel) → 139/155 ; 10.9 constatée faite → 140/155 ; 10.23 → 141/155, phase 10 terminée ; 7.4 et 13.1 → 143/155 ; 9.8 écartée (Pangolin suffit) → 143/154 ; 13.8 → 144/154 ; 6.21 ajoutée et faite (site de GSB) → 145/155 ; phase 11 (GLPI) cadrée : 12 tâches ajoutées, 11.1 faite → 146/167 ; puis 11.2 à 11.8 → 153/167.) (06/11 : phase 17 (LogAnalyzer) cadrée : 8 tâches ajoutées, 17.1 faite → 154/175 ; 13.6 close (restauration depuis la copie du NAS) → 155/175 ; 17.2 → 156/175 ; 17.3 → 157/175 ; 17.4 et 17.5 → 159/175 ; 17.6 → 160/175 ; 17.7 → 161/175 ; 17.8 → 162/175, phase 17 terminée ; 11.11 → 163/175 ; 11.9 → 164/175 ; 11.10 → 165/175 ; 11.12 → 166/175, phase 11 terminée ; phase 18 (Matomo, site en ligne) ajoutée : 10 tâches → 166/185, le pourcentage baisse parce que le périmètre grandit ; le pourcentage passe de 92 à 88 % parce que le périmètre grandit.) (08/11 : compteur recalé à 164 : l’en-tête affichait 166 alors que la somme des tableaux des phases donne 164 (le compteur du haut est tenu à la main, deux tâches y avaient été ajoutées deux fois ; la phase 16 comptait 8 au lieu de 9 tâches faites) → 164/185 ; puis 3 phases ajoutées : 19 portail GLPI (9 tâches, demande du dossier du 07/11), 20 copie hors site immuable (6 tâches, demande du dossier du 08/11), 21 GPO « poste Windows prêt à l’arrivée » (7 tâches, demande d’Axel du 08/11) → 164/207 : le pourcentage passe de 89 à 79 % parce que le périmètre grandit, rien n’a reculé.) *(11/11 : ordre décidé par Axel : phases 19, 20, 21 puis 22.) (10/11 : phase 22 « mise à jour de tout le lab » ajoutée, demande d’Axel : 7 tâches → 164/214, 77 % ; 18.1 → 165/214 ; 18.2 → 166/214 ; 18.3 → 167/214 ; 18.4 → 168/214 ; 18.5 → 169/214 ; 18.6 → 170/214 ; 18.7 → 171/214 ; tâche 18.11 ajoutée (adresse réelle des visiteurs) → 171/215 ; 18.11 → 172/215 ; 18.9 → 173/215 ; 18.10 → 174/215 ; 19.1 → 175/215 ; 19.7 écartée → 175/214, 82 %.) (04/11 : 13.15 close, 138/161.) (Rappel historique : 45 → 53 → 62 → 95 → 102 → 103 → 104 → 105 → 108 → 115 → 116 → 118 → 112 → 119 → 121 → 131 (15/10 : les 10 tâches de la phase 14) → 130 (17/10 : la tâche 13.11 est écartée) → 131 (18/10 : tâche 13.15 ajoutée) → 132 (28/10 : tâche 14.11, compte lecteur et export du tableau de bord) → 136 (29/10 : compteur recalé : l’en-tête affichait 107 / 132 alors que la somme des tableaux donnait déjà 111 / 136) → 144 (29/10 : phase 15, zone « Visiteurs », 8 tâches) → 145 (30/10 : tâche 14.12, alerte « site lent » demandée par le contrat de service) → 147 (30/10 : tâches 15.9 et 15.10, le poste visiteur intégré à la sauvegarde, à Grafana et aux alertes, demande d’Axel) → 148 (30/10 : phase 16, détection d’intrusion, tâche de cadrage) → 150 (30/10 : 7.14 exercice d’incident de la S7, 15.11 qualité de service, demandés pour la R1) → 161 (02/11 : phase 16 détaillée en 12 tâches après le choix Wazuh + Suricata ; le pourcentage passe de 85 à 80 % parce que le périmètre grandit). 108 → 112 le 14/10 : la phase 12 compte désormais 5 tâches au lieu de sa seule tâche de cadrage ; le compteur n’avait pas suivi (la somme du tableau donnait déjà 93 / 112). Le pourcentage passe de 85 à 84 % pour cette raison, pas par recul.) (11/11 : phase 20 arrêtée après l’étude 20.1 (pas de place sur le NAS, décision d’Axel) : 20.2 à 20.6 écartées → 182/210.) (11/11 : phase 23 ajoutée (revue des alertes, 5 tâches, demande d’Axel) → 188/215.) (12/11 : recompte depuis le tableau des phases : total 214 (et non 215) ; 16.6 (décision Wazuh du 11/11) reportée dans la phase 16 → 190/214.) (12/11 : phase 24 ajoutée (charte informatique, 4 tâches, 3 faites) → 193/218.)

OÙ J’EN SUIS

Position au 12/11 : le lab est complet pour la R1 (38 tests sur 39, reste l’exercice d’incident de janvier). Ce qui reste est de l’exploitation : revoir les alertes trop bavardes (phase 23), étendre Wazuh (16.7), tout mettre à jour (phase 22), finir les MO de la phase 21, laisser venir les vraies visites du site (18.8).

Du 07 au 12/11 : site de GSB en ligne par Pangolin avec mesure d’audience Matomo conforme CNIL (phase 18) ; portail GLPI des salariés (connexion par l’annuaire en LDAPS, tickets, guide, phase 19) ; copie immuable étudiée puis écartée faute de place (phase 20, le lab reste en 3-2-1-0) ; GPO « poste prêt à l’arrivée » (agents, SSH par clé, LAPS, pare-feu, audit), testée sur une VM Windows 11 temporaire puis supprimée (phase 21) ; les 3 alertes de la copie hors site éprouvées (T30 : 17 règles sur 17) ; Wazuh étendu aux serveurs web (5 agents) ; charte informatique écrite, connue (bannière, GLPI, intranet) et contrôlée deux fois (Wireshark, Kudu), avec sa liste des logiciels autorisés (phase 24) ; limitation de débit de la zone VISITEURS prouvée par la mesure (T21, phase 15). Toute la documentation relue et envoyée au formateur le 12/11 (ac17810).

Historique de la position : le socle, la haute disponibilité et l’Active Directory sont en place.

Le domaine sio.internal est en service sur AD-Core-01 (Server Core) : poste-win11 y est joint et rangé, l’annuaire porte une arborescence OU=SIO, 6 comptes et des groupes en AGDLP. La chaîne applicative est redondée (cluster Galera à 3 nœuds, répartiteur HAProxy, deux serveurs web), le WAN n’accepte qu’une connexion entrante (l’hyperviseur vers le serveur de sauvegarde), l’accès distant passe par Tailscale. Depuis le 15/10, tout le lab est sauvegardé chaque nuit par un Proxmox Backup Server (incrémental, 7 jours, restauration testée).

Depuis le 28/10, la supervision a son tableau de bord de production « Lab BTS — Production » : disponibilité des 6 services sur 30 jours (dont Termix et Pangolin, de bout en bout), cluster Galera, sauvegardes par VM, état des 13 machines (processeur, mémoire et disques réglés dans Proxmox, latence disque), connexions refusées et réussies. Il a déjà servi : le bruit des journaux a été divisé par plus de dix (contrôles de santé, annonces CARP).

Le 28/10, la mémoire a été réduite (34 → 30 Gio) et le disque de srv-docker ramené de 150 à 32 Gio (étape 53).

Du 29/10 au 01/11 : Grafana prévient par mail (11 règles, toutes testées par une panne réelle ou un seuil abaissé, étape 54) ; la zone Visiteurs (VLAN 50, 5ᵉ zone) est en service avec son poste de test, supervisé et sauvegardé (étape 55) ; les journaux sont conservés 6 mois et purgés chaque nuit, le bruit de l’AD filtré à la source (étape 56) ; le formateur ouvre les machines par Termix (étape 57). Tests 7.10 et 7.13 réussis. Le 02-03/11, la détection d’intrusion est entrée en service (phase 16) : un serveur Wazuh tout-en-un sur srv-wazuh (10.0.30.16, 6 Gio fixes, essai assumé sous le minimum éditeur), 3 agents (srv-ha, ad-core-01, poste-win11) inscrits avec mot de passe, une règle par zone vers le seul serveur, et Suricata sur pfSense en détection seule sur VISITEURS et USERS ; trois attaques simulées détectées en 2 à 3 s (étapes 59 et 60, MO-19). Le 03/11 au soir, la détection prévient par mail : alertes Wazuh de niveau ≥ 10 et créations de comptes (59.8), alertes réseau de Suricata lues par Wazuh puis envoyées par mail (60.6), avec un bandeau « Alertes en cours » et un bloc « Intrusions Wazuh » dans le tableau de production. Chaque maillon prouvé jusqu’au mail reçu. La perte de quorum (7.11) est testée (étape 58). Le 05/11, les deux premières stratégies de groupe sont en service sur OU=Ordinateurs (bannière d’avertissement, réponse au ping depuis le lab), posées et prouvées en PowerShell par SSH (étape 61, MO-20) ; les deux points ouverts du poste (SSH en compte du domaine, ping) sont clos. Le 05/11 après-midi, HAProxy ne garde plus que les nœuds Galera synchronisés (sonde du port 9200, étape 62) : la phase 10 est terminée. Le 05/11 en fin de journée : le site WordPress est devenu le site de GSB (public + intranet) ; la copie hors site des sauvegardes est en service sur le NAS d’Axel (14 VM copiées et relues sans erreur, surveillée dans Grafana) ; GLPI est en service sur les serveurs web en actif / secours, base dans Galera, bascule testée (phase 11, 8/12 ; étape 66). Le 06/11 : la nuit est vérifiée (sauvegardes, copie sur le NAS, export SQL avec GLPI) et une machine a été restaurée depuis la copie du NAS (étape 65.3) : la phase 13 (sauvegarde) est terminée. La phase 17 est terminée : LogAnalyzer montre les journaux bruts en direct (HTTPS 8443, lecture seule) ; son premier usage a coupé à la source le bruit de la sonde Galera (77 % des journaux) et fait corriger les sessions de GLPI (H-89). L’après-midi, la phase 11 (GLPI) est terminée : 13 machines s’inventorient seules chaque jour et se rangent dans l’entité de leur zone (étape 69) ; les alertes deviennent des tickets (sécurité tout de suite, le reste après 2 h, résolution automatique, ticket rattaché à la machine : étape 70, test réel réussi) ; MO-21 et MO-23. Aussi : alerte quand HAProxy retire un serveur (étape 68), sonde Galera durcie (H-90), Wazuh dans la ligne des services ; le soir, bruit de routine des journaux coupé (étape 67.4 bis) et faille APT corrigée sur les 12 machines Linux (veille, étape 71). Restent surtout la semaine de mesure de Wazuh (décision le 10/11), puis l’extension des agents (16.7) ; après le BTS blanc : mots de passe SSH, compte collaborateur WordPress (15.11 avancée et faite le 12/11).

PROCHAINES ACTIONS (dans cet ordre)

Rappel pour les VM en IP fixe (VLAN 10, 20, 30) : le DHCP y est désactivé. Chaque machine doit recevoir quatre paramètres saisis à la main — adresse, masque /24, passerelle 10.0.XX.1 et DNS 10.0.XX.1. Oublier le DNS reproduit exactement la panne rencontrée sur poste-win11 : adressage correct, résolution de noms impossible.

Accès au lab : Termix http://10.0.30.12:443 (port explicite — voir étape 20D) · Portainer https://10.0.30.12:9443 · pfSense https://10.0.40.1 — le tout depuis n’importe où via Tailscale.

Légende

Phase 1 — Socle pfSense

Validé : System Information affiche 2.9.0, WAN et LAN en up, uptime 2 jours.

Phase 2 — Sécurisation minimale

Validation initiale erronée. Cette tâche avait été cochée le 16/09 sur la foi de la disparition du bandeau. La comparaison des quatre sauvegardes XML a montré une empreinte bcrypt identique du 17/09 au 25/09 : le mot de passe n’avait jamais changé. Corrigé le 25/09. Voir incident H-08 du Troubleshooting.

Vérification fiable : System → User Manager, colonne Last Changed du compte admin — et non la présence ou l’absence du bandeau, qui ne s’affiche pas sur toutes les pages.

Phase 3 — Trunk et VLAN

Validé : Status > Interfaces affiche WEB (opt1, vtnet1.10) → 10.0.10.1, BDD (opt2, vtnet1.20) → 10.0.20.1, ADM (opt3, vtnet1.30) → 10.0.30.1, USERS (opt4, vtnet1.40) → 10.0.40.1, toutes en 255.255.255.0 et up. LAN repassé en 10.0.0.1 / 255.255.255.0.

La logique à comprendre : un VLAN n’existe pas « quelque part », il existe sur tout le chemin. Le tag est posé par pfSense (3.1 ), transporté par le switch virtuel (3.2 / 3.3), puis interprété comme un réseau routé (3.5 / 3.6). Si un maillon manque, rien ne passe — et le symptôme ressemble à « le câble est débranché ».

Phase 4 — Pare-feu et routage

La matrice a été rédigée avant toute manipulation de l’interface. C’est elle qui justifie chaque règle devant un jury.

Principes retenus : BDD n’initie aucun flux · le bastion (srv-docker) est la seule machine autorisée à sortir du VLAN 30, en RDP/SSH uniquement · les USERS n’accèdent qu’au site web, au domaine AD et au bastion.

Phase 5 — Déploiement des VM

Le DHCP n’est activé que sur le VLAN 40. Les VM des VLAN 10, 20 et 30 ne reçoivent aucune adresse au démarrage : l’IP se saisit à la main. Ce n’est pas une panne.

Le champ VLAN Tag fait tout le travail : Proxmox tague et détague pour la VM, qui n’a rien à configurer et croit être sur un réseau ordinaire. C’est un port access. pfSense, lui, est en trunk (champ vide) car il gère les tags lui-même.

Test après chaque VM : dans le VLAN 40, elle doit recevoir une IP en 10.0.40.1xx. Une adresse dans une autre plage = mauvais tag.

Phase 6 — Services applicatifs

Chaîne applicative (WEB + BDD)

La tâche 6.4 est le cœur pédagogique du TP. C’est le moment où une application traverse réellement le pare-feu entre deux VLAN. Si WordPress affiche « Erreur de connexion à la base de données », le premier réflexe est de vérifier la règle SRV_WEB → SRV_MYSQL : 3306.

Active Directory

La tâche 6.9 est un vrai bonus SISR. Un Linux membre d’un domaine Active Directory, avec authentification des utilisateurs du domaine, est une compétence peu courante au niveau BTS. Elle n’ajoute aucune règle de pare-feu : SSSD utilise les mêmes ports que Windows (Kerberos, LDAP, DNS), déjà ouverts par la règle USERS → ADM : PORTS_DC_AD.

Points ouverts sur le poste Windows (constatés le 08/10), clos le 05/11 :

Constat du 08/10	Vérification du 05/11
SSH vers poste-win11 en SIO\Administrateur : ECONNRESET après ~25 s d’authentification	ssh sio.internal\[email protected] → session PowerShell ouverte (compte du domaine). Cause de l’échec du 08/10 non établie (hypothèse d’Axel : latence de la connexion)
Ping srv-docker → 10.0.40.100 sans réponse	Le poste est en 10.0.40.10 depuis le 21/10 (réservation DHCP). ping -c3 10.0.40.10 depuis srv-docker → 0 % de perte (0,5 ms)

Bastion (hôte Docker)

Un portail unique pour les deux protocoles : Termix ouvre les sessions SSH vers les machines Linux et les sessions de bureau à distance vers les machines Windows. Il tourne sur l’hôte Docker 10.0.30.12, qui devient le bastion unique du lab — un seul point d’entrée, une seule adresse à filtrer, une seule règle à justifier.

Phase 7 — Tests et validation

Le test 7.3 vaut autant que les autres. Un pare-feu qui laisse tout passer « fonctionne » aussi. Ce qui prouve qu’il travaille, c’est un flux refusé, journal à l’appui (Status > System Logs > Firewall). Capture obligatoire.

Phase 8 — Finalisation

La tâche 8.3 est à faire aussi en cours de route, après chaque étape importante. Le fichier XML restaure toute la configuration en une minute. C’est ton filet de sécurité — et c’est un réflexe d’administrateur que le jury remarque.

Phase 9 — Accès distant sécurisé (bonus)

Objectif : joindre le lab depuis n’importe où, sans ouvrir le moindre port entrant sur le réseau de l’établissement.

Solution retenue : Tailscale en subnet router sur pfSense. Un tunnel sortant contourne le NAT de l’établissement ; le mode subnet router expose les réseaux entiers avec un seul nœud enrôlé, au lieu d’un agent par machine.

Validé : depuis le poste de travail, ping 10.0.30.12 répond et ssh [email protected] ouvre une session — sans rebond, sans tunnel manuel, sans port ouvert.

Pourquoi Tailscale sur pfSense et non sur srv-docker : sur le bastion, le SNAT de Tailscale ferait apparaître tout le trafic comme venant de SRV_BASTION — la règle 4 de l’onglet ADM ne l’autoriserait alors qu’en 22/3389. Sur pfSense, le trafic entre directement dans le routeur, avec sa propre interface et ses propres règles.

Décision à assumer : la règle de l’onglet Tailscale fait du tailnet une zone de confiance ayant accès complet au lab. C’est l’objectif, mais c’est une entrée de plus dans la matrice de flux — au même titre que le WAN.

Ce que la phase 9 permet de supprimer (tâche 9.7) : T-1 (allow all sur le WAN), T-2 (admin pfSense depuis le VLAN 40) et T-5 (SSH exposé sur le WAN) deviennent inutiles. Remplacer une exposition par un accès authentifié est un excellent argument de soutenance.

Phase 10 — Haute disponibilité et répartition de charge

Objectif : passer d’une architecture mono-serveur à une architecture redondée. Un cluster Galera à 3 nœuds pour la base, un répartiteur HAProxy devant deux serveurs web.

10.0 — Les trois idées à retenir avant de commencer

Galera n’est pas une machine, HAProxy en est une.

   HAProxy INTERCEPTE le trafic          Galera COORDONNE des serveurs
   ────────────────────────────          ────────────────────────────
   client ─► srv-ha ─► srv-web-01        srv-mysql-01 ◄══╗
                   └─► srv-web-02        srv-mysql-02 ◄══╬══ pair-à-pair
                                         srv-mysql-03 ◄══╝
   il est SUR le chemin                  rien au milieu
   → il lui faut sa propre VM            → AUCUNE VM supplémentaire

Galera est une bibliothèque (libgalera_smm.so) livrée avec mariadb-server et déjà installée. On ne l’installe pas : on l’active par configuration sur chaque nœud.

Le répartiteur RÉDUIT la surface d’accès à la base. Les serveurs web ne joindront plus MariaDB du tout : seul srv-ha le fera. La règle SRV_WEB → SRV_MYSQL devient SRV_HA → GALERA_NODES. Ajouter une couche restreint les autorisations — argument fort.

Répartir ≠ basculer. Le HTTP se répartit vraiment (roundrobin sur les deux serveurs web). Galera, non : deux écritures simultanées sur des nœuds différents provoquent un conflit de certification. La configuration canonique est un basculement — tout va sur le nœud 1, les nœuds 2 et 3 sont déclarés backup.

10.1 — Machines à créer

Convention d’adressage complétée : .1 passerelle · .2–.9 points d’entrée et infrastructure · .10 et au-delà serveurs applicatifs. C’est pourquoi le répartiteur prend le .5 : son rôle se lit dans son adresse.

10.2 — Renommages préalables

10.3 — Pare-feu

Aucune règle n’est nécessaire pour la réplication Galera : les trois nœuds sont dans le même VLAN 20, le trafic est commuté et ne traverse pas pfSense. L’alias PORTS_GALERA est créé pour documenter les ports et servir si les nœuds étaient un jour répartis. C’est un point à expliciter en soutenance, pas à masquer.

10.4 — Cluster Galera

10.5 — HAProxy

10.6 — WordPress et synchronisation

Pourquoi le sens unique, et pourquoi l’épinglage de /wp-admin vont ensemble. lsyncd est unidirectionnel par nature ; synchroniser dans les deux sens crée des boucles. En épinglant toute l’administration sur le nœud 1, on garantit que seul lui écrit des fichiers — exactement la même logique que le « un seul écrivain » de Galera. Les deux décisions se tiennent.

Phase 7 (suite) — Tests de haute disponibilité

Le 7.11 est le test le plus formateur du TP. Avec deux nœuds arrêtés, le survivant refuse délibérément d’écrire au lieu de continuer seul. C’est contre-intuitif : on s’attend à ce qu’un système « tienne » le plus longtemps possible. Or un cluster préfère s’arrêter plutôt que risquer deux moitiés qui divergent — le split-brain. C’est la définition même du quorum, et pouvoir l’expliquer vaut des points.

Le 7.13 n’est pas une redite. Après avoir ajouté trois machines, un répartiteur et assoupli le bind-address, il faut re-prouver que le cloisonnement tient toujours. Vérifier qu’une évolution n’a pas ouvert de brèche, c’est ce que fait un test de non-régression.

Phase 11 — GLPI sur les serveurs web, base dans le cluster Galera (cadrée le 05/11, terminée le 06/11)

Mission « Assistance » de GSB : un outil de gestion de parc et de tickets. Avis du formateur (29/10) : interface via HAProxy et les deux serveurs web, base sur le cluster Galera. Une seconde application sur le même cluster prouve qu’il s’agit d’un service mutualisé. WordPress reste le site public de GSB (étape 64).

Décisions d’Axel (05/11) : GLPI sur srv-web-01/02 (aucune nouvelle VM : l’hyperviseur n’a que 11 Gio libres sur 62) · actif / secours (tout sur srv-web-01, srv-web-02 en relève, fichiers recopiés par lsyncd) · fonctions : parc et tickets, alertes Grafana → tickets, inventaire automatique (agent GLPI). Non retenus pour l’instant : connexion par l’AD, notifications par mail. Faits relevés : Debian 13, Apache 2.4.68, PHP 8.4.24, 2 Gio de RAM par serveur web, MariaDB 11.8.6 ; GLPI 11 demande PHP ≥ 8.2 et MariaDB ≥ 10.6 (compatibilité avec 11.8 À VÉRIFIER).

Phase 12 — Rendre l’infrastructure accessible au formateur, puis aux examinateurs (arrêtée le 05/11 : l’accès Termix du formateur suffit, décision d’Axel)

Étape décidée le 08/10 : que le formateur puisse constater l’infrastructure, et, à terme, que des examinateurs le puissent aussi. Avant la phase 12, le lab n’était joignable que par Axel : le WAN n’accepte aucune connexion entrante, et l’accès distant repose sur un tailnet privé qui est une zone de confiance totale (dette T-6).

Suivi détaillé de cette phase : TP - SISR\Pangolin\SUIVI-PROJET.md (dossier de travail de Pangolin, créé le 14/10). Les tâches 12.x ci-dessous restent la référence ; le zoom les découpe en sous-tâches. La documentation reste celle du TP : étapes 40 à 42, incidents H-17 et H-18, MO-10.

Solution retenue le 13/10 : Pangolin auto-hébergé chez Axel (voir « Décision » plus bas). Les questions du tableau suivant restent utiles pour 12.1 (le besoin réel des publics).

Questions à trancher ensemble

Constats d’Axel et pistes à étudier (12/10) — rien n’est décidé ni construit

Un accès en modification pour un tiers change le risque. Le jury pourrait casser le lab : instantanés Proxmox avant chaque ouverture, comptes dédiés à durée limitée, jamais le coffre Termix ni le registre des mots de passe, et journal des accès.

Phase 13 — Sauvegarde de toute l’infrastructure (cadrée le 14/10, terminée le 06/11)

Sujet ajouté le 09/10 : sauvegarder l’ensemble du lab sur le NAS de l’établissement, qui dispose de beaucoup de place (information d’Axel, non vérifiée). Démarré le 14/10 : Axel met l’accès externe (phase 12) en pause pour ne pas être surpris par une perte de données. Objectif posé par Axel : une sauvegarde complète, automatique et testée.

Ne rien commencer avant d’en avoir parlé ensemble. Ce qui suit pose le contexte et les questions, pas des réponses.

Pourquoi c’est important

Plan PBS arrêté avec Axel (15/10) — réalisé le 15/10 (tâche 13.9)

Constats vérifiés dans le Proxmox de l’école (14/10) (captures d’Axel, connecté en root@pam)

Premier essai : sauvegarde manuelle de srv-web-01 (VM 110), 14/10, journal vzdump d’Axel

Questions à trancher ensemble

Réponses retenues au 15/10 : périmètre = toutes les VM du pool ; pilotage = tâche planifiée par Axel sur son pool ; NAS = Syno (NFS, déjà déclaré) ; outil = Proxmox Backup Server ; chiffrement non retenu ; rétention 7 jours ; restauration testée (VM 136 en vzdump, VM 139 en PBS). Ouvert : la règle 3-2-1 (pas de copie hors site, 13.6), ce qu’on montre le jour de l’épreuve.

Vue d’ensemble du chemin

[1-4] Socle, VLAN, pare-feu ............... 
[5-6] VM et services ......................   tout en service ; reste AD-Core-02 (reporté)
[7]   Tests de validation .................   12 sur 13 (7.1 attend AD-Core-02)
[8]   Finalisation ........................   reste la relecture finale (8.4)
[9]   Accès distant (Tailscale) ........... 
[10]  Haute disponibilité ................. 
[11]  GLPI ................................ 
[12]  Accès externe (Pangolin) ............   arrêtée (Termix suffit)
[13]  Sauvegarde ..........................   restauration depuis la copie hors site prouvée
[14]  Supervision et journaux .............   reste la fin de lab (14.10, 14.11) et 14.1 (dossier)
[15]  Zone « Visiteurs » ..................   reste la qualité de service (après le BTS blanc)
[16]  Wazuh + Suricata ....................   mesure jusqu'au 10/11, puis extension
[17]  LogAnalyzer ......................... 
[18]  Matomo + site en ligne ..............   ← tu es ici (prochaine séance, après l'échange Wazuh/Suricata)
[19]  Portail GLPI des salariés ........... 
[20]  Copie hors site immuable ............ 
[21]  GPO « poste Windows prêt » .......... 
[22]  Mise à jour de tout le lab ........... 

Le TP s’est joué en deux temps. La phase 3 était le premier point de bascule : sans VLAN opérationnels, rien n’était testable. La phase 10 est le second : elle ne construit plus l’infrastructure, elle la rend résiliente.

Ce qui change de nature en phase 10. Jusqu’ici, chaque étape répondait à « est-ce que ça marche ? ». Désormais la question devient « est-ce que ça continue de marcher quand une machine tombe ? ».

C’est un autre métier : on ne vérifie plus qu’un service répond, on vérifie qu’il survit. Les tests 7.7 à 7.13 sont conçus pour ça — ils commencent tous par arrêter quelque chose.

Phase 14 — Supervision, centralisation des journaux et alertes (cadrée le 15/10, en construction depuis le 19/10)

Demandée par le formateur le 15/10 : la solution doit s’appuyer sur le cluster MySQL (Galera). La mission N4 du cours sert d’inspiration (éléments à superviser, agents déployés par script, alertes à plusieurs niveaux, panne provoquée) ; ses livrables ne sont pas remplis ici. Cadrage d’Axel du 02/10 : la supervision fait voir, les journaux font prévoir. Périmètre : le BTS et le lab (OMB hors sujet).

Décisions du cadrage (15/10)

Schéma du projet (provisoire, hors annexes) : LAB\travail\Projet-Supervision.drawio. Il passera dans Infrastructure-TP.drawio une fois le projet construit et testé (14.10).

Points à vérifier en chemin : clés primaires exigées par Galera sur les tables des journaux ; charge d’écriture répliquée ; métriques de pfSense ; outil de transfert des journaux Windows ; compte d’envoi e-mail (secret dans Bitwarden). Disque de srv-mysql-01 relevé le 15/10 (df -h) : 96 Go, 2 Go utilisés, 90 Go libres (les deux autres nœuds, clones, non relevés).

Phase 15 — Zone « Visiteurs » (VLAN dédié) (demandée par Axel le 29/10)

Contexte : GSB a une zone « Visiteurs » (VLAN 150 chez GSB) : invités et visiteurs, accès Internet seul, qui peuvent seulement interroger le DNS et le DHCP. Elle manque au lab. Elle sert à deux réalisations : l’extension qualité de service de la mission N4 (limitation de débit de cette zone, mesures avant et après avec iperf3) et le VPN des visiteurs de la mission N1 (un visiteur n’atteint que l’application). Sources : conventions-gsb §2, lettres de mission N4 et N1 (dossier de rendu). Le VLAN 50 n’est cité nulle part dans la documentation du lab (vérifié le 29/10).

Décisions à confirmer

Validé : une machine du VLAN 50 obtient une adresse, sort sur Internet et se voit refuser toutes les autres zones, journal du pare-feu à l’appui.

La logique à comprendre : c’est le même principe que la zone USERS, en plus fermé. Une zone se définit par ce qu’elle peut atteindre : ici, le DNS, le DHCP et Internet, rien d’autre. La règle de rejet doit précéder la règle de sortie large, sinon elle ne sert à rien (voir la matrice de flux).

Phase 16 — Détection d’intrusion et alerte (demandée par Axel le 30/10 ; cadrée le 02/11 : Wazuh + Suricata)

Objectif : être prévenu d’une intrusion (ou d’une tentative) sur le lab, pas seulement d’une panne. Les alertes de la phase 14 voient les pannes et les rafales de mots de passe faux ; elles ne voient ni une attaque réseau, ni un fichier système modifié, ni un compte créé en douce.

Validé : une attaque simulée (scan de ports, modification d’un fichier système ou création d’un compte, selon l’outil retenu) produit une alerte reçue par mail, preuve à l’appui.

Phase 17 — Journaux bruts en direct : LogAnalyzer (demandée, cadrée et mise en service le 06/11)

Objectif : un écran simple pour voir tous les journaux stockés, bruts et en direct, sans rien chercher, faire des recherches faciles, et repérer ce qui choque pour affiner ou ajouter des règles (filtres rsyslog, Wazuh, alertes Grafana). Grafana reste l’écran central (ce que ses requêtes choisissent) ; LogAnalyzer est la loupe. Limite : le bruit jeté à la source par rsyslog (étape 56) n’arrive jamais en base, LogAnalyzer ne le voit pas.

Validé : depuis le PC d’Axel, les derniers messages des deux sources s’affichent et se rafraîchissent seuls ; un logger de test apparaît en quelques secondes ; poste-win11 est refusé ; le compte loganalyzer ne peut pas lire les tables.

Phase 18 — Mesure d’audience du site de GSB (Matomo), site mis en ligne (demandée le 06/11 par la conversation portfolio, compétence C3 de l’E5 ; montage choisi par Axel ; à démarrer à la prochaine séance)

Objectif : mesurer l’audience du site public de GSB, en conformité RGPD (dispense de consentement selon le guide de la CNIL), avec de vraies visites : le site est mis en ligne par Pangolin. Matomo est une application à part sur les serveurs web (actif / secours, base dans Galera, comme GLPI) : troisième usage du cluster mutualisé.

Validé : des visites réelles venues d’Internet apparaissent dans Matomo avec des adresses anonymisées ; les réglages CNIL sont prouvés ; l’administration de WordPress et de Matomo est refusée depuis Internet.

Phase 19 — Portail GLPI : les salariés de GSB ouvrent eux-mêmes leurs tickets (demandée le 07/11 par la conversation du dossier, compétences C2 et C5 de l’E5 ; ajoutée au suivi le 08/11)

Objectif : aujourd’hui, un ticket GLPI naît d’une alerte (étape 70) ou d’une saisie de l’administrateur ; aucun salarié ne peut en ouvrir. On ouvre l’interface simplifiée de GLPI (profil Self-Service : ouvrir un ticket, le suivre, répondre, rien d’autre), avec si possible la connexion par les comptes du domaine sio.internal.

Validé : un salarié se connecte avec son compte du domaine depuis son poste, ouvre un ticket, le voit traité et clos ; il ne voit rien d’autre de GLPI ; le guide d’une page est écrit.

Phase 20 — Copie hors site immuable (le second « 1 » de 3-2-1-1-0) (arrêtée le 11/11 après l’étude, décision d’Axel : pas de place sur le NAS) (demandée le 08/11 par la conversation du dossier, fiche RP03 ; ajoutée au suivi le 08/11)

Objectif : aujourd’hui, la copie hors site (S3 sur le NAS, étape 65) est en ligne : quelqu’un qui a les clés peut l’effacer, et un rançongiciel aussi. Une copie immuable ne peut pas être supprimée, même avec les clés, tant que sa durée de rétention n’est pas écoulée.

Validé : une suppression faite avec les bonnes clés est refusée pendant la rétention ; les sauvegardes de la nuit continuent sans erreur.

Phase 21 — GPO « poste Windows prêt à l’arrivée sur le domaine » (demandée par Axel le 08/11)

Objectif : aujourd’hui, une nouvelle machine Windows est intégrée à la main en suivant le MO-18 (§5) : exporteur de mesures, journaux, agent Wazuh, agent GLPI, accès SSH par clé, pare-feu. Le but : qu’un poste qui rejoint le domaine et arrive dans la bonne unité d’organisation reçoive tout seul ce qui se pose sur la machine, par des stratégies de groupe (GPO), comme les deux GPO de l’étape 61.

Ce qu’une GPO ne peut pas faire (elle n’agit que sur le poste) : le déclarer dans Prometheus, dans Termix, dans la sauvegarde PBS, dans la note d’adressage. Ces étapes restent côté serveurs (script du bastion ou geste d’Axel).

Validé : une machine Windows qui rejoint le domaine est supervisée, inventoriée et surveillée par Wazuh sans qu’on se connecte dessus ; seule la déclaration côté serveurs reste à lancer.

Phase 22 — Mise à jour de tout le lab (demandée par Axel le 10/11)

Objectif : passer tout ce qui peut l’être à la dernière version stable (systèmes, pare-feu, Windows, applications), sans casser le service : une machine à la fois pour les paires (serveurs web, nœuds Galera), sauvegarde de la nuit vérifiée avant, tableau de production et tests de non-régression après. Reprend aussi le rappel du 27/10 « mettre à jour Grafana et tout ce qui peut l’être ».

Phase 23 — Revue des règles d’alerte : moins de mails, mais les bons (demandée par Axel le 11/11)

Objectif : Axel reçoit beaucoup trop de mails d’alerte. Une alerte qu’on reçoit trop souvent finit par ne plus être lue, et la vraie panne passe inaperçue (« fatigue d’alerte »). On garde la détection, mais chaque mail doit appeler une action. Deux sources envoient des mails : les règles d’alerte de Grafana (17 règles) et Wazuh (toute alerte de niveau 10 ou plus, par exemple les vulnérabilités « High » d’un poste neuf, 11/11).

Phase 24 — Charte informatique de GSB : l’écrire, la faire connaître, contrôler son respect (demande de la conversation du dossier, 11/11 ; preuve E5 C1, fiche RP11)

Validé : tout est à jour (liste des versions avant / après), aucun service interrompu plus que prévu, le tableau de production est vert et les tests de non-régression passent.