Aller au contenu

Proxmox · pfSense · Wazuh · Fail2Ban · MITRE ATT&CK

Blue Team Lab : détecter, répondre, récupérer

On ne sait pas si une détection fonctionne tant qu’on ne l’a pas vue se déclencher.

Projet personnel

Un laboratoire de sécurité défensive complet sur un seul hyperviseur : une machine attaquante, une cible, un pare-feu et un SIEM, pour rejouer des attaques et vérifier qu’elles sont détectées.

01 · Avant

Comment cela se passait

  • Un SIEM configuré, mais aucune preuve qu’il détecte quoi que ce soit.
  • Des journaux dispersés, lus après coup.
  • Une réponse aux incidents jamais entraînée.

02 · Problème

Le problème et ses contraintes

Configurer un SIEM ne prouve pas qu’il détecte quoi que ce soit. Il fallait un environnement isolé où reproduire des techniques d’attaque connues, observer ce qui remonte (ou ne remonte pas), et entraîner la réponse.

  • Isolement total : le trafic d’attaque ne doit jamais sortir du lab.
  • Une seule machine physique.
  • Des scénarios reproductibles, reliés au référentiel MITRE ATT&CK.
  • Détection ET réponse : bannir, analyser, rétablir.

03 · Rôle

Ce qui a été conçu et construit ici

  • Installation et configuration de l’ensemble du lab : hyperviseur Proxmox, pare-feu pfSense, serveur cible Ubuntu, SIEM Wazuh et Fail2Ban, réseau isolé.
  • Rejeu des techniques d’attaque depuis la machine Kali, configuration des règles de détection Wazuh utilisées dans les scénarios et de la réponse Fail2Ban, lecture et analyse des journaux.
  • Ce qui vient d’ailleurs : les outils eux-mêmes (Proxmox, pfSense, Wazuh, Fail2Ban, Kali Linux) et le référentiel MITRE ATT&CK.

04 · Architecture

La chaîne, étape par étape

  1. HyperviseurProxmox
  2. Pare-feupfSense
  3. AttaquantKali Linux
  4. CibleUbuntu Server
  5. RéponseFail2Ban
  6. DétectionWazuh

  1. 01 · Proxmox

    Hyperviseur

    Toutes les machines du lab sont des machines virtuelles Proxmox : un environnement complet sur une seule machine physique.

    Exemple de topologie (simplifiée)
kali      attaquant
srv-cible Ubuntu Server
siem      Wazuh
fw        pfSense

  2. 02 · pfSense

    Pare-feu

    pfSense est le pare-feu du lab : il route et filtre le trafic entre les machines.

    Exemple de règles (synthétique)
bloquer   attaquant → Internet
autoriser attaquant → srv-cible:22
journaliser tout le reste

  3. 03 · Kali Linux

    Attaquant

    Une machine Kali reproduit des techniques d’attaque connues contre la cible, pour vérifier ce qui est détecté.

    technique  T1110.001  Password Guessing
cible      srv-cible:22 (SSH)

  4. 04 · Ubuntu Server

    Cible

    Un serveur Ubuntu expose des services ; ses journaux d’authentification sont surveillés.

    Failed password for invalid user admin from 10.20.0.15 port 51544 ssh2
Failed password for root from 10.20.0.15 port 51546 ssh2

  5. 05 · Fail2Ban

    Réponse

    Après plusieurs échecs, Fail2Ban bannit l’adresse attaquante : la réponse est automatique et immédiate.

    fail2ban.actions  [sshd] Ban 10.20.0.15

  6. 06 · Wazuh

    Détection

    L’agent Wazuh remonte les journaux ; une règle de détection signale les échecs répétés et les relie à la technique MITRE.

    {
  "regle": "échecs d’authentification multiples",
  "mitre": "T1110",
  "agent": "srv-cible",
  "srcip": "10.20.0.15"
}

05 · Automatisation

Ce qui se fait seul

  • Bannissement automatique après échecs répétés.
  • Alertes Wazuh reliées aux techniques MITRE.
  • Scénarios rejouables pour vérifier la détection.

