106 lines
5.5 KiB
Markdown
106 lines
5.5 KiB
Markdown
# Wazuh
|
|
|
|
## Étude
|
|
|
|
L'étude se trouve dans un autre document.
|
|
|
|
## Composants Wazuh
|
|
|
|
L'éco-système Wazuh peut être découpé en 4 éléments :
|
|
- l'indexer Wazuh qui tourne coté serveur
|
|
- le manager Wazuh qui tourne coté serveur
|
|
- le dashboard Wazuh qui tourne coté serveur
|
|
- l'agent Wazuh qui tourne sur la machine à surveiller
|
|
|
|
## Wazuh server
|
|
|
|
NUO mets à disposition 1 serveur Wazuh de préprod pour des tests : `wazuh-pp.in.nuonet.fr`. Cadoles a la main complète sur le serveur. Cadoles a installé un serveur wazuh complet (indexer+server+dashboard) avec docker sur ce serveur.
|
|
|
|
NUO mets à disposition un service Wazuh de production découpé en 3 serveurs :
|
|
- xdr-dashboard.in.nuonet.fr pour la partie graphique, accessible en https
|
|
- xdr-server.in.nuonet.fr pour la communication avec les agents entre autre
|
|
- xdr-indexer.in.nuonet.fr pour l'inexdation (aucune interaction)
|
|
|
|
### Wazuh server PP
|
|
|
|
Pour faire des tests, le serveur de PP a été configuré. Tout est dans le dossier ~cadoles/wazuh-docker/single-node ou dans le conteneur docker directement, `/var/ossec/etc/ossec.conf`. La documentation suivie est ici : https://documentation.wazuh.com/current/deployment-options/docker/wazuh-container.html
|
|
|
|
Une fois up, il est possible d'entrer dans le conteneur `single-node-wazuh.manager-1` pour modifier des config, voir ce que le serveur reçoit de la part des agents (dans `/var/ossec/logs/archives/archives.json`) si les options
|
|
```
|
|
<ossec_config>
|
|
<global>
|
|
<logall>yes</logall>
|
|
<logall_json>yes</logall_json>
|
|
</global>
|
|
</ossec_config>
|
|
```
|
|
ont bien été ajoutées au fichier de configuration `/var/ossec/etc/ossec.conf`.
|
|
|
|
`/var/ossec/bin/wazuh-logtest` permet entre autre de tester les `decoders` et les `rules`.
|
|
|
|
## Wazuh agent
|
|
|
|
Sur les 2 clusters k8s (prod et PP) ont été déployé 1 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/).
|
|
|
|
OpenNix est une organization russe. Il a été décidé de réimplémenter une solution pour intégrer l'agent Wazuh dans kubernetes. Cela se présente sous la forme de projets maintenus par Cadoles :
|
|
- https://forge.cadoles.com/Cadoles/wazuh-agent-k8s-autoadd : programme go pour enregistrer (via API) puis démarrer un agent Wazuh + Dockerfile
|
|
- https://forge.cadoles.com/CadolesKube/wazuh-agent-kustom : kustomization d'un DaemonSet pour déployer un agent Wazuh et wazuh-agent-k8s-autoadd sur chaque noeud d'un cluster k8s, d'une ConfigMap et d'un Secret
|
|
|
|
|
|
### Configuration
|
|
|
|
Au 26 mai 2025, le fichier de configuration de l'agent, `/var/ossec/etc/ossec.conf` est la suivante :
|
|
```
|
|
<ossec_config>
|
|
<client>
|
|
<server>
|
|
<address>{{ getenv "WAZUH_MANAGER_HOST" }}</address>
|
|
<port>{{ getenv "WAZUH_MANAGER_PORT" "1514" }}</port>
|
|
</server>
|
|
</client>
|
|
|
|
<localfile>
|
|
<location>/var/log/pods/*/*/*.log</location>
|
|
<log_format>syslog</log_format>
|
|
</localfile>
|
|
</ossec_config>
|
|
```
|
|
|
|
Les parties variables sont remplacées grâce à [gomplate](https://docs.gomplate.ca/).
|
|
|
|
### Mise en place
|
|
|
|
Dans les projet k8s-deploy et k8s-pp-deploy
|
|
```
|
|
kustomize build --load-restrictor LoadRestrictionsNone kustomize/trust-manager/ --enable-helm
|
|
kustomize build --load-restrictor LoadRestrictionsNone kustomize/wazuh-agent
|
|
```
|
|
|
|
### Ajout d'un agent
|
|
|
|
Une fois l'agent déployé, il faut demander à NUO (Nomena) d'ajouter le serveur dans le bon groupe sur NUO afin de le voir.
|
|
|
|
### Mise à jour de la config
|
|
|
|
Pour mettre à jour la configuration de l'agent Wazuh (ossec.conf), :
|
|
|
|
### Mise à jour de l'agent Wazuh
|
|
|
|
Il est en théorie possible d'upgrade l'agent Wazuh depuis le serveur Wazuh. Cependant, dans le cadre de kubernetes, Cadoles ne recommande pas l'upgrade d'agent Wazuh depuis le serveur Wazuh car même si la mise-à-jour fonctionne (peu probable à cause de l'environnement conteneurisé), si le pod redémarre, il retournera à la version précédente. Il vaut mieux mettre à jour le Dockerfile du projet https://forge.cadoles.com/CadolesKube/wazuh-agent-kustom puis déployer sur les 2 clusters k8s. Attention à la compatibilité entre l'agent et le serveur Wazuh. L'agent ne doit jamais être plus récent que le serveur.
|
|
|
|
### Changement de CA
|
|
|
|
La CA utilisée pour signer le certificat du serveur Wazuh de NUO est dans le fichier `kustomize/trust-manager/resources/wazuh-manager-ca.yaml` dans les dépôts git k8s-deploy et k8s-pp-deploy. Pour changer de CA, il suffit d'éditer le fichier puis de déployer le changement avec kubectl apply. Ne pas oublier de pousser ces changements sur les dépôts git.
|
|
|
|
Demander :
|
|
- version du wazuh manager (la version de l'agent doit être inférieure ou égale) -> v4.11.2 v4.12 cet am
|
|
- certificats ? -> autosigné (pas sûr)
|
|
- nom/addresse du manager wazuh et API server -> xdr-dashboard.in.nuonet.fr xdr-server.in.nuonet.fr xdr-indexer.in.nuonet.fr
|
|
- ouverture du port de l'API depuis les machines du cluster (55000) -> Noména va le faire
|
|
- OK pour auto-enregistrement via l'API ? -> OK, on ne voit pas de soucis
|
|
- Création de compte pour nous sur le dashboard -> Noména va le faire
|
|
- Création de compte de service pour l'enregistrement des clients wazuh -> Noména va le faire
|
|
- Dans quel groupe mettre les agents -> Noména va y réfléchir (par salle et par environnement prod/pp)
|
|
- Est-ce qu'ils voient les logs pour d'autre apps ? Ont-ils activé l'archivage des logs ? Ils auront une presta pour voir l'intégration d'applicatifs. Pas exploitable rapidement.
|
|
- Quelle config ossec.conf ? Veulent-ils quelque chose en particulier ? Peut-être wodle docker-listener mais nécessite de redémarrer docker. Noména va y réfléchir.
|