TP1 — Socle & segmentation : votre infra, votre code

Conception d'architecture Ingénieurs · ESIROI Vagrantfile · OPNsense · default-deny · ~8 h

---

1. Contexte — votre dossier devient une base

Au TP0, votre groupe a rendu un dossier : des zones justifiées, une matrice de flux, un plan d’adressage. Aujourd’hui, ce dossier cesse d’être du papier. Votre groupe est une base australe ; chaque décision du dossier va se câbler, se coder, se prouver — sur vos postes.

Le principe du module tient en une phrase : voici OPNsense et des machines nues — vous écrivez le code qui pose l’infra, vous découpez les zones, vous écrivez les règles. Et l’objectif de sécurité aussi : un attaquant qui compromet le frontal exposé ne doit pas pouvoir se promener dans le SI. C’est ce que vous allez prouver — pas affirmer, prouver.

Le fil rouge du module : si ce n’est pas dans le dépôt, ça n’existe pas

Dès aujourd’hui, tout ce qui se code ou s’exporte vit dans le dépôt Git du groupe : Vagrantfile, matrice, config.xml (sans secrets), notes. Raison de fond : une base isolée doit être reconstructible sans celui qui l’a montée — une panne en hiver austral n’attend pas la prochaine rotation. La preuve arrivera en fin de TP3 : l’épreuve du destroy.

---

Des indices, pas des réponses

Chaque palier dit ce que vous devez obtenir et comment le prouver. Le « comment faire » n’est pas écrit : cherchez, dans la documentation des outils et dans le dépôt server. Si vous bloquez, des blocs Indice repliés vous orientent sans donner la solution. Dans le rapport, listez les indices que vous avez ouverts : sans malus, c’est une information honnête sur votre autonomie.

2. L’architecture cible — 3 zones réparties sur 4 postes

Le SI de la base est découpé en 3 zones derrière un unique pare-feu OPNsense à état, plus mgmt, le plan d’administration (le réseau depuis lequel le pare-feu s’administre — ce n’est pas une zone du SI).

Zone	VLAN	Rôle	Ce qui y tournera (TP2)	Subnet — votre plan	Hébergé par
z-front	(votre n°)	Zone exposée (DMZ)	Caddy + Nextcloud — seule zone joignable du WAN	10.G.40.0/24	Membre B
z-services	(votre n°)	Le précieux	AD Windows (LDAP/DNS) + PostgreSQL — ne sort jamais vers Internet	10.G.10.0/24	Membre C
z-soc	(votre n°)	Le plan d’analyse	Grafana + Loki — cul-de-sac : tout pousse vers lui, il ne sort nulle part	10.G.50.0/24	Membre D
mgmt	—	Plan d’admin	Rien : le poste OPNsense administre la GUI en local	192.168.56.0/24 (imposé — voir §4)	Membre A

G = le numéro de votre groupe (groupe 3 → 10.3.40.0/24, etc.). Ce n’est pas un caprice : au TP3, deux bases s’interconnectent — et deux réseaux identiques ne s’interconnectent pas. Votre plan d’adressage du TP0 devait être disjoint du voisin ; maintenant vous savez pourquoi.

Les numéros de VLAN sont VOTRE décision — inscrivez-les dans ma-topologie.yaml

Comme votre plan d’adressage, vous choisissez vos IDs de VLAN (un par zone). Contraintes réelles à respecter :

• distincts entre zones, dans l’intervalle 2–4094 (évitez le VLAN 1, souvent le natif du switch) ;
• identiques sur les trois points qui doivent s’accorder : le port access du membre, les VLAN autorisés du trunk d’OPNsense, et la sous-interface OPNsense de la zone (§4) — une incohérence là est la panne n°1 ;
• contrairement aux subnets, les VLAN sont locaux à votre switch : ils n’ont pas besoin d’être disjoints du groupe voisin.

Repère pratique (facultatif) : caler l’ID sur le 3e octet du subnet (subnet …40.0/24 → VLAN 40) rend le plan lisible d’un coup d’œil — mais c’est votre choix, pas une règle.

