Réponse active et notifications : courriel et Teams

La réponse active de Wazuh exécute automatiquement une action sur une machine quand une règle se déclenche : bloquer une adresse IP dans le pare-feu local pendant dix minutes, par exemple. Les notifications envoient les alertes graves aux personnes qui doivent agir, par courriel ou dans un canal de messagerie comme Microsoft Teams. Ce chapitre configure une réponse active limitée dans le temps, détaille les risques d'une réaction automatique, puis branche le courriel et Teams, et relie Wazuh à la gestion des incidents et à la supervision.

Comment fonctionne la réponse active

Deux blocs de l'ossec.conf du serveur travaillent ensemble :

• un bloc <command> déclare un script de réponse : son nom, le programme à lancer, et s'il accepte une durée (timeout_allowed) ;
• un bloc <active-response> déclenche ce script : pour quelles règles (rules_id), ou à partir de quel niveau (level), sur quelle machine (location), pour combien de temps (timeout).

Quand la règle se déclenche, le serveur envoie l'ordre à l'agent, qui exécute le script avec les droits du système (root ou SYSTEM) en lui passant l'alerte. Avec un timeout, l'agent annule l'action à l'expiration du délai : l'adresse bloquée est débloquée.

Wazuh fournit des scripts prêts à l'emploi. Sous Linux : firewall-drop (ajoute l'adresse source à iptables), firewalld-drop, host-deny (l'ajoute à /etc/hosts.deny), route-null (route vers nulle part), disable-account (désactive un compte), restart-wazuh. Sous Windows : netsh.exe (règle de blocage dans le pare-feu Windows), route-null.exe, restart-wazuh.exe.

Bloquer une adresse après une force brute SSH

srv-web est le serveur le plus exposé. On veut que toute adresse qui déclenche une alerte de force brute SSH soit bloquée sur srv-web pendant dix minutes. La commande firewall-drop est déjà déclarée dans l'ossec.conf du serveur ; il suffit d'ajouter :

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712,5763</rules_id>
  <timeout>600</timeout>
</active-response>

Puis on protège les adresses qui ne doivent jamais être bloquées, dans la section <global> du même fichier, à côté des entrées existantes :

<global>
  <white_list>192.168.10.208/28</white_list>   <!-- VLAN d'administration -->
  <white_list>192.168.10.180</white_list>      <!-- le serveur Wazuh lui-même -->
</global>

sudo systemctl restart wazuh-manager

Sur srv-web, le script appelle la commande iptables. Sur Debian 13, installe le paquet iptables s'il manque : il pilote en réalité nftables, le pare-feu du noyau. Pour tester, depuis une machine du laboratoire hors de la liste blanche, tape volontairement de mauvais mots de passe SSH vers srv-web jusqu'à déclencher la règle 5763 : la connexion suivante échoue, l'agent écrit l'action dans /var/ossec/logs/active-responses.log, et le tableau de bord montre une alerte de réponse active. Dix minutes plus tard, l'adresse est débloquée.

Les précautions avant d'automatiser

Une réponse automatique agit sans qu'un humain vérifie. Bien réglée, elle ralentit un attaquant ; mal réglée, elle devient une arme contre toi.

Recevoir les alertes par courriel

Le serveur Wazuh sait envoyer des courriels, mais ne gère pas l'authentification SMTP. Or tout serveur de messagerie moderne, celui de l'entreprise comme Microsoft 365, refuse un envoi anonyme. La solution documentée : un relais local, Postfix, installé sur srv-journaux, qui accepte les messages de Wazuh sans authentification sur l'interface locale et les transmet au vrai serveur avec la méthode que celui-ci accepte. Chez Sorbier, le serveur de messagerie interne smtp.sorbier.example accepte un compte d'envoi et son mot de passe.

1. Le relais Postfix. Installe-le (à la question du type de configuration, choisis Système satellite) avec le module d'authentification :

sudo apt install -y postfix libsasl2-modules

Dans /etc/postfix/main.cf, règle le relais vers le serveur de messagerie de Sorbier, en TLS et avec authentification, et n'écoute que la machine elle-même :

inet_interfaces = loopback-only
relayhost = [smtp.sorbier.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Le compte d'envoi et son mot de passe vont dans /etc/postfix/sasl_passwd, protégé :

[smtp.sorbier.example]:587 wazuh@sorbier.example:<MOT_DE_PASSE_DU_COMPTE_D_ENVOI>

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl restart postfix
echo "Test du relais" | mail -s "Test srv-journaux" securite@sorbier.example   # paquet mailutils

2. Wazuh. Dans l'ossec.conf du serveur, les sections <global> et <alerts> existent déjà : modifie leurs valeurs.

<global>
  <email_notification>yes</email_notification>
  <smtp_server>localhost</smtp_server>
  <email_from>wazuh@sorbier.example</email_from>
  <email_to>securite@sorbier.example</email_to>
  <email_maxperhour>12</email_maxperhour>
</global>

<alerts>
  <log_alert_level>3</log_alert_level>
  <email_alert_level>12</email_alert_level>
</alerts>

Toute alerte de niveau 12 ou plus part vers la liste securite@sorbier.example. Au-delà de 12 courriels par heure, Wazuh regroupe les alertes dans un seul message, pour ne pas inonder les boîtes pendant une attaque.

3. Des envois ciblés. Un bloc <email_alerts> envoie certaines alertes à une personne précise, sans attendre le regroupement :

<email_alerts>
  <email_to>antoine.mercier@sorbier.example</email_to>
  <rule_id>100110, 100320</rule_id>
  <do_not_delay />
</email_alerts>

Le responsable reçoit immédiatement les modifications nocturnes des groupes d'administration (règle 100110) et les créations de comptes suivies d'une élévation (règle 100320).

Publier les alertes dans Teams

Chez Sorbier, l'équipe informatique travaille dans un canal Microsoft Teams. Y publier les alertes graves les rend visibles de tous, et la discussion sur l'alerte se fait au même endroit. Wazuh intègre nativement Slack, PagerDuty, VirusTotal, Shuffle et Maltiverse ; pour Teams, on écrit une intégration personnalisée.

1. Côté Teams. Les anciens connecteurs de webhooks entrants d'Office 365 ont été retirés en 2026 ; on passe par l'application Workflows. Dans le canal, menu … > Workflows, choisis le modèle d'envoi d'alertes de webhook vers un canal (Send webhook alerts to a channel), indique l'équipe et le canal : Teams donne une URL de webhook. Garde-la comme un secret : quiconque la connaît peut publier dans le canal.

2. Le script. Wazuh appelle un script dont le nom commence par custom-, placé dans /var/ossec/integrations/, avec trois paramètres : le fichier JSON de l'alerte, une clé d'API (inutile ici) et l'URL du webhook. Ce script en Python, /var/ossec/integrations/custom-teams, met l'alerte en forme de carte adaptative (Adaptive Card), le format qu'attend le flux Workflows :

#!/var/ossec/framework/python/bin/python3
# custom-teams : publie une alerte Wazuh dans un canal Teams (webhook créé avec Workflows).
# Wazuh appelle ce script avec trois paramètres : le fichier JSON de l'alerte, la clé d'API
# (vide ici) et l'URL du webhook (hook_url).
import json
import sys
import urllib.request


def carte(alerte):
    regle = alerte.get("rule", {})
    agent = alerte.get("agent", {})
    techniques = ", ".join(regle.get("mitre", {}).get("id", [])) or "aucune"
    faits = [
        {"title": "Niveau", "value": str(regle.get("level", "?"))},
        {"title": "Règle", "value": str(regle.get("id", "?"))},
        {"title": "Agent", "value": agent.get("name", "?")},
        {"title": "ATT&CK", "value": techniques},
        {"title": "Heure", "value": alerte.get("timestamp", "?")},
    ]
    return {
        "type": "message",
        "attachments": [
            {
                "contentType": "application/vnd.microsoft.card.adaptive",
                "content": {
                    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
                    "type": "AdaptiveCard",
                    "version": "1.4",
                    "body": [
                        {
                            "type": "TextBlock",
                            "text": "Wazuh : " + regle.get("description", "alerte"),
                            "weight": "Bolder",
                            "size": "Medium",
                            "wrap": True,
                        },
                        {"type": "FactSet", "facts": faits},
                    ],
                },
            }
        ],
    }


def main():
    fichier_alerte, hook_url = sys.argv[1], sys.argv[3]
    with open(fichier_alerte, encoding="utf-8") as f:
        alerte = json.load(f)
    corps = json.dumps(carte(alerte)).encode("utf-8")
    requete = urllib.request.Request(
        hook_url, data=corps, headers={"Content-Type": "application/json"}
    )
    with urllib.request.urlopen(requete, timeout=10) as reponse:
        print("Teams a répondu", reponse.status)


if __name__ == "__main__":
    main()

La première ligne désigne le Python livré avec le serveur Wazuh : pas besoin d'en installer un autre. Le script n'utilise que la bibliothèque standard. Donne-lui les bons droits :

sudo chmod 750 /var/ossec/integrations/custom-teams
sudo chown root:wazuh /var/ossec/integrations/custom-teams

3. Le branchement. Dans l'ossec.conf du serveur :

<integration>
  <name>custom-teams</name>
  <hook_url>https://URL-DONNEE-PAR-WORKFLOWS</hook_url>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>

Redémarre wazuh-manager. Chaque alerte de niveau 12 ou plus est publiée dans le canal sous forme de carte : description, niveau, règle, machine, techniques ATT&CK et heure. Des filtres <rule_id> ou <group> restreignent ce qui part. En cas de souci, le journal /var/ossec/logs/integrations.log dit ce qui s'est passé. N'oublie pas le flux : srv-journaux doit pouvoir joindre les services de Microsoft en HTTPS, ce que le pare-feu de Sorbier n'autorise pas par défaut pour un serveur du VLAN 20.

Relier les alertes à la gestion des incidents

Une notification n'est utile que si elle débouche sur une action tracée. Deux liens à établir :

• Avec l'outil de tickets. GLPI sait créer un ticket à partir d'un courriel reçu sur une boîte dédiée (ses collecteurs). En envoyant les alertes de niveau 12 et plus vers cette boîte, chaque alerte grave devient un ticket, avec un responsable, un statut et un historique. Le cours GLPI et gestion de parc présente l'outil.
• Avec la procédure de réponse. Une alerte qualifiée en incident déclenche la réponse à incident : main courante, confinement, éradication, retour à la normale, retour d'expérience. Si des données personnelles sont touchées, l'obligation de notifier la CNIL sous 72 heures s'applique.

Superviser Wazuh lui-même

Un SIEM en panne ne détecte plus rien, et personne ne s'en aperçoit : aucune alerte, c'est aussi ce qu'on voit quand tout va bien. La supervision de Sorbier, avec Zabbix (cours Supervision), doit donc surveiller srv-journaux comme n'importe quel serveur critique :

À l'inverse, Grafana peut afficher des données de Wazuh : l'indexeur parle le même langage qu'OpenSearch, et Grafana sait l'interroger avec sa source de données OpenSearch. Un même écran peut ainsi montrer la charge des serveurs (Zabbix) et le nombre d'alertes de sécurité (Wazuh). Le tableau de bord de Wazuh reste l'outil d'enquête ; Grafana, celui de la vue d'ensemble.

Exercices

<group name="sorbier,sshd,">
  <rule id="100160" level="10">
    <if_sid>5712,5763</if_sid>
    <hostname>^srv-depot$</hostname>
    <description>Sorbier : force brute SSH sur srv-depot</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100160</rules_id>
  <timeout>1800</timeout>
</active-response>