Wazuh est réparti sur 4 serveurs distincts pour optimiser les performances et la redondance. On retrouve 3 indexeurs (siem-1dexer.local.uttop.fr, siem-2dexer.local.uttop.fr, siem-3dexer.local.uttop.fr) ayant 1 To de stockage chacun. La réplication est activée, le stockage total est donc de 2 To.

Les modules Serveur (OpenSearch et Filebeat) et Dashboard (OpenDashboard) sont sur le même serveur. Si un jour le besoin d’exposer le dashboard se présente, il faudra alors séparer le module Wazuh Dashboard sur son propre serveur.

Les données des différentes sources sont envoyées au serveur, qui décode, puis génère les alertes et les transmet quotidiennement aux indexeurs.

Côté matériel, tous les serveurs ont 16 Go de mémoire et 8 vCPUs. Les VM 1dexer et 2dexer sont virtualisées sur VMWare (esx3 et esx4), 3dexer et siem sont virtualisées sur le serveur physique Hyper-V infra-SI.

Lorsqu’une nouvelle mise à jour est disponible, une notification apparaît sur la page principale. Il est possible de vérifier à tout moment l’état de mise à jour dans Menu → Dashboard management → Server APIs.

Il est recommandé de réaliser des snapshots des serveurs et des sauvegardes des configurations personnalisées avant d’effectuer les mises à jour.

Il existe sur le serveur Ansible un playbook de mise à jour des composants centraux de Wazuh : ********************. Ce playbook prépare les serveurs pour l’installation puis applique la mise à jour sur les composants dans l’ordre correct automatiquement.

Avant l’exécution, il faut cependant mettre à jour les URL du module Filebeat et des templates d’alertes aux lignes 187 et 193. Ces URL sont trouvables au lien suivant, rubrique « Configuring filebeat » : https://documentation.wazuh.com/4.14/upgrade-guide/upgrading-central-components.html#configuring-the-vulnerability-detection-and-indexer-connector

En exécutant la commande suivante, on lance la mise à jour (elle prend entre 5 et 10 minutes) :

****************************************

Si vous souhaitez réaliser la mise à jour manuellement, il faut mettre à jour chaque composant individuellement en commençant par les indexeurs et en finissant par le dashboard. Le détail de la méthode de mise à jour est disponible sur la documentation officielle de Wazuh : https://documentation.wazuh.com/4.14/upgrade-guide/upgrading-central-components.html

La mise à jour des agents est plus simple. Depuis la page de gestion des agents, on peut sélectionner la totalité des agents puis More > Upgrade agents pour mettre à jour la totalité des agents.

Si, après une mise à jour du serveur, les agents apparaissent tous comme déconnectés, il faut consulter les logs du manager Wazuh :

cat /var/ossec/logs/ossec.log | grep -i -E "error|warn"

Si des erreurs de la forme : « wazuh-authd: WARNING: Duplicate name ‘example.uttop.fr’, rejecting enrollment. Agent '001' has not been disconnected long enough to be replaced » apparaissent, cela signifie que les agents ont générés de nouvelles clés et ne peuvent pas se connecter au serveur car leurs noms d'hote est déjà pris avec une différente clé. Il faut autoriser les agents à remplacer les précédents connus, même si la clé est différente. Pour cela, modifiez le fichier /var/ossec/etc/ossec.conf et dans la section <auth> ajoutez les lignes :

<force_insert>yes</force_insert>
<force_time>0</force_time>

Redémarrez le manager :

sudo systemctl restart wazuh-manager

Après quelques secondes, les agents devraient se connecter. Il faut ensuite supprimer ces lignes par sécurité.

Merci d'ajouter ici les autres problèmes identifiés et leurs solutions

Il existe plusieurs sources de données ingérées dans Wazuh :

Les agents sont la source principale d’informations sur les serveurs. Ces programmes sont installés dans l’OS et permettent d’obtenir des informations sur les serveurs, les vulnérabilités et la configuration. Ils surveillent les logs de l’OS mais aussi les logs applicatifs.

On peut ajouter une nouvelle source de logs sur un agent (pour une application par exemple) en l’ajoutant dans le fichier ossec.conf, soit directement sur l’agent, soit sur le serveur, ou bien sur un groupe directement (/var/ossec/etc/shared/nom_du_groupe/agent.conf). On ajoute une section localfile de cette forme :

