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.

---

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/ses VM(s) et lit la source de vérité partagée ma-topologie.yaml (le plan du groupe — une seule et même copie versionnée pour tout le monde).

# Chaque membre, sur SON poste, dans son propre Vagrantfile :
vagrant up            # Membre B lève web · Membre C lève db · Membre D lève soc
                      # (l'AD Windows de C, lui, se monte à la main — TP2)

Pourquoi un fichier par membre (et pas un fichier unique partagé) : la carte à ponter porte un nom local à chaque poste (en0, eth0…) et personne ne fait tourner l’infra entière sur sa machine. Le fichier de chacun décrit donc exactement ce qui tourne chez lui. L’unicité, elle, est portée par ma-topologie.yaml, que tout le monde partage.

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

Ce que votre Vagrantfile doit dire, et pourquoi :

# Votre fichier lit le plan partagé (à la racine du dépôt) et ne définit QUE votre hôte.
require 'yaml'
TOPO = YAML.load_file(File.expand_path('../ma-topologie.yaml', __dir__))
# ... sélectionnez VOTRE hôte (celui dont owner == vous), puis :
#   config.vm.define <short> do |node|
#     node.vm.network "public_network",
#       bridge: "<votre carte>",  # LOCALE à votre poste — VBoxManage list bridgedifs
#       ip:     "<l'IP de votre hôte dans le plan>"   # statique, VOTRE plan
#     node.vm.provider "virtualbox" { |vb| vb.memory = <la RAM du plan> }
#   end

• public_network (pont) : la VM est posée sur la carte physique de votre poste, donc sur le switch. Aucun tag VLAN côté invité : c’est le port access du switch qui place votre VM dans le bon VLAN (§2). Le seul chemin d’une zone à l’autre passera à travers OPNsense (le trunk, §4) — un pare-feu ne filtre que ce qui le traverse.
• Vous ne taguez pas, vous ne pontez pas « à plat » : votre port switch fait la zone. 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).
• 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.
• Déclarez la RAM de votre VM : un Vagrantfile qui ne budgète pas sa RAM n’est pas un plan d’infrastructure.

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, ce n’est plus l’intnet local : c’est que chaque port du switch est dans le bon VLAN. Sans VLAN, le pont est une passoire.

---

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 :

cd server/ingenieurs
./create-opnsense-vm.sh /chemin/OPNsense-25.7-dvd-amd64.iso

OPNsense tient sur le poste du Membre A, dont la carte physique est branchée sur le port trunk du switch. Le script crée une VM vierge à trois cartes (le trunk remplace les 5 pattes intnet du modèle mono-poste) :

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 les VLAN 40·10·50 (sous-interfaces ci-dessous)
NIC4	em3 → opt4	pont RJ45	Transit — TP3 uniquement, absente aujourd’hui

Sur em2 (le trunk), vous créez une sous-interface VLAN par zone — c’est le router-on-a-stick :

Sous-interface (sur em2)	VLAN	Devient	Adresse (passerelle de zone)
VLAN de z-front	(votre n°)	opt1 → z-front	10.G.40.1/24
VLAN de z-services	(votre n°)	opt2 → z-services	10.G.10.1/24
VLAN de z-soc	(votre n°)	opt3 → z-soc	10.G.50.1/24

Installez depuis l’assistant (le mot de passe root est votre secret, hors Git), retirez l’ISO, redémarrez. Puis, dans la GUI : em1 = mgmt (192.168.56.10/24) ; Interfaces ▸ Other Types ▸ VLAN → créez une sous-interface par zone sur le parent em2, avec vos numéros de VLAN (ceux de ma-topologie.yaml) ; Interfaces ▸ Assignments → assignez chaque VLAN en opt1/opt2/opt3 et donnez-lui le .1 de votre plan. em2 lui-même ne porte aucune adresse : il ne fait que transporter les tags. Les numéros doivent être identiques à ceux des ports access du switch — sinon le trafic de zone n’arrive jamais.

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. VBox est réputé retirer les tags 802.1q sur certaines cartes — si c’est votre cas, vos sous-interfaces VLAN 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 : passez la carte physique du poste A en mode promiscuité « Autoriser tout » (VirtualBox ▸ Réseau ▸ Avancé), et à défaut, repli documenté avec l’enseignant (carte USB-Ethernet dédiée par VLAN, ou trunk pris en charge par un mini-switch). 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 les réseaux host-only à 192.168.56.0/21 par défaut. 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) — un geste qui doit rester explicite, jamais au boot : déclarez pour cela un provisioner Vagrant en run: "never", que vous lancez à la demande. 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 patte 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 : simuler PostgreSQL et LDAP en écoute
nc -lk 5432 &
nc -lk 389 &

Puis, depuis z-front, balayez en bash pur (pas de nmap à installer) :

DB=10.G.10.30
for p in 22 389 5432; do
  timeout 2 bash -c "</dev/tcp/$DB/$p" 2>/dev/null \
    && echo "$p  ouvert" || echo "$p  bloqué"
done

Preuve E3 : le balayage « tout ouvert » depuis z-front. Cette photo « avant » est un livrable noté : 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 — le livrable central, jugé 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é ;
• 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 plus 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. Livrable

Un dossier dans le dépôt Git du groupe :

1. Votre Vagrantfile — écrit par vous, IPs de votre plan, RAM budgétée.
2. La matrice d’ACLs justifiée ligne à ligne — le cœur du rendu.
3. L’export config.xml (sans secrets) — la configuration réelle, conforme à la matrice.
4. Le couple de balayages avant/après — E3 (tout ouvert) et E4 (matrice appliquée), côte à côte.
5. La sortie de check-vm.sh sur chaque VM de la base — état validé, fiche produite.

9. 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 rendus, 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.

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.