Exploiter Wazuh : tri des alertes, rétention, sauvegarde et mises à jour

Exploiter Wazuh, c'est le faire vivre après l'installation : regarder les alertes chaque jour et en tirer des décisions, ajuster les règles, limiter la durée de conservation des données, gérer qui a accès à quoi, sauvegarder ce qui permet de reconstruire le serveur, et le mettre à jour sans le casser. C'est ce qui sépare un SIEM utile d'une démonstration qui s'endort au bout d'un mois. Ce chapitre donne la routine d'exploitation, les réglages qui l'accompagnent, et la façon de présenter ce travail à l'examen.

Une routine d'exploitation

Cette routine prend une vingtaine de minutes par jour dans une PME comme Sorbier. Sans elle, les alertes s'accumulent, et le jour de l'incident, personne ne sait plus distinguer l'anormal du bruit habituel.

Trier les alertes chaque jour

Le tri quotidien suit la démarche du chapitre 11, en commençant par le haut :

1. Les alertes de niveau 12 et plus : chacune est lue et qualifiée. Elles devraient être rares ; si elles ne le sont pas, c'est qu'une règle est mal réglée.
2. Les alertes de niveau 10 et 11 : on les regroupe par règle et par source (le graphique des règles les plus fréquentes aide), puis on examine chaque groupe.
3. Les nouveautés : une règle qui n'était jamais apparue, un agent qui produit soudain dix fois plus d'alertes, une adresse inconnue.

