taisa456/network-security-snortLaboratoire Snort 3 IDS → IPS sur Kali. Règles de détection personnalisées + application iptables contre la reconnaissance ICMP, les scans SYN Nmap, la force brute FTP avec Hydra, et la backdoor vsftpd 2.3.4 (CVE-2011-2523).
Un déploiement complet de Snort 3 à la fois en tant que système de détection d’intrusion (monitoring passif) et système de prévention d’intrusion (blocage actif via iptables), validé contre quatre vecteurs d’attaque au sein d’un réseau virtuel de trois machines sur Kali Linux.
Le laboratoire démontre la distinction opérationnelle entre détection et prévention en exécutant deux fois une même chaîne d’attaque à quatre vecteurs — d’abord contre un IDS qui journalise mais ne peut pas bloquer, puis contre une couche IDS + IPS basée sur iptables qui bloque les attaques de manière sélective tout en préservant le trafic légitime.
| Composant | Détails |
|---|---|
| Analyseur / Routeur | Kali Linux — 3 adaptateurs : eth0 WAN (192.168.10.143, NAT), eth1 LAN1 (10.10.10.1, host-only), eth2 LAN2 (192.168.50.1, host-only) |
| Attaquant | Kali Linux — eth0 sur VMnet9 (10.10.10.10) — passerelle par défaut 10.10.10.1 |
| Cible | Metasploitable 2 — eth0 sur VMnet10 (192.168.50.10) — passerelle par défaut 192.168.50.1 |
| Version de Snort | Snort++ 3.12.1.0-0kali1 (installé sur l’Analyseur) |
| Outils d’attaque | Nmap 7.99, Hydra v9.6, Metasploit Framework (msfconsole) |
| Virtualisation | VMware — VMnet9 = 10.10.10.0/24, VMnet10 = 192.168.50.0/24 (tous deux host-only) |
Tout le trafic entre l’Attaquant et Metasploitable est obligé de passer par l’Analyseur, ce qui en fait le point de contrôle naturel à la fois pour la surveillance et l’application des règles.
┌─────────────────────────┐
│ Analyseur / Routeur │
│ Kali + Snort 3 │
│ │
Attaquant Kali ──VMnet9──┤ eth1: 10.10.10.1 │
10.10.10.10 │ │
│ eth0: 192.168.10.143 ───┼──> WAN (NAT)
│ │
Metasploitable 2 ─VMnet10┤ eth2: 192.168.50.1 │
192.168.50.10 │ │
└─────────────────────────┘
Remplacez ce schéma ASCII par
screenshots/01-network-topology.pngune fois que vous avez l’image en place :Topologie
Le laboratoire se déroule en deux étapes avec une chaîne d’attaque identique à quatre vecteurs à chaque fois :
ping pour la découverte d’hôtesnmap -sS pour l’énumération des ports (1000 ports)Étape 1 (IDS) exécute Snort en mode passif sur l’Analyseur avec cinq règles personnalisées — observer les alertes en temps réel, confirmer que l’exploitation se déroule malgré tout.
Étape 2 (IPS) associe Snort à une couche d’application iptables utilisant des règles de blocage chirurgicales — confirmer que les attaques sont bloquées tandis que le ping ICMP et la connexion FTP légitime restent fonctionnels.
MASQUERADE + FORWARD pour que l’Analyseur route entre les sous-réseaux et vers le WAN — voir scripts/router_config.sh.scripts/ping_check.sh avant d’installer Snort.Snort est installé via le gestionnaire de paquets Kali (sudo apt install snort -y) et configuré dans /etc/snort/snort.conf :
HOME_NET = "10.10.10.0/24,192.168.50.0/24"
EXTERNAL_NET = "any"
ips = {
enable_builtin_rules = true,
include = "/etc/snort/rules/local.rules",
variables = default_variables
}
alert_fast = { file = true, packet = false }
HOME_NET couvre les deux sous-réseaux internes afin que Snort considère tout le trafic inter-sous-réseaux sur l’Analyseur comme digne d’inspection. alert_fast produit des alertes compactes sur une ligne (la journalisation paquet par paquet générerait un volume excessif).
Validation de la configuration :
sudo snort -T -c /etc/snort/snort.conf
# Résultat : 652 règles chargées (5 personnalisées textuelles + 647 intégrées), 0 avertissements
Cinq règles dans /etc/snort/rules/local.rules (fichier complet dans scripts/local.rules) :
| SID | Nom | Déclencheur |
|---|---|---|
| 1000001 | Ping ICMP détecté | Tout trafic ICMP dans les deux sens — détecte les pings de reconnaissance |
| 1000002 | Tentative de connexion FTP | Toute connexion TCP vers le port 21 — détecte le trafic légitime et la force brute |
| 1000003 | Possible scan SYN Nmap | Paquets TCP avec uniquement le flag SYN (flags:S) — signature d’un scan half-open |
| 1000004 | Tentative de backdoor VSFTPD 2.3.4 | content:":)" sur le port FTP 21 — la chaîne exacte du déclencheur CVE-2011-2523 |
| 1000005 | Possible shellcode Metasploit | `content:" |
Snort s’exécute en mode passif sur les deux interfaces internes :
sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 \
-A alert_fast -l /var/log/snort/
# Surveiller les alertes dans un second terminal :
sudo tail -f /var/log/snort/alert_fast.txt
Le message de démarrage confirme pcap DAQ configured to passive — Snort voit chaque paquet mais ne peut ni les supprimer ni les modifier.
Après avoir exécuté scripts/attack_simulator.sh depuis l’Attaquant :
| Attaque | Détection | Résultat |
|---|---|---|
| Reconnaissance ICMP | ✅ SID 1000001 — alertes bidirectionnelles | Ping terminé |
| Scan SYN Nmap | ✅ SID 1000003 — milliers d’alertes en <1 seconde | 23 ports ouverts énumérés |
| Force brute FTP Hydra | ✅ SID 1000002 — alertes répétées de connexion FTP | Identifiants msfadmin:msfadmin découverts |
| Backdoor vsftpd 2.3.4 | ✅ SID 1000004 — correspondance de contenu :) déclenchée | Shell root Meterpreter obtenu |
L’IDS a tout détecté et n’a rien arrêté. C’est la leçon centrale de l’étape 1 : un IDS fonctionnel sans application des règles est un système d’alarme, pas une serrure. Au moment où un analyste SOC lit les alertes, l’attaquant est déjà root.
Observation secondaire : les règles intégrées de Snort (116:408, 116:414) se déclenchent sur le trafic DHCP broadcast — pas malveillant, mais dans un déploiement en production, elles nécessiteraient des règles de suppression pour garder le journal d’alertes exploitable.
La couche IPS est déployée avec scripts/ips_setup.sh, qui :