CONCEPTION ET SÉCURISATION D'UNE INFRASTRUCTURE RÉSEAU VIRTUALISÉE
Projet ESIEA | 2 semaines en groupe de 4
Le contexte : Concevoir une infra d’entreprise réaliste de A à Z
Dans le cadre de la formation ESIEA, on nous a demandé de concevoir le réseau complet d’une entreprise simulée. Pas juste un schéma sur papier, mais une infrastructure fonctionnelle et sécurisée montée intégralement en virtuel. L’idée était simple mais exigeante : appliquer les concepts qu’on voyait en cours (VLANs, Active Directory, SIEM, firewall) dans un environnement maîtrisé et les faire fonctionner ensemble sans rien casser.
On était 4 personnes sur le projet, ce qui veut dire que fallait vraiment bien communiquer et coordonner les tâches pour ne pas se marcher dessus. C’était 2 semaines intensives, pas « chill » mais pas non plus « travail de dingue » – juste du boulot bien organisé et sérieux.
La philosophie du projet : Sécurité par la conception
De nos jours, la sécurité d’un SI ne se limite plus à un antivirus. Ça repose sur une architecture réseau segmentée, une gestion stricte des identités, et une supervision en temps réel pour détecter les anomalies avant qu’elles ne deviennent des problèmes.
On a structuré le projet autour de trois piliers fondamentaux : d’abord le cloisonnement réseau (VLANs) pour limiter la surface d’attaque et empêcher le mouvement latéral d’un attaquant, ensuite la gestion des identités via Active Directory avec du hardening agressif pour minimiser les privilèges, et enfin la détection d’incidents via Wazuh pour tracker les menaces en temps réel et lever les alertes avant qu’il ne soit trop tard.
L’architecture qu’on a déployée
Le réseau, c’était classique mais vraiment efficace : 4 VLANs séparant les départements (direction, production, serveurs, et guest). Chaque VLAN avait ses propres ACLs (Access Control Lists) strictes sur le firewall pour contrôler précisément qui parle à qui. Par exemple, les clients du VLAN guest ne pouvaient absolument pas accéder aux serveurs du VLAN production. C’était du cloisonnement vrai.
Pour le firewall et le routage inter-VLAN, on a utilisé pfSense (c’est léger, flexible, et parfait pour un lab, mais aussi assez robuste). On a configuré les règles de filtrage en principe du moindre privilège : autoriser strictement ce qui est nécessaire, bloquer tout le reste par défaut. C’est l’approche inverse de beaucoup d’infrastructures qu’on voit en production (malheureusement).
On a déployé Windows Server pour l’Active Directory : création des unités organisationnelles (OU) par département, des utilisateurs correspondants, et surtout des GPO (Group Policy Objects) pour un hardening massif des postes clients. Et là, on a vraiment verrouillé les machines. C’était drôle de tester comment bloquer littéralement tout ce qui pouvait l’être. Rien ne pouvait s’installer sans demande admin, le micro était coupé, les services Windows inutiles désactivés, les droits des utilisateurs au minimum. C’était du hardening de ouf, genre une machine qui fait juste le job qu’on lui demande et rien d’autre.
Le défi qui nous a vraiment pris du temps : Le puits de logs Wazuh
Ici, c’est là où ça s’est vraiment compliqué. Wazuh tournait sur le PC d’un collègue (c’était le puits de logs centralisé où devaient remonter tous les événements de toutes les machines). Le truc critique, c’est que si le puits de logs n’est pas bien configuré, tu ne collectes rien du tout. Zéro alerte, zéro détection, zéro supervision. C’est juste un serveur qui ne tourne pour rien.
Au début, Wazuh n’était pas configuré correctement. Les agents sur les machines clients envoyaient bien les logs (on voyait les processus qui s’exécutaient), mais Wazuh n’écoutait pas correctement les connexions entrantes. L’interface était vide. On a passé pas mal de temps à débugger la configuration : vérifier les ports ouverts, les certificats SSL, les permissions d’accès au puits, les configurations de listener. C’était frustrant parce que tout semblait en place (les machines tournaient, les logs existaient forcément quelque part, mais l’interface Wazuh était juste… vide).
Finalement on a trouvé le truc : c’était une configuration de listener qui était cassée. Les agents tentaient de se connecter sur un port qui n’était pas réellement à l’écoute. Une fois réglée, tout a remonté d’un coup, les logs ont commencé à arriver, les dashboards se sont remplis. Ça m’a appris quelque chose d’important : une architecture de SIEM, ce n’est pas juste « installer un serveur Wazuh et des agents », c’est s’assurer que toute la plomberie de collecte fonctionne correctement. Un maillon faible et rien ne remonte.
Le test de détection : Force brute sur Wazuh
Une fois que Wazuh était enfin en place, on a voulu vraiment tester si ça détectait les menaces ou si c’était juste de la belle interface. Donc on a lancé une simulation d’attaque par force brute : plusieurs tentatives de connexion échouées rapidement sur un poste client pour voir si Wazuh levait une alerte.
Au départ, ça n’a pas marché du tout. Les tentatives échouées arrivaient bien dans Wazuh (on les voyait dans les logs), mais aucune alerte n’était levée. Pourquoi ? Parce que les règles de détection n’étaient pas configurées correctement. Les seuils étaient trop hauts ou les patterns de détection ne matchaient pas précisément les logs réels qu’on était en train de générer.
On a ajusté sérieusement : baissé les seuils de détection, affiné les règles pour matcher exactement le pattern d’une force brute (par exemple : si plus de 5 échecs d’authentification en moins de 2 minutes, lever une alerte). Cette fois, ça a marché. L’attaque simulée a déclenché une alerte Wazuh instantanément. C’était un moment cool parce qu’on voyait concrètement que la détection fonctionnait vraiment, pas juste théoriquement.
Le bug de routage qui aurait pu tout casser
À un moment, une communication critique ne passait pas entre deux VLANs. Un client du VLAN production ne pouvait pas parler aux serveurs du VLAN serveurs (ça, c’est un gros problème en production). Classiquement, c’est un problème de routage mal configuré ou de firewall qui bloque sans raison valable.
Là, c’est où mon bagage en support réseau chez Zenconnect a vraiment fait la différence. Je savais exactement comment approcher le problème de façon systématique : vérifier les routes sur pfSense, checker les ACLs ligne par ligne, tracer le trafic avec des pings progressifs pour identifier exactement où ça casse. J’ai pu debugger méthodiquement au lieu de crier « c’est cassé ! » et chercher au hasard.
Finalement, c’était une route par défaut mal configurée sur pfSense qui causait un blackhole (trou noir) pour ce VLAN spécifique. Les paquets partaient mais ne revenaient jamais. Une fois corrigée, tout a communiqué correctement. C’est ce genre de moment qui montre pourquoi l’expérience terrain compte vraiment – en lab, tu as des outils et de la doc, mais savoir raisonner systématiquement sur les problèmes réseau, ça s’apprend en le faisant sur de vrai équipement.
L’Active Directory : Clean et efficace
Côté AD, ça s’est bien passé sans trop de friction. On a créé les structures par département, les utilisateurs correspondants avec les bons droits, et les GPO pour le hardening. Rien de révolutionnaire techniquement, mais c’était fonctionnel et vraiment sécurisé. Les GPO de hardening, c’était du « bloquer absolument tout ce qui n’est pas strictement nécessaire » (aucune installation sans admin, les services Windows inutiles complètement désactivés, les droits au minimum absolu). C’était excessif pour une vraie entreprise (on aurait enragé les utilisateurs), mais pour un lab académique, c’était cool de voir que ça marchait vraiment sans cassure.
Ce qu’on a vraiment appris
Esprit critique : Concevoir une architecture, ce n’est pas juste suivre un tutoriel YouTube. Il faut questionner chaque choix technique : pourquoi cette segmentation VLAN spécifiquement et pas une autre ? Pourquoi ces ACLs là et pas d’autres ? Un SIEM sans logs bien configurés, c’est juste une belle interface vide et inutile. J’ai appris à penser en couches (physique, réseau, application) et à vérifier que chaque couche fait vraiment son job avant de passer à la suivante.
Ingénierie réseau : Les ACLs qu’on a configurées, c’était classique mais vraiment efficace. Pas du complexe pour faire genre « je suis expert », juste les règles strictement nécessaires pour isoler les VLANs et contrôler le trafic. Et le débugging du routing, ça m’a rappelé qu’une chose : connaître la théorie c’est bien, mais savoir tester une hypothèse, isoler un problème et le fixer, c’est largement mieux. C’est ça qui fait la vraie différence.
Le travail en groupe : On était 4, et pendant 2 semaines, fallait que tout le monde soit vraiment sur la même longueur d’onde. Communiquer sur qui fait quoi, partager l’infrastructure virtuelle sans se marcher dessus, documenter sérieusement pour que les autres puissent reprendre le travail si besoin. Ce n’est pas trivial quand y’a une seule instance Wazuh sur un PC et que tout le monde y accède en même temps.
Les lendemains
Le projet s’est clôturé par une démo fonctionnelle devant les intervenants : on a montré que le réseau bloquait réellement les menaces (via les alertes Wazuh), que la segmentation VLAN était effective et isolait vraiment les départements, que le hardening était en place et fonctionnel. Ça a marché du premier coup, ce qui a montré qu’on avait bien pensé l’architecture.
Cette réalisation m’a donné envie d’aller vraiment loin avec l’automatisation. Déployer manuellement 4 VLANs, c’est fun une fois. Mais imaginer ça à l’échelle (50 VLANs, 1000 utilisateurs, 10 sites différents) ? Fallait de l’IaC (Infrastructure as Code) – Ansible, Terraform, tout ça. Pas le temps de le faire pendant le projet, mais c’est vraiment dans ma roadmap.