Virtualisation

Tout le lab tourne sur Proxmox : attaquant, cible, pare-feu et SIEM sur une seule machine physique.

Filtrage

pfSense route et filtre le trafic entre les machines du lab.

Collecte et détection

Wazuh collecte les journaux et déclenche les alertes ; chaque scénario est relié à une technique MITRE ATT&CK.

Réponse

Fail2Ban répond automatiquement aux échecs d’authentification répétés ; l’analyse et le retour à la normale restent des étapes humaines.

06 · Choix techniques

Pourquoi ces choix, et pas d’autres

Un seul hyperviseur

Tout le lab sur une machine physique : coût nul, isolement simple, instantanés pour revenir à un état propre. L’alternative, plusieurs machines ou un hébergeur, n’apportait rien pour l’objectif.

Wazuh comme SIEM

Libre, avec des agents et des règles qui se relient aux techniques MITRE ATT&CK : la couverture est connue, pas supposée.

Fail2Ban pour la réponse automatique

Simple et déterministe. Une réponse orchestrée plus large aurait masqué ce que l’on voulait apprendre : voir chaque détection se déclencher.

Aucune IA

Une détection doit pouvoir être relue et testée ; des règles explicites s’y prêtent, un modèle non.

07 · IA

La place de l’IA

Aucune IA dans ce projet : la détection repose sur des règles Wazuh et la réponse sur Fail2Ban, deux mécanismes déterministes et explicables. C’est volontaire : une détection doit pouvoir être relue et testée.

08 · Sécurité

Ce qui protège le système

  • Le lab est séparé de tout environnement de production.
  • Les attaques sont rejouées contre des machines du lab uniquement.
  • Chaque détection est reliée à une technique MITRE ATT&CK, pour savoir ce qui est couvert et ce qui ne l’est pas.

Ce que nous ajouterions pour une mise en production chez un client

  • Réseau dédié à la machine attaquante, sans sortie vers Internet.
  • Instantanés avant chaque scénario, pour revenir à un état propre.
  • Comptes d’administration distincts pour l’hyperviseur, le pare-feu et le SIEM.
  • Règles de détection versionnées et testées à chaque modification.

09 · Fiabilité

Quand quelque chose échoue

  • Chaque règle de détection vérifiée par une attaque rejouée.
  • Chaque scénario relié à une technique MITRE ATT&CK : couverture connue.
  • Analyse et retour à la normale gardés comme étapes humaines.

Ce qui a été testé

  • Chaque scénario est rejoué depuis la machine Kali et doit déclencher la règle Wazuh attendue, puis la réponse Fail2Ban ; ce qui ne se déclenche pas est noté comme non couvert.

Limites connues

  • Lab isolé, sans trafic réel : les détections sont validées sur des attaques rejouées, pas sur un réseau en service.
  • Couverture MITRE ATT&CK partielle, limitée aux scénarios rejoués.
  • Aucune mesure de délai de détection publiée.

10 · Résultat

Le résultat

  • Un environnement où chaque détection est vérifiée par une attaque rejouée, pas supposée.
  • Une chaîne complète : événement, détection, analyse, réponse, récupération.

ProxmoxpfSenseKali LinuxUbuntu ServerWazuhFail2BanMITRE ATT&CK

Projet réalisé dans un laboratoire personnel isolé. Adresses, noms de machines et journaux affichés ici sont des exemples synthétiques.

11 · Documentation

Ce qui documente ce projet

  • La topologie, les règles de pare-feu et les extraits de journaux affichés ci-dessus sont synthétiques mais représentatifs du lab.
  • Chaque scénario est relié à une technique MITRE ATT&CK : la liste de ce qui est couvert, et de ce qui ne l’est pas, est tenue à jour dans le lab.
  • Ce projet est une preuve de culture système, de journalisation et de réponse à incident ; il n’est pas une offre de cybersécurité.
Parler de mon projet Projet suivant : Support d’une communauté en ligne : tri et routage automatiques