Chaque alerte grave reçoit une décision écrite dans le ticket : faux positif (avec la cause), vrai positif bénin (avec la justification, le ticket de changement), ou incident (avec le numéro de l'incident). Cette trace sert le jour où l'on se demande « l'avait-on vu ? », et c'est elle qu'un auditeur ou un jury demande à voir.

Gérer la durée de conservation

Par défaut, l'indexeur garde les alertes sans limite : un index par jour, jusqu'à ce que le disque soit plein. C'est un problème technique (l'indexeur bloque les écritures quand le disque est presque plein, et la détection s'arrête) et un problème juridique : les alertes contiennent des données personnelles, que le RGPD interdit de garder plus longtemps que nécessaire. Sorbier retient 180 jours, dans la fourchette de six mois à un an que recommande la CNIL pour les journaux de sécurité, et l'inscrit à son registre des traitements.

Une politique de gestion des index (ISM, Index State Management) supprime automatiquement les index plus anciens que la durée fixée. Dans le tableau de bord :

1. Menu ☰ > Indexer management > Index Management.
2. State management policies > Create policy > JSON editor > Continue.
3. Policy ID : sorbier-retention-alertes.
4. Remplace le contenu par la politique ci-dessous, puis Create.

{
  "policy": {
    "description": "Sorbier : suppression des alertes Wazuh après 180 jours",
    "default_state": "conservation",
    "states": [
      {
        "name": "conservation",
        "actions": [],
        "transitions": [
          { "state_name": "suppression", "conditions": { "min_index_age": "180d" } }
        ]
      },
      {
        "name": "suppression",
        "actions": [
          { "retry": { "count": 3, "backoff": "exponential", "delay": "1m" }, "delete": {} }
        ],
        "transitions": []
      }
    ],
    "ism_template": [
      { "index_patterns": ["wazuh-alerts-*"], "priority": 1 }
    ]
  }
}

Chaque nouvel index d'alertes entre dans l'état conservation ; à 180 jours, il passe dans l'état suppression et il est effacé. Le modèle ism_template applique la politique aux index créés après elle. Pour les index déjà présents : Index Management > Indices, sélectionne-les, Actions > Apply policy, choisis sorbier-retention-alertes.

Comptes et droits dans le tableau de bord

Le compte admin peut tout faire : modifier les règles, supprimer des agents, effacer des index. On ne le partage pas et on ne s'en sert pas au quotidien. Chaque personne a son compte nominatif, avec les droits de son rôle :

Les droits se règlent à deux endroits, parce que Wazuh a deux composants qui protègent chacun leurs données :

• l'indexeur, qui garde les alertes : Indexer management > Security, rubriques des utilisateurs internes (Internal users), des rôles et de leur association ; c'est là qu'on crée le compte et qu'on dit quels index il peut lire ;
• l'API du serveur, qui gère agents, règles et configuration : Server management > Security, où l'on associe le compte à un rôle de l'API, comme readonly pour la lecture seule.

Un compte de lecture seule mal réglé d'un côté peut encore agir de l'autre : teste chaque compte en te connectant avec lui. Le principe est celui du moindre privilège ; et si l'annuaire de l'entreprise le permet, on préfère brancher le tableau de bord sur une authentification centralisée plutôt que multiplier les comptes locaux.

Sauvegarder la configuration

Si srv-journaux disparaît (disque mort, rançongiciel), il faut pouvoir le reconstruire. Les alertes passées sont précieuses, mais ce qui est irremplaçable, c'est la configuration : sans client.keys, tous les agents doivent être réinscrits un par un ; sans tes règles, des mois de réglage sont perdus.

Une tâche planifiée produit chaque nuit une archive :

sudo tar -czf /var/backups/wazuh-config-$(date +%F).tar.gz \
  /var/ossec/etc/ossec.conf /var/ossec/etc/client.keys /var/ossec/etc/authd.pass \
  /var/ossec/etc/rules /var/ossec/etc/decoders /var/ossec/etc/lists /var/ossec/etc/shared \
  /var/ossec/api/configuration \
  /etc/wazuh-indexer/certs /etc/filebeat/certs /etc/wazuh-dashboard/certs

L'archive contient des clés privées et des secrets : elle se copie hors du serveur, chiffrée, vers un emplacement à accès restreint. En plus, la machine virtuelle entière est sauvegardée par la solution de sauvegarde de l'hyperviseur, ce qui permet de tout restaurer d'un bloc ; la stratégie d'ensemble (règle 3-2-1, sauvegardes hors ligne, tests de restauration) est dans le cours Sauvegarde et PRA. Une sauvegarde qu'on n'a jamais essayé de restaurer n'en est pas une : restaure l'archive sur une machine de test une fois par trimestre.

Mettre à jour Wazuh

Les mises à jour corrigent des failles (le serveur Wazuh est une cible de choix : il voit tout) et apportent des règles nouvelles. Elles se préparent :

1. Lire les notes de version : changements incompatibles, ordre et précautions particulières.

2. Prendre un instantané de la machine virtuelle dans Proxmox.

3. Réactiver le dépôt Wazuh, désactivé au chapitre 3 :

   bashCopier le code de la section Mettre à jour Wazuh

   sudo sed -i "s/^#deb /deb /" /etc/apt/sources.list.d/wazuh.list
   sudo apt update
   

4. Mettre à jour dans l'ordre : l'indexeur d'abord, puis le serveur (et Filebeat), puis le tableau de bord, en suivant le guide de mise à niveau de la documentation pour ta version (il précise, par exemple, les opérations à faire sur l'indexeur avant de l'arrêter).

5. Vérifier : les quatre services actifs, filebeat test output, les alertes qui arrivent, la version affichée dans le tableau de bord.

6. Désactiver à nouveau le dépôt.

7. Mettre à jour les agents, en dernier : un agent ne doit jamais être plus récent que le serveur. Le tableau de bord peut mettre à jour les agents à distance depuis Agents management ; sinon, on redéploie le paquet (par la même GPO, avec le nouveau MSI).

Documenter ta réalisation pour le BTS

Un serveur Wazuh bien exploité fait une excellente réalisation professionnelle pour l'épreuve E6 de l'option SISR. Le jury attend que tu expliques tes choix et que tu démontres que cela fonctionne. Une documentation solide contient :

Pendant l'épreuve, prépare une démonstration courte et sûre : un échec de connexion répété sur ton contrôleur de domaine, l'alerte qui monte au niveau 10, la règle personnalisée qui la complète, la carte qui arrive dans Teams. Le cours E6 SISR détaille l'épreuve et l'environnement attendu.

Exercices