Code : MO-SEC-004 | Version : 1.0 | Date : 16 avril 2026 | Auteur : C. Legrand
¶ MO-SEC-004 — Gerer Suricata pendant les TP de cybersecurite
¶ 1. Objet
Ce mode operatoire decrit la conduite a tenir vis-a-vis du moteur Suricata IDS de l'infrastructure BTS SIO lorsqu'une seance de travaux pratiques de cybersecurite genere du trafic legitimement intrusif (scan de ports, fuzzing, brute-force, exploitation de vulnerabilites sur cibles de laboratoire).
Sans preparation, ces TP saturent l'onglet Alerts de plusieurs centaines d'evenements de severite 2 et 3, ce qui produit deux effets indesirables :
- le bruit pedagogique masque les eventuelles alertes reelles concomitantes (compromission, scan exterieur) ;
- l'historique d'alertes devient inexploitable pour la consultation quotidienne decrite dans MO-SEC-002.
Le present document propose un cadre operationnel en trois temps — avant, pendant, apres la seance — pour isoler le trafic TP du trafic legitime, sans alterer durablement la posture de detection.
Mode actuel = IDS, pas IPS. Suricata est deploye en mode IDS (
PCAP live mode, configuration verifiee le 16 avril 2026) : il detecte mais ne bloque pas. Consequence directe : aucun TP n'est techniquement entrave par la presence du moteur. La preparation decrite ici vise uniquement la lisibilite des alertes. Si le moteur passe un jour en mode IPS, ce mode operatoire devra etre complete d'une section sur la desactivation stricte des regles bloquantes pendant les TP.
¶ 2. Champ d'application
| Public concerne | Enseignants intervenant dans les TP de cybersecurite BTS SIO option SISR (modules Securite des reseaux et Detection d'intrusion) |
| Systeme | Pare-feu OPNsense (10.0.112.1), moteur Suricata en mode IDS, 32 rulesets actifs sur 68 disponibles |
| Salle TP | Plage IP des postes etudiants (typiquement 10.0.232.0/24) |
| Cibles autorisees | VMs de laboratoire dediees (Metasploitable, DVWA, machines isolees du reseau de production) |
| Duree estimee | 10 min de preparation, 5 min de restauration |
¶ 3. Prerequis
- Compte administrateur OPNsense (identifiants dans le coffre Vaultwarden de l'equipe)
- Acces reseau au pare-feu
10.0.112.1(cable RJ45 ou tunnel VPN WireGuard) - Connaissance de MO-SEC-002 (consultation des alertes Suricata)
- Liste des postes participants (IP ou plage) communiquee en amont par l'enseignant responsable du TP
- Perimetre d'exercice valide (cibles autorisees, duree, types d'attaques pratiquees)
Aucune attaque hors perimetre. Les alertes ignorees ou supprimees pendant un TP doivent l'etre uniquement pour les IPs et SID pedagogiques prevus. Toute alerte d'origine externe au TP, meme concomitante, doit rester visible et traitee selon MO-SEC-002.
¶ 4. Procedure
¶ 4.1 Avant le TP — preparation
Etape 1 — Recenser les postes participants
Demander a l'enseignant responsable la liste des postes etudiants utilises pour le TP. Convertir en plage CIDR si possible (ex. 10.0.232.0/24 pour la salle complete, 10.0.232.10-25 pour un sous-ensemble).
Noter egalement :
- l'horaire prevu (debut / fin) ;
- les types d'attaques (scan, brute-force, exploitation, sniffing) ;
- les machines cibles (IPs des VMs de laboratoire).
Etape 2 — Se connecter a l'interface OPNsense
Ouvrir http://10.0.112.1 et s'authentifier avec le compte administrateur (cf. MO-SEC-002 §4.1). Naviguer vers :
Services → Intrusion Detection → Administration
Verifier que le service est en etat Running (point vert) avant toute modification.
Etape 3 — Snapshot de l'etat des rulesets
Avant toute desactivation, exporter la liste des rulesets actifs pour pouvoir restaurer fidelement a l'issue du TP. Depuis un poste connecte au LAN :
curl -s -b cookies.txt \
'http://10.0.112.1/api/ids/settings/listRulesets' \
| jq '.rows[] | select(.enabled=="1") | .filename' \
> /tmp/suricata_rulesets_avant.txt
wc -l /tmp/suricata_rulesets_avant.txt
Ce fichier servira de reference pour la restauration en §4.5. Une methode equivalente via l'UI consiste a prendre une capture d'ecran de l'onglet Rules avec les rulesets actives.
¶ 4.2 Desactiver les rulesets bruyants pour le TP
Etape 4 — Identifier les rulesets concernes par le type de TP
Selon la nature du TP, certains rulesets generent un volume disproportionne d'alertes attendues. Le tableau ci-dessous indique les rulesets a desactiver temporairement :
| Type de TP | Rulesets a desactiver temporairement |
|---|---|
| Scan Nmap, recon reseau | ET scan.rules, ET policy.rules (partiellement) |
| Brute-force SSH/HTTP (Hydra) | ET attack_response.rules, ET hunting.rules |
| Exploitation Metasploit | ET exploit.rules, ET shellcode.rules |
| Sniffing / ARP poisoning | Aucun (ecoute passive non detectee par Suricata) |
| Web app testing (DVWA, OWASP Juice Shop) | ET web_specific_apps.rules, ET web_server.rules |
Etape 5 — Desactiver un ruleset depuis l'UI
Dans l'onglet Rules, localiser le ruleset cible (utiliser le filtre de recherche). Decocher la case Enabled sur la ligne correspondante, puis cliquer sur Save.
Etape 6 — Recharger la configuration
Apres avoir modifie l'ensemble des rulesets pertinents, retourner sur l'onglet Administration et cliquer sur Apply en haut a droite (icone de recharge).
L'operation prend environ 30 secondes a 1 minute selon le nombre de regles. Pendant ce temps, le service est redemarre : aucune alerte n'est capturee durant cette fenetre courte.
Alternative ciblee — suppress par SID. Plutot que de desactiver un ruleset entier, il est possible de supprimer l'alerte uniquement pour certaines IP source via une regle
suppress. Plus chirurgical, mais plus long a configurer pour un TP ponctuel. Voir §4.3 ci-dessous.
¶ 4.3 Ajouter des regles d'exception (alternative chirurgicale)
Etape 7 — Acceder a la page des exceptions
Dans le module IDS, naviguer vers :
Services → Intrusion Detection → User defined
Cette page permet de definir des actions personnalisees par SID, source ou destination, sans toucher aux rulesets globaux.
Etape 8 — Creer une suppression d'alerte par SID et IP source
Cliquer sur + Add et remplir :
- Action :
suppress - SID : identifiant de la regle (ex.
2024364pour ET SCAN Nmap) - Track :
by_src(par adresse source) - IP : plage TP (ex.
10.0.232.0/24) - Description :
TP Nmap salle 232 -- 16/04/2026
Sauvegarder, puis appliquer la configuration depuis l'onglet Administration.
Utiliser
suppresssi :
- le TP ne concerne qu'un sous-ensemble de SID dans un ruleset ;
- d'autres regles du meme ruleset doivent rester actives sur d'autres IP ;
- l'enseignant souhaite garder une trace meme partielle (SID logue, alerte non remontee dans l'UI).
Preferer la desactivation complete du ruleset si :
- le TP est court (<1 h) et concerne un nombre eleve de SID ;
- la classe couvre l'ensemble de la salle (gain de temps).
¶ 4.4 Pendant le TP — surveillance parallele
Etape 9 — Filtrer les alertes hors TP
Garder ouvert l'onglet Alerts dans une fenetre separee. Appliquer le filtre suivant pour exclure le trafic de la plage TP :
!10.0.232.0/24
Toute alerte qui apparait malgre ce filtre provient d'une autre source et doit etre traitee selon MO-SEC-002.
Etape 10 — Surveiller la severite 3
Appliquer un second filtre par severite : Severity = 3. Toute alerte de severite 3 hors perimetre TP justifie une interruption immediate du TP et une investigation (cf. MO-SEC-002 §4.7).
¶ 4.5 Apres le TP — restauration de l'etat nominal
Etape 11 — Reactiver les rulesets desactives
Retourner dans Rules et reactiver chaque ruleset liste dans le snapshot pris en §4.1. La case Enabled doit etre a nouveau cochee pour chaque ruleset concerne.
Verifier en comparant avec le fichier /tmp/suricata_rulesets_avant.txt ou avec la capture d'ecran de reference.
Etape 12 — Supprimer les regles d'exception creees
Retourner dans User defined. Cocher chaque regle creee pour le TP (reperables a la description TP ... -- date) et cliquer sur Delete.
Etape 13 — Recharger la configuration
Onglet Administration, cliquer sur Apply. Attendre la fin du redemarrage du moteur (point vert).
Verifier le compteur de rulesets actifs : il doit etre identique a celui note avant le TP (32 sur 68 dans la configuration de reference d'avril 2026).
¶ 4.6 Documenter la seance
Etape 14 — Creer une entree dans le journal de bord
Sur le wiki interne (https://wiki.legrand-tech.fr/fr/journal-de-bord), ajouter une entree datee contenant :
- Date, horaire, salle TP
- Nom de l'enseignant et intitule du TP
- Plage IP impactee
- Liste des rulesets et SID neutralises
- Heure de restauration de l'etat nominal
- Eventuelles alertes hors perimetre observees pendant la seance
Cette tracabilite permet de correler a posteriori des incidents potentiels avec des fenetres TP, et d'identifier les rulesets recurrement neutralises (candidats a un ajustement permanent).
### TP Nmap -- Salle 232 -- 16/04/2026 14:00-16:00 - Enseignant : <NOM> - Module : SISR-S2 -- Detection d'intrusion - Plage IP TP : 10.0.232.0/24 (16 postes) - Cible : VM Metasploitable 10.0.232.250 - Rulesets desactives : ET scan.rules - SID supprimes : aucun (ruleset entier) - Restauration : 16/04 16:05 - Alertes hors perimetre : 0
¶ 5. Cas types
¶ 5.1 TP Nmap (scan de ports)
- Desactiver
ET scan.rules(couvre la plupart des techniques de scan TCP/UDP/SYN) - Optionnellement, suppress sur SID 2024364 (ET SCAN Nmap) si seuls quelques postes scannent
- Apres TP : verifier qu'aucune alerte
ET SCANn'est restee dans la file post-reactivation
¶ 5.2 TP Hydra (brute-force SSH ou HTTP)
- Desactiver
ET attack_response.rules(alertes sur tentatives de connexion repetees) - Si Hydra cible une cible HTTPS interne, desactiver aussi
ET hunting.rules - Garantir que la cible est bien une VM de laboratoire isolee
¶ 5.3 TP Metasploit (exploitation de vulnerabilites)
- Desactiver
ET exploit.rulesetET shellcode.rules - Valider en amont la liste des exploits utilises avec l'enseignant (certains modules declenchent encore d'autres rulesets)
- Apres TP, prendre 5 minutes pour relire les alertes capturees avant la desactivation : elles documentent les signatures que les etudiants ont declenchees
¶ 5.4 TP Wireshark (sniffing passif)
- Aucune action requise sur Suricata : l'ecoute passive n'emet aucun trafic detectable
- Profiter de la seance pour faire decouvrir aux etudiants l'onglet Alerts comme outil complementaire de Wireshark
¶ 5.5 TP Web (DVWA, OWASP Juice Shop)
- Desactiver
ET web_specific_apps.rules - Selon les modules pratiques (XSS, SQLi),
ET web_server.rulespeut aussi generer du bruit - Confirmer que la cible (DVWA) est sur une VM ou un conteneur isole, jamais sur l'infrastructure de production
¶ 6. Verifications finales
Apres la seance, controler les points suivants :
- ✅ Le service Suricata est Running (point vert dans Administration)
- ✅ Le nombre de rulesets actifs correspond a l'etat avant TP (32 sur 68 par defaut)
- ✅ Aucune regle dans User defined n'a un libelle
TP ...restant - ✅ Les alertes apres restauration concernent du trafic legitime de l'infrastructure (pas de SID pedagogique recent provenant de la plage TP)
- ✅ Une entree a ete creee dans le journal de bord du wiki
- ✅ L'enseignant responsable du TP a confirme la fin de la seance
¶ 7. Depannage
| Probleme | Solution |
|---|---|
| Apres Apply, le service ne redemarre pas | Consulter System → Log Files → General pour identifier l'erreur. Cause frequente : une regle suppress mal formee (SID inexistant ou IP invalide). Supprimer la regle facheuse et reappliquer. |
| Le compteur de rulesets ne revient pas a 32 apres restauration | Comparer ligne a ligne le contenu de l'onglet Rules avec la capture prise en §4.1. Un ruleset peut avoir ete oublie. Reactiver manuellement et appliquer. |
| Volume d'alertes anormalement eleve apres la seance | Verifier que la plage TP ne genere plus de trafic intrusif (poste oublie, scan en arriere-plan). Filtrer les alertes par IP et investiguer les sources residuelles. |
| Aucune alerte capturee pendant la seance, meme hors plage TP | Verifier que les interfaces WAN et LAN sont toujours cochees dans Administration. Un Apply sur une configuration incomplete peut deselectionner les interfaces dans certaines versions d'OPNsense. |
| Conflit avec une autre seance en parallele | Coordonner avec les autres enseignants : un seul TP cybersecu actif a la fois sur l'infrastructure pour eviter d'enchevetrer les exceptions. Sinon, isoler chaque TP par un sous-reseau distinct et utiliser exclusivement suppress by_src. |
¶ 8. Voir aussi
- MO-SEC-002 — Consulter et traiter les alertes Suricata IDS (procedure quotidienne)
- MO-NET-001 — Verification post-hardening OPNsense (cadre de validation generale)
- MO-SEC-001 — Exploitation Wazuh (correlation alertes Suricata → SIEM, hors perimetre IDS strict)
References
- Suricata — Suricata User Guide, Rule Management (https://docs.suricata.io/en/latest/rule-management/)
- OPNsense — Intrusion Detection System (IDS) (https://docs.opnsense.org/manual/ids.html)
- ANSSI — Recommandations de securite relatives a un systeme GNU/Linux, R80 (2019)
- ANSSI — Guide d'hygiene informatique, mesure 33 (2017)
- Audit BTS SIO — Constat F-SEC-002 / Recommandation R-036