Les étapes

La philosophie du projet : sécurité par la conception. De nos jours, la sécurité ne se limite plus à un antivirus. Elle 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 : 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. Enfin la détection d’incidents via Wazuh pour traquer les menaces en temps réel.

L’architecture qu’on a déployée : 4 VLANs séparant les départements (direction, production, serveurs, 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 un véritable cloisonnement.

Pour le firewall et le routage inter-VLAN, on a utilisé pfSense (léger, flexible, et parfait pour un lab, mais assez robuste). On a configuré les règles de filtrage selon le 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.

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. On a vraiment verrouillé les machines. 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 un durcissement extrême : chaque machine exécutait uniquement la tâche demandée et rien d’autre.

Le défi qui a vraiment pris du temps : le puits de logs Wazuh. Wazuh tournait sur le PC d’un collègue (c’était le puits centralisé où devaient remonter tous les événements de toutes les machines L’enjeu critique était le suivant : si le concentrateur de logs n’est pas bien configuré, on ne collecte rien du tout. Zéro alerte, zéro détection, zéro supervision. Le serveur tourne alors à vide.

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 à diagnostiquer 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, nous avons identifié la cause : la configuration de l’écouteur (listener) était défaillante. 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 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. 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 ne correspondaient 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 correspondre 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 important parce qu’on voyait concrètement que la détection fonctionnait vraiment, pas juste théoriquement.

Le problème de routage critique. À 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.

C’est là où l’expérience en support réseau chez Zenconnect a vraiment fait la différence. On savait exactement comment approcher le problème de façon systématique : vérifier les routes sur pfSense, vérifier les ACLs ligne par ligne, tracer le trafic avec des pings progressifs pour identifier exactement où ça casse. On a pu diagnostiquer méthodiquement au lieu de céder à la panique et de chercher à l’aveugle.

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, on a des outils et de la doc, mais savoir raisonner systématiquement sur les problèmes réseau, ça s’apprend en le faisant sur du vrai équipement.

L’Active Directory : propre 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 (risque de blocage total des utilisateurs), mais pour un lab académique, il était très formateur de constater son efficacité sans provoquer de dysfonctionnements.