Construire un lab cybersécurité pour 20 apprenants avec Proxmox VE : isolation et remise à zéro automatisée

GazelForm

il y a 9 heures

7 min de lecture

Un cours de cybersécurité ou de réseau se joue en grande partie dans le lab. C'est là que l'apprenant configure, attaque, défend, casse et répare. Encore faut-il que l'environnement tienne la charge : vingt apprenants qui démarrent leurs machines en même temps, des exercices offensifs qui ne doivent jamais déborder sur le réseau de l'école, et une remise à zéro rapide entre deux sessions. Dans cet article, nous détaillons une architecture de lab type, construite sur Proxmox VE, avec isolation par apprenant et réinitialisation automatisée.

Les exigences de départ

Avant de choisir un outil, il faut fixer le cahier des charges. Pour une promotion de 20 apprenants en cybersécurité, nous partons de ces exigences :

un environnement isolé par apprenant (ou par binôme), sans possibilité d'atteindre le lab d'un voisin ;
aucune route vers le réseau de l'école ni vers Internet depuis les machines d'exercice ;
un accès depuis un simple navigateur, sans client à installer sur les postes ;
une remise à l'état initial en quelques minutes, déclenchable par le formateur ;
une construction reproductible : le lab de la session suivante doit être identique à celui-ci.

Architecture générale

Le socle est un hyperviseur Proxmox VE, sur un ou plusieurs nœuds. Le principe tient en trois réseaux bien séparés :

                 Réseau école
                      |
          [ vmbr0 : administration Proxmox ]   (formateur uniquement)
                      |
              +---------------+
              |  Proxmox VE   |
              +---------------+
                 |         |
   [ VNet "acces" ]     [ vmbr1 : trunk VLAN, zone SDN "labs" ]
    10.99.0.0/24             |        |         |
     |                     lab01    lab02  ...  lab20   (1 VLAN par apprenant)
     |-- Guacamole            |
     |-- net0 de chaque     Kali, cible Linux, Windows Server AD...
         poste d'attaque    (aucune passerelle, aucune sortie)

vmbr0 porte l'interface d'administration de Proxmox. Seul le formateur y accède.
La zone SDN « labs » s'appuie sur un bridge vmbr1, de préférence VLAN-aware, sans interface physique sur un nœud unique ou relié à un switch où ces VLAN restent isolés. Chaque apprenant dispose de son propre VNet, donc de son propre VLAN, dans lequel vivent ses machines.
Le VNet « acces » relie la passerelle Apache Guacamole à la première interface du poste d'attaque de chaque apprenant. C'est le seul chemin d'entrée dans le lab, et le pare-feu Proxmox l'empêche de servir de passage entre apprenants.

Les VNets d'exercice n'ont aucune passerelle : ce sont des segments de niveau 2 fermés. Un outil de balayage lancé par erreur sur une mauvaise plage ne trouvera rien d'autre que le lab de l'apprenant.

Dimensionnement

Pour un scénario type « attaque et défense d'un petit SI », chaque apprenant dispose de :

un poste d'attaque Kali Linux : 2 vCPU, 4 Go de RAM ;
un contrôleur de domaine Windows Server : 2 vCPU, 4 Go de RAM ;
une cible Linux volontairement vulnérable : 1 vCPU, 1 à 2 Go de RAM.

Soit environ 10 Go de RAM par apprenant, et 200 Go pour une promotion de 20, auxquels s'ajoutent la marge de l'hyperviseur et les services communs (Guacamole, éventuellement un SIEM partagé). Deux leviers réduisent nettement l'empreinte réelle :

