LINUX:Wazuh-SCA

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche

→ retour au menu pour les actions préventives

But

Ce module a pour but d'analyser la configuration du système et de divers services au terme duquel un rapport est généré. Il se base sur des fichiers de contrôles en se basant sur diverses règles. On peut en créer soi-même mais quelques uns sont fournis pour divers systèmes ou logiciels phares. Il joue un rôle semblable au logiciel "Lynis" vu dans un autre article.


Configuration

Sur la machine où le service "wazuh-manager" s'exécute, cette configuration est placée dans le fichier "/var/ossec/etc/ossec.conf".

Sur les machines hébergeant l'agent distant, la configuration peut être contenue dans le fichier du même nom mais il est plus pratique de transmettre cette configuration via le système de partage vu précédemment. Dans le cas du partage par défaut, sur la machine Manager, ce fichier se nomme "/var/ossec/etc/shared/default/agent.conf" et sur l'agent distant, il se trouve sous le nom "/var/ossec/etc/default/agent.conf".

De plus dans le cas de partage de configuration "SCA", il est requit d'ajouter sur l'agent distant une option qui permet d'activer ce module. Celle-ci est à mettre dans le fichier '"/var/ossec/etc/local_internal_options.conf" comme conseillé précédemment. 

sca.remote_commands=1


La configuration est comprise entre les balises <sca> et </sca>.

Voici une configuration de base: 

 <sca>
   <enabled>yes</enabled>
   <scan_on_start>no</scan_on_start>
   <interval>12h</interval>
   <skip_nfs>yes</skip_nfs>
 </sca>

Explication des options:

  • enabled: active le module
  • scan_on_start: lance le traitement dès le lancement du service
  • interval: définit l'intervalle entre le lancement de deux traitements; ici 12h
  • skip_nfs: le traitement évite les partitions NFS


Policies

L'ensemble des règles de contrôles des configurations sur système globalement sont reprises sous format YAML dans des fichiers ayant l'extension "yml".


Un ensemble de fichiers de ces règles toutes faites se retrouvent dans le répertoire "/var/ossec/ruleset/sca". Chaque fichier reprend les règles pour un thème donné. Par exemple le fichier "cis_apache_24.yml" est dédié au service WEB Apache de version 2.4 et le fichier "cis_rhel8_linux.yml" est dédié au système Linux de la distribution RedHat Entreprise version 8. Par défaut, tous les fichiers de ce répertoire ayant l'extension "yml" seront traités. Sous Fedora, tous les fichiers sont désactivés car ils portent l'extension "yml.disabled" sauf un, le fichier "cis_rhel8_linux.yml".


Malheureusement à chaque mise à jour, le contenu de ce répertoire est réinitialisé. Or il faudra d'une part renommer les fichiers désirés, adapter un peu leur contenu et d'autre part ils devront être transférés vers les agents distants.

Pour pallier à ces limitations, nous avons opté pour l'utilisation du système de partage. Nous allons mettre les fichiers retenus dans le répertoire "/var/ossec/etc/shared/default" sur la machine manager après les avoir renommés avec l'extension "yml". Ces fichiers seront transférés automatiquement dans le répertoire "/var/ossec/etc/default". Mais il faut ensuite signaler au module "SCA" où les trouver.

Nous avons retenu les fichiers:

  • cis_apache_24.yml
  • cis_mysql5-6_community.yml
  • cis_rhel8_linux.yml
  • cis_rhel9_linux.yml
  • sca_unix_audit.yml
  • web_vulnerabilities.yml

Les noms des fichiers sont assez explicites pour devoir les expliquer.