<localfile>
    <log_format>format(syslog,json …)</log_format>
    <location>emplacement_des_logs</location>
</localfile>

Pour pousser la configuration, il faut redémarrer le manager puis les agents :

sudo systemctl restart wazuh-manager
sudo /var/ossec/bin/agent_control -R -a

On peut aussi utiliser cette méthode pour ingérer des informations plus personnalisées. Par exemple, Suricata (la sonde IDS mise en place sur le réseau) génère des alertes et les écrit dans un fichier JSON. Ce fichier est lu par l’agent Wazuh. Le même concept est utilisé pour Zabbix.

Installation de nouveaux agent

Pour installer un nouvel agent manuellement, la page de déploiement d’agent est très pratique : https://siem.local.uttop.fr/app/endpoints-summary#/agents-preview/deploy On sélectionne l’OS et les groupes, puis il suffit de copier les commandes sur l’agent.

S'il y a une quantité importante d’agents à installer, un playbook Ansible est disponible. Il faudra penser à mettre à jour les paquets d’installation à la dernière version.

En dehors des données obtenues des agents, Wazuh ingère aussi via syslog les informations de différents éléments.

Le Pare-feu Palo Alto transmet les logs de trafic, d'URL, de menaces (threat), WildFire, d'authentification et de données. Cette partie est configurable depuis la console PaloAlto : Objects → Log Forwarding.

Les switchs transmettent leurs alertes via logging:

Aruba:

********************
********************
********************

Alcatel:

********************
********************
********************
********************

Les syslog de Vcenter sont aussi transferé, configuré depuis la page https://********************

Les iDrac et iLO permettent aussi de transmettre le syslog vers Wazuh.

Pour ajouter une nouvelle source syslog, la configuration côté source peut varier mais il faut toujours autoriser l’IP dans Wazuh. Dans le fichier /var/ossec/etc/ossec.conf, section <remote>, il faut ajouter une ligne :

<allowed-ips>172.0.0.1</allowed-ips>

en remplaçant avec l’IP de la machine source. Il est aussi possible d’ajouter des plages d'adresses directement (127.0.0.0/24 par exemple).

Il est aussi possible d’importer des données via requêtes API. Plusieurs méthodes sont possibles pour cela. Actuellement, seul HarfangLab est utilisé de cette manière : un script Python est exécuté par cron. Ce script écrit dans un fichier dont le chemin est spécifié comme fichier local dans ossec.conf. On précisera de cette manière :

<localfile>
    <log_format>json</log_format>
    <location>********************</location>
</localfile>

Lors de l’ajout de nouvelles sources de données, si un décodeur n’est pas inclus dans Wazuh, il faut créer un décodeur personnalisé. Les décodeurs se trouvent dans le fichier /var/ossec/etc/decoders/local_decoders.xml.

Ils consistent à identifier un log reçu pour extraire les données importantes et le classer. Il faut donc identifier les éléments uniques à ce type de log et les noter pour l’identification, puis une expression régulière (regex) est utilisée pour extraire les données voulues dans des valeurs utilisables par Wazuh.

L’identification peut être réalisée par des mots-clés ou bien des patterns. Prenons pour exemple les décodeurs pour les switchs Aruba :

********************
********************
********************
********************
********************
********************
********************

Le premier décodeur sert à identifier le log reçu comme un log provenant d’un switch Aruba en détectant le pattern utilisé par ces switchs. Le deuxième est un décodeur enfant qui, pour tout log détecté comme provenant d’un switch Aruba, extrait les informations voulues (nom du switch, importance de l’événement, etc.). Le module de création d’alerte obtient donc des données lisibles pour pouvoir chercher le déclenchement d’une règle.

Pour tout décodeur personnalisé, un groupe de règles personnalisées doit être créé. En effet, même décodés, si aucune règle n’est déclenchée par le log, aucune alerte ne sera créée et, par conséquent, l’information n'est pas conservée dans Wazuh.

Toutes les règles personnalisées sont présentes dans le fichier /var/ossec/etc/rules/local_rules.xml.

Prenons pour exemple les règles pour les switchs Aruba :

********************
********************
********************
********************
********************

Toutes les règles sont insérées dans un groupe spécifique, ce qui est très utile pour la recherche depuis Wazuh.

Pour chaque règle, il faut indiquer un identifiant unique et un niveau de sévérité.

