Lab ACTIVE — TRAINING GRID

IDS / IPS Fondamentaux

Apprends à distinguer un système de détection d'un système de prévention, à lire une alerte comme un analyste SOC, et à repérer une attaque directement dans des logs bruts.

DifficultéDébutant
Tâches9
Durée estimée45–60 min
PrérequisAucun
1

Qu'est-ce qu'un IDS/IPS ?

Un IDS (Intrusion Detection System) est un système qui surveille le trafic réseau ou l'activité d'une machine pour repérer des comportements suspects ou malveillants. Il agit comme une caméra de surveillance : il observe, journalise et alerte, mais n'intervient jamais directement sur le trafic.

Un IPS (Intrusion Prevention System) fait le même travail de détection, mais il est placé en ligne sur le flux réseau et peut bloquer activement une connexion suspecte avant qu'elle n'atteigne sa cible.

À retenir : détection = observer. Prévention = observer + agir.
Quel acronyme désigne un système qui se contente d'observer et d'alerter, sans jamais bloquer le trafic ?
2

IDS vs IPS

La différence entre les deux n'est pas la capacité de détection (souvent identique), mais leur position sur le réseau et leur mode d'action.

  • IDS : positionné en dérivation (out-of-band) via un port mirroring (SPAN/TAP). Le trafic est copié, analysé, mais jamais interrompu.
  • IPS : positionné en ligne (inline), directement dans le chemin du trafic. Il peut couper une connexion, dropper un paquet ou reset une session.
Compromis : un IPS mal réglé peut bloquer du trafic légitime (faux positif = interruption de service). Un IDS n'a pas ce risque, mais laisse passer l'attaque pendant qu'il alerte.
Quel système est positionné directement "en ligne" dans le flux réseau et peut bloquer un paquet ?
3

Détection par signature vs par anomalie

Un IDS/IPS peut détecter les menaces selon deux méthodes principales :

  • Basée sur les signatures : compare le trafic à une base de motifs connus (une règle Snort/Suricata, par exemple). Rapide et fiable sur les attaques connues, mais aveugle face à une menace inédite (zero-day).
  • Basée sur l'anomalie : établit d'abord une baseline du comportement "normal", puis alerte sur tout écart significatif. Capable de détecter l'inconnu, mais génère plus de faux positifs.
Exemple : une règle qui matche l'empreinte exacte du ver Blaster = signature. Un pic soudain de trafic sortant à 3h du matin sur un serveur qui n'en génère jamais = anomalie.
Quelle méthode de détection est capable de repérer une attaque inconnue (zero-day) en se basant sur un écart de comportement ?
4

NIDS vs HIDS

Un IDS/IPS peut aussi être classé selon son emplacement :

  • NIDS (Network) : surveille le trafic sur un segment réseau entier — typiquement placé sur un switch avec port mirroring. Ex : Suricata, Snort.
  • HIDS (Host) : installé sur une machine individuelle, il surveille les logs système, l'intégrité des fichiers, les processus. Ex : OSSEC, Wazuh.
À retenir : un NIDS voit tout le trafic d'un segment mais rien à l'intérieur d'une machine chiffrée. Un HIDS voit l'intérieur d'une machine mais rien du réseau global.
Quel type d'IDS est installé directement sur une machine pour surveiller ses logs et fichiers locaux ?
5

Anatomie d'une alerte

Voici une alerte générée par un moteur de type Suricata/Snort. Chaque champ raconte une partie de l'histoire de l'attaque.

alert.log
[1:2001219:19] ET SCAN Potential SSH Scan [Classification: Attempted Information Leak] [Priority: 2]
{TCP} 203.0.113.44:51422 -> 198.51.100.10:22
Timestamp: 2026-07-14 22:14:07

Décomposition : 1:2001219:19 est le SID (Signature ID), identifiant unique de la règle déclenchée. Vient ensuite le message descriptif, la classification, la priorité (1 = critique), puis le couple IP source:port → IP destination:port.

Dans cette alerte, quelle est l'adresse IP source (celle qui a initié la connexion suspecte) ?
6

Analyse de log 1 — Scan de ports

Un extrait de log firewall capture une même IP source qui tente de se connecter à de nombreux ports différents en quelques secondes — signature classique d'un scan de ports (type nmap).

