Détection des intrusions : mettre en place une surveillance efficace

Ce que vous saurez faire à la fin

1. Comprendre la différence entre IDS, IPS, SIEM, SOAR et choisir l’outil adapté à la taille de votre PME.
2. Déployer Wazuh (SIEM open source gratuit) avec collecte de logs Windows, Linux et appliances réseau.
3. Installer Suricata comme IDS pour analyser le trafic réseau en temps réel et détecter les intrusions.
4. Créer des règles de corrélation et des alertes pertinentes en évitant la fatigue d’alerte.
5. Décider entre un SOC interne et un SOC managé externalisé (MSSP) selon votre budget et vos compétences.

Durée : 7h. Pré-requis : VPS Ubuntu 22.04 avec 8 Go RAM minimum (15 000 FCFA/mois chez Scaleway ou Orange Cloud), accès root, postes Windows/Linux à monitorer, switch managé pour mirror port (en option), budget SOC externalisé : à partir de 350 000 FCFA/mois pour PME (Orange Cyberdefense Sénégal, KSecure).

Étape 1 — Distinguer IDS, IPS, SIEM et SOAR

Pour une PME, le combo gagnant : Wazuh (SIEM + EDR) + Suricata (IDS réseau). Coût en infra : un VPS à 15 000 FCFA/mois.

Étape 2 — Installer Wazuh Manager

Wazuh est gratuit, open source, et combine SIEM + HIDS + détection vulnérabilités. Installation en mode tout-en-un :

# Sur Ubuntu 22.04 avec 8 Go RAM
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

# L'installation déploie :
# - Wazuh manager (port 1514, 1515, 55000)
# - Wazuh indexer (basé sur OpenSearch, port 9200)
# - Wazuh dashboard (port 443)

# Récupérer le mot de passe admin
sudo tar -axf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt -O | grep -P "\'admin\'" -A 1

# Accéder au dashboard
# https://<ip-vps>
# user: admin / password: récupéré ci-dessus

Étape 3 — Déployer les agents Wazuh sur les postes

Sur chaque serveur ou poste Windows à monitorer :

# Windows - Téléchargement et installation
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.0-1.msi `
    -OutFile $env:tmp\wazuh-agent.msi

msiexec.exe /i $env:tmp\wazuh-agent.msi /q `
    WAZUH_MANAGER='<ip-manager>' `
    WAZUH_REGISTRATION_SERVER='<ip-manager>' `
    WAZUH_AGENT_GROUP='windows-postes'

NET START WazuhSvc

# Linux (Ubuntu/Debian)
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring \
    --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
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
WAZUH_MANAGER="<ip-manager>" sudo apt install wazuh-agent
sudo systemctl enable --now wazuh-agent

Étape 4 — Configurer la collecte de logs critiques

Éditez /var/ossec/etc/ossec.conf sur le manager pour activer les modules essentiels. Sur chaque agent, configurez les sources de logs :

<!-- Linux : surveiller les logs auth, sudo, ssh -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

<!-- Windows : journaux Sysmon et Security -->
<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

<!-- Surveillance d'intégrité de fichiers (FIM) -->
<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin</directories>
  <directories check_all="yes" realtime="yes">C:\Windows\System32</directories>
</syscheck>

Installez Sysmon sur Windows pour des logs détaillés (création de processus, connexions réseau, modifications registry) :

Invoke-WebRequest -Uri https://download.sysinternals.com/files/Sysmon.zip -OutFile sysmon.zip
Expand-Archive sysmon.zip
Invoke-WebRequest -Uri https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -OutFile config.xml
.\Sysmon\Sysmon64.exe -accepteula -i config.xml

Étape 5 — Installer Suricata pour la détection réseau

Suricata analyse le trafic réseau en temps réel et détecte les patterns d’attaque connus.

# Installation sur Ubuntu (sur le serveur passerelle ou avec port mirror)
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update
sudo apt install suricata jq

# Configurer l'interface à monitorer
sudo nano /etc/suricata/suricata.yaml
# af-packet:
#   - interface: eth0  (ou enp0s3, etc.)

# Mettre à jour les règles ET (Emerging Threats)
sudo suricata-update
sudo suricata-update list-sources
sudo suricata-update enable-source et/open

# Démarrer Suricata
sudo systemctl enable --now suricata
sudo tail -f /var/log/suricata/eve.json | jq

Étape 6 — Intégrer Suricata dans Wazuh

Pour centraliser les alertes Suricata dans Wazuh, ajoutez la lecture de eve.json à l’agent installé sur le serveur Suricata :

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Wazuh dispose de décodeurs natifs pour Suricata. Les alertes apparaissent dans le dashboard, classées par sévérité (1 à 15).

Étape 7 — Créer des règles de corrélation personnalisées

Les règles par défaut sont génériques. Adaptez-les à votre PME en éditant /var/ossec/etc/rules/local_rules.xml :

<group name="local,authentication,">
  <!-- Détecter 5 échecs SSH en 60 secondes depuis IP non sénégalaise -->
  <rule id="100100" level="10" frequency="5" timeframe="60">
    <if_matched_sid>5710</if_matched_sid>
    <description>Brute force SSH détecté</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

  <!-- Connexion admin en dehors des heures de bureau -->
  <rule id="100101" level="12">
    <if_sid>5715</if_sid>
    <user>admin|root|administrateur</user>
    <time>19:00-7:00</time>
    <weekday>saturday,sunday</weekday>
    <description>Connexion admin hors heures bureau Sénégal</description>
  </rule>

  <!-- Téléchargement suspect via PowerShell -->
  <rule id="100102" level="13">
    <if_sid>91802</if_sid>
    <match>DownloadString|Invoke-WebRequest|IEX</match>
    <description>PowerShell de téléchargement suspect</description>
  </rule>
