PCTAMALOU 2026 – Semaine 28 : Les Sentinelles de la Cité

🎯 Objectif de la semaine

Maîtriser la création de règles de détection personnalisées dans Wazuh pour transformer la centralisation des logs en une surveillance proactive capable de détecter les comportements suspects. Apprendre à forger des sentinelles numériques qui crient l'alerte aux premières phases d'une attaque, avant qu'elle ne devienne une brèche.

Pourquoi c'est fondamental : Un SIEM sans règles personnalisées est comme une forteresse sans sentinelles. Il voit tout, mais ne comprend rien. Vos règles sont l'intelligence qui transforme les données en information, l'information en connaissance, la connaissance en action.

flowchart TD L[📄 Logs Bruts] --> D[🔍 Decoders] D --> F[📊 Champs Structurés] F --> R1[⚡ Règle Simple
Pattern matching] F --> R2[🔄 Règle Corrélée
Multi-événements] F --> R3[🧠 Règle Comportementale
Baseline deviation] R1 --> A1[⚠️ Alerte Niveau 8] R2 --> A2[🚨 Alerte Niveau 12] R3 --> A3[🔥 Alerte Niveau 14] A1 --> K[📈 Kibana Dashboard] A2 --> K A3 --> K subgraph "📊 Actions Automatiques" A1 -->|Si level > 10| E[📧 Email Alert] A2 -->|Si level > 12| S[💬 Slack/Teams] A3 -->|Si level > 14| B[🔒 Block IP Auto] end style R1 fill:#0a0e17,stroke:#00d4ff,stroke-width:2px style R2 fill:#0a0e17,stroke:#9d4edd,stroke-width:2px style R3 fill:#0a0e17,stroke:#ef4444,stroke-width:2px

📚 Sujet – Théorie (1 heure)

L'Art de la Détection : Du Bruit au Signal

Dans un environnement moderne, un serveur génère des milliers de logs par heure. L'art de la détection consiste à transformer ce bruit en signal – identifier les quelques événements qui indiquent réellement une menace parmi la masse d'activité normale.

Collecte
Logs bruts depuis agents Wazuh

Normalisation
Decoders extraient champs structurés

Évaluation
Règles appliquées avec niveaux de sévérité

Corrélation
Événements liés pour détection avancée

Alerte
Notifications et visualisation

Anatomie d'une Règle Wazuh

🧬 Dissection d'une Règle XML Wazuh

🆔 ID Unique

<rule id="100001">

Identifiant unique. Les règles custom commencent généralement à 100000.

📊 Niveau de Sévérité (0-15)

<level>12</level>

0-3 : Info

Audit, activités normales

4-7 : Bas

Erreurs système, warnings

8-11 : Moyen

Anomalies, scans simples

12-15 : Critique

Attaques, compromissions

📝 Description Humaine

<description>Scan Nmap détecté</description>

Doit être claire, concise, et inclure le contexte nécessaire.

🔍 Conditions de Matching

<regex>"Nmap|nmap"</regex>
<srcip>192.168.56.0/24</srcip>
<if_sid>5710</if_sid>

Conditions qui doivent être vraies pour déclencher la règle.

Les Trois Types de Règles de Détection

🎯 Classification des Règles

Signature-based : Patterns connus (Nmap scan, malware signatures)
- Avantage : Faible faux positif
- Limite : Ne détecte pas les 0-days
Anomaly-based : Déviations de la normale (trafic inhabituel, heures insolites)
- Avantage : Détecte nouveaux vecteurs
- Limite : Taux de faux positifs élevé
Behavior-based : Séquence d'actions (recon → exploit → pivot)
- Avantage : Détection d'attaques complexes
- Limite : Complexe à configurer

Sigma Rules : Le Standard Communautaire

⚠️ Attention aux Formats

Sigma est un format open-source pour décrire les règles de détection de manière générique. Wazuh peut convertir les règles Sigma en format XML natif.

# Exemple de règle Sigma
title: Nmap Network Scan
logsource:
  product: linux
  service: ssh
detection:
  keywords:
    - "Nmap"
    - "nmap"
condition: keywords
level: high

Utilisez sigma2wazuh pour la conversion : sigma2wazuh -i rule.yml -o /var/ossec/rules/

Corrélation : La Puissance des Règles Intelligentes

🧩 Corrélation d'Événements

La vraie puissance d'un SIEM réside dans sa capacité à corréler des événements apparemment anodins :