Sur la machine manager, la configuration est amendée comme suit: 

 <sca>
   <enabled>yes</enabled>
   <scan_on_start>no</scan_on_start>
   <interval>12h</interval>
   <skip_nfs>yes</skip_nfs>
   <policies>
    <policy>etc/shared/default/cis_apache_24.yml</policy>
    <policy>etc/shared/default/cis_mysql5-6_community.yml</policy>
    <policy>etc/shared/default/cis_rhel8_linux.yml</policy>
    <policy>etc/shared/default/cis_rhel9_linux.yml</policy>
    <policy>etc/shared/default/sca_unix_audit.yml</policy>
    <policy>etc/shared/default/web_vulnerabilities.yml</policy>
    <policy enabled="no">ruleset/sca/cis_rhel8_linux.yml</policy>
   </policies>
 </sca>

On remarque que le fichier "/var/ossec/ruleset/sca/cis_rhel8_linux.yml" est désactivé car son homologue "/var/ossec/etc/shared/default/cis_rhel8_linux.yml" devra être adapté pour être opérationnel et que le n° des règles seront en double et par ce fait, elles entreront en conflit entre elles.

Remarquons que le chemin de ces fichiers est relatif; en effet le chemin de base pour Wazuh est "/var/ossec".


Dans le fichier de partage pour les agents "/var/ossec/etc/shared/default/agent.conf" sur la machine manager, la configuration devient: 

 <sca>
   <enabled>yes</enabled>
   <scan_on_start>no</scan_on_start>
   <interval>12h</interval>
   <skip_nfs>yes</skip_nfs>
   <policies>
    <policy>etc/shared/cis_apache_24.yml</policy>
    <policy>etc/shared/cis_mysql5-6_community.yml</policy>
    <policy>etc/shared/cis_rhel8_linux.yml</policy>
    <policy>etc/shared/cis_rhel9_linux.yml</policy>
    <policy>etc/shared/sca_unix_audit.yml</policy>
    <policy>etc/shared/web_vulnerabilities.yml</policy>
    <policy enabled="no">ruleset/sca/cis_rhel8_linux.yml</policy>
   </policies>
  </sca>

Dans ce cas le chemin sera celui de la machine de l'agent distant "/var/ossec/etc/shared".

Dans notre cas, du côté des agents, ce sont toutes des machines Linux. Il est évident que si nous sommes en présence aussi de machines Windows, il faut ajouter un profil autre que le défaut adapté à Windows et lier les agents de ces machines à ce profil.


Adaptation des policies

Les principales modifications à effectuer concerne le nom des fichiers de configuration à analyser. La syntaxe YAML est facilement compréhensible. Les modifications sont faciles.


Quelques exemples:

  • Le fichier "cis_mysql5-6_community.yml" est adapté à MySql or nous utilisons MariaDB. Les fichiers de configuration sont similaires mais leurs noms et le répertoire sont différents.
  • Nous avons ajouté un second service SSH spécial pour les sauvegardes avec un fichier de configuration spécifique; ce second fichier doit être ajouté.
  • Les fichiers de configurations du service WEB Apache, on été découpés et organisés dans des répertoires par nom de domaine et protocoles pour une question de lisibilité. Le dossier contenant les sources des sites WEB a été déplacé pour une question de place et n'est plus dans le répertoire "/var/www".


Enfin les fichiers de règles concernant un OS et une distribution spécifique contiennent des vérifications sur ces deux informations. Nous utilisons la distribution de Linux Fedora (versions 36 et 37) appartenant à l'ensemble des distributions sous l'égide de RedHat. Or les fichiers "cis_rhel8_linux.yml" et "cis_rhel9_linux.yml" n'acceptent pas Fedora. Nous allons donc ajouter deux règles.

Sous la section "requirements" et la sous-section "rules" du fichier "cis_rhel8_linux.yml", nous avons quelques règles qui nous serviront de base.

Voici le contenu de cette section: 

requirements:
 title: "Check RHEL8 family platform"
 description: "Requirements for running the policy against RHEL 8 family."
 condition: any
 rules:
   - 'f:/etc/redhat-release -> r:^Red Hat Enterprise Linux && r:release 8'
   - 'f:/etc/redhat-release -> r:^Cloud && r:release 8'
   - 'f:/etc/redhat-release -> r:^Oracle && r:release 8'
   - 'f:/etc/redhat-release -> r:^Better && r:release 8'
   - 'f:/etc/redhat-release -> r:^OpenVZ && r:release 8'