firewall.log
012026-07-14 09:02:11 DROP TCP 198.51.100.77:40211 -> 10.10.10.5:21
022026-07-14 09:02:11 DROP TCP 198.51.100.77:40212 -> 10.10.10.5:22
032026-07-14 09:02:11 DROP TCP 198.51.100.77:40213 -> 10.10.10.5:23
042026-07-14 09:02:12 DROP TCP 198.51.100.77:40214 -> 10.10.10.5:80
052026-07-14 09:02:12 DROP TCP 198.51.100.77:40215 -> 10.10.10.5:443
062026-07-14 09:02:12 DROP TCP 198.51.100.77:40216 -> 10.10.10.5:445
072026-07-14 09:02:13 DROP TCP 198.51.100.77:40217 -> 10.10.10.5:3389
082026-07-14 09:02:13 DROP TCP 198.51.100.77:40218 -> 10.10.10.5:8080
Indice : compte le nombre de ports distincts touchés en une seconde sur la même IP destination — c'est le signal qui distingue un scan d'un trafic normal.
Combien de ports distincts ont été sondés sur la machine 10.10.10.5 dans cet extrait ?
7

Analyse de log 2 — Brute force SSH

Un extrait de auth.log montre une série d'échecs d'authentification rapprochés sur le service SSH — le motif typique d'une attaque par force brute.

auth.log
01Jul 14 03:11:02 srv sshd[2291]: Failed password for admin from 185.220.101.9 port 55231 ssh2
02Jul 14 03:11:04 srv sshd[2293]: Failed password for admin from 185.220.101.9 port 55240 ssh2
03Jul 14 03:11:06 srv sshd[2295]: Failed password for admin from 185.220.101.9 port 55248 ssh2
04Jul 14 03:11:08 srv sshd[2297]: Failed password for admin from 185.220.101.9 port 55255 ssh2
05Jul 14 03:11:11 srv sshd[2299]: Failed password for admin from 185.220.101.9 port 55261 ssh2
06Jul 14 03:11:13 srv sshd[2301]: Accepted password for admin from 185.220.101.9 port 55270 ssh2
Signal fort : plusieurs échecs consécutifs sur le même compte, en quelques secondes, suivis d'un succès — c'est presque toujours un brute force qui a fini par aboutir, pas un utilisateur qui se trompe de mot de passe.
Quel nom d'utilisateur a été ciblé par cette attaque ?
8

Analyse de log 3 — Injection SQL

Un log d'accès web (access.log) contient une requête qui sort clairement du comportement attendu d'un formulaire de connexion.

access.log
01203.0.113.90 - - [14/Jul/2026:11:42:03] "GET /produits?id=17 HTTP/1.1" 200 3120
02203.0.113.90 - - [14/Jul/2026:11:42:19] "GET /login.php?user=admin&pass=1' OR '1'='1 HTTP/1.1" 200 892
03203.0.113.90 - - [14/Jul/2026:11:42:19] "GET /login.php?user=admin&pass=1'-- HTTP/1.1" 302 0
Pourquoi c'est malveillant : le paramètre pass contient une syntaxe SQL (guillemet, opérateur logique, commentaire --) au lieu d'un mot de passe. L'objectif est de manipuler la requête SQL du serveur pour contourner l'authentification.
Quel type d'attaque web ce log révèle-t-il ?
9

Challenge final

Un IDS a généré plusieurs alertes en l'espace de quelques minutes sur le même hôte cible. Analyse la séquence complète pour identifier l'auteur de l'attaque.

ids-alerts.log
01[ALERT] ET SCAN Nmap Scripting Engine — src 198.51.100.23 -> 10.10.10.5 (22 ports, 4s)
02[ALERT] ET SCAN Suspicious inbound to SSH — src 198.51.100.23 -> 10.10.10.5:22
03[ALERT] SSH Brute Force — 14 failed logins in 9s — src 198.51.100.23 -> 10.10.10.5:22
04[ALERT] SSH Authentication Success following Brute Force — src 198.51.100.23 user=root
05[ALERT] Outbound connection to known C2 infrastructure — src 10.10.10.5 -> 45.33.32.156:4444
Ce que ça raconte : reconnaissance (scan) → ciblage d'un service exposé → force brute réussie → prise de contrôle → connexion sortante vers une infrastructure de commande et contrôle (C2). C'est la chaîne complète d'une intrusion.
Soumets l'adresse IP source de l'attaquant au format flag pour valider la room : WICE{IP_ATTAQUANT}