TP – Une sonde Suricata : écrire, tester, régler

BTS SIO SISR 2e année – Bloc 3 – S12 – en binôme : un tape, l'autre lit ; on échange les rôles à chaque partie

Note

But. Installer une sonde Suricata, écrire des règles, les tester avec une attaque de laboratoire, compter vrais positifs, faux positifs et attaques manquées, régler, puis envoyer les alertes au collecteur de la séance S11.

Durée : 3 h 10. Prérequis : cours S12 lu ; S11.

Note

Comment ce TP fonctionne. Tu anticipes (« J'anticipe »), tu manipules, tu notes ce que tu constates, puis tu expliques (« Je comprends »). Un bilan de compétences clôt la séance.

Binôme : ____________ / ____________

Warning

Attaques uniquement dans le laboratoire isolé. Les outils et requêtes de ce TP ne se lancent jamais contre une machine qui n'est pas la cible du laboratoire : c'est un délit, même « pour tester » (séance S04, loi Godfrain).

Le laboratoire

Deux machines virtuelles Debian sur un réseau interne isolé, avec un compte sudo :

Machine	Adresse	Rôle
`cible`	`10.40.0.20`	Petit site web et sonde Suricata, qui observe sa propre interface réseau
`attaque`	`10.40.0.10`	Génère le trafic du scénario (`curl`, `nmap`)

Note

Pour simplifier, la sonde est installée sur la cible. Dans une organisation, une sonde est une machine dédiée, branchée sur un port miroir : le principe est le même. Retrouve le nom de ton interface avec ip -br a (par exemple enp0s3) : il remplace IFACE plus bas.

Contraintes. Instantané des deux machines ; paquets : suricata, jq (sur cible), curl et nmap (sur attaque) ; tu notes la sortie de chaque commande (capture datée).

Partie A – Avant de commencer (≈ 15 min)

J'anticipe. Cette sonde est-elle un IDS ou un IPS ? Si elle était placée derrière un reverse proxy qui déchiffre le HTTPS, verrait-elle plus de choses qu'en amont ? ______________________

Je comprends. Donne un exemple de trafic qu'une sonde réseau ne peut pas analyser : ______________________

Partie B – Installer et démarrer (≈ 30 min)

B1 – La cible : un site, une sonde

Sur cible :

sudo apt install -y suricata jq python3
mkdir -p ~/web/catalogue && cd ~/web
echo "<h1>Cible du laboratoire</h1>" > index.html
echo "Catalogue" > catalogue/index.html
sudo python3 -m http.server 80 --bind 10.40.0.20 &

Sur attaque : curl -s -o /dev/null -w "%{http_code}\n" http://10.40.0.20/ doit afficher 200.

B2 – Les règles

Sur cible, crée ~/local.rules :

# Regle 1 : outil d'attaque identifie par son User-Agent
alert http any any -> $HOME_NET any (msg:"LAB outil sqlmap (User-Agent)"; http.user_agent; content:"sqlmap"; nocase; classtype:web-application-attack; sid:1000001; rev:1;)
# Regle 2 : remontee de repertoire dans l'adresse demandee
alert http any any -> $HOME_NET any (msg:"LAB remontee de repertoire"; http.uri; content:"../"; classtype:web-application-attack; sid:1000002; rev:1;)
# Regle 3 : balayage de ports (beaucoup de SYN depuis la meme source)
alert tcp any any -> $HOME_NET any (msg:"LAB balayage de ports"; flags:S; threshold:type both, track by_src, count 20, seconds 5; classtype:attempted-recon; sid:1000003; rev:1;)
# Regle 4 (trop large, volontairement) : le mot select dans l'adresse
alert http any any -> $HOME_NET any (msg:"LAB injection SQL (large)"; http.uri; content:"select"; nocase; classtype:web-application-attack; sid:1000004; rev:1;)

Note

La règle 2 contient volontairement une erreur (le tampon à chercher). Tu la trouveras en partie C.

B3 – Vérifier, puis lancer

sudo mkdir -p /var/log/suricata-lab
sudo suricata -T -c /etc/suricata/suricata.yaml -S ~/local.rules \
  --set vars.address-groups.HOME_NET="[10.40.0.0/24]" -l /var/log/suricata-lab

-T teste la configuration sans la lancer ; -S charge uniquement ton fichier de règles ; HOME_NET désigne ton réseau.

Si le test réussit, lance la sonde au premier plan dans un deuxième terminal (arrêt par Ctrl+C) :

sudo suricata -c /etc/suricata/suricata.yaml -S ~/local.rules \
  --set vars.address-groups.HOME_NET="[10.40.0.0/24]" \
  --af-packet=IFACE -l /var/log/suricata-lab

Attends le message Engine started, puis quelques secondes de plus avant le premier test.

Point de contrôle : capture du test -T et du message Engine started.

Partie C – Le scénario d'attaque (≈ 45 min)

Sur attaque, rejoue dans cet ordre, en notant l'heure de chaque ligne :

# 1. Outil d'attaque identifie
curl -s -o /dev/null -A "sqlmap/1.8" "http://10.40.0.20/index.html?id=1"
# 2. Remontee de repertoire
curl -s -o /dev/null --path-as-is "http://10.40.0.20/../../etc/passwd"
# 3. Requete LEGITIME qui contient le mot select
curl -s -o /dev/null "http://10.40.0.20/catalogue/?select=rouge"
# 4. Vraie injection
curl -s -o /dev/null "http://10.40.0.20/index.html?id=1%20UNION%20SELECT%20password"
# 5. Navigation normale
curl -s -o /dev/null -A "Mozilla/5.0" "http://10.40.0.20/"
# 6. Balayage de ports
nmap -sS -p 1-200 -T4 10.40.0.20

Sur cible, lis les alertes (attends quelques secondes) :

sudo cat /var/log/suricata-lab/fast.log
sudo jq -r 'select(.event_type=="alert") | [.alert.signature_id, .src_ip, (.http.url // "-")] | @tsv' /var/log/suricata-lab/eve.json
sudo jq -c 'select(.event_type=="http") | [.http.url, .http.status]' /var/log/suricata-lab/eve.json

J'anticipe. Avant de lire : pour chacune des six actions, la sonde alertera-t-elle ? ______________________

Complète le tableau :

#	Action	Alerte ? (sid)	Vrai positif, faux positif, attaque manquée ou vrai négatif ?
1	Outil `sqlmap`
2	Remontée de répertoire
3	Requête légitime avec `select`
4	Injection `UNION SELECT`
5	Navigation normale
6	Balayage de ports

Je comprends. Une des attaques n'a pas été signalée alors que la sonde la voit (la troisième commande de jq montre l'adresse demandée). Laquelle ? Compare l'adresse affichée par jq avec ce que cherche la règle : que remarques-tu ? ______________________