La première règle est très générale, tous les logs décodés par le décodeur des switchs la déclenchent (<decoded_as>********************</decoded_as>). Les suivantes se basent sur l’identifiant de la première règle (<if_sid>********************</if_sid>) puis trient avec la valeur décodée ******************** pour essentiellement convertir le niveau de criticité fourni par le switch en un niveau utilisé par Wazuh.

Des faux positifs récurrents peuvent apparaître sur Wazuh, générant de la fatigue de log, du bruit et donc une perte de temps pour l’équipe. Pour faire disparaître ces faux positifs, il faut créer des règles précises les identifiant avec un niveau 0. La dernière section du fichier est dédiée à ces faux positifs.

Par exemple, les switchs Alcatel créent des alertes lors d’une connexion SSH, ce qui est normal. Mais le serveur Ansible se connecte aux switchs automatiquement tous les jours pour son activité normale. On peut donc créer une règle enfant de celle générant l’alerte en question en filtrant pour le serveur Ansible afin de déclencher une alerte de niveau 0, qui écrit par-dessus l’alerte originale. Le faux positif a alors disparu.

********************
********************
********************
********************

Il est possible de tester si une règle fonctionne correctement, il faut obtenir un ou plusieurs logs tels qu'ils sont obtenu par Wazuh. Puis dans Menu → Server Management → Ruleset test, on entre les logs et lance le teste.

Le teste nous indique le résultat du décodage et de l'alerte.

Un dashboard est un regroupement de visualisations, organisées pour avoir une observation efficace de l’information. Le dashboard peut être dédié à la surveillance d’un type d’événements, à un service ou bien à un utilisateur spécifique.

Avant de débuter la création d’un dashboard, il faut commencer par se demander quel est son but et quelles informations vont être tirées de son observation. Après cela, il est temps de commencer les différentes visualisations.

Les visualisations sont le moyen le plus efficace de représenter une information voulue. Elles peuvent prendre de nombreuses formes, de la simple métrique à une frise chronologique ou une carte. Pour créer une visualisation, il faut commencer par comprendre l’information que l’on cherche à obtenir, puis déterminer le meilleur format visuel pour cette information, avant de chercher la source des données.

La source de l’information est un index ou bien une recherche personnalisée. Dans la majorité des cas, il s’agit de l’index d’alertes, mais il y a des index spécialisés pour des informations précises (une visualisation ne peut utiliser qu’un seul index). L’utilisation d’une recherche personnalisée comme source d’une visualisation est utile pour ne pas avoir à copier des filtres de recherche pour plusieurs visualisations différentes. En effet, une recherche personnalisée n’est rien de plus qu’une liste de filtres et il est tout à fait possible d’ajouter des filtres sur la visualisation ou même sur le dashboard. Il y a énormément d’informations pouvant être extraites des alertes sur Wazuh, mais il est possible qu'elles soient manquantes.

Zabbix transmet les données de façon minime vers Wazuh. Donc, dans le cas où des données opérationnelles nécessaires pour la visualisation voulue ne sont pas transmises, il faut indiquer à Zabbix de les transmettre. Pour ce faire, il faut identifier la donnée voulue (clic droit sur un hôte → Éléments), puis la sélectionner et dans l’onglet « Tags » ajouter le tag Target : Wazuh. Attention, cela n’ajoutera que la donnée de cet hôte. Pour la donnée globale, il faut dans l’onglet Éléments, sélectionner l’élément parent et ajouter le tag à cet endroit.

Après une sauvegarde, la donnée commencera à apparaître sous la forme d’alerte Wazuh et pourra donc être visualisée.

Pour plus de détails sur le fonctionnement des différentes visualisations et le fonctionnement des différents champs, merci de consulter la documentation officielle : https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/creating-custom-dashboards.html

Afin de surveiller des comportements ou patterns anormaux très spécifiques, il est possible de créer un monitor dédié, lié à une alerte et générant une notification externe.

Par exemple, Zabbix récupère constamment les températures ambiantes des serveurs physiques ; cette donnée est transférée vers Wazuh. On pourrait donc vouloir créer une alerte lorsque la température d’une salle dépasse un certain seuil.

Pour cela, il faut créer un monitor via le menu : Menu → Explore → Alerting → Monitor.