La base est distribuée sur vos 4 postes ESIROI

Vous êtes 4 dans le groupe et vous n’assemblez pas tout sur une seule machine : chaque membre héberge une part de l’infra sur SON poste ESIROI (VirtualBox), et les postes se relient par le switch managé de la salle. La segmentation n’est donc plus locale à une machine — elle se fait par VLAN 802.1Q sur le switch.

Membre	Tient	Sur son poste (VirtualBox)	Port du switch
A — Réseau	OPNsense (pare-feu, routage, règles, transit TP3)	1 VM appliance montée à la main	trunk (vos 3 VLAN)
B — Front	TAAF-WEB-001 (Caddy + Nextcloud)	Vagrant	access — VLAN de z-front
C — Identité & données	TAAF-AD-001 (AD Windows) + TAAF-DB-001 (PostgreSQL)	AD à la main + Vagrant	access — VLAN de z-services
D — SOC	TAAF-MON-001 (Grafana + Loki)	Vagrant	access — VLAN de z-soc

Le piège 802.1q — pourquoi les postes membres sont en access, pas en trunk

VirtualBox retire les tags VLAN sur un pont dans beaucoup de configurations. Si chaque membre taguait ses trames côté invité, elles arriveraient nues sur le switch. La parade : le switch fait tout le travail VLAN. Le port de chaque membre est un port access (untagged) placé dans le VLAN de sa zone — ses VMs se bridgent normalement, sans aucun tag côté invité. Seul le poste A (OPNsense) est sur un port trunk : c’est là, et là seulement, que vivent les tags, et c’est OPNsense qui les sépare en sous-interfaces (§4). À tester tôt : voir l’encart « router-on-a-stick » du §4.

Les invariants — ce que votre architecture doit rendre vrai

1. Règle d’or — z-front n’atteint z-services que sur les flux nominatifs de ses applications (la base de Nextcloud, l’annuaire) ; tout le reste tombe.
2. Isolement du SOC — un seul port entre dans z-soc : l’ingestion Loki (3100). Rien n’en sort. Compromis, le SOC n’est pas un pivot.
3. Egress — z-services et z-soc ne sortent pas vers le WAN : anti-exfiltration.
4. Default-deny — la dernière règle de chaque interface est block log : le refus est une donnée de détection.

Le sens de l’invariant SOC

Loki vit dans z-soc et ce sont les zones qui poussent leurs journaux vers lui (un agent par machine, au TP2). Un collecteur qui tirerait les logs depuis le SOC créerait des flux SOC → zones — et violerait « rien n’en sort ». Le mode de collecte n’est pas un détail d’outillage : c’est l’invariant qui le dicte.

---

3. Palier E1 : votre Vagrantfile (chacun le sien)

C’est le livrable IaC du module : vous l’écrivez, de zéro. Le dépôt ne fournit pas de squelette clé en main, seulement des indications (Vagrantfile.skel : une checklist commentée, rien de copiable-collable). Comme chaque membre héberge sa part sur son propre poste, chacun écrit SON Vagrantfile, qui ne définit que sa VM et lit la source de vérité partagée ma-topologie.yaml (le plan du groupe, une seule copie versionnée pour tout le monde).

Ce que votre Vagrantfile doit obtenir, à vous de trouver comment :

• votre VM est posée sur la carte physique de votre poste, donc sur le switch, sans aucun tag VLAN côté invité : c’est le port access du switch qui la place dans sa zone (§2) ;
• elle porte l’IP statique de votre plan, lue dans ma-topologie.yaml, pas écrite en dur ;
• sa RAM est budgétée : un Vagrantfile qui ne budgète pas sa RAM n’est pas un plan d’infrastructure ;
• zone ≠ hôte : la zone est un réseau (un VLAN), l’hôte est une machine (TAAF-WEB-001). Les deux ne portent jamais le même nom.

Organisation du dépôt de groupe

