Lire une alerte Wazuh : décodeurs, règles et niveaux

Lire une alerte Wazuh, c'est comprendre comment une ligne de journal est devenue une alerte : un décodeur a extrait ses champs (l'utilisateur, l'adresse source, l'action), puis une règle a décidé qu'elle méritait une alerte et lui a donné un niveau, de 0 (ignoré) à 16 (gravité maximale). Wazuh fournit des milliers de décodeurs et de règles. Ce chapitre suit une ligne de journal à travers le moteur d'analyse, explique les niveaux d'alerte, et apprend à lire une règle fournie par Wazuh et le contenu d'une alerte ; le chapitre 7 passe à l'écriture de tes propres règles.

Le chemin d'un journal dans le moteur d'analyse

Prends cette ligne, écrite par srv-web et lue par son agent dans journald :

Nov  3 03:12:44 srv-web sshd-session[2214]: Failed password for root from 192.168.10.71 port 51514 ssh2

Le moteur d'analyse du serveur (wazuh-analysisd) la traite en trois phases.

Phase 1, le prédécodage. Wazuh reconnaît l'en-tête au format syslog et en extrait trois champs : l'horodatage (Nov 3 03:12:44), le nom de la machine (srv-web) et le nom du programme (sshd-session). Le reste est le message.

Phase 2, le décodage. Wazuh cherche le décodeur qui correspond. Le décodeur parent sshd s'applique à tout programme dont le nom commence par sshd. Parmi ses décodeurs enfants, ssh-failed reconnaît le début Failed password et extrait, grâce à une expression régulière, l'utilisateur (root), l'adresse source (192.168.10.71) et le port source (51514).

Phase 3, les règles. Les règles forment un arbre : une règle « enfant » ne s'évalue que si sa règle « parent » a correspondu. La règle 5700 regroupe tous les événements du décodeur sshd, sans alerte. Son enfant 5716 reconnaît un message qui commence par Failed. Son enfant à lui, 5760, reconnaît Failed password : c'est la règle la plus précise qui correspond, elle donne l'alerte « sshd: authentication failed. », niveau 5. Si les échecs venus de la même adresse atteignent huit en deux minutes, la règle de fréquence 5763 « sshd: brute force trying to get access to the system », de niveau 10, se déclenche.

Le niveau final est comparé au seuil d'enregistrement, log_alert_level, qui vaut 3 par défaut : en dessous, l'événement est analysé mais aucune alerte n'est écrite.

Les niveaux d'alerte

Chaque règle a un niveau de 0 à 16. La documentation de Wazuh donne à chaque niveau un sens précis :

En pratique, on raisonne par tranches, et on règle les notifications en conséquence :

Lire une règle

Voici les deux règles SSH rencontrées plus haut, telles qu'elles sont dans /var/ossec/ruleset/rules/0095-sshd_rules.xml (on a retiré pour la lisibilité les groupes de conformité PCI DSS, RGPD, HIPAA et NIST, qui servent aux tableaux de bord de conformité) :

<rule id="5760" level="5">
  <if_sid>5700,5716</if_sid>
  <match>Failed password|Failed keyboard|authentication error</match>
  <description>sshd: authentication failed.</description>
  <mitre>
    <id>T1110.001</id>
    <id>T1021.004</id>
  </mitre>
  <group>authentication_failed,</group>
</rule>

<rule id="5763" level="10" frequency="8" timeframe="120" ignore="60">
  <if_matched_sid>5760</if_matched_sid>
  <same_source_ip />
  <description>sshd: brute force trying to get access to the system. Authentication failed.</description>
  <mitre>
    <id>T1110</id>
  </mitre>
  <group>authentication_failures,</group>
</rule>

Lis donc la règle 5763 ainsi : « si la règle 5760 (échec de mot de passe SSH) s'est produite 8 fois en 120 secondes depuis la même adresse source, lève une alerte de niveau 10, rattachée à la technique T1110 Brute Force, puis tais-toi 60 secondes ».

Lire une alerte

Chaque alerte est écrite en JSON dans /var/ossec/logs/alerts/alerts.json, une par ligne, et envoyée à l'indexeur. Le tableau de bord en affiche les champs dans le détail d'un événement. Voici l'alerte de la règle 5760 pour la ligne du début, mise en forme et abrégée :

{
  "timestamp": "2026-11-03T03:12:44.418+0100",
  "rule": {
    "level": 5,
    "description": "sshd: authentication failed.",
    "id": "5760",
    "mitre": {
      "id": ["T1110.001", "T1021.004"],
      "tactic": ["Credential Access", "Lateral Movement"],
      "technique": ["Password Guessing", "SSH"]
    },
    "firedtimes": 3,
    "groups": ["syslog", "sshd", "authentication_failed"]
  },
  "agent": { "id": "006", "name": "srv-web", "ip": "192.168.10.225" },
  "manager": { "name": "srv-journaux" },
  "full_log": "Nov  3 03:12:44 srv-web sshd-session[2214]: Failed password for root from 192.168.10.71 port 51514 ssh2",
  "predecoder": { "program_name": "sshd-session", "timestamp": "Nov  3 03:12:44", "hostname": "srv-web" },
  "decoder": { "parent": "sshd", "name": "sshd" },
  "data": { "srcip": "192.168.10.71", "srcport": "51514", "dstuser": "root" },
  "location": "journald"
}

Pour un événement Windows, les champs décodés sont rangés sous data.win : data.win.system.eventID, data.win.eventdata.targetUserName, data.win.eventdata.ipAddress, data.win.eventdata.logonType. Ce sont ces noms qu'on utilise dans les recherches du tableau de bord et, sans le préfixe data., dans les règles (win.eventdata.targetUserName).

Exercices

<rule id="87702" level="10" frequency="18" timeframe="45" ignore="240">
  <if_matched_sid>87701</if_matched_sid>
  <same_source_ip />
  <description>Multiple pfSense firewall blocks events from same source.</description>
  <mitre>
    <id>T1110</id>
  </mitre>
</rule>