Contrôle d'intégrité des fichiers (FIM) avec Wazuh

Le contrôle d'intégrité des fichiers, ou FIM (File Integrity Monitoring), consiste à calculer l'empreinte et les attributs de fichiers choisis, puis à alerter dès qu'un fichier est ajouté, modifié ou supprimé. Dans Wazuh, c'est le module syscheck de l'agent qui s'en charge, sur les fichiers de Linux et de Windows et sur les clés du registre Windows. Ce chapitre explique ce qu'il compare, sa configuration par défaut, la surveillance en temps réel avec l'auteur de la modification, la lecture d'une alerte FIM et la détection d'un rançongiciel par les modifications en masse.

Ce que compare le contrôle d'intégrité

À chaque analyse, l'agent relève pour chaque fichier surveillé :

• ses empreintes (MD5, SHA-1 et SHA-256) : la moindre modification du contenu change l'empreinte ;
• sa taille, sa date de modification, son numéro d'inode sous Linux ;
• son propriétaire, son groupe et ses permissions (droits Unix, ou liste de contrôle d'accès sous Windows).

Il compare avec l'état enregistré lors de l'analyse précédente, garde le nouvel état dans sa base locale et envoie au serveur un événement pour chaque différence : ajout, modification ou suppression. Le serveur en fait une alerte.

Les empreintes servent ici de preuve d'intégrité, comme dans le cours Cryptographie : on ne peut pas modifier un fichier en gardant la même empreinte SHA-256. Un attaquant qui remplace un programme système, ajoute une ligne au fichier sudoers ou modifie une page du site web est donc vu, même s'il a soigneusement remis la date de modification d'origine.

La configuration par défaut

L'agent surveille déjà, sans rien régler, les emplacements que les attaquants modifient le plus souvent :

Quelques fichiers ne sont jamais montrés en détail : pour /etc/shadow et les clés privées TLS, Wazuh signale le changement sans jamais en afficher le contenu (option nodiff).

Une analyse toutes les 12 heures, c'est utile pour un contrôle de fond, mais trop lent pour les fichiers qui comptent : un site web défiguré à 9 h serait signalé le soir. Pour ceux-là, on passe en temps réel.

Surveiller un dossier en temps réel, et savoir qui l'a modifié

Trois attributs de la balise <directories> changent tout :

Sur srv-web, le contenu du site et la configuration de SSH et de sudo. Dans l'agent.conf du groupe serveurs-web :

<agent_config>
  <syscheck>
    <directories realtime="yes" report_changes="yes">/var/www/html</directories>
    <directories realtime="yes" report_changes="yes">/etc/ssh,/etc/sudoers.d</directories>
    <ignore type="sregex">\.log$|/cache/</ignore>
  </syscheck>
</agent_config>

Sur srv-fichiers, les partages sensibles, avec l'auteur des modifications. Une section <agent_config> peut viser une seule machine par son nom (l'attribut name est une expression régulière : ancre-la avec ^ et $ pour ne pas viser aussi srv-fichiers2), dans l'agent.conf du groupe windows-serveurs :

<agent_config name="^srv-fichiers$">
  <syscheck>
    <directories whodata="yes">D:\Partages\Direction</directories>
    <directories whodata="yes">D:\Partages\Paie</directories>
  </syscheck>
</agent_config>

Sur les contrôleurs de domaine, le dossier SYSVOL, où vivent les scripts et les GPO : un script de connexion modifié par un attaquant s'exécute sur toutes les machines du domaine.

<agent_config name="^srv-ad$|^srv-ad2$">
  <syscheck>
    <directories whodata="yes">C:\Windows\SYSVOL\domain\scripts</directories>
    <directories realtime="yes">C:\Windows\SYSVOL\domain\Policies</directories>
  </syscheck>
</agent_config>

Lire une alerte FIM

L'alerte porte, sous syscheck, les informations utiles : le chemin (syscheck.path), le type d'événement (syscheck.event : added, modified, deleted), les empreintes avant et après (syscheck.sha256_before, syscheck.sha256_after), la taille, le propriétaire, le mode de détection (syscheck.mode : scheduled, realtime ou whodata) et, avec report_changes, la différence (syscheck.diff). Avec whodata, elle ajoute l'auteur : syscheck.audit.user.name et le processus, syscheck.audit.process.name.

Par exemple, une alerte 550 sur srv-fichiers :

Le tableau de bord présente ces événements dans Endpoint security > File Integrity Monitoring, avec un inventaire des fichiers surveillés par agent et l'historique de leurs modifications.

Lire, c'est décider. Une modification n'est pas une attaque : la comptable modifie un fichier de virements, c'est son travail. La question est toujours : cette modification était-elle attendue ?

• Une mise à jour du site a été planifiée ce matin : les modifications de /var/www/html à 9 h sont normales. À 3 h, sans intervention prévue, elles ne le sont pas.
• jlefevre, comptable, modifie un fichier de la paie un mardi à 10 h : normal. Le même compte modifie 400 fichiers de la direction en deux minutes : anormal.
• Le fichier hosts d'un serveur change : presque jamais normal. C'est une technique pour détourner un nom (le serveur de mises à jour, l'annuaire) vers une adresse contrôlée par l'attaquant.

Repérer un rançongiciel par les modifications en masse

Un rançongiciel chiffre les fichiers les uns après les autres, aussi vite qu'il peut : chaque fichier chiffré est un fichier modifié (ou supprimé puis recréé avec une nouvelle extension). Sur un partage surveillé en temps réel, cela produit une avalanche d'alertes 550, 553 et 554 en quelques secondes, sur une même machine. Une règle de fréquence transforme cette avalanche en une alerte grave :

<group name="sorbier,syscheck,">
  <rule id="100200" level="12" frequency="50" timeframe="60">
    <if_matched_group>syscheck_entry_modified</if_matched_group>
    <same_location />
    <description>Sorbier : modifications de fichiers en masse sur une même machine (rançongiciel ?)</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>
</group>

Les alertes de modification de fichiers appartiennent au groupe syscheck_entry_modified ; if_matched_group compte les événements de ce groupe et <same_location /> impose qu'ils viennent du même endroit, donc du même agent. Cinquante modifications en une minute sur la même machine déclenchent une alerte de niveau 12, rattachée à la technique T1486 Data Encrypted for Impact. Le seuil se règle sur ton activité normale : regarde combien de modifications un partage reçoit, au plus fort, en une minute de travail ordinaire, et place le seuil nettement au-dessus.

La détection de rootkits

Le module rootcheck, actif par défaut, complète le FIM : il cherche des fichiers et des signatures de rootkits connus, des processus et des ports cachés (visibles pour le noyau mais pas pour les commandes du système), des permissions anormales. Ses trouvailles donnent la règle 510 « Host-based anomaly detection event (rootcheck) », de niveau 7. Il produit parfois des faux positifs sur des systèmes récents ; chaque alerte se vérifie à la main avant de conclure.

Exercices

<agent_config>
  <syscheck>
    <directories realtime="yes" report_changes="yes">/srv/suivi/app</directories>
    <ignore>/srv/suivi/app/cache</ignore>
    <nodiff>/srv/suivi/app/config.php</nodiff>
  </syscheck>
</agent_config>