les clones liés : toutes les machines d'un même type partagent l'image disque du template et ne stockent que leurs différences. Ils nécessitent un stockage compatible (LVM-thin, ZFS, Ceph RBD ou fichiers qcow2) ;
KSM (Kernel Samepage Merging), actif par défaut sur Proxmox via ksmtuned (la fusion ne se déclenche qu'au-delà d'un certain taux d'occupation de la RAM), qui fusionne les pages mémoire identiques entre VM. Avec vingt instances du même système, le gain est sensible, mais il ne faut pas compter dessus pour dimensionner au plus juste.

Côté stockage, privilégiez des disques NVMe : le goulot d'étranglement d'un lab de formation est presque toujours le démarrage simultané de toutes les machines en début de séance.

Étape 1 : créer la zone SDN et un VNet par apprenant

Sur Proxmox VE 8, le SDN se pilote en ligne de commande avec pvesh. On crée une zone de type VLAN adossée à vmbr1, puis vingt VNets :

# Zone VLAN adossée au bridge vmbr1 (VLAN-aware)
pvesh create /cluster/sdn/zones --zone labs --type vlan --bridge vmbr1

# Un VNet par apprenant : lab01 -> VLAN 1001, ..., lab20 -> VLAN 1020
for i in $(seq -w 1 20); do
  pvesh create /cluster/sdn/vnets --vnet "lab$i" --zone labs --tag $((1000 + 10#$i))
done

# VNet d'accès pour Guacamole
pvesh create /cluster/sdn/vnets --vnet acces --zone labs --tag 999

# Application de la configuration SDN
pvesh set /cluster/sdn

Le 10#$i force l'interprétation en base 10 : sans lui, Bash lit « 08 » et « 09 » comme des nombres octaux invalides et la boucle s'arrête au huitième apprenant. Notez aussi que les identifiants de VNet sont limités à 8 caractères : choisissez des noms courts, en minuscules et sans caractère spécial.

Étape 2 : préparer les templates

Chaque type de machine est installé une fois, configuré, puis converti en template :

# VM 9001 = Kali préparée (outils, comptes, fond d'écran du cours...)
qm template 9001
# VM 9002 = Windows Server, VM 9003 = cible Linux
qm template 9002
qm template 9003

Pour Windows Server, l'image d'évaluation est valable 180 jours : planifiez la reconstruction du template avant chaque nouvelle session longue plutôt que de découvrir l'expiration en plein TP. Pensez aussi à généraliser l'image (sysprep) avant de la convertir, pour que chaque clone obtienne un SID distinct. Attention : sysprep n'est pas pris en charge sur un contrôleur de domaine déjà promu. Lancez-le sur le serveur avant sa promotion, et scriptez la promotion au premier démarrage du clone.

Étape 3 : déployer les labs des apprenants

Chaque apprenant reçoit un pool de ressources, qui servira ensuite de périmètre pour la remise à zéro. Le cloning d'un template produit par défaut un clone lié :

for i in $(seq -w 1 20); do
  n=$((10#$i))
  base=$((2000 + n * 10))           # apprenant 01 -> VMID 2010, 2011, 2012
  pvesh create /pools --poolid "lab-s$i"

  qm clone 9001 $((base + 1)) --name "s$i-kali"  --pool "lab-s$i"
  qm clone 9002 $((base + 2)) --name "s$i-dc"    --pool "lab-s$i"
  qm clone 9003 $((base + 3)) --name "s$i-cible" --pool "lab-s$i"

  # Kali : net0 sur le VNet d'accès (pare-feu actif), net1 dans le lab
  qm set $((base + 1)) --net0 "virtio,bridge=acces,firewall=1" \
                       --net1 "virtio,bridge=lab$i"
  qm set $((base + 2)) --net0 "virtio,bridge=lab$i"
  qm set $((base + 3)) --net0 "virtio,bridge=lab$i"

  # État de référence pour les remises à zéro
  for vmid in $((base + 1)) $((base + 2)) $((base + 3)); do
    qm snapshot "$vmid" baseline --description "Etat initial de la session"
  done
done

Étape 4 : verrouiller l'accès avec le pare-feu Proxmox

Le VNet d'accès est partagé par tous les postes d'attaque. Sans filtrage, un apprenant pourrait atteindre la Kali de son voisin. On active donc le pare-feu de chaque VM et on n'autorise en entrée que la passerelle Guacamole (ici 10.99.0.10). Exemple de fichier /etc/pve/firewall/2011.fw :

[OPTIONS]
enable: 1
ipfilter: 1
policy_in: DROP
policy_out: ACCEPT

[IPSET ipfilter-net0]
10.99.0.11

[RULES]
IN ACCEPT -i net0 -source 10.99.0.10 -p tcp -dport 22,3389

Ici, 10.99.0.11 est l'adresse de la Kali de l'apprenant 01 sur le réseau d'accès.

Trois points de vigilance :

le pare-feu doit aussi être activé au niveau du datacenter, sinon les règles des VM restent sans effet ;
l'option firewall=1 doit figurer sur l'interface concernée (c'est le cas de net0 à l'étape 3) ;
ipfilter n'est efficace qu'avec l'ipset ipfilter-net0 qui liste l'adresse autorisée de la VM : pour une VM, contrairement à un conteneur, Proxmox ne déduit pas cette adresse de la configuration. Une fois l'ipset renseigné, tout trafic sortant (IP et ARP) portant une autre adresse source est rejeté, ce qui empêche l'usurpation d'adresse et l'empoisonnement ARP entre apprenants sur le réseau d'accès.

Activez également le pare-feu de la VM Guacamole pour n'y accepter, depuis le réseau de l'école, que le port HTTPS.

Le VNet d'accès n'ayant pas de passerelle, policy_out: ACCEPT ne donne aucune sortie vers l'extérieur : il permet seulement à la Kali de répondre à Guacamole.

Étape 5 : la remise à zéro en une commande

Entre deux exercices, ou quand un apprenant a rendu son environnement inutilisable, le formateur restaure l'état de référence :

#!/usr/bin/env bash
# reset-lab.sh <numero_apprenant>   ex. : ./reset-lab.sh 07
set -euo pipefail
pool="lab-s$1"

for vmid in $(pvesh get /pools --poolid "$pool" --output-format json \
              | jq -r '.[0].members[] | select(.type == "qemu") | .vmid'); do
  qm rollback "$vmid" baseline --start 1
done
echo "Lab $pool restauré."

Les snapshots étant pris sans l'état mémoire, la VM est arrêtée après le rollback : l'option --start 1 la redémarre aussitôt. Pour remettre toute la promotion à zéro, il suffit d'appeler le script dans une boucle sur les vingt apprenants, idéalement en parallèle par lots pour ne pas saturer les disques.

Sur un cluster de plusieurs nœuds, qm n'agit que sur les VM du nœud local : il faut alors passer par l'API (pvesh create /nodes/<noeud>/qemu/<vmid>/snapshot/baseline/rollback) ou orchestrer la remise à zéro avec Ansible.

Intégrer les équipements réseau

Pour les modules Cisco, Fortinet ou Stormshield, deux approches coexistent :

des appliances virtuelles directement dans le VNet de l'apprenant (pare-feu virtuel, routeur virtuel), clonées comme les autres VM ;
un émulateur réseau (EVE-NG, GNS3 ou Cisco Modeling Labs) installé dans une VM Proxmox. Il faut alors activer la virtualisation imbriquée et donner à cette VM le type de processeur host.

Dans les deux cas, utilisez exclusivement des images obtenues dans un cadre de licence valide : les conditions d'usage en lab varient selon les éditeurs et doivent être vérifiées avant chaque déploiement.

Les pièges les plus fréquents

Le démarrage simultané de 60 VM en début de séance : échelonnez les démarrages par lots ou lancez-les avant l'arrivée des apprenants.
La dérive d'horloge après un rollback : un contrôleur de domaine dont l'heure est décalée casse l'authentification Kerberos. Prévoyez une resynchronisation au démarrage.
Le MTU : si vous passez à une zone SDN de type VXLAN pour répartir les labs sur plusieurs nœuds, l'encapsulation réduit le MTU utile (1450 octets sur un lien à 1500). Ajustez les interfaces des VM en conséquence.
Les templates qui vieillissent : mises à jour, licences d'évaluation, outils obsolètes. Reconstruisez-les à chaque session plutôt que de les laisser dériver.

Ce qu'apporte un lab bien conçu

Un lab isolé, reproductible et réinitialisable change la dynamique d'un cours. Le formateur n'a plus peur qu'un exercice offensif déborde. L'apprenant peut se tromper, recommencer, et aller au bout de sa démarche. Et l'établissement dispose d'un environnement qu'il peut réutiliser d'une promotion à l'autre.

Les formateurs GazelForm spécialisés en réseau et cybersécurité peuvent vous accompagner sur ce type d'environnement. Vous souhaitez construire ou faire évoluer le lab de vos formations ? Contactez-nous pour en discuter.