network-security-snort

Laboratoire 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).

Topologie réseau

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.

Remplacez ce schéma ASCII par screenshots/01-network-topology.png une fois que vous avez l’image en place : Topologie

Méthodologie

Le laboratoire se déroule en deux étapes avec une chaîne d’attaque identique à quatre vecteurs à chaque fois :

1. Reconnaissance ICMP — ping pour la découverte d’hôtes
2. Scan SYN Nmap — nmap -sS pour l’énumération des ports (1000 ports)
3. Attaque par force brute FTP Hydra — attaque sur les identifiants du service vsftpd
4. Backdoor vsftpd 2.3.4 — exploitation Metasploit pour CVE-2011-2523

É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.

Configuration pré-déploiement

1. Configurer l’Analyseur avec trois NICs dans VMware (deux host-only, une NAT/pont).
2. Activer le forwarding IP et ajouter les règles MASQUERADE + FORWARD pour que l’Analyseur route entre les sous-réseaux et vers le WAN — voir scripts/router_config.sh.
3. Vérifier la connectivité de bout en bout depuis chaque VM avec scripts/ping_check.sh avant d’installer Snort.

Configuration de Snort

Snort est installé via le gestionnaire de paquets Kali (sudo apt install snort -y) et configuré dans /etc/snort/snort.conf :

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 :

Règles de détection personnalisées

Cinq règles dans /etc/snort/rules/local.rules (fichier complet dans scripts/local.rules) :

Étape 1 — Mode IDS

Snort s’exécute en mode passif sur les deux interfaces internes :

Le message de démarrage confirme pcap DAQ configured to passive — Snort voit chaque paquet mais ne peut ni les supprimer ni les modifier.

Résultats IDS

Après avoir exécuté scripts/attack_simulator.sh depuis l’Attaquant :

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.

Étape 2 — Mode IPS

La couche IPS est déployée avec scripts/ips_setup.sh, qui :

1. Vide les règles iptables existantes
2. Réactive le forwarding IP et réapplique le routage de base
3. Applique quatre règles de blocage chirurgicales ciblant des signatures d’attaque spécifiques
4. Lance Snort en mode démon (-D) pour une journalisation continue

Règles iptables

Résultats IPS

Le même script d’attaque a été relancé depuis l’Attaquant :

Trafic normal préservé

Deux vérifications manuelles ont confirmé l’application sélective :

• ping -c 4 192.168.50.10 → 4 paquets transmis, 4 reçus, 0% de perte
• ftp 192.168.50.10 avec msfadmin:msfadmin → 220 (vsFTPd 2.3.4) … 230 Login successful

Preuve quantitative à partir des compteurs de paquets iptables pendant l’exécution : 2051 paquets acceptés, 12 paquets supprimés par la règle connlimit FTP, 808 paquets ICMP acceptés — application sélective en chiffres.

Journalisation Snort continue

Même en mode IPS, Snort a continué à déclencher les alertes SID 1000002 / 1000003 sur les paquets qui atteignaient son point d’inspection passif avant que iptables ne supprime les suivants — ce qui signifie qu’iptables assure l’application des règles tandis que Snort fournit la journalisation d’audit, fonctionnant de concert.

Résultats IDS vs IPS — Côte à côte

Discussion

Toutes les attaques simulées ont-elles été détectées en mode IDS ?

Oui — chacun des SID 1000001–1000004 s’est déclenché correctement pendant la simulation d’attaque :

• Ping ICMP (1000001) — alertes bidirectionnelles pour chaque écho/réponse.
• Scan SYN Nmap (1000003) — avalanche d’alertes en quelques millisecondes, randomisation caractéristique des ports source.
• Force brute FTP (1000002) — piste d’audit claire des tentatives de connexion parallèles d’Hydra avec horodatages précis.
• Backdoor vsftpd (1000004) — la correspondance de contenu :) a capturé exactement la séquence d’octets de l’exploit.

Mais détection ≠ prévention. L’exploit vsftpd a ouvert un shell root Meterpreter alors que toutes les alertes se déclenchaient. Un analyste SOC surveillant l’IDS en temps réel aurait vu la compromission — mais avec l’attaquant déjà root en quelques secondes, l’alerte seule ne suffit pas. C’est le cœur opérationnel de la raison d’être de l’IPS.

Quelle a été l’efficacité de l’IPS pour bloquer les attaques sans casser le trafic normal ?

La mise en œuvre a atteint une atténuation complète des attaques sans impact observable sur le trafic légitime. L’efficacité provient d’une conception chirurgicale des règles — chaque règle iptables cible une signature comportementale, pas un protocole large :

• Limitation de débit SYN brise le schéma d’inondation des scans de ports sans affecter les poignées de main normales.
• connlimit par source bloque le parallélisme des outils de force brute sans casser les sessions FTP uniques.
• Correspondance STRING supprime la charge utile exacte de l’exploit sans filtrer le trafic de connexion FTP légitime.

Une limitation reconnue : ICMP est entièrement autorisé, ce qui signifie qu’un attaquant peut toujours confirmer que Metasploitable est en vie via ping. Dans un environnement à plus haute sécurité, cela serait limité en débit ou restreint à des sources de confiance. Dans ce laboratoire, ICMP est le principal mécanisme de vérification de connectivité, il reste donc ouvert.