Note

Indice : cherche, dans la documentation de Suricata, la différence entre les tampons http.uri et http.uri.raw.

Point de contrôle : capture de fast.log et du tableau rempli.

Partie D – Régler (≈ 55 min)

D1 – Corriger la règle qui ne se déclenche pas

Dans ~/local.rules, remplace http.uri; content:"../"; par http.uri.raw; content:"../"; dans la règle 2. Arrête la sonde (Ctrl+C), relance-la, rejoue uniquement l'action 2 et vérifie que l'alerte apparaît.

D2 – Réduire le faux positif

La règle 4 déclenche sur l'action 3, légitime. Mets-la en commentaire (# au début de la ligne) et ajoute :

# Regle 4 corrigee : "union" suivi de "select" (une vraie signature d'injection)
alert http any any -> $HOME_NET any (msg:"LAB injection SQL (UNION SELECT)"; http.uri; content:"union"; nocase; content:"select"; nocase; distance:0; classtype:web-application-attack; sid:1000005; rev:1;)

Relance, rejoue les actions 3 et 4.

Je comprends. Que signifie distance:0 ? Pourquoi cette règle ne se déclenche-t-elle plus sur ?select=rouge ? ______________________

D3 – Une attaque que personne n'a prévue

Rejoue, depuis attaque, en changeant l'outil déclaré :