</group>

sudo systemctl restart wazuh-manager
sudo /var/ossec/bin/wazuh-logtest # tester les règles

Étape 8 — Configurer les notifications d’alerte

Pour ne pas rater les vraies attaques, configurez les alertes vers email + Slack/Teams :

<!-- ossec.conf : email pour alertes critiques -->
<global>
  <email_notification>yes</email_notification>
  <smtp_server>smtp.gmail.com</smtp_server>
  <email_from>wazuh@votreentreprise.sn</email_from>
  <email_to>rssi@votreentreprise.sn</email_to>
  <email_maxperhour>20</email_maxperhour>
  <email_alert_level>10</email_alert_level>
</global>

<!-- Webhook Slack via Active Response -->
<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/T0/B0/XXX</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Étape 9 — Éviter la fatigue d’alerte

Trop d’alertes = aucune alerte lue. Stratégies pour réduire le bruit :

• Augmenter le seuil email à level 10+ (vraies menaces, pas l’info).
• Whitelister les IP internes connues, les scans de monitoring légitimes (UptimeRobot, etc.).
• Définir des horaires de garde : alertes critiques 24/7, alertes moyennes uniquement en heures bureau.
• Grouper les alertes similaires (10 alertes brute force en 5 min = 1 ticket).
• Réviser les règles tous les mois : désactiver celles qui produisent > 80 % de faux positifs.

Étape 10 — Mettre en place la réponse automatique (Active Response)

Wazuh peut bloquer automatiquement une IP qui attaque. Configurez avec parcimonie pour éviter de vous bloquer vous-même.

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100100,5712</rules_id>
  <timeout>1800</timeout>
</active-response>

L’IP est bloquée pour 30 minutes via iptables, puis débloquée automatiquement.

Étape 11 — Surveiller les actifs critiques en priorité

Étape 12 — Décider SOC interne vs SOC externalisé (MSSP)

Acteurs MSSP au Sénégal : Orange Cyberdefense, KSecure, Sonatel Business, Atos.

Étape 13 — Construire un runbook de réponse à incident

Pour chaque type d’alerte critique, documentez la procédure :

RUNBOOK : Détection ransomware (Rule 87105)

1. ISOLER (5 min)
   - Console Wazuh > Endpoint > Isolate
   - Ou manuellement : déconnecter câble réseau

2. PRÉSERVER LES PREUVES
   - Snapshot VM si applicable
   - Dump RAM avec WinPMEM ou LiME
   - Copie disk avec dd vers stockage externe

3. ANALYSER
   - IOC : hash fichiers, IPs C2, registry keys
   - Période d'infection : remonter Sysmon EventID 1
   - Latéralisation : chercher 4624 type 3 vers autres hosts

4. NETTOYER
   - Restaurer depuis sauvegarde saine
   - Réinstaller poste si doute
   - Changer mots de passe utilisateur

5. COMMUNIQUER
   - DG dans l'heure
   - CDP Sénégal si données personnelles touchées (72h)
   - Clients impactés par lettre

6. RETEX dans 7 jours

Étape 14 — Mesurer l’efficacité du SOC

KPI mensuels à présenter au CODIR :

• MTTD (Mean Time To Detect) : objectif < 30 min pour incidents critiques.
• MTTR (Mean Time To Respond) : objectif < 4h pour contenir une menace.
• Taux de faux positifs : objectif < 20 % des alertes investiguées.
• Couverture logs : % d’actifs avec agent Wazuh, objectif 100 %.
• Règles ajustées par mois : indicateur de maturité, viser 5-10/mois.

Erreurs classiques à éviter

• Déployer le SIEM sans définir les use cases : vous collectez des téraoctets de logs sans rien détecter.
• Trop d’alertes en email : les analystes finissent par tout ignorer (alert fatigue).
• Pas de Sysmon sur Windows : les logs natifs Windows sont insuffisants pour détecter les attaques modernes.
• Active Response trop agressif : bloquer le DG ou un client important = incident métier.
• SIEM exposé sur Internet sans MFA : votre outil de détection devient la cible n°1.
• Pas de runbook : chaque incident est géré différemment, perte de temps et erreurs.
• Sous-estimer le stockage logs : 100 endpoints = environ 50 Go/mois, prévoyez 12 mois rétention pour la conformité.

Checklist Détection d’Intrusions

✓ Wazuh Manager déployé sur VPS dédié 8 Go RAM minimum
✓ Agents Wazuh installés sur 100 % des serveurs et postes critiques
✓ Sysmon installé sur Windows avec config SwiftOnSecurity
✓ Suricata configuré avec règles ET Open à jour
✓ Logs auth.log, Security, Sysmon, applicatifs collectés
✓ Surveillance d'intégrité (FIM) activée sur dossiers critiques
✓ Règles de corrélation personnalisées au contexte PME
✓ Notifications email + Slack/Teams configurées (level 10+)
✓ Active Response activé pour brute force avec timeout
✓ Tableau de bord critiques affiché en NOC ou écran RSSI
✓ Runbooks documentés pour 5 incidents prioritaires
✓ Décision SOC interne vs MSSP prise et contractée
✓ KPI MTTD/MTTR mesurés et reportés mensuellement
✓ Rétention logs minimum 12 mois (OHADA / CDP Sénégal)
✓ Tests d'intrusion semestriels pour valider la détection