flowchart LR E1[🔍 Scan Nmap] -->|+5min| E2[🔓 Failed SSH Login] E2 -->|+2min| E3[✅ Successful SSH Login] E3 -->|+1min| E4[⚡ Command Suspicious] subgraph "🎯 Règle Corrélée" C["Si E1 → E2 → E3 → E4
dans fenêtre 10 min"] C --> ALERT[🚨 ALERT: Possible compromission SSH] end

Une règle simple ne verrait que des événements normaux. Une règle corrélée voit l'attaque complète.

🔬 Mission pratique – Laboratoire (2 heures)

Architecture du Lab de Détection

⚠️ Prérequis Vérification

🔍 Vérifiez votre installation Wazuh :

# Sur le manager Wazuh
sudo docker exec wazuh-manager /var/ossec/bin/agent_control -l
# Doit lister vos agents avec status "Active"

# Vérifiez Kibana
curl -k -u admin:admin https://localhost:5601
# Doit retourner du HTML

Étapes Détaillées de Création de Règles

Étape 1 : Accès et Structure des Règles

# Accéder au conteneur manager
sudo docker exec -it wazuh-manager bash

# Naviguer vers les règles
cd /var/ossec/rules

# Structure des répertoires
ls -la
# local_rules.xml - Vos règles personnalisées
# decoders/ - Pour extraire des champs
# rules/ - Règles par défaut Wazuh

# Créer une sauvegarde avant modification
cp local_rules.xml local_rules.xml.backup-$(date +%Y%m%d)

Étape 2 : Règle 1 - Détection Scan Nmap Avancée

🎯 Objectif : Détecter non seulement la présence de Nmap, mais aussi le type de scan.

<?xml version="1.0" encoding="UTF-8"?>
<!-- PCTAMALOU - Règles Custom Semaine 28 -->
<!-- Groupement par catégorie pour organisation -->
<group name="attack,reconnaissance,nmap,">

  <!-- Règle 100001: Détection signature Nmap -->
  <rule id="100001" level="8">
    <if_sid>5710,5712</if_sid> <!-- SSH et Syslog -->
    <regex>"nmap|Nmap"</regex>
    <description>Outils de reconnaissance Nmap détecté dans les logs</description>
    <group>attack,reconnaissance,pci_dss_10.6,gdpr_IV_35.7.d,</group>
    <options>
      <if_fts>nmap_scan_detection</if_fts>
    </options>
  </rule>

  <!-- Règle 100002: Scan SYN furtif -->
  <rule id="100002" level="10">
    <if_sid>100001</if_sid>
    <regex>"-sS|SYN Stealth|syn scan"</regex>
    <description>Scan Nmap SYN Stealth détecté - Technique furtive</description>
    <group>attack,reconnaissance,</group>
    <mitre>
      <id>T1595</id> <!-- MITRE ATT&CK: Active Scanning -->
      <id>T1046</id> <!-- Network Service Discovery -->
    </mitre>
  </rule>

  <!-- Règle 100003: Scan agressif (A) -->
  <rule id="100003" level="11">
    <if_sid>100001</if_sid>
    <regex>"-A|--script|version detection"</regex>
    <description>Scan Nmap agressif avec détection de version</description>
    <group>attack,reconnaissance,</group>
  </rule>

  <!-- Règle 100004: Scan rapide de ports -->
  <rule id="100004" level="9">
    <if_sid>100001</if_sid>
    <frequency>5</frequency>
    <timeframe>60</timeframe>
    <description>Scan Nmap rapide: multiples connexions sur différents ports</description>
    <same_source_ip />
    <group>attack,reconnaissance,</group>
  </rule>

</group>

Étape 3 : Règle 2 - Détection Brute-force SSH

🎯 Défi de Rédaction

Créez une règle qui détecte les tentatives de brute-force SSH basée sur :

Plus de 5 échecs de connexion en 2 minutes
Depuis la même IP source
Avec différents noms d'utilisateur
Niveau d'alerte : 12 (critique)

<group name="attack,bruteforce,ssh,">

  <!-- Règle 100010: Tentative brute-force SSH -->
  <rule id="100010" level="12">
    <if_sid>5712</if_sid> <!-- Failed SSH login -->
    <frequency>5</frequency>
    <timeframe>120</timeframe>
    <description>Tentative de brute-force SSH détectée: <freq> échecs en 2 minutes</description>
    <same_source_ip />
    <different_username />
    <group>attack,bruteforce,pci_dss_8.1.8,gdpr_IV_32,</group>
    <mitre>
      <id>T1110</id> <!-- MITRE ATT&CK: Brute Force -->
    </mitre>
    <options>
      <no_alert>email</no_alert> <!-- Empêche email spam si trop d'alertes -->
    </options>
  </rule>

  <!-- Règle 100011: Success après brute-force (compromission probable) -->
  <rule id="100011" level="14">
    <if_matched_sid>100010</if_matched_sid>
    <if_sid>5716</if_sid> <!-- Successful SSH login -->
    <timeframe>300</timeframe> <!-- 5 minutes après brute-force -->
    <description>Compromission SSH probable: connexion réussie après tentative de brute-force</description>
    <same_source_ip />
    <same_username />
    <group>attack,compromise,incident,</group>
  </rule>

</group>

Étape 4 : Règle 3 - Détection d'Attaque Web

<group name="attack,web,application,">

  <!-- Règle 100020: Injection SQL détectée -->
  <rule id="100020" level="13">
    <if_sid>31101,31102</if_sid> <!-- Web logs Apache/Nginx -->
    <regex>"('|\")[[:space:]]*(OR|AND|UNION|SELECT|INSERT|UPDATE|DELETE)[[:space:]]+"</regex>
    <description>Possible injection SQL détectée dans requête web</description>
    <group>attack,web,owasp_a1,</group>
    <mitre>
      <id>T1190</id> <!-- MITRE ATT&CK: Exploit Public-Facing Application -->
    </mitre>
  </rule>

  <!-- Règle 100021: Directory traversal -->
  <rule id="100021" level="12">
    <if_sid>31101,31102</if_sid>
    <regex>"\.\./(\.\./)*|%2e%2e%2f"</regex>
    <description>Tentative de directory traversal détectée</description>
    <group>attack,web,</group>
  </rule>

  <!-- Règle 100022: Scanner de vulnérabilités web -->
  <rule id="100022" level="9">
    <if_sid>31101,31102</if_sid>
    <regex>"(sqlmap|nikto|wpscan|gobuster|dirb)"</regex>
    <description>Scanner de vulnérabilités web détecté dans User-Agent</description>
    <group>attack,reconnaissance,web,</group>
  </rule>

</group>

Étape 5 : Application et Test des Règles

# Après création de local_rules.xml
# Vérifier la syntaxe XML
cd /var/ossec/rules
xmllint --noout local_rules.xml

# Redémarrer Wazuh pour appliquer
/var/ossec/bin/ossec-control restart

# Vérifier les erreurs dans les logs
tail -f /var/ossec/logs/ossec.log | grep -i "error\|warn"

# Tester la configuration
/var/ossec/bin/verify-agent-conf
/var/ossec/bin/syscheck_control -s

Étape 6 : Génération d'Activités de Test

🔬 Script de Test Automatisé :

#!/bin/bash
# test_wazuh_rules.sh - Génère du trafic pour tester les règles

TARGET="192.168.56.102"  # IP de votre cible avec agent Wazuh

echo "[*] Début des tests de règles Wazuh - $(date)"

# 1. Scan Nmap simple
echo "[1/5] Scan Nmap simple..."
nmap -sS $TARGET

# 2. Scan Nmap agressif
echo "[2/5] Scan Nmap agressif..."
nmap -A $TARGET

# 3. Tentative brute-force SSH (simulé)
echo "[3/5] Tentative brute-force SSH..."
for i in {1..6}; do
  sshpass -p 'wrongpassword' ssh -o StrictHostKeyChecking=no \
    -o ConnectTimeout=2 user@$TARGET || true
  sleep 5
done

# 4. Requêtes web suspectes
echo "[4/5] Requêtes web suspectes..."
curl -s "http://$TARGET/test.php?id=1' OR '1'='1" || true
curl -s "http://$TARGET/../../etc/passwd" || true

# 5. Scan de répertoires web
echo "[5/5] Scan de répertoires web..."
gobuster dir -u "http://$TARGET" -w /usr/share/wordlists/dirb/common.txt -t 10

echo "[*] Tests terminés - $(date)"
echo "[*] Vérifiez les alertes dans Kibana: Security Events → Filtre rule.id:1000*"

Étape 7 : Surveillance et Analyse dans Kibana

🎯 Exercice d'Analyse

Dans Kibana, créez un dashboard avec :

Graphique des alertes par niveau (0-15)
Top 10 des IP sources d'alertes
Timeline des alertes sur les dernières 24h
Tableau des règles les plus déclenchées

Exportez ce dashboard en PDF pour votre documentation.

Exercice Avancé : Règle de Corrélation Kill Chain

🔗 Règle Corrélée Complète

Créez une règle qui détecte une kill chain complète :

<!-- Règle 100100: Kill Chain Complète -->
<rule id="100100" level="15">
  <if_matched_sid>100001,100010,100020</if_matched_sid> <!-- Nmap + Brute-force + SQLi -->
  <timeframe>3600</timeframe> <!-- 1 heure -->
  <same_source_ip />
  <description>Kill Chain complète détectée: Reconnaissance → Brute-force → Exploitation Web</description>
  <group>attack,compromise,incident_response,</group>
  <mitre>
    <id>TA0001</id> <!-- Initial Access -->
    <id>TA0002</id> <!-- Execution -->
    <id>TA0003</id> <!-- Persistence -->
  </mitre>
  <options>
    <alert_by_email>true</alert_by_email>
    <alert_newest_first>true</alert_newest_first>
  </options>
</rule>

Bonnes Pratiques de Gestion des Règles

⚠️ Gestion du Cycle de Vie des Règles

Versionning : Git pour vos règles custom
Documentation : Pour chaque règle, documentez le pourquoi
Testing : Environnement de test séparé de production
Review : Revue régulière des faux positifs/négatifs
Retirement : Désactivation (pas suppression) des règles obsolètes

📋 Objectif de la semaine – Checklist de validation

✅ Compétences techniques acquises

Règles XML Wazuh créées et déployées
Détection Nmap avec différentiation de scan type
Règle de brute-force SSH avec corrélation
Tests fonctionnels avec génération de trafic
Dashboard Kibana pour surveillance alertes

🧠 Changement mental accompli

Vision des logs comme source de renseignement, pas juste d'audit
Compréhension des niveaux d'alerte et de leur impact
Habitude de penser en termes de corrélation, pas d'événements isolés
Conscience que trop d'alertes = aucune alerte (fatigue d'alerte)