On le nomme et on sélectionne la méthode de collecte de l’information. Dans ce cas, ce sera par requête. On indique aussi la fréquence à laquelle la requête est réalisée (ici, toutes les 5 minutes).

On précise ensuite la source utilisée pour les requêtes.

Il faut ensuite écrire une requête précise pour extraire l’information sur laquelle nous réaliserons le déclenchement. Ici, on récupère toutes les données de température ambiante envoyées par Zabbix lors des 3 dernières minutes, supérieures à 27°C et provenant des serveurs physiques.

Une autre option aurait été de réaliser une requête plus vaste et d'ajouter le critère de température supérieure à 27°C directement dans le déclencheur.

********************
********************
********************
********************
********************

En temps normal, la requête devrait renvoyer que rien n’a été trouvé, la liste « hits » est donc vide :

********************
********************
********************

Comme l’extraction est exacte, il n'y a pas besoin de règle de déclenchement complexe : on déclenche simplement s'il y a un résultat. Dans un autre cas, on pourrait complexifier le déclencheur (voir le monitor ssh-successful-login-time).

ctx.results[0].hits.total.value > 0

Une fois le déclencheur activé, il génère un message via l'un des canaux de communication mis en place. Wazuh permet d'utiliser diverses méthodes, mais deux ont été mises en place ici :

• Email via ******************** à l'adresse ********************.
• Tchap avec un Webhook Matrix via le compte Tchap ******************** dans le salon Tchap Wazuh.

On crée le webhook avec la commande suivante :

********************
********************
********************

Et on l'enregistre avec :

sudo pm2 save --force

Où -t est le token permanent obtenu via une requête POST :

curl -X POST "********************"      -H "Content-Type: application/json"      -d '{
           "type": "m.login.password",
           "identifier": {
               "type": "m.id.user",
               "user": "********************"
           },
           "password": "**********",
           "initial_device_display_name": "********************"
         }'

Et -k est la clé à insérer directement dans le message JSON, cette clé est arbitraire, il faut juste que ce soit la même dans le webhook et le message :

{
  "key": "secret",
  "body": "Message"
}

Lors de la création du canal de communication dans Wazuh, on sélectionne Custom Webhook et on précise un envoi POST, le header JSON (Content-Type: application/json) et dans l’URL :

********************
********************

Le code du salon (CODESALON) est accessible dans les paramètres du salon spécifique : Paramètres → Avancé → Identifiant interne du salon.

Le contrôle d’accès au dashboard Wazuh (siem-indexer@uttop.fr) est basé sur du RBAC (Role-Based Access Control), c’est-à-dire que les accès d’un utilisateur dépendent de son rôle. Sur notre infrastructure Wazuh, l’authentification se fait en SSO via SAML.

Il est possible de donner des accès à des utilisateurs ou des groupes, de créer des autorisations personnalisées et donc de lier des groupes LDAP à des groupes Wazuh.

Cependant, il est obligatoire de configurer ce contrôle d’accès à deux endroits différents car Wazuh utilise deux moteurs de permissions distincts : l’un pour la gestion de l’accès aux données et l’autre pour la gestion de l’infrastructure.

Le contrôle d’accès aux données est géré par le module OpenSearch Security présent sur les indexeurs. Les fichiers permettant de le configurer sont dans le dossier /etc/wazuh-indexer/opensearch-security/.

Il est aussi possible de réaliser cette configuration depuis le dashboard : Menu → Indexer management → Security.

Le fichier roles_mapping.yml permet de lier un utilisateur ou un rôle LDAP à un rôle Wazuh. Par exemple, cet extrait montre que les groupes ******************** et ******************** ainsi que l’utilisateur ******************** sont liés au groupe ******************** :

********************
********************
********************
********************
********************

Sur le dashboard, dans Menu → Server Management → Security, on retrouve le module de contrôle d’accès. La page Roles permet de créer des rôles personnalisés, la page Policies permet de créer des politiques donnant des droits spécifiques à des rôles, et le Role mapping permet (comme pour l’indexeur) de lier un groupe ou un utilisateur du LDAP à un rôle du Dashboard Wazuh.

Par exemple, ce mapping réalise la même chose que celui vu précédemment pour l’indexeur. Un accès sur le Dashboard permettra de se connecter et de modifier les paramètres du serveur, mais ne donnera l’accès à aucune donnée.

Image:

Pour plus d'informations, veuillez consulter la documentation officielle : https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html