TP Jour 3 — Suricata & Wazuh

Horaire	Activité	VM(s)	Durée
09h00 – 09h45	Cours — NIDS vs HIDS, architecture Suricata, modes IDS/IPS	—	45 min
09h45 – 10h30	Cours — Architecture Wazuh (Manager / Agent / Ruleset), FIM, rootcheck	—	45 min
10h30 – 10h45	Pause	—	15 min
10h45 – 13h00	TP 1 — Installation Suricata + centralisation alertes dans Splunk	SOC + Cible	2h15
13h00 – 14h00	Pause déjeuner	—	1h
14h00 – 17h30	TP 2 — Installation Wazuh Manager + Agent + centralisation Splunk	SOC + Cible	3h30
17h30 – 18h00	Validation + débrief + snapshot	—	30 min

📌

Flux de données de ce TP

Trafic réseau → Suricata (VM SOC, écoute sur l'interface NAT) → /var/log/suricata/eve.json → Splunk UF (VM SOC) → Splunk index=security

Installation de Suricata VM SOC

⏱ ~30 min

Installer Suricata depuis le PPA officiel VM SOC

Le paquet Suricata du dépôt Ubuntu standard est souvent en retard de version. On utilise le PPA officiel de l'OISF pour avoir la dernière version stable.

TerminalVM SOC

sudo apt update
sudo apt install -y software-properties-common

# Ajouter le PPA officiel OISF
sudo add-apt-repository ppa:oisf/suricata-stable -y
sudo apt update
sudo apt install -y suricata

# Vérifier la version installée
suricata --build-info | head -5

Identifier l'interface réseau NAT VMware VM SOC

Suricata doit écouter sur l'interface qui reçoit le trafic du réseau NAT VMware — c'est celle qui porte l'IP 192.168.91.x.

TerminalVM SOC

# Trouver l'interface qui porte l'IP NAT VMware
ip a | grep -B2 "192.168.91"
# → Le nom de l'interface est affiché juste au-dessus (ex: ens33, ens32, eth0)

# Alternative : lister toutes les interfaces
ip link show
# → Repérer l'interface qui n'est pas "lo" ni "docker" ni "veth"

# Exemple typique sur VMware Workstation :
# ens33 → interface NAT principal

⚠️

Noter le nom de l'interface

Il sera utilisé dans toutes les étapes suivantes. Sur VMware Workstation avec Ubuntu 22.04, c'est généralement ens33. Sur d'autres configurations : ens32, eth0, enp0s3. Ne pas confondre avec lo (loopback).

Configuration de Suricata VM SOC

⏱ ~30 min

Configurer le fichier suricata.yaml VM SOC

On configure les trois paramètres essentiels : l'interface d'écoute, les réseaux à considérer comme "maison" (HOME_NET), et le format de sortie EVE JSON.

Terminal — modifications ciblées dans suricata.yamlVM SOC

# 1. Définir HOME_NET avec le sous-réseau NAT VMware
sudo sed -i 's|HOME_NET: "\[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12\]"|HOME_NET: "[192.168.91.0/24]"|' \
  /etc/suricata/suricata.yaml

# 2. Vérifier la modification
grep "HOME_NET" /etc/suricata/suricata.yaml | head -3

# 3. Vérifier que la sortie EVE JSON est activée (elle l'est par défaut)
grep -A5 "eve-log:" /etc/suricata/suricata.yaml | head -10
# → Doit afficher : enabled: yes et filename: eve.json

/etc/suricata/suricata.yaml — section af-packet (interface)VM SOC

# Trouver et modifier la section af-packet pour pointer sur l'interface NAT
# Remplacer "ens33" par le nom réel de votre interface

grep -n "af-packet" /etc/suricata/suricata.yaml | head -5
# → Repérer la ligne avec "- interface: eth0" ou similaire

# Modifier via sed (adapter eth0 et ens33 selon votre config)
sudo sed -i 's/- interface: eth0/- interface: ens33/' /etc/suricata/suricata.yaml

# Vérifier
grep "interface:" /etc/suricata/suricata.yaml | head -3

Télécharger et activer les règles de détection VM SOC

suricata-update est l'outil officiel pour gérer les règles. Sur Suricata 8.x, il est déjà inclus dans le paquet — pas besoin de pip.

TerminalVM SOC

# Vérifier que suricata-update est disponible (inclus dans Suricata 8.x)
which suricata-update
suricata-update --version

# Si absent sur votre version, l'installer via apt (pas pip) :
# sudo apt install -y suricata-update

# Mettre à jour l'index des sources puis télécharger les règles ET/open (~30 Mo)
sudo suricata-update update-sources
sudo suricata-update

# Vérifier les règles téléchargées
ls -lh /var/lib/suricata/rules/
sudo wc -l /var/lib/suricata/rules/suricata.rules
# → 49 000+ règles avec Suricata 8.x

⚠️

Ne pas utiliser pip3 install suricata-update --break-system-packages

Cette option n'existe pas sur toutes les versions de pip et est inutile ici — suricata-update est embarqué nativement dans Suricata 8.x. Si vraiment absent : sudo apt install -y suricata-update.

💡

Anatomie d'une règle Suricata

alert tcp any any -> $HOME_NET 22 (msg:"ET SCAN SSH Scan"; flags:S; threshold:type both,track by_src,count 5,seconds 60; sid:2001219; rev:20;)
action alert · protocole tcp · source any · destination HOME_NET port 22 · options : message, seuil, identifiant

Démarrage et premier test de Suricata VM SOC

⏱ ~20 min

Valider la configuration et démarrer Suricata VM SOC

TerminalVM SOC

# Valider la configuration (test à sec)
sudo suricata -T -c /etc/suricata/suricata.yaml -v 2>&1 | tail -5
# → Doit afficher : "Configuration provided was successfully loaded."

# Démarrer Suricata
sudo systemctl enable --now suricata

# Vérifier le démarrage
sudo systemctl status suricata

# Suivre les logs de démarrage
sudo tail -f /var/log/suricata/suricata.log
# → Attendre les messages "engine started"
# → Ctrl+C pour quitter le suivi

✅

Résultat attendu

Le service Suricata est active (running) et le fichier /var/log/suricata/eve.json existe et grandit au fur et à mesure du trafic réseau.

Créer une règle locale Nmap et tester la détection Les deux VMs

Les règles ET/open ne contiennent pas de règle générique pour les scans SYN basiques. Il faut créer une règle locale dans /etc/suricata/rules/local.rules — c'est aussi la pratique SOC réelle pour les règles métier personnalisées.

Terminal — créer la règle de détection SYN scanVM SOC

# Créer le répertoire et le fichier de règles locales
sudo mkdir -p /etc/suricata/rules

sudo bash -c 'cat > /etc/suricata/rules/local.rules' << 'ENDOFFILE'
alert tcp any any -> $HOME_NET any (msg:"SCAN nmap SYN scan detected"; flags:S; threshold:type threshold,track by_src,count 5,seconds 3; sid:9000001; rev:1;)
ENDOFFILE

cat /etc/suricata/rules/local.rules

Terminal — activer local.rules dans suricata.yamlVM SOC

# Trouver le numéro de ligne de la section rule-files
grep -n "rule-files" /etc/suricata/suricata.yaml

# Ouvrir le fichier et ajouter local.rules dans la section rule-files :
sudo nano /etc/suricata/suricata.yaml
# Chercher "rule-files:" et ajouter en dessous :
#   - /etc/suricata/rules/local.rules

# Valider la configuration
sudo suricata -T -c /etc/suricata/suricata.yaml -v 2>&1 | tail -3
# → Doit afficher : "Configuration provided was successfully loaded."

sudo systemctl restart suricata

💡

Pourquoi un threshold à 5 paquets en 3 secondes ?

Sans threshold, chaque paquet SYN TCP normal déclenche une alerte — Splunk serait noyé. Un scan nmap sur 1000 ports envoie 1000 SYN en moins d'une seconde : le seuil de 5 est largement atteint en pratique. C'est le compromis fondamental détection/faux positifs.

Terminal — lancer le scan Nmap depuis la VM cibleVM CIBLE

sudo apt install -y nmap

# Un seul scan suffit — nmap envoie des centaines de SYN en une fraction de seconde
# Remplacer 192.168.91.10 par l'IP réelle de votre VM SOC
nmap -sS -p 1-1000 192.168.91.10

Terminal — vérifier les alertesVM SOC

# Vérifier dans fast.log (plus lisible que eve.json pour un test rapide)
sudo tail -20 /var/log/suricata/fast.log
# → Doit afficher : [**] SCAN nmap SYN scan detected [**]

# Voir toutes les signatures déclenchées dans eve.json
sudo grep '"event_type":"alert"' /var/log/suricata/eve.json   | python3 -c "import sys,json; [print(json.loads(l)['alert']['signature']) for l in sys.stdin]"   | sort | uniq -c | sort -rn | head -10

✅

Résultat attendu

Dans fast.log : [**] [1:9000001:1] SCAN nmap SYN scan detected [**] avec 192.168.91.20 → 192.168.91.10.
Vous pouvez aussi voir ET SCAN Possible Nmap User-Agent Observed — une règle ET/open qui détecte le User-Agent HTTP de nmap. Deux couches de détection pour un seul scan.

🚨

Attention au disque pendant les tests Nmap

Chaque scan génère des milliers d'entrées dans eve.json. Si le disque se remplit, le système entier se bloque. Après les tests, vider le fichier : sudo truncate -s 0 /var/log/suricata/eve.json. Vérifier l'espace : df -h /.

Centraliser les alertes Suricata dans Splunk VM SOC

⏱ ~35 min

Configurer le Splunk UF pour lire eve.json VM SOC

Au Jour 2, le Splunk UF a été installé sur la VM cible. Ici, il faut l'installer sur la VM SOC pour lire les fichiers locaux (eve.json de Suricata, alerts.json de Wazuh).

⚠️

Deux instances Splunk sur la VM SOC = conflit de port

Splunk Enterprise utilise le port management 8089. Le Splunk UF doit utiliser un port différent — choisir 8090 quand le démarrage demande un port de management.

Terminal — installer le Splunk UF sur la VM SOCVM SOC

# Vérifier si le UF est déjà présent
sudo /opt/splunkforwarder/bin/splunk status 2>/dev/null || echo "UF absent, installation nécessaire"

# Si absent : télécharger et installer (URL fournie par l'enseignant)
wget -O /tmp/splunkforwarder.deb "URL_FOURNIE"
sudo dpkg -i /tmp/splunkforwarder.deb

# Premier démarrage — définir un compte admin UF (ex: admin / même mdp que Splunk)
# Si "port 8089 already in use" → entrer 8090 quand demandé
sudo /opt/splunkforwarder/bin/splunk start --accept-license --answer-yes --no-prompt

# Activer le démarrage automatique
sudo /opt/splunkforwarder/bin/splunk enable boot-start

# Pointer le UF vers Splunk Enterprise (qui écoute sur le même hôte port 9997)
# Remplacer VOTRE_MOT_DE_PASSE par celui défini ci-dessus
sudo /opt/splunkforwarder/bin/splunk add forward-server 192.168.91.10:9997   -auth admin:VOTRE_MOT_DE_PASSE

# Vérifier la connexion
sudo /opt/splunkforwarder/bin/splunk list forward-server

🚨

IMPORTANT — SSL obligatoire sur Splunk Enterprise récent

Splunk Enterprise 9.x configure par défaut la réception en SSL (splunktcp-ssl:9997). Si le UF reçoit Connection reset by peer, vérifier /opt/splunk/etc/system/local/inputs.conf — si la ligne [splunktcp-ssl:9997] est présente, le UF doit envoyer en SSL. Dans ce cas ajouter dans /opt/splunkforwarder/etc/system/local/outputs.conf :

useSSL = true
sslVerifyServerCert = false

Puis redémarrer : sudo /opt/splunkforwarder/bin/splunk restart

TerminalVM SOC

# Ajouter Suricata eve.json aux sources du Forwarder
sudo bash -c 'cat >> /opt/splunkforwarder/etc/system/local/inputs.conf' << 'ENDOFFILE'

[monitor:///var/log/suricata/eve.json]
index = security
sourcetype = suricata
ENDOFFILE

# Vérifier l'ajout
cat /opt/splunkforwarder/etc/system/local/inputs.conf | grep -A3 "suricata"

# Autoriser le Forwarder à lire les logs Suricata
sudo chmod 644 /var/log/suricata/eve.json
sudo usermod -aG adm splunk 2>/dev/null || true

# Redémarrer le Forwarder
sudo /opt/splunkforwarder/bin/splunk restart

Vérifier les alertes Suricata dans Splunk + Exercices SPL VM SOC

Depuis l'interface Splunk, vérifier l'arrivée des alertes et explorer les données.

Exercice 1 — Voir les événements Suricata

index=security sourcetype=suricata

# ❓ Quels event_type voyez-vous ? (alert, dns, http, tls, flow...)
# ❓ Suricata génère plus que des alertes — c'est un NIDS complet

Exercice 2 — Isoler les alertes uniquement ⭐ LIVRABLE

index=security sourcetype=suricata event_type=alert
| spath output=signature path=alert.signature
| spath output=src_ip path=src_ip
| spath output=dest_ip path=dest_ip
| spath output=severity path=alert.severity
| stats count by signature, src_ip, severity
| sort -count

# ⭐ LIVRABLE : Screenshot → binome_tp3_suricata.png
# ❓ Quelle signature est déclenchée le plus souvent ?
# ❓ Quelle est l'IP source des scans détectés ?

📌

Signatures attendues dans les résultats

Vous devriez voir au moins deux signatures :
— SCAN nmap SYN scan detected (votre règle locale — plusieurs centaines d'occurrences)
— ET SCAN Possible Nmap User-Agent Observed (règle ET/open — quelques occurrences)
L'IP source est celle de votre VM cible (192.168.91.20). Les alertes SURICATA Applayer Detect protocol only one direction ou SURICATA HTTP request missing protocol sont des anomalies de protocole internes à Suricata — elles sont normales et sans risque.

Exercice 3 — Corréler avec Fail2ban (attaque complète)

# Voir la séquence : scan Suricata → tentatives SSH → ban Fail2ban
index=security (sourcetype=suricata event_type=alert)
             OR (sourcetype=linux_secure "Failed password")
             OR (sourcetype=fail2ban "Ban")
| eval source_tool=case(sourcetype=="suricata","1_Suricata",
                        sourcetype=="linux_secure","2_SSH_fail",
                        sourcetype=="fail2ban","3_Fail2ban")
| stats count by source_tool
| sort source_tool

# ❓ Suricata a-t-il détecté le scan avant que Fail2ban ne réagisse ?

🚨

Si aucune alerte dans Splunk après 5 minutes

1. Vérifier que le Forwarder lit le fichier : sudo tail -f /var/log/splunk/splunkd.log | grep suricata
2. Vérifier les permissions : ls -la /var/log/suricata/eve.json — doit être lisible par tous.
3. Regénérer du trafic depuis la VM cible (nmap, curl) pour alimenter eve.json.
4. Vérifier dans Splunk que l'index security reçoit bien des données récentes.

📌

Architecture Wazuh dans ce lab

Wazuh Manager (VM SOC :1514/UDP) ← reçoit ← Wazuh Agent (VM cible Linux) → analyse → Alertes → /var/ossec/logs/alerts/alerts.json → Splunk UF → Splunk

Installation du Wazuh Manager VM SOC

⏱ ~45 min

Ajouter le dépôt Wazuh et installer le Manager VM SOC

TerminalVM SOC

# Installer les dépendances
sudo apt install -y curl gnupg

# Ajouter la clé GPG Wazuh
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH \
  | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
sudo chmod 644 /usr/share/keyrings/wazuh.gpg

# Ajouter le dépôt Wazuh 4.x
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update

# Installer le Manager
sudo apt install -y wazuh-manager

# Démarrer et activer
sudo systemctl enable --now wazuh-manager

# Vérifier le démarrage (peut prendre 30-60 secondes)
sudo systemctl status wazuh-manager

✅

Résultat attendu

Le service wazuh-manager est active (running). Le répertoire /var/ossec/ existe avec les sous-dossiers logs/, rules/, etc/.

Ouvrir le port Wazuh sur la VM SOC VM SOC

TerminalVM SOC

# Port 1514 UDP : communication agent → manager
sudo ufw allow from 192.168.91.0/24 to any port 1514 proto udp

# Port 1515 TCP : enregistrement des agents (optionnel selon version)
sudo ufw allow from 192.168.91.0/24 to any port 1515 proto tcp

sudo ufw reload

# Vérifier que Wazuh écoute
ss -ulnp | grep 1514

Installation de l'agent Wazuh sur la VM cible

⏱ ~30 min

Installer l'agent Wazuh VM Cible

Le même dépôt est utilisé sur la VM cible, mais on installe le paquet wazuh-agent au lieu du Manager.

TerminalVM CIBLE

# Ajouter le dépôt Wazuh (même procédure que sur le Manager)
sudo apt install -y curl gnupg
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH \
  | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
sudo chmod 644 /usr/share/keyrings/wazuh.gpg

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update

# Installer l'agent en définissant l'adresse du Manager
# Remplacer 192.168.91.10 par l'IP réelle de votre VM SOC
WAZUH_MANAGER="192.168.91.10" sudo apt install -y wazuh-agent

# Démarrer l'agent
sudo systemctl enable --now wazuh-agent

# Vérifier le statut
sudo /var/ossec/bin/wazuh-control status

Vérifier la connexion Agent ↔ Manager Les deux VMs

Terminal — depuis la VM SOCVM SOC

# Lister les agents connectés
sudo /var/ossec/bin/agent_control -l

# Résultat attendu :
# ID: 001, Name: dis-client, IP: 192.168.91.20, Status: Active

# Vérifier les logs du Manager
sudo tail -20 /var/ossec/logs/ossec.log | grep -i "agent\|connect"

Terminal — depuis la VM cibleVM CIBLE

# Vérifier le statut de l'agent
sudo /var/ossec/bin/wazuh-control status

# Vérifier les derniers logs de l'agent (Wazuh 4.x ne logue plus "Connected to:" explicitement)
sudo tail -20 /var/ossec/logs/ossec.log
# → Chercher : wazuh-agentd started, logcollector started, syscheckd started
# → L'absence de messages d'erreur = connexion OK

🚨

Si l'agent n'apparaît pas dans la liste

1. Vérifier la config de l'agent : cat /var/ossec/etc/ossec.conf | grep "address" — doit afficher l'IP de la VM SOC.
2. Tester la connectivité UDP : nc -zuv 192.168.91.10 1514 depuis la VM cible.
3. Vérifier UFW sur la VM SOC : sudo ufw status | grep 1514.
4. Redémarrer les deux services : sudo systemctl restart wazuh-manager + sudo systemctl restart wazuh-agent.

Déclencher et observer les alertes Wazuh

⏱ ~40 min

Déclencher des alertes Wazuh — FIM et SSH Les deux VMs

Wazuh génère des alertes sur de nombreux événements. Voici les plus intéressants à déclencher en TP.

⚠️

Points importants avant de commencer

1. Le FIM (surveillance d'intégrité) tourne par défaut toutes les 12h. Il faut réduire la fréquence à 60s pour les tests du TP.
2. alerts.log n'existe que sur la VM SOC (manager). Sur la VM cible (agent), ce fichier n'existe pas — c'est normal et attendu.
3. Créer les fichiers de test après le restart de Wazuh, sinon ils font partie de la baseline et ne génèrent aucune alerte.

Étape préalable — Réduire la fréquence FIM à 60s sur les DEUX VMsLes deux VMs

# Sur la VM SOC et sur la VM cible — même manipulation
sudo nano /var/ossec/etc/ossec.conf
# Chercher la section <syscheck> et modifier <frequency> :
# <frequency>60</frequency>  ← mettre 60 au lieu de 43200

# Vérifier l'absence de doublon (une seule valeur dans syscheck)
grep -n "frequency" /var/ossec/etc/ossec.conf | head -5

# Sur la VM SOC : redémarrer le manager
sudo /var/ossec/bin/wazuh-control restart

# Sur la VM cible : redémarrer l'agent
sudo systemctl restart wazuh-agent

Alerte 1 — FIM : créer un fichier test APRÈS le restartVM CIBLE

# Attendre 30 secondes après le restart de l'agent
# puis créer un fichier dans /etc (surveillé par défaut)
# CRUCIAL : créer après le restart — sinon il fait partie de la baseline
sudo touch /etc/test_wazuh_fim
sudo echo "test" | sudo tee /etc/test_wazuh_fim

Vérification FIM — UNIQUEMENT sur la VM SOC (manager)VM SOC

# Attendre 60-90 secondes que le scan FIM tourne
# Vérifier que le scan s'est bien déclenché :
sudo grep "scan started\|scan ended" /var/ossec/logs/ossec.log | tail -5

# Chercher les alertes FIM (règles 550/553/554)
sudo tail -200 /var/ossec/logs/alerts/alerts.log | grep -i "554\|553\|550\|test_wazuh\|added\|deleted"
# → Doit afficher :
# Rule: 554 (level 5) -> 'File added to the system.'
# File '/etc/test_wazuh_fim' added

# ⚠️ Si rien n'apparaît : forcer le scan depuis le manager
sudo /var/ossec/bin/agent_control -r -u 003
# puis attendre 60 secondes et relancer la vérification

📌

Règles FIM Wazuh et architecture de centralisation

Règle 554 niveau 5 → fichier ajouté. Règle 553 niveau 7 → fichier modifié. Règle 550 niveau 7 → fichier supprimé.
Les alertes sudo/PAM qui apparaissent également sont normales — Wazuh surveille les élévations de privilèges.
Architecture importante : l'agent (VM cible) détecte et envoie au manager (VM SOC) qui centralise dans alerts.log. Il n'y a pas d'alerts.log sur l'agent.

Alerte 2 — Tentatives SSH échouéesVM SOC

# Générer des tentatives SSH échouées vers la VM cible
for i in {1..5}; do
  ssh -o ConnectTimeout=3 -o StrictHostKeyChecking=no \
    wazuhtest@192.168.91.20 2>/dev/null || true
done

# Vérifier les alertes SSH côté manager
sudo tail -20 /var/ossec/logs/ossec.log

Consulter toutes les alertes en temps réel (format lisible)VM SOC

sudo tail -f /var/ossec/logs/alerts/alerts.json \
  | python3 -c "
import sys, json
for line in sys.stdin:
    try:
        a = json.loads(line)
        agent = a.get('agent',{}).get('name','?')
        level = a.get('rule',{}).get('level','?')
        desc  = a.get('rule',{}).get('description','?')
        print(f'[L{level}] {agent} - {desc}')
    except: pass
"

Centraliser les alertes Wazuh dans Splunk VM SOC

⏱ ~50 min

Configurer le Splunk UF pour lire alerts.json VM SOC

TerminalVM SOC

# Ajouter le fichier alerts.json Wazuh aux sources du Forwarder
sudo bash -c 'cat >> /opt/splunkforwarder/etc/system/local/inputs.conf' << 'ENDOFFILE'

[monitor:///var/ossec/logs/alerts/alerts.json]
index = security
sourcetype = wazuh
ENDOFFILE

# Autoriser le Forwarder à lire les fichiers Wazuh
sudo chmod 644 /var/ossec/logs/alerts/alerts.json
sudo chmod 755 /var/ossec/logs/alerts/

🚨

IMPORTANT — SSL obligatoire si Splunk Enterprise écoute en splunktcp-ssl

Splunk Enterprise 9.x configure la réception en SSL par défaut (splunktcp-ssl:9997). Si le Forwarder reçoit Connection reset by peer, c'est que le Forwarder envoie en clair alors que Splunk attend du SSL. La solution : ajouter useSSL = true dans outputs.conf.

Vérifier : cat /opt/splunk/etc/system/local/inputs.conf | grep splunktcp
Si la ligne contient [splunktcp-ssl:9997] → appliquer la config SSL ci-dessous.

/opt/splunkforwarder/etc/system/local/outputs.conf — config SSL si nécessaireVM SOC

# Vérifier le contenu actuel
cat /opt/splunkforwarder/etc/system/local/outputs.conf

# Si Splunk Enterprise écoute en splunktcp-ssl, réécrire outputs.conf avec SSL :
sudo bash -c 'cat > /opt/splunkforwarder/etc/system/local/outputs.conf' << 'ENDOFFILE'
[tcpout]
defaultGroup = default-autolb-group

[tcpout:default-autolb-group]
server = 192.168.91.10:9997
useSSL = true
sslVerifyServerCert = false

[tcpout-server://192.168.91.10:9997]
useSSL = true
sslVerifyServerCert = false
ENDOFFILE

Terminal — redémarrer et vérifier la connexionVM SOC

# Redémarrer le Forwarder
sudo /opt/splunkforwarder/bin/splunk restart

# Vérifier que la connexion est établie
sudo tail -10 /opt/splunkforwarder/var/log/splunk/splunkd.log | grep -i "connect\|error"
# → Succès  : "Connected to idx=192.168.91.10:9997"
# → SSL KO  : "Connection reset by peer" → appliquer le outputs.conf SSL ci-dessus
# → SSL OK  : "Connected to idx=192.168.91.10:9997" après avoir ajouté useSSL=true

Exercices SPL sur les alertes Wazuh VM SOC

Exercice 1 — Explorer les alertes Wazuh

index=security sourcetype=wazuh

# ❓ Quels champs JSON sont présents ? (rule.level, rule.description, agent.name)
# ❓ Quel est l'agent qui génère des alertes ?

Exercice 2 — Alertes par niveau de criticité ⭐ LIVRABLE

index=security sourcetype=wazuh
| spath output=level path=rule.level
| spath output=description path=rule.description
| spath output=agent path=agent.name
| stats count by level, description, agent
| sort -level, -count

# ⭐ LIVRABLE : Screenshot → binome_tp3_wazuh.png
# ❓ Quelle alerte a le niveau de criticité le plus élevé ?
# ❓ Les alertes FIM (modification de fichiers) apparaissent-elles ?

Exercice 3 — Vue 360° : Suricata + Wazuh + Fail2ban

# Corrélation complète des 3 outils de détection
index=security (sourcetype=suricata event_type=alert)
             OR (sourcetype=wazuh)
             OR (sourcetype=fail2ban "Ban")
| eval outil=case(
    sourcetype=="suricata",   "Suricata (réseau)",
    sourcetype=="wazuh",      "Wazuh (hôte)",
    sourcetype=="fail2ban",   "Fail2ban (prévention)")
| timechart span=10m count by outil

# Visualization → Line Chart
# Sauvegarder : Save As → Report → "TP3_Detection_360"

# ❓ Quelle couche de détection génère le plus d'événements ?
# ❓ Y a-t-il une corrélation temporelle entre les alertes Suricata et Wazuh ?

Exercice 4 (bonus) — Alertes critiques uniquement (niveau ≥ 7)

index=security sourcetype=wazuh
| spath output=level path=rule.level
| where level >= 7
| spath output=description path=rule.description
| spath output=agent path=agent.name
| table _time, level, description, agent
| sort -level, -_time

# ❓ Quelles alertes dépassent le niveau 7 ? Que signifient-elles ?
# ❓ En production, quel niveau déclencherait une notification d'astreinte ?

🚨

Snapshot avant de quitter

Faire un snapshot des deux VMs nommé "Jour3_OK". Les services Suricata et Wazuh Manager consomment de la RAM — vérifier que la VM SOC dispose encore d'au moins 500 Mo libres : free -h.

🌐 TP 1 — Suricata NIDS

✓
Suricata est actif : sudo systemctl status suricata → active (running)
✓
Suricata écoute sur la bonne interface NAT : grep "interface:" /etc/suricata/suricata.yaml affiche ens33 (ou votre interface)
✓
Le fichier /var/log/suricata/eve.json existe et contient des entrées
✓
Au moins une alerte générée : sudo grep '"event_type":"alert"' /var/log/suricata/eve.json | wc -l retourne > 0
✓
Dans Splunk : index=security sourcetype=suricata event_type=alert retourne des événements
✓
Screenshot binome_tp3_suricata.png réalisée (exercice 2)

🛡️ TP 2 — Wazuh HIDS

✓
Wazuh Manager actif sur la VM SOC : sudo systemctl status wazuh-manager → active (running)
✓
Wazuh Agent actif sur la VM cible : sudo systemctl status wazuh-agent → active (running)
✓
L'agent est visible sur le Manager : sudo /var/ossec/bin/agent_control -l affiche l'agent avec Status: Active
✓
Le fichier /var/ossec/logs/alerts/alerts.json existe et contient des alertes
✓
Dans Splunk : index=security sourcetype=wazuh retourne des événements avec des champs JSON parsés
✓
Au moins une alerte FIM visible dans Splunk (modification de fichier dans /etc)
✓
Le rapport "TP3_Detection_360" est sauvegardé dans Splunk
✓
Screenshot binome_tp3_wazuh.png réalisée (exercice 2)

💬 Questions de réflexion — Débrief collectif

Suricata n'a pas vu l'attaque FIM détectée par Wazuh. Pourquoi est-ce normal et attendu ?

Suricata analyse le trafic réseau — il voit les paquets qui transitent sur l'interface. Une modification de fichier locale (touch /etc/passwd) n'émet aucun paquet réseau. C'est précisément pour ça que le HIDS (Wazuh) est complémentaire au NIDS (Suricata) : il couvre la surface d'attaque interne à l'hôte.

Avec les 3 outils déployés (Fail2ban, Suricata, Wazuh), quel type d'attaque reste non couvert ?

Les attaques chiffrées : trafic TLS/HTTPS malveillant, C2 via DNS, exfiltration sur port 443. Suricata voit les paquets mais pas leur contenu chiffré. Wazuh détecte les processus mais pas les communications sortantes chiffrées. C'est le rôle d'un proxy SSL-inspect ou d'une analyse comportementale (UBA/UEBA) — hors scope de ce cours.

Demain (Jour 4) : à partir des données collectées aujourd'hui, quels dashboards seraient les plus utiles pour un analyste L1 ?

1. Dashboard temps réel : flux d'alertes par outil avec code couleur de criticité. 2. Top 10 des IPs sources d'alertes Suricata (radar des scanners). 3. Timeline des bannissements Fail2ban superposée aux alertes Suricata (corrélation scan → brute-force). 4. Alerte FIM : liste des fichiers modifiés dans /etc, /bin sur les 24h. Ce sont exactement les 4 dashboards du Jour 4.

🎉

Jour 3 terminé — le SOC a maintenant 3 couches de détection !

Demain (Jour 4) : construction des dashboards de sécurité Splunk, mise en place des alertes automatiques par email, et génération de rapports PDF. Le SOC devient opérationnel.

Sondes de Détection d'Intrusion Réseau & Système

🏗️ Architecture à la fin du Jour 3

🎯 Objectifs pédagogiques

⚠️ Prérequis — État des Jours 1 & 2

📦 Livrables fin de journée

⚠️ Points d'attention

🗓️ Planning de la journée

Déploiement de Suricata NIDS

Installation de Suricata VM SOC

Installer Suricata depuis le PPA officiel VM SOC

Identifier l'interface réseau NAT VMware VM SOC

Configuration de Suricata VM SOC

Configurer le fichier suricata.yaml VM SOC

Télécharger et activer les règles de détection VM SOC

Démarrage et premier test de Suricata VM SOC

Valider la configuration et démarrer Suricata VM SOC

Créer une règle locale Nmap et tester la détection Les deux VMs

Centraliser les alertes Suricata dans Splunk VM SOC

Configurer le Splunk UF pour lire eve.json VM SOC

Vérifier les alertes Suricata dans Splunk + Exercices SPL VM SOC

Déploiement de Wazuh HIDS

Installation du Wazuh Manager VM SOC

Ajouter le dépôt Wazuh et installer le Manager VM SOC

Ouvrir le port Wazuh sur la VM SOC VM SOC

Installation de l'agent Wazuh sur la VM cible

Installer l'agent Wazuh VM Cible

Vérifier la connexion Agent ↔ Manager Les deux VMs

Déclencher et observer les alertes Wazuh

Déclencher des alertes Wazuh — FIM et SSH Les deux VMs

Centraliser les alertes Wazuh dans Splunk VM SOC

Configurer le Splunk UF pour lire alerts.json VM SOC

Exercices SPL sur les alertes Wazuh VM SOC

Checklist de Validation du Jour 3

Suricata n'a pas vu l'attaque FIM détectée par Wazuh. Pourquoi est-ce normal et attendu ?

Avec les 3 outils déployés (Fail2ban, Suricata, Wazuh), quel type d'attaque reste non couvert ?

Demain (Jour 4) : à partir des données collectées aujourd'hui, quels dashboards seraient les plus utiles pour un analyste L1 ?