Vagrant cherche un fichier nommé exactement Vagrantfile : deux membres ne peuvent donc pas avoir le leur au même endroit. Chacun travaille dans son sous-dossier du dépôt Git du groupe, et tous pointent vers le même plan à la racine :

depot-groupe/
├── ma-topologie.yaml        ← la source de vérité, partagée (racine)
├── membre-B-front/Vagrantfile   → lève web
├── membre-C-services/Vagrantfile → lève db
└── membre-D-soc/Vagrantfile     → lève soc

Chacun cd dans son dossier puis vagrant up. Rien de ce qui tourne n’existe hors du dépôt (fil rouge reproductibilité).

Indice : par où chercher

• Vagrant sait poser une VM en pont sur une carte de l’hôte, désignée par son nom, et lui fixer une adresse. Le nom de la carte est local à votre poste : VBoxManage list bridgedifs vous le donne.
• Un Vagrantfile est du Ruby : lire un fichier YAML et y choisir l’entrée dont le champ owner est vous tient en quelques lignes.
• Le fournisseur VirtualBox se configure dans un bloc dédié, c’est là que se déclare la mémoire.

Preuve E1 : chaque membre fait vagrant up sans erreur sur son poste ; vagrant ssh répond ; chaque Vagrantfile est commité (et tous lisent le même ma-topologie.yaml).

Chacun lance check-vm.sh sur sa VM et partage la fiche

Une fois vagrant ssh fait, lancez ../check-vm.sh (à la racine du dépôt server) dans votre VM. Il valide l’état du déploiement (hostname attendu, compte taaf-engineer, Docker, binaires) et produit une fiche (rôle, IP, conteneurs, ports) à copier-coller au groupe : c’est ce qui permet à chacun de se câbler entre postes.

Le vrai piège ici : le pont « à plat » (sans VLAN)

« Je ponte mes VMs sur ma carte, tout le monde se voit sur le switch. » S’ils se voient tous sur un même VLAN, c’est exactement le problème : un seul segment L2, des échanges MAC à MAC entre zones, et un pare-feu qui ne voit rien passer. Vos règles seraient parfaitement écrites et parfaitement contournées. Ce qui sauve l’architecture, c’est que chaque port du switch est dans le bon VLAN. Sans VLAN, le pont est une passoire. Vérifiez avec l’enseignant que votre port est bien dans votre VLAN avant de vous étonner d’un flux qui passe (ou ne passe pas).

---

4. Palier E2 : le pare-feu existe

OPNsense s’installe à la main, depuis l’ISO officielle : c’est une appliance, son installation est un geste d’ingénieur, pas de la plomberie. Le dépôt fournit seulement la VM vierge, câblée pour le modèle distribué :

cd server/ingenieurs
./create-opnsense-vm.sh --trunk <carte> /chemin/OPNsense-25.7-dvd-amd64.iso   # <carte> = VBoxManage list bridgedifs

OPNsense tient sur le poste du Membre A, dont la carte physique est branchée sur le port trunk du switch. La VM a trois cartes aujourd’hui, une quatrième au TP3 :

Carte VBox	OPNsense	Rattachement	Usage
NIC1	em0 → wan	NAT	Sortie Internet
NIC2	em1 → lan	host-only	mgmt : GUI depuis le poste A, anti-lockout
NIC3	em2	pont sur le trunk	Porte vos trois VLAN de zones
NIC4	em3 → opt4	pont sur un adaptateur USB vers RJ45	Transit, TP3 uniquement, absente aujourd’hui ; l’adaptateur se demande à l’enseignant

Ce que vous devez obtenir : em1 est votre plan d’administration en 192.168.56.10/24 ; sur em2, une interface par zone, chacune à votre numéro de VLAN et portant le .1 de votre plan ; em2 lui-même ne porte aucune adresse. Le mot de passe root est votre secret, hors Git.

Indice : router-on-a-stick sous OPNsense