curl -s -o /dev/null -A "Mozilla/5.0" "http://10.40.0.20/index.html?id=1%27%20OR%20%271%27=%271"
curl -s -o /dev/null -A "Mozilla/5.0" "http://10.40.0.20/index.html?id=1/**/UnIoN/**/SeLeCt/**/1"

J'anticipe. Laquelle des deux lignes sera signalée ? ______________________

Puis constate. Pour celle qui est manquée, écris une règle 6 (nouveau sid, par exemple 1000006) qui la détecte sans déclencher sur la navigation normale. Teste-la sur les actions 5 et 3.

Je comprends. Un attaquant qui change le User-Agent neutralise la règle 1. Que peut-on en déduire de la valeur d'une règle qui repose uniquement sur le nom d'un outil ? ______________________

D4 – Une exception documentée

Imagine que l'équipe lance chaque nuit un scanneur de vulnérabilités interne (séance S13) depuis 10.40.0.10 : il déclencherait la règle 5 tous les soirs. Ajoute dans /etc/suricata/threshold.config (en sudo) :

suppress gen_id 1, sig_id 1000005, track by_src, ip 10.40.0.10

Relance la sonde, rejoue l'action 4 : plus d'alerte pour la règle 5. Mais la règle 1 (outil sqlmap) continue de déclencher depuis cette adresse.

Je comprends. Remplis la fiche d'exception : règle, adresse, raison, responsable, date de revue. Que se passe-t-il si un attaquant prend le contrôle de 10.40.0.10 ? ______________________

Warning

Remets ensuite le fichier /etc/suricata/threshold.config dans son état initial (supprime la ligne ajoutée) pour ne pas fausser la suite du TP.

Point de contrôle : captures avant et après de chaque réglage.

Partie E – Relier à la supervision (≈ 20 min)

E1 – Envoyer les alertes au collecteur

Sur cible, avec la configuration d'envoi de la séance S11 en place (/etc/rsyslog.d/90-envoi.conf), crée /etc/rsyslog.d/20-suricata.conf :

module(load="imfile")
input(type="imfile" File="/var/log/suricata-lab/fast.log" Tag="suricata" Severity="warning" Facility="local5")

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Rejoue une action d'attaque, puis cherche l'alerte dans le dossier de la machine sur le collecteur.

E2 – Corréler

Je comprends. Une même adresse figure dans une alerte de balayage de ports et dans des échecs SSH (partie D de la séance S11). Que conclus-tu, et quelle règle de corrélation écrirais-tu ? ______________________

Partie F – Bilan chiffré (≈ 15 min)

Règle	Vrais positifs	Faux positifs	Attaques manquées
1 `sqlmap`
2 remontée de répertoire (avant / après correction)
4 large / 5 corrigée
3 balayage de ports
6 (la tienne)

Je comprends. Quelle règle recommanderais-tu de passer en blocage (mode prévention) un jour, et lesquelles garderais-tu en simple alerte ? Justifie. ______________________

Retour en entreprise (si ta situation le permet)

Observer : ton entreprise a-t-elle une sonde ? Où est-elle placée ? Qui lit les alertes, et combien en reçoit-on par jour ?
Documenter : compare avec tes réponses de la partie F.

Rendu

Compte rendu PDF, nommé RENDU-B3A2-S12-NOM.pdf, contenant les captures datées des parties B à E, les tableaux de C et F, la règle 6 et la fiche d'exception de D4.

Bilan de la séance

Compétence du référentiel	Ce que j'ai fait dans cette séance	Niveau
B3.4 – Garantir la disponibilité, l'intégrité et la confidentialité des services informatiques et des données de l'organisation face à des cyberattaques
B3.5A – Assurer la cybersécurité d'une infrastructure réseau, d'un système, d'un service

Note

Je sais faire, sans aide :

Lire une règle de détection et expliquer chacune de ses parties ;
Tester une règle avec une attaque de laboratoire ;
Distinguer vrai positif, faux positif et attaque manquée, et régler ;
Documenter une exception ;
Relier une alerte à des journaux.

Ce que je dois reprendre : ______________________