Nous ajoutons vers la ligne 31, les deux lignes suivantes précédées d'une ligne de commentaire pour repérer facilement les modifications apportées: 

# ADB
   - 'f:/etc/redhat-release -> r:^Fedora && r:release 36'
   - 'f:/etc/redhat-release -> r:^Fedora && r:release 37'

Ces règles analysent le fichier ("f") "/etc/redhat-release".

Par exemple, le contenu de ce fichier sous Fedora 37 est: 

Fedora release 37 (Thirty Seven)

Ce fichier doit commencer par le mot "Fedora" relatif à la distribution et doit contenir "release 36" ou "release 37" pour les versions actuellement présentes. Les autres règles peuvent être mises en commentaire.


Vérification

Pour une exécution rapide pour test, modifiez dans le fichier de configuration la ligne "<scan_on_start>yes</scan_on_start>" et redémarrons le service.

En premier lieu, suivez l'exécution du module "SCA" dans le fichier journal "/var/ossec/logs/ossec.log". Repérez toute erreur et y remédier. Voici un extrait du journal: 

2022/11/21 16:35:39 sca: INFO: Module started.
2022/11/21 16:35:39 sca: INFO: Policy '/var/ossec/ruleset/sca/cis_rhel8_linux.yml' disabled by configuration.
2022/11/21 16:35:39 sca: INFO: Loaded policy '/var/ossec/etc/shared/cis_apache_24.yml'
2022/11/21 16:35:39 sca: INFO: Loaded policy '/var/ossec/etc/shared/sca_unix_audit.yml'
2022/11/21 16:35:39 sca: INFO: Loaded policy '/var/ossec/etc/shared/cis_rhel8_linux.yml'
2022/11/21 16:35:39 sca: INFO: Loaded policy '/var/ossec/etc/shared/cis_rhel9_linux.yml'
2022/11/21 16:35:39 sca: INFO: Loaded policy '/var/ossec/etc/shared/cis_mysql5-6_community.yml'
2022/11/21 16:35:39 sca: INFO: Loaded policy '/var/ossec/etc/shared/web_vulnerabilities.yml'
2022/11/22 04:35:39 sca: INFO: Starting Security Configuration Assessment scan.
2022/11/22 04:35:39 sca: INFO: Starting evaluation of policy: '/var/ossec/etc/shared/cis_apache_24.yml'
2022/11/22 04:35:43 sca: INFO: Evaluation finished for policy '/var/ossec/etc/shared/cis_apache_24.yml'
2022/11/22 04:35:43 sca: INFO: Starting evaluation of policy: '/var/ossec/etc/shared/sca_unix_audit.yml'
2022/11/22 04:35:46 sca: INFO: Evaluation finished for policy '/var/ossec/etc/shared/sca_unix_audit.yml'
2022/11/22 04:35:46 sca: INFO: Starting evaluation of policy: '/var/ossec/etc/shared/cis_rhel8_linux.yml'
2022/11/22 04:38:26 sca: INFO: Evaluation finished for policy '/var/ossec/etc/shared/cis_rhel8_linux.yml'
2022/11/22 04:38:27 sca: INFO: Starting evaluation of policy: '/var/ossec/etc/shared/cis_rhel9_linux.yml'
2022/11/22 04:39:53 sca: INFO: Evaluation finished for policy '/var/ossec/etc/shared/cis_rhel9_linux.yml'
2022/11/22 04:40:02 sca: INFO: Starting evaluation of policy: '/var/ossec/etc/shared/cis_mysql5-6_community.yml'
2022/11/22 04:40:05 sca: INFO: Evaluation finished for policy '/var/ossec/etc/shared/cis_mysql5-6_community.yml'
2022/11/22 04:40:05 sca: INFO: Starting evaluation of policy: '/var/ossec/etc/shared/web_vulnerabilities.yml'
2022/11/22 04:40:30 sca: INFO: Evaluation finished for policy '/var/ossec/etc/shared/web_vulnerabilities.yml'
2022/11/22 04:40:30 sca: INFO: Security Configuration Assessment scan finished. Duration: 291 seconds.