Machine Snort dédiée vs plugin pfSense/OPNsense

Ce laboratoire utilise une machine Snort dédiée. Comparé à l’exécution de Snort comme plugin à l’intérieur d’un pare-feu comme pfSense ou OPNsense :

Avantages de l’approche dédiée :

• Isolation des performances — CPU et RAM entièrement disponibles exclusivement pour l’inspection de paquets ; pas de contention avec le routage, DHCP, VPN, DNS.
• Flexibilité de positionnement — l’IDS/IPS peut être placé en ligne, sur un port SPAN/miroir, ou à une frontière de segment interne pour surveiller le trafic est-ouest qui n’atteint jamais le pare-feu périphérique.
• Contrôle total de la configuration — chaque préprocesseur, paramètre DAQ, plugin de sortie et calendrier de mise à jour des règles est configurable via CLI. pfSense n’expose qu’un sous-ensemble via son interface graphique.
• Résilience — la machine IDS/IPS peut être configurée en fail-open ou fail-closed indépendamment du routeur. Dans pfSense, un crash de Snort entraîne simultanément la perte du routage et de la détection.

Compromis :

• Courbe d’apprentissage plus raide — nécessite une compétence en ligne de commande et une gestion directe des ensembles de règles.
• Surcharge de maintenance — mises à jour de règles, mises à niveau de version, rotation des journaux, tout manuellement.

Snort dédié est le bon choix pour les environnements d’entreprise ayant besoin de performances, de positionnement et de personnalisation. L’approche plugin pfSense/OPNsense est plus adaptée aux environnements de petite entreprise ou de laboratoire à domicile où la facilité d’utilisation est prioritaire.

Note sur l’architecture

L’étape 2 est techniquement Snort passif + application iptables, et non Snort exécuté en mode inline véritable — Snort lui-même journalise (pcap DAQ configured to passive), et iptables effectue la suppression basée sur les limites de débit, les correspondances de chaînes et les comptages de connexions.

Il s’agit d’un modèle de déploiement légitime et courant (c’est ainsi que fonctionnent de nombreuses piles IDS/IPS Linux réelles). Une suite naturelle consisterait à migrer l’étape 2 vers une configuration inline véritable en utilisant snort --daq nfq (ou afpacket en mode inline) avec les actions de règle reject / drop de Snort, de sorte que Snort lui-même effectue la suppression sur la base de la correspondance complète des signatures plutôt que de déléguer à iptables.

Structure du dépôt

Reproduction du laboratoire

⚠️ Utilisation en laboratoire uniquement. Ces scripts exécutent de véritables exploits et outils de force brute contre une cible volontairement vulnérable. Ne les exécutez pas contre un système dont vous n’êtes pas propriétaire et pour lequel vous n’avez pas d’autorisation écrite explicite de test.

1. Construire trois VM dans VMware selon la topologie ci-dessus (VMnet9 et VMnet10 en host-only).
2. Sur l’Analyseur : exécuter scripts/router_config.sh, puis scripts/ping_check.sh pour confirmer la connectivité complète.
3. Installer Snort 3 sur l’Analyseur :
   root@kitploit:~

   sudo apt update && sudo apt install snort -y
   

4. Placer scripts/local.rules dans /etc/snort/rules/local.rules et définir HOME_NET = "10.10.10.0/24,192.168.50.0/24" dans /etc/snort/snort.conf.
5. Valider : sudo snort -T -c /etc/snort/snort.conf — attendre 652 règles chargées, 0 avertissements.
6. Étape 1 — IDS :
   root@kitploit:~

   sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 -A alert_fast -l /var/log/snort/
   # Dans un autre terminal :
   sudo tail -f /var/log/snort/alert_fast.txt
   

   Sur l’Attaquant : sudo ./scripts/attack_simulator.sh — observer les alertes se déclencher et le shell Meterpreter.
7. Étape 2 — IPS : sur l’Analyseur, exécuter sudo ./scripts/ips_setup.sh, puis relancer la chaîne d’attaque sur l’Attaquant. Confirmer les blocages, puis tester manuellement :
   root@kitploit:~

   ping -c 4 192.168.50.10        # doit réussir
   ftp 192.168.50.10              # msfadmin / msfadmin — doit réussir
   

Avertissement éthique

Toutes les activités documentées dans ce dépôt ont été menées exclusivement dans un environnement de laboratoire virtuel VMware autonome à des fins d’apprentissage académique supervisé. Aucun système externe, de production ou réel n’a été ciblé, scanné ou affecté de quelque manière que ce soit. Metasploitable 2 est une machine virtuelle intentionnellement vulnérable conçue spécifiquement pour la formation en sécurité.

Ce matériel ne doit pas être utilisé pour reproduire ces activités contre un système réel sans autorisation écrite explicite du propriétaire du système. Les scans de ports, attaques par force brute ou exploitation de services réseau non autorisés sont illégaux dans la plupart des juridictions.

Licence

MIT — voir LICENSE. Le rapport de laboratoire lui-même est fourni à titre de référence éducative.