1.
Introduction
Ce projet a pour objectif de concevoir et de mettre en œuvre une
architecture réseau de type Zero Trust Network dans un environnement
virtualisé à l’aide de GNS3 et VirtualBox. L’innovation principale réside
dans la mise en place d’une micro-segmentation dynamique : les règles
de sécurité s’adaptent automatiquement en fonction des alertes générées
par Suricata (IDS/IPS), en modifiant en temps réel les règles du pare-feu
pfSense.
Cette approche vise à renforcer la sécurité d’un réseau simulé en limitant la
surface d’attaque et en réagissant rapidement aux menaces détectées.
2. Étude de l’existant
2.1 Pratiques actuelles de segmentation réseau
Utilisation classique de VLAN statiques et de règles de pare-feu
définies manuellement.
Contrôle limité des communications inter-segments.
Détection d’intrusion réactive, non couplée à des actions
automatiques.
2.2 Limites identifiées
Temps de réaction élevé face aux menaces.
Difficulté à maintenir des règles de pare-feu adaptées en temps réel.
Exposition des segments réseau en cas de faille ou de mauvaise
configuration.
3. Solution proposée
3.1 Objectifs
Concevoir une architecture Zero Trust avec des segments isolés.
Intégrer un IDS/IPS (Suricata) pour surveiller le trafic réseau.
Automatiser l’adaptation des règles pfSense via API en fonction des
alertes.
Visualiser les événements via un tableau de bord.
3.2 Architecture générale
3.3 Automatisation dynamique
1. Détection automatique
La menace est repérée par des outils de surveillance
réseau ou des systèmes de détection d’intrusion (IDS),
comme Suricata ou Snort. Cette détection déclenche
immédiatement un script de réponse.
2. Script d’automatisation
Un script (Python ou Bash) est lancé pour initier une
réaction : préparation d’une requête vers une API de pare-
feu, identification de la source malveillante, et génération
d’une règle de blocage.
3. Appel API pare-feu
Le script communique avec le pare-feu via son API pour
proposer une règle de blocage (par IP, port ou protocole).
Cela permet une intégration fluide avec des solutions
comme pfSense, FortiGate, ou Palo Alto.
4. Validation par le SOC
Avant d’appliquer la règle, une validation est demandée
au centre de supervision de sécurité (SOC). Cela garantit
que seules les menaces confirmées entraînent des
blocages, réduisant les faux positifs.
5. Blocage automatisé et journalisation
Si la validation est approuvée :
Les règles sont appliquées au pare-feu.
La source malveillante est bloquée.
Une alerte est archivée.
Les événements sont enregistrés dans un SIEM
(ex. : ELK Stack, Splunk, Graylog).
6. Surveillance continue
Une fois l’action exécutée, le système retourne en mode
de surveillance continue, prêt à traiter d’autres menaces.
Cette boucle permet une cybersécurité proactive et
adaptative.
4. Objectifs détaillés et étapes
4.1 Préparation de l’environnement
Installer GNS3 et VirtualBox.
Déployer les VMs : pfSense, Suricata (si sur VM dédiée), XVWA, Kali,
Windows/Linux.
Créer plusieurs sous-réseaux/VLANs : [Link]/24,
[Link]/24, etc.
4.2 Configuration réseau
Configurer pfSense (interfaces LAN, DMZ, WAN).
Définir règles initiales de filtrage.
Activer l’API REST (pfSense-pkg-API).
4.3 Déploiement Suricata
Installation dans pfSense ou sur VM séparée.
Activation des règles Emerging Threats / Snort.
Configuration des logs au format JSON (EVE).
4.4 Automatisation dynamique
Développement d’un script qui :
o Analyse le fichier [Link].
o Détecte les alertes critiques.
o Modifie les règles via l’API pfSense (ex : blocage IP, interdiction
d’un segment).
4.5 Cas de test
Attaque avec Kali (SQLi, XSS).
Vérification : détection, génération de log, réaction automatique.
4.6 Supervision
Intégration ELK ou Grafana/Loki.
Affichage des alertes et règles modifiées.
5. Composants techniques
Composant Rôle OS/Version
pfSense Pare-feu, API, FreeBSD / dernière version stable
routage
Suricata IDS/IPS Intégré à pfSense ou VM dédiée
(Linux)
XVWA Serveur vulnérable Linux / Apache, PHP
Kali Linux Générateur Linux Kali dernière version
d’attaques
Windows/Linux Poste utilisateur Win10 / Ubuntu 20.04
client
GNS3 + Virtualisation/ Windows/Linux hôte
VirtualBox simulation
Composant Rôle OS/Version
ELK / Grafana Supervision Linux / Docker optionnel
6. Résultats attendus
Blocage automatique des menaces détectées.
Micro-segmentation dynamique opérationnelle.
Tableaux de bord fonctionnels pour suivi des événements et règles
actives.
7. Pistes d’amélioration
Intégration d’un SIEM comme Wazuh.
Notifications automatiques (SMS/WhatsApp via Twilio).
Ajout de machine learning pour classifier les alertes (faux positifs,
vraies menaces).
Schéma simplifié de l’architecture complète
+--------------------+
| ELK / Grafana |
| Tableau de bord |
+--------------------+
^
| Logs & supervision
|
+-------------+ +-----------+-----------+ +-------------------+
| WAN | <----> | pfSense | <----> | DMZ |
| (Internet) | | Interfaces: WAN, LAN, DMZ | | XVWA (Web vuln.) |
+-------------+ +-----------+-----------+ +-------------------+
|
|
LAN (commutateur VLAN)
------------------------------------------------------------
| | |
VLAN 10: Kali Linux VLAN 20: Windows ADDS VLAN 30: Client
Linux
+-------------+ +-------------------------------------+
+--------------------------+
| Kali Linux | | Windows Server ADDS | | Client Linux
|
+-------------+ +---------------------------------+
Schéma illustrant l’automatisation dynamique
[Suricata] --Détecte menace--> [Script Automation] --API--> [pfSense
règle dynamique]
| |
v v
[Génération alerte] [Blocage IP
/ segment]
👉 Ce cahier des charges peut être enrichi par des schémas graphiques
réalisés avec des outils comme [Link] si besoin.