Contexte : projet de cyber range léger (laboratoire de cybersécurité isolé) conçu pour un client industriel, hébergé sur l'hôte Proxmox · Testé sur : Proxmox VE 8 (Debian 12), VM Debian 13, Python 3 / FastAPI, LXD · Dernière vérification : contenu de janvier 2026 non revérifié (état du lab mis à jour le 01/10/2026)
État au 01/10/2026 : lab démonté. La VM de gestion
debian-mgmt(VM 150) n'existe plus sur l'hôte et l'interface web publiée n'a plus de machine derrière elle. Seul le pont isolévmbr150subsiste, sans adresse IPv4. L'hôte est depuis passé en Proxmox VE 9. Cette page documente la conception et les étapes de construction, réutilisables pour remonter le lab.
¶ Objectif
- Mettre en place, sur un hôte Proxmox VE, un cyber range : un laboratoire isolé pour l'analyse de logiciels malveillants, la simulation d'attaques et de défenses et les scénarios Red Team / Blue Team.
- Décrire la segmentation réseau, et en particulier le pont dédié
vmbr150et son rôle d'isolement. - Construire progressivement une plateforme qui déploie automatiquement une topologie de lab à partir d'un fichier JSON : moteur réseau, validateur, orchestrateur, API, puis interface web.
¶ Architecture réseau
¶ Topologie de l'hôte
- Interface physique :
eno1. - Ponts principaux :
| Pont | Rôle |
|---|---|
vmbr0 |
Accès Internet, gestion de Proxmox VE, réseau local (porte l'adresse IP de l'hôte). |
vmbr1 |
Pont isolé (usages divers, tests internes). |
vmbr20 |
Pont isolé (usages divers, tests internes). |
vmbr150 |
Pont dédié au lab : réseau isolé (air gap virtuel), sans port physique (bridge-ports none). |
¶ Rôle de vmbr150
- Segment dédié aux VM et conteneurs du lab (analyse de logiciels malveillants, simulations d'attaque et de défense, scénarios Red/Blue).
- Aucun lien physique montant : pas de sortie vers Internet ni vers le réseau local, ce qui garantit un confinement strict.
- Fonctionne comme un réseau « bulle » (bubble network) : tout le trafic reste dans le lab, sauf si l'on ajoute un relais contrôlé (bastion, proxy, passerelle filtrante).
- Permet d'appliquer des politiques de sécurité propres au lab (pare-feu Proxmox, règles par VM, VLAN internes) sans impacter la production ni la gestion de Proxmox VE.
¶ Pourquoi l'isolation est critique
- Réduction du risque : empêche la fuite de charges malveillantes ou de données sensibles vers le réseau local ou Internet.
- Réalisme des scénarios : les exercices Red/Blue exigent un environnement contrôlé, sans influence extérieure non maîtrisée.
- Conformité et traçabilité : facilite la preuve du confinement et la limitation du périmètre lors d'un audit de sécurité.
- Surface d'attaque minimale : aucune exposition externe des VM de test, aucun service publié par erreur.
¶ Points de configuration essentiels
- Créer le pont sans port physique :
bridge-ports none,bridge-stp off(si le STP n'est pas requis),bridge-fd 0. - N'attribuer une adresse IP au pont que si l'administration locale du lab l'exige ; sinon, le laisser sans IP pour réduire la surface d'attaque.
- Appliquer les règles du pare-feu Proxmox au niveau du datacenter, du pont ou de la VM pour contrôler le trafic interne.
- Documenter les VLAN internes prévus (par exemple : production du lab, gestion du lab, attaque, OT simulée) et leur correspondance avec les VM.
- Prévoir un point de passage contrôlé (bastion ou jump host) si un accès ponctuel au lab est nécessaire, avec authentification forte et journalisation.
Déclaration correspondante dans /etc/network/interfaces de l'hôte :
auto vmbr150
iface vmbr150 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0
¶ VM de gestion debian-mgmt
¶ Rôle et caractéristiques
La VM debian-mgmt sert de bastion et de « cerveau » du cyber range : accès d'administration, outillage de déploiement, supervision. Elle est à double attachement (dual-homed) : net0 sur vmbr0 pour Internet et la gestion, net1 sur vmbr150 pour le réseau isolé du lab. Debian 13 (Trixie) a été choisie, plus récente que l'hôte Debian 12 de l'époque, pour bénéficier des derniers correctifs de sécurité.
| Élément | Valeur |
|---|---|
| ID / nom | 150 / debian-mgmt |
| Système | Debian 13 (Trixie) |
| CPU | 4 cœurs, type host (virtualisation imbriquée) |
| RAM | 8 Go (8 192 Mo) |
| Stockage | 40 Go sur le pool LVM-thin, avec discard=on et ssd=1 |
| Réseau de gestion | net0 : bridge=vmbr0 (accès Internet, mises à jour) |
| Réseau du cyber range | net1 : bridge=vmbr150 (isolé, air gap) |
Pourquoi --cpu host : ce type propage le modèle de processeur de l'hôte dans la VM et active la virtualisation imbriquée (VT-x). La VM peut ainsi héberger des hyperviseurs ou des appliances internes au lab sans perte de fonctionnalités processeur.
¶ Création de la VM
La VM a été supprimée puis recréée avec qm create pour garantir le contrôleur virtio-scsi-single et le type de CPU host :
- disque
vm-150-disk-0de 40 Go provisionné sur le pool LVM-thin, avecdiscard=onetssd=1pour optimiser les entrées-sorties ; - contrôleur
scsihw=virtio-scsi-single, pour des performances stables et une large compatibilité ; - amorçage sur l'ISO
local:iso/Debian13.iso(lecteuride2), dans l'ordrevirtio0puiside2pour l'installation initiale.
# Création propre de la VM 150 (sur l'hôte Proxmox, en root)
qm create 150 \
--name debian-mgmt \
--memory 8192 --cores 4 --cpu host \
--scsihw virtio-scsi-single \
--virtio0 pool:40,discard=on,ssd=1 \
--net0 virtio,bridge=vmbr0 \
--net1 virtio,bridge=vmbr150 \
--cdrom local:iso/Debian13.iso \
--boot 'order=virtio0;ide2'
L'option
--bootdoit être entre guillemets : sans eux, le shell interprète le;comme une fin de commande.
Résultat : la VM démarre et l'installateur Debian est prêt.
¶ Accès SSH par clé via le bastion
Chaîne d'accès : poste Windows → hôte Proxmox (utilisateur mass) → VM debian-mgmt.
1. Côté poste Windows, générer une paire de clés ED25519 dans %USERPROFILE%\.ssh (emplacement utilisé automatiquement par le client SSH du profil) :
ssh-keygen -t ed25519 -C "bastion-access" -f "$env:USERPROFILE\.ssh\id_ed25519"
2. Sur l'hôte Proxmox (en root), créer l'utilisateur et déposer la clé publique :
adduser mass
# (facultatif, si sudo est installé) usermod -aG sudo mass
mkdir -p /home/mass/.ssh && chmod 700 /home/mass/.ssh
cat <<'EOF' >> /home/mass/.ssh/authorized_keys
# coller ici la clé publique ED25519
EOF
chmod 600 /home/mass/.ssh/authorized_keys
chown -R mass:mass /home/mass/.ssh
Les permissions doivent être strictes : .ssh en 700, authorized_keys en 600.
3. Variante : envoyer la clé depuis Windows vers l'hôte Proxmox, puis vers la VM :
# Vers l'hôte Proxmox
Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" | ssh mass@<IP_PROXMOX> "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"
# Vers la VM debian-mgmt
Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" | ssh mass@<IP_VM> "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"
4. Durcir SSH sur l'hôte et sur la VM :
Désactivez la connexion root et l'authentification par mot de passe pour imposer les clés. Vérifiez d'abord que la connexion par clé fonctionne, sous peine de perdre l'accès.
# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
systemctl restart ssh
Sur Debian, sshd est un alias du service ssh : systemctl restart sshd fonctionne également.
Dépannage : si usermod ou sudo est introuvable dans une session SSH non interactive, vérifiez que /usr/sbin est dans le PATH, ou utilisez le chemin complet : sudo /usr/sbin/usermod -aG sudo mass.
¶ Adresse IP statique
L'interface de gestion de la VM, identifiée avec ip a, est ens18. Elle passe de DHCP à une adresse statique pour stabiliser l'adresse de gestion.
État initial (DHCP) :
# /etc/network/interfaces (extrait)
auto ens18
iface ens18 inet dhcp
Configuration cible (statique) :
# /etc/network/interfaces (extrait)
auto ens18
iface ens18 inet static
address 192.168.1.X
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 1.1.1.1 8.8.8.8
Application et vérification :
sudo systemctl restart networking
ip a show dev ens18 # vérifier l'adresse et l'état
Dépannage : si l'ancienne adresse reste affichée avec la mention secondary, c'est un reliquat du bail DHCP : la reconfiguration ajoute l'IP statique sans retirer l'ancienne. Deux corrections possibles :
sudo ip addr flush dev ens18, puissudo systemctl restart networking;- ou
sudo dhclient -r ens18pour libérer l'ancien bail avant le redémarrage du réseau.
Vérifiez ensuite avec ip a qu'il ne reste qu'une seule adresse active.
¶ Étape 1 — Moteur réseau et isolation
Objectif : valider manuellement, puis automatiser, l'interconnexion de deux hôtes virtuels (pc1, pc2) reliés à un commutateur virtuel sur 10.150.0.0/24.
- Le pont
br-labjoue le rôle de commutateur L2 virtuel. - Les namespaces réseau
pc1etpc2sont des hôtes isolés. - Les paires
vethsont les câbles virtuels qui les relient au pont.
pc1(ns) -- veth-pc1 <-> veth-pc1-br -- [ br-lab ] -- veth-pc2-br <-> veth-pc2 -- pc2(ns)
¶ Mise en place (root)
# Commutateur virtuel
ip link add br-lab type bridge
ip link set br-lab up
# Namespaces (piles réseau)
ip netns add pc1
ip netns add pc2
ip -n pc1 link set lo up
ip -n pc2 link set lo up
# Câbles veth vers le pont
ip link add veth-pc1 type veth peer name veth-pc1-br
ip link set veth-pc1 netns pc1
ip link set veth-pc1-br master br-lab
ip link set veth-pc1-br up
ip -n pc1 link set veth-pc1 up
ip link add veth-pc2 type veth peer name veth-pc2-br
ip link set veth-pc2 netns pc2
ip link set veth-pc2-br master br-lab
ip link set veth-pc2-br up
ip -n pc2 link set veth-pc2 up
# Adressage du lab en /24
ip -n pc1 addr add 10.150.0.11/24 dev veth-pc1
ip -n pc2 addr add 10.150.0.12/24 dev veth-pc2
¶ Vérification
Ping de pc1 vers pc2 (résultat attendu : 0 % de perte) :
ip netns exec pc1 ping -c 2 10.150.0.12
Capture ICMP sur le pont, dans deux terminaux :
# Terminal 1
tcpdump -ni br-lab icmp -vv
# Terminal 2
ip netns exec pc1 ping -c 2 10.150.0.12
tcpdump affiche les echo request de 10.150.0.11 vers 10.150.0.12 et les echo reply en retour.
¶ Industrialisation par scripts
setup_lab.shcrée le pont, les namespaces, les paires veth et les adresses IP. Il doit être idempotent : on peut le relancer sans rien casser.cleanup.shsupprime les namespaces, les paires veth et le pont pour repartir d'un état propre.- Reproductibilité :
setup_lab.shreconstruit,cleanup.shremet tout à zéro.
./setup_lab.sh
ip netns exec pc1 ping -c 2 10.150.0.12
tcpdump -ni br-lab icmp -c 4 & sleep 0.3; ip netns exec pc1 ping -c 2 10.150.0.12; wait
./cleanup.sh
¶ Étape 2 — Modèle de topologie JSON et validation
Objectif : décrire la topologie en JSON et bloquer tout déploiement incohérent avant exécution. Format minimal (MVP) :
nodes: un nœudnetwork(le pont) et des nœudshost(avec leur IP) ;edges: des lienshost -> networkqui déclarent les connexions.
Exemple de topologie (mini-cyberlab/topologies/topo.json) :
{
"name": "mvp-2hosts-1net",
"nodes": [
{ "id": "net1", "type": "network", "bridge": "br-lab" },
{ "id": "pc1", "type": "host", "ip": "10.150.0.11/24" },
{ "id": "pc2", "type": "host", "ip": "10.150.0.12/24" }
],
"edges": [
{ "source": "pc1", "target": "net1" },
{ "source": "pc2", "target": "net1" }
]
}
Le validateur tools/validate_topology.py contrôle :
- la présence de
nodesetedges, et l'unicité des identifiants ; - exactement un nœud
networket au moins deuxhost; - des adresses IP valides, uniques et dans le même sous-réseau ;
- le raccordement de chaque hôte à un réseau via
edges.
S'il n'y a pas d'erreur, il affiche le pont, les hôtes et le sous-réseau déduit. Le JSON est lu avec l'encodage utf-8-sig, pour accepter les fichiers enregistrés avec un BOM sous Windows.
python3 tools/validate_topology.py topologies/topo.json
¶ Étape 3 — Orchestrateur (topologie JSON, plan, déploiement)
Objectif : automatiser le déploiement à partir d'une topologie validée. Trois briques :
- moteur réseau :
scripts/setup_lab.shetscripts/cleanup.sh(création et suppression du pont, des namespaces, des paires veth et des IP) ; - planificateur :
tools/plan_topology.py, simulation (dry-run) lisible des actions prévues ; - déployeur :
tools/deploy_topology.py, qui valide le JSON puis appelle le moteur réseau.
Flux complet :
- Lecture du JSON.
- Validation de la structure (nœuds, liens, IP, sous-réseau, connexions).
- Extraction du pont, des hôtes et des IP.
- Plan : affichage des actions.
- Exécution : création du pont, des namespaces, des paires veth, adressage IP.
- Vérification par ping et
tcpdump, puis nettoyage.
Le lab est éphémère : cleanup.sh supprime tout, deploy_topology.py recrée tout.
python3 tools/plan_topology.py topologies/topo.json
python3 tools/deploy_topology.py topologies/topo.json
ip netns exec pc1 ping -c 2 10.150.0.12
bash scripts/cleanup.sh br-lab pc1 pc2
¶ Étape 4 — API FastAPI
Objectif : piloter l'orchestrateur par HTTP plutôt qu'en lançant les scripts à la main (mode « plateforme »). Composants : api/app.py (FastAPI), serveur uvicorn, réutilisation du validateur, du planificateur et du déployeur.
¶ Préparation
cd /home/mass/mini-cyberlab
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install fastapi uvicorn
¶ Lancement
source .venv/bin/activate
uvicorn api.app:app --host 0.0.0.0 --port 8000 --reload
- Santé :
curl -s http://127.0.0.1:8000/healthdoit renvoyer{"ok":true}. - Documentation Swagger (facultatif) :
http://127.0.0.1:8000/docs.
¶ Flux HTTP
# Création de la topologie (JSON existant)
curl -s -X POST http://127.0.0.1:8000/topologies \
-H "Content-Type: application/json" \
--data-binary @topologies/topo.json
# Noter l'identifiant renvoyé, par exemple <ID>
# Plan puis déploiement
curl -s -X POST http://127.0.0.1:8000/topologies/<ID>/plan
curl -s -X POST http://127.0.0.1:8000/topologies/<ID>/deploy
# Vérifications
ip netns list
ip netns exec pc1 ping -c 2 10.150.0.12
# Nettoyage
curl -s -X POST http://127.0.0.1:8000/topologies/<ID>/cleanup
Par défaut, l'API écoute sur
0.0.0.0:8000, donc sur toutes les interfaces. Pour la garder confinée, liez-la à l'adresse de gestion de la VM ou à127.0.0.1et accédez-y par un tunnel SSH.
L'historique (GET /history) est réservé aux rôles admin et superadmin.
¶ Étape 5 — Interface web (MVP)
Une interface web statique pilote le plan de contrôle FastAPI : elle envoie une topologie JSON et déclenche le plan, le déploiement et le nettoyage. Les réponses de l'API s'affichent dans une zone de journaux, ce qui permet de valider rapidement chaque action. En pratique : on colle une topologie, on clique sur Create, Plan, Deploy puis Cleanup, et l'on voit ce que fait l'API. C'est un MVP crédible pour montrer le flux complet à petite échelle.
UI (MVP) -> API FastAPI -> Orchestrateur -> pont Linux + netns + veth + IP
Démonstration :
- Create : envoie la topologie JSON et obtient un identifiant.
- Plan : affiche la simulation des actions à exécuter.
- Deploy : crée
br-lab, les namespacespc1etpc2, les paires veth et les IP. - Cleanup : supprime le lab et revient à l'état initial.
Après une première passe de mise en forme CSS :
¶ Authentification et identité visuelle
- Connexion : un écran de connexion plein écran est obligatoire (pas de champs de connexion dans la barre supérieure) ; la déconnexion ramène à cet écran.
- Libellés : l'interface affiche « Orchestrateur Virtual Machine », même si le moteur repose sur LXD.
- Accès par rôle : l'onglet Historique n'est visible que pour les rôles
adminetsuperadmin(l'API bloque aussiGET /history) ; l'onglet « Comptes & Droits » est réservé ausuperadmin. - Logos : favicon
mini_logo_cyberlab.png, logo de la barre supérieureLogo_Page_carre.png, écran de connexionLogo_Page.png, pied de pagelogo_ssbiker.png(fichiers dansmini-cyberlab/api/custom).
¶ Étape 6 — Déploiement réel
- Objectif : déclencher l'exécution réelle du plan via l'API (création du pont, des namespaces, des paires veth et des IP).
- Entrée :
POST /topologies/{id}/deployexécute le moteur réseau. - Résultat : le lab existe dans Linux (
br-lab,pc1,pc2, paires veth, IP). - Nettoyage :
POST /topologies/{id}/cleanuprevient à l'état initial.
¶ Étape 7 — Séparation gestion / lab
Objectif : isoler, dans la VM, le plan de gestion (SSH, API) du plan de données du lab.
| Interface | Rôle |
|---|---|
ens18 |
Gestion : IP de gestion, SSH, API. |
ens19 |
Lab : 10.150.0.1/24, sans passerelle. |
- Isolation : aucun routage entre gestion et lab (
net.ipv4.ip_forward=0, complété si besoin par des règles de pare-feu). - Vérification :
ip a show ens19affiche10.150.0.1/24et l'API reste surens18.
¶ Migration des namespaces vers des conteneurs LXC (LXD)
¶ Pourquoi ce changement
Le MVP crée ses hôtes avec des namespaces Linux (veth et ip netns) : c'est rapide et léger, mais ce ne sont pas de « vraies machines » (tous partagent le même système). Pour se rapprocher d'un cyber range réaliste tout en restant léger, le lab passe à des conteneurs LXC pilotés par LXD :
- isolation plus propre qu'un namespace ;
- cycle de vie d'une machine (création, démarrage, arrêt, suppression) ;
- réseau identique (pont
br-lab) ; - faible consommation, adaptée à la VM.
¶ Installation de LXD et stockage persistant
Objectifs : installer LXD, activer les services, stocker les conteneurs hors de /var (pour ne pas remplir la VM) et garantir la persistance après redémarrage.
- Pool LXD
labpoolen modedir, situé dans/home/lxd/labpool. - Script du dépôt :
for_debian/01_install_lxd.sh. Il installelxd,lxd-client,lxcfset leurs dépendances, démarre et activelxdetlxcfs, initialise LXD par preseed, crée et valide le poollabpool(source/home/lxd/labpool) et, en option, ajoute l'utilisateurmassau groupelxd.
Vérifications :
lxc version # client et serveur OK
lxc storage list # labpool présent, source /home/lxd/labpool
¶ Réseau du lab persistant et profil LXD
Objectifs : raccorder automatiquement au lab les conteneurs créés par l'API, en réutilisant br-lab (relié à vmbr150 via ens19), avec un profil LXD stable.
- Réseau persistant de la VM :
br-labporte10.150.0.1/24etens19est un port du pont (bridge_ports ens19). - Profil LXD
lab: interfaceeth0en modebridged, parentbr-lab. - Script du dépôt :
for_debian/02_config_lab_network.sh. Il vérifie la présence d'ens19, vérifie ou créebr-lab, y attacheens19, applique10.150.0.1/24surbr-labet crée le profil LXDlab.
Vérifications :
ip -br addr show br-lab # 10.150.0.1/24
bridge link # ens19 master br-lab
lxc profile show lab # eth0 en bridged sur br-lab
Résultat : LXD est prêt et persistant, le stockage des conteneurs est dans /home (et non dans /var), le réseau du lab est persistant et le profil lab raccorde automatiquement tout conteneur à br-lab.
¶ Adaptation du backend
Le backend (API) est ensuite modifié pour que le déploiement et le nettoyage pilotent LXD, avec une image locale choisie selon la topologie :
- création et démarrage des conteneurs ;
- configuration d'une IP statique (par exemple
10.150.0.11/24,10.150.0.12/24) ; - choix de l'image locale par hôte selon
os_release(debian13oualpine-linux) ettools_profile(base,attackoudefense) ; - aucun téléchargement pendant le déploiement (images préconstruites) ;
- nettoyage par suppression des conteneurs.
L'interface web reste identique (interface, puis API, puis déploiement).
¶ Étape 8 — Images LXD d'attaque et de défense
Objectif : préconstruire des images LXD locales pour les profils « attack » et « defense », afin de ne rien télécharger au moment du déploiement.
- Images (alias LXD) :
debian13-attack,debian13-def,alpine-attack,alpine-def. - Comptes :
mass(membre de sudo, mot de passe<MOT_DE_PASSE_LAB_MASS>) ettest(sans droits, mot de passe<MOT_DE_PASSE_LAB_TEST>). - SSH : authentification par mot de passe active, connexion root désactivée, service SSH démarré dans les images.
- Profil attack : outillage d'audit et d'attaque léger (nmap, hydra, john, netcat, curl, git, python3, tcpdump).
- Profil defense : services exposés (par exemple apache2 et vsftpd, ou lighttpd) et fichier d'identifiants volontairement faibles pour les démonstrations.
- Export local : archives
.tar.gzdans/home/mini-cyberlab-images.
Les images de défense contiennent volontairement des identifiants faibles : elles ne doivent jamais être raccordées à un autre réseau que le pont isolé du lab.
¶ Construction et export
cd /home/mass/mini-cyberlab
chmod +x scripts/*.sh
# Construction et export des 4 images (via l'interface Internet de la VM)
sudo BUILD_PARENT=ens18 ./scripts/build_lxd_tool_images.sh
# Vérification des alias et des exports
lxc image list | grep -E "debian13-(attack|def)|alpine-(attack|def)"
ls /home/mini-cyberlab-images
Adaptez BUILD_PARENT si l'interface Internet de la VM n'est pas ens18.
¶ Choix du système et des outils dans la topologie
Chaque hôte déclare son système et son profil d'outils :
{
"id": "pc1",
"type": "host",
"ip": "10.150.0.11/24",
"os_release": "debian13",
"tools_profile": "attack"
}
Valeurs autorisées :
os_release:debian13oualpine-linux;tools_profile:base,attackoudefense.
¶ Import et export des images (facultatif)
L'export est fait automatiquement par scripts/build_lxd_tool_images.sh vers /home/mini-cyberlab-images. Pour un import manuel :
sudo ./scripts/import_lxd_images.sh
¶ Publication de l'interface web (dernier état)
Dans son dernier état, l'interface (éditeur JSON, boutons Create, Plan, Deploy et Cleanup, journaux) était publiée via le reverse proxy sur un sous-domaine cyberlab de 2sinnovation.com, et appelait l'API FastAPI locale.
- Service de l'interface :
mini-cyberlab-ui.service, exécuté par l'utilisateurmass:
# mini-cyberlab-ui.service (extrait)
[Service]
User=mass
WorkingDirectory=/home/mass/mini-cyberlab/ui
ExecStart=/usr/bin/python3 -m http.server 8088 --bind 0.0.0.0
- Droits recommandés sur les fichiers de l'interface :
find ui -type d -exec chmod 755 {} +
find ui -type f -exec chmod 644 {} +
- Backend LXD : images locales
debian13-attack,debian13-def,alpine-attacketalpine-def(comptes SSHmassettest, mots de passe de lab<MOT_DE_PASSE_LAB_MASS>et<MOT_DE_PASSE_LAB_TEST>; ping validé). Dans cette version du dépôt, les scripts s'appellentscripts/creer_images_lxc_outils.sh(avecBUILD_PARENT=ens18), qui génère et exporte les archives dans/home/mini-cyberlab-images, puisimporter_images_lxd.shsi besoin. - Déploiement : topologie JSON avec un
network(pontbr-lab) et des hôtes décrits paros_release(debian13oualpine-linux) ettools_profile(attackoudefense). Le pilote LXD impose une IP statique persistante et relancesshdet le ping. - Vérification rapide :
systemctl status mini-cyberlab-api.service mini-cyberlab-ui.service, puis, dans l'interface, Create, Plan, Deploy et Cleanup. Depuis le clientdebian-cli, lancer/home/nettoyer_known_hosts.sh, puis :
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password mass@10.150.0.11 # ou .12
¶ Pistes d'évolution
Si le lab est remonté, les étapes suivantes étaient prévues :
- valider le plan d'adressage interne du lab sur
vmbr150(CIDR, DHCP statique, MAAS ou ISC, réservations) ; - définir les VLAN et les règles de pare-feu associées (flux autorisés, micro-segmentation) ;
- mettre en place un bastion d'accès au lab (SSH ou RDP via VPN ou réseau de gestion) et tracer toutes les actions ;
- tester l'isolement : vérifier qu'aucune route, aucun trafic ARP, CDP ou LLDP ne sort de
vmbr150versvmbr0; - ne pas republier l'interface sur Internet sans authentification forte ni filtrage.
¶ Références
- Hôte Proxmox alpha : état actuel de l'hôte et de ses ponts.
- Reverse proxy nginx (CT 210) : publication des services web.
- Utilisation de base de Nmap : outil présent dans les images « attack ».
- Créer un tunnel SSH : accéder à l'API sans l'exposer.
- Documentation LXD : documentation.ubuntu.com/lxd.
- Documentation FastAPI : fastapi.tiangolo.com.