Résultats

Ensuite si vous avez activé la réception de mails, vous devrez recevoir un rapport succinct par analyse au format JSON. Ces rapports sont aussi centralisés sur la machine manager dans les journaux d'alertes. Le fichier courant est "/var/ossec/logs/alerts/alerts.json". Ceci pour autant que les niveaux d'alerte soient supérieurs ou égaux à ceux définis dans le fichier de configuration entre les balises <alerts> et </alerts> comme vu précédemment.


Si vous avez installé le module WUI de Wazuh que nous verrons dans un autre article, vous pouvez y voir le détail. Il faut choisir un agent. Dans le menu en haut à gauche, on clique sur "WAZUH" et en dessous sur "Agents". On clique ensuite sur l'agent désiré dans la liste qui apparaît. Enfin dans l'écran qui s'ouvre, on clique sur "SCA" dans le menu du haut pour avoir une vue d'ensemble des résultats. Le résultat détaillé de chaque analyse est disponible en cliquant sur l'analyse souhaitée.


Malheureusement cet interface WEB ne reprend que les agents distants et non l'agent local de la machine manager.

Il est possible d'avoir ces détails pour l'agent local de la machine manager en effectuant une requête à l'API de WAZUH sur la machine manager; on obtient une sortie au format JSON. Nous verrons l'utilisation de l'API dans un autre article.

Voici un script qui récupère au format JSON le résultat de l'analyse de l'audit Unix (fichier "sca_unix_audit.yml"). Le nom de l'entrée se retrouve dans ce fichier sous la section "policy", c'est la valeur de la variable "id". Ici "unix_audit". 

#!/bin/bash
TOKEN=$(curl -u wazuh:wazuh -k -X GET "https://localhost:55000/security/user/authenticate?raw=true")
curl -k -X GET "https://localhost:55000/sca/000/checks/unix_audit" -H "Authorization: Bearer $TOKEN" | python -m json.tool
curl -k -X GET "https://localhost:55000/sca/001/checks/unix_audit?result=failed" -H "Authorization: Bearer $TOKEN" | python -m json.tool

Pour rappel, la seconde ligne sert à s'authentifier à l'API via le paramètre "-u" en donnant le couple nom d'utilisateur suivi du mot de passe séparés par un double point. A l'installation cet utilisateur est "wazuh" et son mot de passe est "wazuh"; il est crucial et évident de changer ce mot de passe pour une question de sécurité basique. Nous verrons dans un autre article comment changer ces mots de passe et comment adapter la configuration en conséquence. Grâce à cette requête, on récupère un jeton pour cette session dans la variable "TOKEN"; ce jeton est utilisé pour les requêtes qui suivent.

La requête suivante demande tous les résultats pour l'agent locale qui porte toujours le n° "000". La dernière ne sélectionne que les résultats qui ne sont pas passés ("result=failed") pour l'agent distant ayant le n° "001". Le résultat s'affiche sur une ligne; on le fait passer dans une fonction de "python" afin d'obtenir une version incrémentée, plus lisible.


Notons qu'il faut regarder ces résultats avec prudence. Fedora installe les versions des logiciels les plus récents et certains paramètres analysés sont obsolètes. SSH est dans ce cas. En outre certains logiciels sont des forks qui ont évolués plus rapidement et dont certains paramètres ont disparu. C'est le cas de MariaDB qui remplace MySQL.



→ retour au menu pour les actions préventives

Récupérée de « https://www.adbweb.gslb.eu/wiki/index.php?title=LINUX:Wazuh-SCA&oldid=2779 »