🛡️ IDS/IPS — Snort et règles de détection

Introduction (10 min)

Dans cette séance nous verrons comment choisir, positionner et exploiter un IDS/IPS de façon rigoureuse pour réduire la fenêtre d'exploitation et limiter les exfiltrations.

🎯 Objectifs de la séance

À l'issue de cette séance, vous serez capable de :

• Expliquer la différence entre IDS (passif) et IPS (inline) et justifier un choix selon le besoin opérationnel.
• Distinguer HIDS et NIDS, et donner des exemples d'outils et d'emplacements pertinents dans l'infrastructure InnovatTech.
• Expliquer le fonctionnement des détections signature-based et anomaly-based, leurs forces/faiblesses, et les implications en termes de faux positifs/négatifs.
• Positionner un capteur (TAP, SPAN, inline) et configurer un port SPAN Cisco pour envoyer le trafic vers un capteur sur debian-srv01.
• Décrire l'architecture de Snort (préprocesseurs, syntaxe des règles, variables) et lire un log EVE JSON.

1. IDS vs IPS : concepts et choix (45 min)

Un IDS (Intrusion Detection System) est un système de surveillance passive qui observe le trafic réseau (ou les événements système) et génère des alertes sans modifier le flot des paquets. En revanche, un IPS (Intrusion Prevention System) est placé inline et peut bloquer ou modifier le trafic en temps réel lorsqu'une règle est déclenchée.

Le choix IDS/IPS dépend du risque acceptable pour l'activité : un IDS minimise les faux bloquages mais nécessite un processus de traitement des alertes ; un IPS protège activement mais peut interrompre des services critiques si mal configuré.

HIDS vs NIDS

HIDS (Host-based IDS) : installé sur un hôte, il analyse les journaux locaux, l'intégrité des fichiers, les appels système. Exemples : OSSEC, Wazuh. Utile pour compléter NIDS quand le trafic chiffré masque des activités.

NIDS (Network-based IDS) : capteur réseau (Snort / Suricata / Zeek) qui analyse les flux, reconstitue les sessions et applique des règles. Positionner un NIDS en SPAN/TAP permet d'observer tous les paquets d'un segment sans impacter la production.

Détection signature-based vs anomaly-based

Signature-based detection : repose sur des règles écrites (patterns, états, séquences).

• Avantages : faible taux de faux positifs sur signatures bien ciblées, performances prévisibles.
• Limites : vulnérable aux 0-day (faux négatifs) et aux variations d'attaque non couvertes par la signature.

Anomaly-based detection : construit une baseline comportementale (volumes, fréquences, entités), puis signale les écarts.

• Avantage : peut détecter des attaques inconnues.
• Inconvénient : forts faux positifs si la baseline n'est pas bien calibrée, complexité opérationnelle plus élevée.

Placement des capteurs

• TAP : miroir matériel, non intrusif, idéal pour surveillance passive sur liens fibre.
• SPAN / port mirror (Cisco) : simple à configurer, peut perdre des paquets sous forte charge.
• Inline (bridge) : déploiement en mode IPS (bloquant). Exemple : Suricata placé en mode bridge sur pfSense pour inspection HTTPS.

Exemple de configuration port SPAN sur Cisco Catalyst 2960 :

Switch> enable
Switch# configure terminal
Switch(config)# monitor session 1 source interface GigabitEthernet0/1 both
Switch(config)# monitor session 1 destination interface GigabitEthernet0/2
Switch(config)# end
Switch# show monitor session 1

Sortie attendue :

Session 1
----------
  Source Ports: Gi0/1 (both)
  Destination Ports: Gi0/2
  Encapsulation: Native

Schéma de positionnement — InnovatTech

                      Internet
                         │
                      [pfSense] WAN
                         │
                   Cisco ISR 4321
                         │
              ┌──────────┴──────────┐
              │                     │
       Catalyst 2960              DMZ switch
      (VLANs LAN)                   │
           │                        │
    Gi0/1 ─┴─> --------- (SPAN) --->|---> debian-srv01 (Snort, 192.168.10.10)
           │
        Hosts (VLAN 20)

2. Snort : architecture et format des règles (25 min)

Snort est un moteur de détection signature-based historiquement répandu. Son architecture comprend des préprocesseurs qui préparent et normalisent les paquets pour la détection :

• frag3 : reconstruction des paquets IP fragmentés et détection d'attaques sur fragments.
• stream5 : réassemblage des flux TCP (reconstruction du flux applicatif, suivi des états TCP).
• http_inspect : décode et normalise les requêtes HTTP pour permettre une inspection fiable des URI et des headers.

Syntaxe des règles Snort

Les règles Snort suivent la structure :

action proto src_ip src_port direction dst_ip dst_port (options)

Variables dans snort.conf

var HOME_NET 192.168.10.0/24
var EXTERNAL_NET any
var HTTP_PORTS [80,8080,8000]

Actions disponibles

Exemple de règle — Détection SSH brute-force

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"SSH Brute Force"; threshold:type both,track by_src,count 10,seconds 60; classtype:attempted-user; sid:9000001; rev:1;)