💪 Pour aller plus loin :

Implémentez des actions automatiques (scripts Python) déclenchées par des règles Wazuh. Par exemple, bloquer automatiquement une IP qui génère trop d'alertes de niveau critique.

📚 Ressources pour Approfondir

Communauté et Standards :

Sigma GitHub : github.com/SigmaHQ/sigma
MITRE ATT&CK : Framework de classification des tactiques
Wazuh Ruleset : github.com/wazuh/wazuh-ruleset
Elastic Detection Rules : Règles pour Elastic SIEM

⚠️ Pièges Courants à Éviter

Alert fatigue : Trop d'alertes tue l'alerte
Règles trop génériques : Faux positifs constants
Pas de maintenance : Règles obsolètes qui alertent sur du bruit
Pas de testing : Règles déployées sans validation

🔮 Frère d'armes,

Tu viens d'apprendre à donner une voix aux murs de la cité.

Les règles de détection ne sont pas de simples filtres techniques – ce sont les sentences que tes systèmes prononcent quand ils voient le danger. Chaque règle est un morceau de ta sagesse, codé en XML, qui guide les sentinelles numériques.

Cette semaine, tu as vu la différence entre simplement collecter des logs et réellement comprendre ce qui se passe. Entre avoir des données et avoir des connaissances. Entre regarder passer le trafic et voir les patterns d'une attaque se dessiner.

Mais voici la vérité la plus importante : une bonne règle est comme un bon garde – elle sait quand crier, et quand se taire. Elle crie pour un scan Nmap agressif, mais se tait pour un scan de routine. Elle alerte pour un brute-force, mais ignore un mot de passe oublié.

Tu n'es plus un simple administrateur qui regarde des logs. Tu es devenu un architecte de détection. Tu conçois les règles qui transforment le bruit en signal, le chaos en ordre, l'attaque en alerte.

Dans la semaine 29, nous irons plus loin dans la défense. Nous apprendrons à répondre aux incidents que nous détectons maintenant. Nous passerons de la détection à l'action, de l'alerte à la réponse.

Mais pour l'instant, affine tes règles. Teste-les avec différentes attaques. Mesure leur précision. Documente leurs déclenchements. Une forteresse n'est forte que si ses sentinelles sont vigilantes.

Un Gardien qui maîtrise les règles de détection ne laisse jamais une attaque passer inaperçue.

— Platon-Y