Wazuh et YARA : détection et quarantaine
Relier la surveillance d’intégrité de Wazuh à YARA et à Active Response pour analyser automatiquement un fichier détecté, isoler les correspondances malveillantes et rendre la décision visible dans le dashboard.
Contexte et objectif
Wazuh FIM constate qu’un fichier a été créé ou modifié, mais il ne qualifie pas son contenu. YARA apporte cette qualification. Active Response permet ensuite d’exécuter une action uniquement lorsqu’une règle correspond.
Le projet assemble ces briques pour obtenir une chaîne complète : détection, analyse, décision, quarantaine et remontée de deux alertes distinctes dans Wazuh. La configuration est déployée avec Ansible pour rester reproductible.
Architecture
Un fichier créé ou modifié dans un répertoire surveillé déclenche une règle FIM 550 ou 554. Active Response lance alors yara.sh sur l’agent concerné. Le script récupère le chemin dans le JSON reçu sur l’entrée standard, exécute YARA avec le ruleset YARA Forge Core et ne met le fichier en quarantaine que si le scan réussit et produit un match. Le fichier est déplacé dans /var/quarantine et ses droits sont retirés. Les logs personnalisés sont ensuite décodés et transformés en règles 100300 et 100301 pour le dashboard.
- Wazuh Manager SRV-LOG-01 et agent Wazuh 4.14.x sur le client pilote.
- Wazuh FIM en temps réel sur le répertoire surveillé, avec exclusions pour éviter le bruit.
- YARA 4.2.3 et YARA Forge Core installés dans /opt/yara.
- yara.sh : contrôle du code retour, séparation de stderr et de la sortie de match, déplacement vers /var/quarantine, chmod 000.
- Decoders et règles locales : 100300 pour la détection, 100301 pour la quarantaine confirmée.
- Ansible : installation, répertoires, déploiement du script, configuration et health check.
Technologies
Réalisation technique
- Installer YARA, jq et unzip avec un rôle Ansible, puis créer /opt/yara et /var/quarantine avec des droits restrictifs.
- Déployer YARA Forge Core et vérifier le ruleset sur un fichier sain avant de tester un échantillon.
- Configurer Wazuh FIM en temps réel sur le répertoire cible et vérifier dans ossec.log que la surveillance est réellement démarrée.
- Écrire yara.sh en distinguant un match, une erreur de scan et un fichier absent, puis déployer le script avec les bons droits.
- Déclarer la commande et l’Active Response sur le manager Wazuh.
- Tester YARA seul, puis créer un fichier EICAR pour déclencher la chaîne complète.
- Créer le decoder yara_scan et la règle 100300, puis le decoder yara_quarantine et la règle 100301.
- Valider les deux lignes avec wazuh-logtest et contrôler la séquence dans Threat Hunting.
- Ajouter un health check qui interroge wazuh-control status, car systemctl seul ne prouve pas que les démons internes tournent.
Difficultés rencontrées
| Symptôme | Cause | Correction |
|---|---|---|
| YARA test-rule.yar : syntax error | Le caractère $ avait été écrit littéralement avec un antislash. | Créer une vraie règle multi-ligne avec $a = "..." puis utiliser condition: $a. |
| Aucun événement FIM | wazuh-syscheckd n’avait pas chargé ou démarré correctement la surveillance. | Contrôler ossec.log et rechercher la ligne Real-time file integrity monitoring started. |
| error scanning ... could not open file | Des fichiers temporaires Ansible ou APT disparaissaient avant le passage de YARA. | Ignorer les chemins temporaires bruyants et vérifier l’existence du fichier avant le scan. |
| Erreur YARA interprétée comme malware | stderr était fusionné avec la sortie de match. | Rediriger stderr séparément et vérifier YARA_RC avant de considérer YARA_OUTPUT. |
| Active Response sans résultat dans le dashboard | Les logs personnalisés n’avaient ni decoder ni règle. | Créer local_decoder.xml et local_rules.xml, puis tester avec wazuh-logtest. |
| Description « YARA file quarantined: » vide | Le decoder matchait mais n’extrayait pas quarantine_path. | Utiliser la regex PCRE2 Quarantaine:\s+(.+)$ avec |
| Script modifié mais comportement inchangé | Le fichier du rôle Ansible avait été édité mais pas redéployé. | Relancer baseline.yml avec --limit et vérifier YARA_RC dans le script distant. |
| systemctl actif mais FIM et execd morts | Le service parent ne suffisait pas à prouver l’état des composants internes. | Utiliser /var/ossec/bin/wazuh-control status et un failed_when Ansible sur les cinq démons. |
Résultats
- Le test EICAR a produit la détection TRELLIX_ARC_Malw_Eicar et le fichier a été déplacé dans /var/quarantine avec chmod 000.
- Le dashboard Threat Hunting affiche la séquence complète : règle 554, détection 100300, suppression de l’emplacement original, quarantaine 100301.
- Le decoder et les règles personnalisées ont été validés avec wazuh-logtest avant le redémarrage du manager.
- Le second passage du playbook s’est terminé avec ok=18, changed=0, unreachable=0 et failed=0, ce qui démontre l’idempotence de la configuration.
- Le health check vérifie les cinq composants Wazuh et ne se contente plus de l’état du service parent.
Limites et points de vigilance
- Une règle YARA peut produire un faux positif : la quarantaine est plus prudente qu’une suppression automatique.
- chmod 000 n’est pas une barrière contre root ; c’est un confinement par permissions Unix.
- Le répertoire /var/quarantine doit rester exclu de FIM pour éviter les boucles.
- Le ruleset YARA doit être mis à jour de façon contrôlée et testé avant généralisation.
- La surveillance temps réel de nombreux chemins peut créer du bruit et consommer des ressources ; le pilote doit être validé avant un déploiement massif.
Documentation complète
Documentation source : Wazuh + YARA Active Response, août 2026, 18 pages. Le PDF contient les commandes, les fichiers de configuration et les captures du montage.