← Projets
AutomatisationTerraformIaCProxmoxSDNDétection

Lab de détection en Infrastructure as Code (Terraform, Proxmox)

Terraform + réseau Proxmox isolé pour déployer à la demande une cible vulnérable et un générateur de trafic malveillant réel, afin que chaque article de blog s'appuie sur une vraie détection plutôt que sur une illustration seule.

Contexte

Pour la série d’articles sur la sécurisation d’un réseau d’entreprise, je voulais des preuves concrètes plutôt que de la théorie : une règle de détection qui se déclenche réellement, une capture qui montre vraiment ce qui se passe. Problème : je n’ai pas toujours le matériel ou la VM déjà prête pour chaque sujet, et monter un lab à la main à chaque fois n’est pas tenable.

Ce projet n’a rien d’offensif. Il existe uniquement pour générer, à la demande, du trafic malveillant réel et connu sur un réseau totalement isolé — afin que l’article qui en découle porte sur la détection (règle, log, analyse), jamais sur la technique d’attaque elle-même.

Architecture

Composant Rôle
Zone SDN Proxmox isolée (10.10.99.0/24) Réseau dédié au lab, NAT contrôlé vers Internet (pour l’installation d’outils), aucune route vers le LAN de production
VM adversary-sim (Debian + outils) Génère le trafic à détecter : scan, exploitation connue, etc.
VM cible (Metasploitable2) Cible volontairement vulnérable, isolée du reste du réseau
Templates Proxmox Construits une fois, provisionnés via l’agent QEMU (pas d’accès SSH à l’hôte), puis clonés à chaque article

Chaque article clone des VM fraîches à partir des templates, fait sa manipulation, capture les preuves, puis détruit les clones. Les templates ne bougent pas — reconstruire le lab pour un nouvel article prend quelques minutes, pas une installation manuelle.

Ce que ça a demandé de résoudre

  • Réseau isolé avec sortie contrôlée : une zone SDN Proxmox avec SNAT (sortie Internet autorisée, LAN jamais routé), plutôt qu’un simple bridge sans issue — pour que l’installation des outils fonctionne sans sacrifier l’isolation.
  • Provisioning sans élargir les accès : installer des paquets sur un template sans donner à Terraform un accès SSH root à l’hôte Proxmox, en passant par le canal de l’agent QEMU exposé via l’API.
  • Images legacy capricieuses : une image VMware de 2012 (Metasploitable2) qui refuse de démarrer tant que son disque n’est pas présenté en IDE plutôt qu’en SCSI — son noyau trop ancien ne détecte pas le volume LVM autrement.
  • Discipline sur les secrets : jeton API à portée limitée, clé SSH générée par Terraform jamais committée, et un garde-fou qui a bloqué une tentative d’extraire la clé privée vers un fichier partagé — un rappel que même un lab jetable mérite une hygiène de secrets sérieuse.

Prochaines étapes

  • Premier article de la série construit entièrement sur ce lab (détection d’une exploitation connue)
  • Mapper chaque scénario généré sur MITRE ATT&CK
  • Étendre à d’autres cibles pour couvrir plus de familles de détection (web, Active Directory)

Ce projet reprend une idée notée dans la feuille de route du laboratoire de sécurité Proxmox : versionner la configuration du lab pour le reconstruire en quelques minutes.