Setup de l'environnement

Auteur : Thibaut Fontaine — Kodetis Dernière mise à jour : 2026

---

Introduction

Cette page prépare l’environnement complet des TP TAAF : vous démarrez les VMs (cœur puis labs bonus) au fur et à mesure des actes, via Vagrant (environnement identique et reproductible). Une golden box préprovisionnée existe côté instructeur : elle sert à valider les énoncés, et de dépannage si une machine refuse de se monter — ce n’est pas une alternative au travail de montage.

Architecture du poste

Le parcours est conçu pour des postes x86_64 (Windows, VirtualBox). Sur Mac Apple Silicon, Vagrant passe par QEMU (§2) : l’Acte 1 fonctionne, mais les VMs ne se voient pas entre elles — prévoyez un poste x86 dès l’Acte 2 (voir l’encart plus bas).

---

1. Architecture & inventaire

Modèle crescendo : on ajoute des VMs acte après acte, toutes sur le même sous-réseau privé (relevez les IP avec hostname -I — notées IP_VM1, IP_VM2, IP_VM3 dans les TPs). L’inventaire ci-dessous est votre point d’entrée unique — VMs cœur + labs bonus.

VM / Lab	Hostname	Acte · TP	RAM	Déploiement	Type
monitoring	TAAF-MONITORING-001	Acte 1	6 GB	vagrant up monitoring	cœur
soc	TAAF-SOC-001	Acte 2	3 GB	vagrant up soc	cœur
apps	TAAF-APPS-001	Acte 1 (observée) · Acte 2 (source SIEM) · Acte 3 (auditée)	4 GB	vagrant up apps	cœur
audit	TAAF-AUDIT-001	Acte 3 (la toolbox qui audite)	2 GB	vagrant up audit	cœur
concordia (Zabbix proxy)	TAAF-CDA-001	Acte 1 · TP6/TP7	2 GB	vagrant up concordia	bonus
Zabbix Server	sur monitoring	Acte 1 · TP6/TP7	(incl.)	stack Docker zabbix-server-lab	bonus
Active Directory (DC)	TAAF-AD-001	Acte 2 · Acte 3	~4 GB	VM Windows manuelle + scripts PS	bonus
Wazuh	sur soc	Acte 2	+4 GB	stack Docker sur la VM soc	bonus