• Une seule carte physique peut porter plusieurs réseaux logiques : cherchez, dans le menu Interfaces, le type d’interface qui se crée sur un parent avec un numéro d’étiquette. Chaque interface créée s’assigne ensuite comme n’importe quelle carte.
• Les trois numéros doivent être identiques au switch (port access du membre) et à OPNsense, sinon le trafic de zone n’arrive jamais.
• Le parent transporte les étiquettes, il n’a pas besoin d’adresse.

router-on-a-stick : le test qui doit passer AVANT d’écrire une seule règle

Tout le modèle distribué repose sur une hypothèse : les trames taguées du switch traversent le pont VirtualBox jusqu’à OPNsense. Certains pilotes de carte hôte retirent les tags 802.1Q ; si c’est votre cas, vos interfaces de zone ne verront jamais un paquet. Testez-le tôt : une VM par zone allumée (§3), depuis OPNsense (Diagnostics ▸ Ping, source = l’interface de zone) pinguez l’hôte de la zone (10.G.40.10, etc.). Si les trois pings passent, votre trunk est bon. Si un VLAN reste muet : regardez d’abord côté pilote de la carte du poste A (filtrage VLAN à désactiver), puis le mode promiscuité de la carte pontée dans VirtualBox ; à défaut, repli documenté avec l’enseignant (carte USB vers RJ45 par VLAN, ou mini-switch qui porte le trunk). Ne débuggez pas une règle de pare-feu tant que ce ping ne passe pas.

Pourquoi mgmt n’est pas dans votre 10.G : contrainte d’hyperviseur, VirtualBox restreint ses réseaux host-only à 192.168.56.0/21 par défaut sur Linux et macOS. Effet de bord sain : le plan d’admin se distingue visuellement du SI segmenté. Et mgmt doit être host-only : c’est le seul rattachement qui remonte jusqu’au poste A pour joindre la GUI.

Preuve E2 : « Câblage vérifié » affiché par le script, les trois pings de zone qui passent (router-on-a-stick validé), et la GUI joignable depuis le poste A sur https://192.168.56.10.

---

5. Palier E3 : le réseau à plat est mesuré

Basculez la route par défaut de chaque VM vers la patte OPNsense de sa zone (le .1 de votre plan). Ce geste doit rester explicite, jamais au boot : tant qu’il n’est pas joué, la VM sort par le NAT (pratique pour installer) ; une fois joué, tout traverse le pare-feu. Posez alors sur chaque interface de zone la politique naïve, tout passe, et mesurez.

Les services réels arrivent au TP2. Pour mesurer aujourd’hui, posez des témoins : un port en écoute là où votre matrice prévoit un service (sur TAAF-DB-001, ce que votre matrice prévoit pour la base de données et l’annuaire). Puis, depuis z-front, balayez ces ports en bash pur, sans rien installer, en distinguant ce qui répond de ce qui ne répond pas.

Indice : témoins et balayage sans outil

• nc sait écouter sur un port et y rester (-l, -k) ; sous 1024, il faut sudo, sinon le témoin n’existe pas et vous mesurerez un « bloqué » qui n’en est pas un.
• Vagrant sait déclarer un provisioner qui ne se lance qu’à la demande (run: "never"), c’est le bon endroit pour le changement de route.
• bash sait ouvrir une connexion TCP sans aucun binaire : cherchez /dev/tcp. Avec timeout, vous saurez faire la différence entre un port qui refuse tout de suite et un port dont la réponse ne vient jamais.

Preuve E3 : le balayage « tout ouvert » depuis z-front. Cette photo « avant » est une preuve notée du rapport : un pare-feu se juge à la différence qu’il produit ; sans « avant », votre « après » ne prouvera rien. C’est aussi l’état de la plupart des SI réels que vous rencontrerez.

---

6. Palier E4 : default-deny posé, matrice écrite

Votre matrice de flux du TP0 devient la matrice d’ACLs du pare-feu, la pièce centrale du chapitre TP1, jugée ligne à ligne :