Cette règle déclenchera une alerte si une source externe effectue 10 connexions vers SSH en 60 secondes. L'option threshold limite les alertes pour réduire les faux positifs produits par des scans ponctuels.

Logs EVE JSON

Snort et Suricata peuvent produire des logs JSON compatibles EVE, utiles pour ingestion SIEM. Exemple d'événement EVE JSON :

{
  "timestamp": "2024-01-01T12:00:00.000000+0000",
  "event_type": "alert",
  "src_ip": "10.0.0.5",
  "src_port": 52344,
  "dest_ip": "192.168.10.10",
  "dest_port": 22,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "signature_id": 9000001,
    "signature": "SSH Brute Force",
    "severity": 3
  }
}

Champs clés : event_type (alert/http/dns/tls), src_ip/dest_ip, proto, alert.signature (nom de la règle), signature_id (sid) utile pour corrélation et suppression.

🔧 Travaux Pratiques (70 min)

Objectifs du TP

• Configurer un port SPAN sur le Catalyst 2960 vers debian-srv01.
• Déployer Snort en mode IDS passif sur debian-srv01.
• Lancer un scan Nmap et une tentative de brute-force SSH depuis la VM attaquante.
• Analyser le pcap et les alertes générées, et produire un rapport listant les signatures déclenchées.

Prérequis techniques

• Accès SSH/console sur Catalyst 2960 et debian-srv01 (Debian 12).
• Outils sur la VM attaquante : nmap, hydra, tcpdump.
• Sur debian-srv01 : snort installé et accès sudo.

Étape 1 — Configurer le port SPAN (Catalyst 2960)

# Exécuter depuis la console du switch
Switch> enable
Switch# configure terminal
Switch(config)# monitor session 1 source interface GigabitEthernet0/1 both
Switch(config)# monitor session 1 destination interface GigabitEthernet0/2
Switch(config)# end
Switch# show monitor session 1

✅ Vérification : la sortie doit indiquer Gi0/1 (both) comme source et Gi0/2 comme destination.

Étape 2 — Installer et démarrer Snort (debian-srv01)

# Mettre à jour et installer snort (Debian 12)
sudo apt update && sudo apt install -y snort
# Vérifier la version
snort -V
# Lancement interactif en mode console (adapter l'interface : eth0)
sudo snort -c /etc/snort/snort.conf -i eth0 -A console -q

Configurer la variable HOME_NET dans /etc/snort/snort.conf :

var HOME_NET 192.168.10.0/24
var EXTERNAL_NET any

Étape 3 — Générer un scan Nmap et une brute-force SSH (VM attaquante)

# Scan SYN simple sur les 1024 premiers ports
sudo nmap -sS -p1-1024 -T4 192.168.10.10 -oA /tmp/scan

# Tentative de brute-force SSH (wordlist courte pour TP)
sudo apt install -y hydra
hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.10.10 -t 4

Étape 4 — Capture et analyse du trafic

# Capturer le trafic miroiré sur debian-srv01
sudo tcpdump -i eth0 host 192.168.10.10 -w /tmp/scan.pcap
# Analyser avec tshark
sudo apt install -y tshark
tshark -r /tmp/scan.pcap -Y "ssh || tcp.flags.syn==1"

Étape 5 — Consulter les alertes Snort

# Fichier d'alertes (emplacement classique)
sudo tail -n 200 /var/log/snort/alert

✅ Extrait d'alerte attendu :

[**] [1:9000001:1] "SSH Brute Force" [**]
[Classification: Attempted User] [Priority: 2]
01/01-12:00:00.000000 10.0.0.5:52344 -> 192.168.10.10:22
TCP TTL:64 TOS:0x0 ID:54321 IpLen:20 DgmLen:60

Livrable attendu

• Le pcap /tmp/scan.pcap produit pendant la séance.
• Un fichier texte récapitulant : commandes exécutées, extrait de /var/log/snort/alert, et une liste des signatures déclenchées (sid, nom, description courte).

Critères de réussite

• ☐ Le port SPAN sur le Catalyst reflète correctement le trafic vers debian-srv01 (show monitor session 1).
• ☐ Snort est opérationnel et capture le trafic (snort -V et logs présents).
• ☐ Le scan Nmap et la tentative de brute-force SSH apparaissent comme alertes dans /var/log/snort/alert.
• ☐ Le livrable contient les extraits d'alertes, le pcap et une brève analyse des signatures déclenchées.

Synthèse (10 min)

Cette séance a posé les fondations : IDS = observation, IPS = action bloquante ; HIDS et NIDS se complètent ; les technologies signature-based détectent rapidement des patterns connus mais manquent les 0-day, tandis que l'anomaly-based détecte l'inattendu au prix d'un travail d'apprentissage et de tuning. Le bon placement (SPAN/TAP vs inline) et la qualité des procédures opérationnelles (tri des alertes, corrélation, runbooks) sont aussi importants que la technologie elle-même.

📝 QCM — Testez vos connaissances