Dossier de choix — détection d’intrusion sur l’infrastructure (phase 16)
Étudiant : Axel · Épreuve : E6 SISR (BTS SIO) · Version : 1.1 · Date : 3 novembre 2026 (1.0 le 2 novembre ; 1.1 : décision sur le formateur, §4)
Ce dossier justifie le choix de l’outil de détection d’intrusion du laboratoire. Le besoin vient de la mission N4 (superviser, alerter, gérer un incident) et d’une demande d’Axel du 30/10 : être prévenu d’une attaque, pas seulement d’une panne. Format repris du dossier de choix de la supervision. Suivi : phase 16 de SUIVI-TP.md.
1. Le besoin et les contraintes
| Besoin de GSB (Galaxy Swiss Bourdin, l’entreprise du cas d’étude) | Traduction technique |
|---|---|
| Savoir qu’une attaque est en cours ou a eu lieu, pas seulement qu’un service est tombé | Détection d’intrusion : sur les machines (fichiers, comptes, journaux) et sur le réseau (balayages, exploits) |
| Être prévenu par le même canal que les pannes | Alerte par e-mail, à côté des alertes de la supervision |
| Comprendre ce qui s’est passé | Un écran qui rassemble les événements de sécurité de toutes les machines, Linux et Windows |
| Couvrir aussi la zone des invités | Surveiller le trafic de la zone VISITEURS (la moins fiable) |
| Contrainte | Origine |
|---|---|
Peu de mémoire : l’hyperviseur pve-01 est partagé par toute la classe, à 81 % de sa RAM le 02/11 (50 Gio sur 62) | Mesuré sur place ; le ballooning a déjà perturbé deux VM du lab (incident H-67) |
| Réutiliser l’existant : journaux centralisés dans Galera, Prometheus, Grafana, alertes par mail | Phase 14 ; ne pas refaire une seconde supervision |
| Logiciels libres | Budget nul, mission N4 |
| Linux et Windows (contrôleur de domaine, poste) | Le lab compte 11 Linux, 2 Windows, 1 pfSense |
| Effort compatible avec le temps restant (R1 en janvier 2027) | Calendrier du cours |
2. Les solutions envisagées
| # | Solution | Où elle regarde | Détecte | Bloque | Ressources | Verdict |
|---|---|---|---|---|---|---|
| A | Wazuh (agents + serveur tout-en-un) | dans les machines : journaux, fichiers, comptes, logiciels | force brute, fichier système modifié, compte créé, logiciel vulnérable, anomalies Windows | oui (« réponse active ») | lourd : 4 vCPU / 8 Gio / 50 Go pour 1 à 25 agents (doc officielle) | Retenue, avec un essai à 6 Gio |
| B | Suricata (paquet pfSense) | sur le réseau : les paquets qui traversent le pare-feu | balayages, exploits connus, trafic malveillant (signatures ET Open) | en mode prévention seulement (pas retenu : mode détection) | moyen : mémoire de pfSense selon les règles (À VÉRIFIER) | Retenue en complément : ce que Wazuh ne voit pas |
| C | CrowdSec (agent + videur) | dans les journaux | force brute, balayages visibles dans les journaux ; liste communautaire d’adresses malveillantes | oui, c’est son point fort | léger (quelques centaines de Mio) | Écartée : doublon de Wazuh (journaux et blocage) ; ne voit pas l’intérieur des machines |
| D | Wazuh + CrowdSec + Suricata | partout | tout | oui | lourd | Écartée : CrowdSec n’apporte que la liste communautaire |
| E | Snort (paquet pfSense) | réseau | comme Suricata | idem | idem | Écartée : même rôle que Suricata, qui est multi-cœurs et lit le JSON (EVE) que Wazuh sait importer |
3. Comparaison des deux candidats principaux
Critères d’un dossier de choix : coût, délai, qualité, éthique, plus l’adéquation au besoin. Aucune des deux solutions n’était installée au moment du choix : la comparaison repose sur la documentation des éditeurs et sur l’expérience des phases 14 et 15 (agents déployés par script, journaux centralisés).
| Critère | A · Wazuh (+ Suricata) | C · CrowdSec (+ Suricata) |
|---|---|---|
| Adéquation au besoin | couvre les trois cas demandés (fichier modifié, compte créé, force brute) et le réseau avec Suricata | couvre la force brute et, avec Suricata, le réseau ; pas les fichiers ni les comptes |
| Coût | gratuit ; 6 à 8 Gio de RAM sur un hôte déjà chargé | gratuit ; presque rien |
| Délai | VM dédiée + installeur tout-en-un (1 séance) ; agents par script (1 séance) ; Suricata (1 séance) ; mesure (1 semaine) | agent sur chaque machine ou sur srv-supervision (1 séance) ; Suricata (1 séance) |
| Qualité | règles toutes faites, écran dédié, agents Linux et Windows officiels ; lit les alertes de Suricata | détection limitée aux journaux ; nos journaux sont dans une base Galera, pas dans des fichiers (À VÉRIFIER : lecture possible ?) |
| Éthique et juridique | les agents lisent les journaux et l’intégrité des fichiers : données personnelles dans les journaux (même cadre que la phase 14 : accès restreint, conservation limitée) ; aucune donnée envoyée hors du lab, sauf le flux de vulnérabilités téléchargé | partage d’adresses malveillantes avec une communauté : des adresses IP sortent du lab (à déclarer) |
| Intégration | un second écran à côté de Grafana (contrainte « un seul écran » assouplie : la sécurité et la disponibilité sont deux métiers) ; mails par Wazuh ou par Grafana via l’indexeur | décisions dans des journaux ; blocage possible dans pfSense |
| Risque principal | la mémoire : le minimum officiel est 8 Gio | ne pas voir une intrusion qui ne laisse pas de trace dans les journaux |
4. La décision, et ses conditions
Wazuh + Suricata (décision d’Axel, 02/11/2026), avec quatre conditions :
| Condition | Pourquoi |
|---|---|
VM srv-wazuh à 6 Gio fixes (minimum = maximum, pas de ballooning), 2 vCPU, 60 Go, zone ADM, Ubuntu Server 24.04 | 8 Gio est irréaliste sur l’hôte partagé ; un programme Java dont Proxmox reprend la mémoire plante (H-67) ; Debian n’est pas dans la liste des systèmes supportés par Wazuh |
| Tas Java de l’indexeur réduit (≈ 1,5 Gio au lieu de la moitié de la RAM), mémoire verrouillée | c’est l’indexeur (OpenSearch) qui pèse, pas le nombre de machines : 14 machines produisent peu d’événements |
| Semaine de mesure avec 3 agents avant d’étendre | prouver que 6 Gio suffisent (mémoire, swap, disque) ; sinon repli sur CrowdSec + Suricata |
| Suricata en mode détection sur VISITEURS et USERS d’abord | pfSense n’a que 2 Gio ; le mode blocage (inline) sur des cartes virtuelles est à vérifier ; les zones non fiables d’abord |
Le formateur n’est pas prévenu de l’ajout de 6 Gio sur pve-01 (question posée le 02/11, retirée : décision d’Axel du 03/11 ; la VM peut être éteinte hors séance si l’hôte souffre).
5. Risques et réponses
| Risque | Réponse |
|---|---|
| 6 Gio ne suffisent pas (swap, indexeur qui s’arrête) | mesuré pendant une semaine ; repli documenté : CrowdSec + Suricata, ou Wazuh sans l’indexeur (agents + serveur seuls, alertes lues par Grafana) À VÉRIFIER |
| L’hôte partagé dépasse ~88 % et le ballooning s’aggrave pour tout le monde | accord du formateur demandé avant ; la VM peut être éteinte en dehors des séances si besoin |
| Deux écrans (Grafana et Wazuh) | les alertes de sécurité arrivent par mail, comme les pannes : l’écran Wazuh ne sert qu’à l’enquête |
| Faux positifs au démarrage (règles génériques) | une semaine d’observation avant d’activer les mails ; seuil de niveau ≥ 10 |
| Suricata ralentit pfSense | mémoire relevée avant et après ; une interface à la fois ; règles ET Open limitées aux catégories utiles |
| Les agents ouvrent un flux de chaque zone vers l’ADM (1514, 1515) | une règle par zone, vers SRV_WAZUH seul, avant les rejets : même modèle que les journaux (514) ; exception assumée pour la zone BDD, déjà documentée pour les journaux |
6. Limites de la comparaison
Ni Wazuh ni CrowdSec n’ont été installés avant le choix : les ressources viennent de la documentation des éditeurs.
Le fonctionnement à 6 Gio est un essai, mesuré sur une semaine ; le dossier sera complété par les mesures réelles
(étape 59 de la documentation). La page Netgate du paquet Suricata était inaccessible le 02/11 : sa consommation
mémoire et le mode de capture sur cartes virtuelles restent À VÉRIFIER à l’installation.