• Les règles s’écrivent sur l’interface source ; premier match gagne : l’ordre est une décision ;
• Le filtrage est à état : les retours d’une connexion autorisée sont implicites ;
• La dernière règle de chaque interface est block log any : le default-deny, journalisé et nommé ;
• Chaque ligne porte une justification métier. Une ligne que vous ne savez pas justifier est une ligne à supprimer.

Vous écrivez la matrice avant d’installer les services (TP2). C’est voulu : la sécurité se spécifie, les services s’y conforment. Si le TP2 exige un flux imprévu, vous amenderez la matrice en justifiant l’amendement, c’est exactement la gestion de changement d’une vraie infra.

Preuve E4 : le même balayage qu’en E3 → seuls les témoins autorisés par votre matrice répondent ; le reste traîne puis tombe (filtré ≠ fermé : le pare-feu a mangé le paquet, la réponse ne vient jamais). Et dans Firewall ▸ Log Files ▸ Live View, vos refus apparaissent, nommés : le refus est une donnée.

---

7. Palier E5 : l’architecture est vérifiée

Il n’y a pas de harnais qui sonde votre réseau à votre place : la preuve d’invariants, c’est le balayage bash « après » de l’étape E4, celui qui montre que seuls les flux autorisés par votre matrice répondent. C’est cette photo, comparée à la photo « tout ouvert » de l’E3, qui est la preuve notée du cloisonnement.

Déclarez vos zones et IPs dans ma-topologie.yaml (gabarit fourni, la déclaration que lit votre Vagrantfile), puis, dans chaque VM, validez l’état du déploiement :

../check-vm.sh

check-vm.sh vérifie l’état local de la VM (hostname attendu, compte taaf-engineer + groupes, démon Docker actif, binaires installés) et produit la fiche à partager avec le groupe. Il ne teste pas le cloisonnement inter-VM, ce n’est pas son rôle : le cloisonnement se prouve avec les balayages bash de l’E3/E4.

Preuve E5 : check-vm.sh passe (code 0) sur chaque VM de la base, et le couple de balayages E3/E4 est cohérent avec votre matrice. Puis exportez la configuration OPNsense (System ▸ Configuration ▸ Backups) et commitez config.xml, après en avoir retiré les secrets (le TP3 en fera une épreuve).

---

8. Le rapport : chapitre TP1

Vous ne rendez aucun fichier : ni Vagrantfile, ni config.xml. Ils vivent dans votre dépôt Git, c’est votre outil, pas le livrable. Ce qui est corrigé, c’est le chapitre TP1 de votre rapport de réalisation, au plan commun. Les preuves à coller, chacune légendée, hostname et date lisibles :

1. Vos sous-interfaces VLAN : capture Interfaces ▸ Assignments d’OPNsense : les trois zones sur em2, avec vos numéros de VLAN et vos passerelles .1.
2. Les trois pings de zone : le test router-on-a-stick qui passe (Diagnostics ▸ Ping depuis chaque interface de zone).
3. Le couple de balayages avant/après : E3 (tout ouvert) et E4 (matrice appliquée), côte à côte, depuis z-front, avec l’IP cible visible.
4. La matrice d’ACLs : sous forme de tableau dans le rapport, justifiée ligne à ligne ; et une capture de Firewall ▸ Rules d’une interface de zone montrant le block log final.
5. Un refus nommé : capture du Live View montrant un paquet bloqué par votre default-deny, horodaté.
6. check-vm.sh au vert : une capture par VM de la base, hostname visible.
7. Un extrait de votre Vagrantfile : 20 lignes maximum : la lecture de ma-topologie.yaml et la définition de votre VM.

9. Les dix questions

De la plus facile à la plus difficile. Chaque réponse cite une valeur relevée dans vos captures. Barème : le rapport.

● Facile : relever, nommer, constater

1. Q1 : Relevez dans votre capture Interfaces ▸ Assignments le nom de la sous-interface, le numéro de VLAN et l’adresse .1 de votre z-front.
2. Q2 : Dans votre balayage « avant » depuis z-front, quels ports ont répondu « ouvert » sur TAAF-DB-001 ? Recopiez la sortie, IP comprise.
3. Q3 : Quelle est la dernière règle de chacune de vos interfaces de zone ? Donnez l’horodatage d’un refus qu’elle a produit dans votre Live View.

