Aller au contenu

Wazuh - FIM

Dans le cadre de la sécurité d'un SI, le FIM est une étape importante.

Son objectif est de vérifier en continu l'intégrité d'un système de fichiers, d'un fichier ou d'un répertoire. Une alerte est remontée pour toute modification, suppression ou ajout sur le système de fichiers.

Il est possible de surveiller tout élèment d'un système de fichiers, cependant certaines données telles que des logs ou des caches ne sont pas à surveiller puisque par défaut, les données sont changeantes en continue. Pour ces cas spécifiques, l'approche doit être différente.

Activation du FIM sur le endpoint

Pour activer le FIM sur le répertoire /root, la modification se fait sur l'agent wazuh installé sur le endpoint :

sed -i '/<syscheck>/a \    <directories check_all="yes" report_changes="yes" realtime="yes">/root</directories>' /var/ossec/etc/ossec.conf ; systemctl restart wazuh-agent
  • realtime="yes" : permet de surveiller en continu le répertoire ou fichier indiqué. Cependant, il est possible de programmer le scan avec "frequency" :
<syscheck>
   <frequency>300</frequency>
</syscheck>
  • report_changes="yes" : permet d'injecter dans le log le contenu du fichier modifié (avant/après).

Puis pour vérifier que le FIM démarre correctement, les logs l'indiquent dans /var/ossec/logs/ossec.log :

2024/01/02 16:56:48 wazuh-syscheckd: INFO: (6009): File integrity monitoring scan ended.
2024/01/02 16:56:48 wazuh-syscheckd: INFO: FIM sync module started.
2024/01/02 16:56:48 wazuh-syscheckd: INFO: (6012): Real-time file integrity monitoring started.

Vérifier que le FIM remonte les alertes

Ajout d'un fichier

Pour vérifier l'activation, il suffit de créer un fichier sous root :

touch /root/test_file

Sur le dashboard, l'alerte remonte correctement : type:video

Modification d'un fichier

Modifiez le fichier /root/test_file, wazuh détecte une modification de la somme md5, il remonte alors l'alerte avec comme information dans le champ "full_log" : File '/root/test_file' modified. type:video

Suppresion d'un fichier

Supprimez le fichier /root/test_file, l'agent remonte une alerte de suppression : File '/root/test_file' deleted. type:video

Détails de l'alerte

Beaucoup d'informations sont remontées sur ces alertes, elles sont pertinentes selon le résultat attendu et l'environnement. Voici quelques informations qui nous semblent pertinentes :

Informations générales :

  • _index : index sur lequel se trouve l'alerte,
  • agent.ip : l'ip de l'agent wazuh,
  • rule.description / full_lo : détails de l'évènement,
  • syscheck.path : chemin complet du fichier modifié,
  • syscheck.mtime_after : timestamp au moment de la modification du fichier,
  • syscheck.event : type de modification.

Sur la conformité aux exigences réglementaires :

  • rule.gdpr : l'évènement est associé à une règle ou plusieurs règles GRPD - plus d'informations sur ce livre blanc,
  • rule.gpg13 : l'évènement est associé à une ou plusieurs règles du "Good Patrice Guide 13" (ensemble de directives de sécurité développées par le gouvernement britannique pour aider les organisations à protéger leurs systèmes d'information),
  • rule.hipaa : l'évènement est associé à une ou plusieurs règles HIPAA (les sociétés qui gèrent des données de santé doivent être certifiées HIPAA),
  • rule.nist_800_53 : l'évènement est associé à une ou plusieurs règles NIST,
  • rule.pci_dss : l'évènement est associé à une ou plusieurs règles PCI DSS (les sociétés qui gèrent des cartes de crédit doivent être certifiées PCI DSS),
  • rule.tsc : l'évènement est associé à une règle ou plusieurs règles du TSC (Trust Services Criteria - Le TSC est un cadre développé par l'American Institute of Certified Public Accountants (AICPA) pour évaluer la fiabilité des services de systèmes et d'organisation, notamment en termes de sécurité, disponibilité, intégrité du traitement, confidentialité, et protection des données personnelles),
  • rule.mitre : l'évènement est associé à une règle ou plusieurs règles du framework MITRE (un modèle et une base de connaissances globale utilisés pour décrire et classer les comportements des cyber-attaquants et les tactiques, techniques, et procédures (TTP) qu'ils emploient lors de cyberattaques).

Sur les droits :

  • syscheck.perm_after : (nouvelles) permissions accordées sur le fichier,
  • syscheck.uid_after : (nouvel) ID de l'utilisateur propriétaire du fichier (ici 0 pour root),
  • syscheck.gid_after : (nouvel) ID du groupe propriétaire du fichier (ici 0 pour root).

Qui a effectué une modification ?

Par défaut, l'auteur (utilisateur) à l'origine d'un évènement n'est pas indiqué. Dans le cadre de la sécurité d'un SI, on doit pouvoir identifier l'utilisateur.

Pour remonter ce type d'informations, wazuh se base sur les logs auditd :

apt install auditd

Puis il faut ajouter whodata dans la configuration du répertoire à surveiller :

sed -i '/<syscheck>/a \    <directories check_all="yes" report_changes="yes" whodata="yes" realtime="yes">/root</directories>' /var/ossec/etc/ossec.conf ; systemctl restart wazuh-agent

On vérifie que la règle auditd "wazuh_fim" a bien été ajoutée par wazuh:

$ auditctl -l | grep wazuh_fim
-w /root -p wa -k wazuh_fim

Vous pouvez ajouter ou modifier un fichier sous /root avec n'importe quel utilisateur.

On voit ici plus de détails avec l'activation du whodata :

wazuh_alert_fim_users

Modifications vers des droits inhabituels

On autorise à tout le monde en 777 un fichier :

cd /root ; touch test ; chmod 777 test

# logs :
File '/root/test' modified
Mode: whodata
Changed attributes: permission
Permissions changed from 'rw-r--r--' to 'rwxrwxrwx'

Pour aller plus loin...