• À l’intérieur de chaque VM Linux, les services tournent en conteneurs Docker.
• Vous accédez aux services depuis votre navigateur via l’IP de la VM (ex. http://IP_VM1:3000 pour Grafana), ou via Caddy (*.univ-taaf.internal, bonus).

Le réseau, c’est à vous

Plusieurs VMs se parlent par IP : apps pousse ses logs vers Loki et expose ses exporters à Prometheus (VM monitoring), soc joint Loki/Grafana de monitoring, audit scanne apps. Tout repose sur la connectivité réseau entre VMs. Relevez les IP (hostname -I) et n’utilisez jamais localhost/127.0.0.1 pour joindre une autre VM.

---

2. Logiciels requis

Le provider de virtualisation dépend de l’architecture de votre machine.

Vagrant (toutes plateformes)

OS	Installation
Windows	vagrantup.com
macOS	brew install vagrant
Linux (Debian/Ubuntu)	sudo apt install vagrant

vagrant --version   # Vagrant 2.4.x

Provider — Windows / Linux / Mac Intel (x86_64)

Vous utilisez VirtualBox.

OS	Installation
Windows	virtualbox.org
Linux (Debian/Ubuntu)	sudo apt install virtualbox
macOS Intel	brew install --cask virtualbox

Version minimale

VirtualBox 7.0 ou supérieur. Vérifiez avec vboxmanage --version.

Windows : installer côté Windows, piloter depuis WSL

C’est le flux de travail du module sur les postes Windows : VirtualBox et Vagrant s’installent côté Windows (ce sont eux qui font tourner les VMs), et vous les pilotez depuis votre terminal WSL grâce à un alias. Une seule installation de Vagrant — jamais un second Vagrant dans WSL (apt install vagrant) : deux Vagrant, deux états, et plus rien ne se comprend.

1. Côté Windows — installez VirtualBox puis Vagrant (installeur .msi). Redémarrez si l’installeur le demande.

2. Côté WSL (Ubuntu) — ajoutez à votre ~/.bashrc ou ~/.zshrc :

   # Vagrant et VirtualBox sont ceux de Windows : on les appelle via leurs .exe
   alias vagrant='vagrant.exe'
   alias VBoxManage='VBoxManage.exe'
   export PATH="$PATH:/mnt/c/Program Files/Oracle/VirtualBox"

   puis source ~/.bashrc (ou rouvrez le terminal).

3. Le projet vit sur le disque Windows — clonez sous /mnt/c/…, jamais dans le système de fichiers Linux de WSL (~), sinon vagrant.exe ne voit pas vos fichiers :

   mkdir -p /mnt/c/taaf && cd /mnt/c/taaf
   git clone https://gitlab.com/kds-formation/server.git
   cd server/but/manual

4. Vérifiez depuis WSL :

   vagrant --version      # Vagrant 2.4.x  (c'est vagrant.exe qui répond)
   VBoxManage --version   # 7.x

Ce que fait l’alias, et ce qu’il ne fait pas

vagrant.exe tourne côté Windows : il lit le Vagrantfile par son chemin Windows (C: aaf\…), crée les VMs dans VirtualBox Windows, et vagrant ssh utilise le client OpenSSH de Windows. Vous gardez votre shell, vos outils et votre git dans WSL — c’est tout l’intérêt. Aucun plugin Vagrant n’est nécessaire pour VirtualBox.

Hyper-V / WSL2 et VirtualBox cohabitent — au prix de la vitesse

WSL2 repose sur l’hyperviseur Windows. VirtualBox 7 sait tourner à côté (il passe par la plateforme d’hyperviseur Windows — icône « tortue » dans la VM), mais les VMs sont nettement plus lentes. C’est le compromis normal du module : on garde WSL2. Si une VM refuse de démarrer (VT-x is not available), vérifiez d’abord le BIOS (VT-x / AMD-V activé) — voir le dépannage §9.

Provider — Mac Apple Silicon (M1/M2/M3/M4 — arm64)

VirtualBox ne convient pas sur Apple Silicon. Vous utilisez QEMU + le plugin vagrant-qemu.

# 1. QEMU
brew install qemu

# 2. Plugin Vagrant pour QEMU
vagrant plugin install vagrant-qemu

qemu-system-aarch64 --version   # QEMU 8+ (idéalement 9+)
vagrant plugin list             # doit lister vagrant-qemu

Détection automatique

Le Vagrantfile détecte votre architecture (uname -m) et choisit automatiquement le bon provider. Vous n’avez rien à préciser.

Apple Silicon : les VMs ne se voient pas entre elles

Le plugin QEMU ne fournit pas de réseau privé entre VMs : chaque VM n’a que son NAT. Or dès l’Acte 1 deux VMs doivent se joindre — Prometheus (monitoring) scrape les exporters d’apps et Alloy (apps) pousse vers Loki (monitoring) — puis la VM soc qui pousse vers Loki (Acte 2) et la VM audit qui scanne apps/monitoring (Acte 3). Il vous faut donc un poste x86 (VirtualBox), ou un binôme équipé. Anticipez-le : ne découvrez pas cette limite le jour de l’Acte 1.

Active Directory = x86 uniquement

La VM Active Directory (Windows Server, bonus Acte 2/3) ne tourne que sur x86_64 (VirtualBox). Sur Apple Silicon, utilisez un poste x86 pour cette partie.

---

3. Récupérer l’infra

git clone https://gitlab.com/kds-formation/server.git
cd server/but/manual

Les VMs Linux sont nues : Ubuntu + git, docker, curl, et deux comptes — vagrant (celui de vagrant ssh, ne le supprimez jamais : c’est votre accès de secours) et taaf-engineer, votre compte d’exploitation (sudo + docker), créé par le bootstrap. Pour lui donner un mot de passe, passez-le au premier vagrant up : TAAF_USER_PASSWORD='VotreSecret' vagrant up monitoring — sinon le compte est verrouillé et vous y entrez par vagrant ssh monitoring puis sudo -iu taaf-engineer. Le mot de passe est le vôtre, il n’est écrit nulle part. Aucun service n’est pré-installé — vous les déployez vous-même en installation des services.

---

4. VMs cœur — démarrage par acte

On démarre uniquement la VM dont l’acte en cours a besoin.

# Acte 1 — Monitoring (SI observé + observabilité)
vagrant up apps          # applications observées (PostgreSQL, NextCloud)
vagrant up monitoring    # observabilité (Grafana, Prometheus, Loki)

# Acte 2 — SIEM (VM nue, à monter soi-même)
vagrant up soc

# Acte 3 — Audit / Purple Team
vagrant up audit

Au premier lancement, Vagrant télécharge la box de base puis installe Docker. Les lancements suivants sont quasi instantanés.

graph TB
 subgraph NET["Réseau privé commun (IP relevées par l'étudiant)"]
 APPS["taaf-apps-001 · IP_APPS<br/>SI observé<br/>PostgreSQL · NextCloud · exporters · Alloy"]
 VM1["taaf-monitoring-001 · IP_VM1<br/>Observabilité<br/>Grafana · Prometheus · Loki · Alertmanager"]
 VM2["taaf-soc-001 · IP_VM2<br/>SOC Grafana-natif<br/>Falco · Suricata · Sigma · Alerting"]
 VM3["taaf-audit-001 · IP_VM3<br/>Toolbox audit"]
 APPS -->|"Alloy pousse les logs · Prometheus scrape"| VM1
 VM2 -->|"détections vers Loki (VM monitoring)"| VM1
 VM3 -->|"scanne / audite"| APPS
 end
 BROWSER["Navigateur étudiant"] -->|"Grafana 3000"| VM1
 DISCORD(["Discord"])
 VM2 -->|"alertes par sévérité"| DISCORD

Ressources des VMs cœur

VM	RAM	CPU	Services	Statut
monitoring	6 GB	2	SI observé (PostgreSQL base_af, NextCloud) + observabilité (Grafana, Prometheus, Loki, Alloy, cAdvisor)	✅ à déployer
soc	3 GB	2	SOC Grafana-natif (Falco/Suricata/Sigma/Alerting)	🚧 monté par l’étudiant (Acte 2)
apps	4 GB	2	Applications (PostgreSQL, NextCloud…) : observées (A1), source du SIEM (A2), cible d’audit (A3)	✅ à déployer
audit	2 GB	2	Toolbox d’audit qui scanne apps (nmap, lynis, syft, grype…)	✅ à déployer

---

5. VMs / labs bonus

Ces labs étendent l’environnement pour les TPs avancés. Démarrez-les uniquement quand le TP correspondant le demande, et selon les ressources de votre machine.

Zabbix — supervision SNMP (Acte 1 · TP6/TP7)

Deux briques : le serveur Zabbix (sur monitoring) et un proxy SNMP sur la VM bonus concordia (Dôme C, derrière le lien Inmarsat BGAN).

# 1. La VM proxy Concordia (Zabbix Proxy + snmpsim)
vagrant up concordia
vagrant ssh concordia
git clone https://gitlab.com/kds-formation/zabbix-lab.git
cd zabbix-lab/zabbix-proxy-lab && make up

Le serveur Zabbix se monte sur la VM monitoring depuis le même dépôt (zabbix-lab/zabbix-server-lab, console sur le port 8080). La console SCADA du lab Concordia est exposée sur http://localhost:3001.

Active Directory — DC Windows (Acte 2 · SIEM Windows + Acte 3 · audit AD)

Un contrôleur de domaine Windows Server TAAF-AD-001, domaine univ-taaf.internal.

Hors flux Vagrant

Cette VM Windows est installée manuellement (Windows Server, x86 uniquement), puis provisionnée par les scripts PowerShell du repo active-directory : Install-AD-DNS-Fixed, Create-OU-TAAF, Create-Groups, Creat-user, Create-Admin-Users, Create-Service-Accounts, Configure-AuditPolicy.

Elle sert à deux moments :

• Acte 2 — intégration des journaux Windows/AD dans le SIEM (events 4624, 4728, 4698…).
• Acte 3 — audit Active Directory (PingCastle, BloodHound).

Wazuh — HIDS (bonus Acte 2)

Stack Docker bonus déployée sur la VM soc, avec un agent à installer sur l’AD (installeur Wazuh officiel — le script n’est pas fourni).

Ressources machine

Wazuh ajoute ~4 GB (JVM OpenSearch) à la VM soc. Ne l’activez que sur une machine confortable. Si votre machine est limitée, arrêtez une VM (vagrant halt <machine>) avant d’en démarrer une autre.

---

6. Accès aux services

L’accès se fait par l’IP de la VM depuis votre navigateur.

Service	VM	URL	Identifiants
Grafana	monitoring	http://IP_VM1:3000	admin / AdminTAAF2024!
Prometheus	monitoring	http://IP_VM1:9090	—
PostgreSQL base_af	apps	IP_APPS:5432	taaf_admin / AdminTAAF2024!
Adminer	apps	http://IP_APPS:8080	—
NextCloud	apps	http://IP_APPS:8081	(voir TP)
Zabbix (serveur)	monitoring	http://IP_VM1:8080	(voir TP6)
Grafana (SOC)	soc	http://IP_VM2:3000	admin / (voir TP)
Console lab Concordia	concordia	http://localhost:3001	—

Pour la toolbox d’audit, entrez dans le conteneur :

vagrant ssh audit
docker exec -it taaf-audit-toolbox bash

---

7. Vérification — l’état attendu avant la Phase 3

À la fin de la Phase 1-2, vos VMs sont créées et nues : Ubuntu + Docker + les deux comptes, aucun service déployé (les services, c’est la Phase 3). Vérifiez exactement ça — ni plus, ni moins.

# 1. Les VMs cœur existent et tournent (au moins apps + monitoring)
vagrant status
#   apps        running (virtualbox)
#   monitoring  running (virtualbox)

# 2. On entre par le compte de la box, puis on bascule sur le compte d'exploitation
vagrant ssh apps
sudo -iu taaf-engineer            # (ou connexion directe si vous lui avez donné un mot de passe)

# 3. taaf-engineer a bien sudo + docker, et Docker répond
id                                # …groups=…(sudo),…(docker)
docker --version                  # Docker version 2x.x
docker ps                         # AUCUN conteneur — normal, la VM est nue

Feu vert pour la Phase 3

Vous êtes prêt quand, sur chaque VM cœur : vagrant status = running, vous entrez en taaf-engineer (sudo + docker), docker --version répond, et docker ps est vide. Un conteneur qui tournerait déjà signifierait que quelque chose a été déployé trop tôt — ce n’est pas attendu ici. Tout est vert ? → Phase 3 — Déployer les services.

---

8. Commandes utiles

Commande	Description
vagrant up <machine>	Démarrer une VM
vagrant halt <machine>	Arrêter une VM
vagrant ssh <machine>	Se connecter en SSH
vagrant status	État de toutes les VMs
vagrant destroy <machine>	Supprimer une VM
vagrant provision <machine>	Relancer le provisionnement

---

9. Dépannage

(Apple Silicon) Erreur « Addressing limited to 32 bits »

Cette erreur vient d’une box demandant plus de 3 Go avec QEMU. Le Vagrantfile du dépôt gère déjà cela (highmem=on). Assurez-vous d’avoir la dernière version du dépôt :

git pull
vagrant destroy <machine> && vagrant up <machine>

(Apple Silicon) Le plugin QEMU n’est pas trouvé

vagrant plugin install vagrant-qemu
vagrant plugin list   # vérifier la présence de vagrant-qemu

(x86) Erreur de virtualisation

Vérifiez que la virtualisation matérielle est activée dans le BIOS (VT-x pour Intel, AMD-V pour AMD).

Sous Windows, VirtualBox cohabite avec WSL2 / Hyper-V (voir §2) : des VMs lentes avec l’icône « tortue » sont normales, pas une panne. Une VM qui refuse de démarrer (VT-x is not available, écran noir) relève du BIOS — ou de la fonctionnalité Windows Plateforme d’hyperviseur Windows manquante : Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform en PowerShell administrateur, puis redémarrez. Ne désactivez pas Hyper-V avec bcdedit : vous perdriez WSL2, donc votre terminal de travail.

Un service ne répond pas sur l’IP de la VM

# Vérifier que les conteneurs tournent
vagrant ssh <machine> -c "docker compose ps"

# Vérifier la connectivité inter-VM (depuis une autre VM)
ping IP_VM1
nc -zv IP_VM1 5432

# Relancer le provisionnement
vagrant provision <machine>

Espace disque insuffisant

df -h
vagrant box prune    # nettoyer les boxes obsolètes

Ne pas modifier les VMs à la main

Ne modifiez pas la configuration des VMs directement. Utilisez toujours le dépôt et vagrant provision pour garantir la reproductibilité.