●● Moyen : expliquer, justifier, relier

4. Q4 : Pourquoi chaque membre écrit-il son Vagrantfile qui lit ma-topologie.yaml, plutôt qu’un Vagrantfile unique partagé ? Deux raisons, dont une propre à votre poste (nom de carte, RAM).
5. Q5 : « Filtré ≠ fermé » : dans vos deux balayages, quelle différence de comportement observez-vous pour un port bloqué (temps de réponse, message), et que dit-elle de ce que fait le pare-feu du paquet ?
6. Q6 : Le filtrage est à état. Prenez une ligne de votre matrice et expliquez pourquoi vous n’avez pas écrit de règle pour le trafic de retour. Que se passerait-il sur un pare-feu sans état ?
7. Q7 : Pourquoi mgmt est-il en 192.168.56.0/24 et pas dans votre 10.G ? Nommez la contrainte d’hyperviseur, puis dites en quoi c’est finalement une propriété utile du plan d’administration.

●●● Difficile : arbitrer, prouver, généraliser

8. Q8 : Prenez trois lignes de votre matrice d’ACLs sur une même interface. Montrez si inverser l’ordre de deux d’entre elles change le comportement, et pourquoi (« premier match gagne »). Donnez un cas où l’ordre est indifférent, et un cas où il ne l’est pas.
9. Q9 : Si le pont VirtualBox du poste A avait retiré les tags 802.1Q, décrivez précisément ce que vous auriez observé au test router-on-a-stick (quels pings, quel symptôme dans OPNsense), et la parade que vous avez ou auriez appliquée. Appuyez-vous sur votre capture des pings de zone.
10. Q10 : Un attaquant tient TAAF-WEB-001. À partir de votre balayage « après », listez tout ce qu’il peut encore joindre, zone par zone, et dites si l’invariant « le SOC n’est pas un pivot » tient. Si un flux vous semble de trop, dites lequel et pourquoi vous l’avez gardé.

10. Critères de réussite

Critère	Ce qu’on vérifie
Le Vagrantfile est le vôtre	Il pose vos 3 zones à vos adresses 10.G.x ; vagrant destroy -f && vagrant up le rejoue sans retouche.
Les 3 zones existent	Chaque zone sur sa patte, chaque hôte à l’IP de votre plan.
Les invariants tiennent	Balayage bash « après » (E4) : seuls les flux autorisés répondent.
Chaque VM est validée	check-vm.sh passe sur chaque VM ; la fiche a été partagée au groupe.
La matrice est construite, pas récitée	Justifications métier, pas de « any → any », l’ordre des règles est assumé.
Le refus est une donnée	Les block log sont visibles dans le Live View.
La photo avant/après existe	Les deux balayages collés dans le rapport, côte à côte.

Deux groupes peuvent rendre deux matrices différentes et réussir tous les deux. Ce qui est noté : les invariants tiennent, et vous savez dire pourquoi chaque ligne existe — c’est ce que mesurent les dix questions.

La suite — TP2

Vos zones sont cloisonnées mais vides : des témoins nc y singent des services. Au TP2, les vrais arrivent — l’AD Windows, PostgreSQL, Nextcloud, la supervision — et votre matrice écrite aujourd’hui va rencontrer la réalité de leurs flux.

---

Récapitulatif — ce qu’il vous faut pour démarrer

• Un poste x86_64 (Apple Silicon : bloqué — aucun invité x86 sur ARM), 32 Go de RAM, ~80 Go de disque, VT-x/AMD-V actif.
• VirtualBox + Vagrant aux versions épinglées du dépôt.
• Le dépôt server cloné, l’ISO OPNsense téléchargée, le dépôt Git du groupe créé.
• Votre dossier TP0 sous les yeux : matrice et plan d’adressage sont vos brouillons directs.