Détection d’Intrusion Active : Déployer Wazuh (XDR/SIEM) pour centraliser et analyser les logs de sécurité

Pourquoi la détection d’intrusion « active » est devenue indispensable (et pourquoi les logs seuls ne suffisent plus)

Il y a quelques années, « avoir des logs » c’était déjà pas mal. On centralisait un peu, on gardait ça quelque part, et quand il se passait un truc, on allait fouiller. Sauf que maintenant... tout s’est accéléré.

Plus d’endpoints. Des postes nomades, des VM qui apparaissent et disparaissent, des conteneurs, du SaaS, du cloud hybride, et une réalité simple : le télétravail a rendu le périmètre flou. Et en face, les attaques ne respectent pas votre rythme. Elles ne se calent pas sur « la revue mensuelle » ou « le point sécurité du vendredi ».

C’est là qu’il faut poser la différence, parce qu’on mélange souvent tout.

• La journalisation, c’est collecter. Stocker. Retenir.
• La détection d’intrusion active, c’est autre chose : corréler + alerter + enrichir + répondre.

Sans corrélation, vous avez un flux. Une rivière. Et le problème n’est pas juste « on ne voit rien ». Le problème, c’est le bruit.

Le coût du bruit, on le sous estime au début. Trop d’alertes, des faux positifs, pas de priorisation, donc... Fatigue. Puis on coupe des notifications. Puis on n’y croit plus. Et le jour où il se passe quelque chose, tout le monde découvre que le SIEM était devenu une jolie étagère à logs.

L’objectif de cet article est simple : déployer Wazuh pour centraliser, normaliser, corréler, puis déclencher des actions utiles à partir des logs. Pas juste « ça remonte ». Plutôt « ça remonte, et on sait quoi faire ensuite ».

À la fin, vous saurez :

• à quoi ressemble une architecture cible Wazuh, simple au départ mais scalable,
• comment faire une installation propre et sécurisée,
• comment faire l’onboarding des agents Windows et Linux,
• comment activer des règles et alertes qui ont du sens (pas 500 règles d’un coup),
• Comment construire des dashboards utiles,
• comment brancher des intégrations (Slack, ticketing, threat intel, IDS réseau),
• et surtout, les bonnes pratiques pour passer du POC à la production sans vous épuiser.

Wazuh en clair : XDR/SIEM open source (et ce qu’il fait réellement au quotidien)

Wazuh, concrètement, c’est une stack open source qui fait plusieurs choses à la fois, et c’est pour ça qu’on l’aime bien.

• Collecte et analyse de logs (agents, syslog, fichiers).
• Corrélation via règles, décoders, seuils, listes.
• FIM (file integrity monitoring) : surveiller les changements sur des fichiers ou répertoires critiques.
• Détection de vulnérabilités : inventaire et rapprochement CVE.
• Conformité : PCI DSS, CIS, GDPR, etc, via des contrôles et rapports.
• Réponses actives : déclencher des actions, prudemment, quand un signal est suffisamment fort.

Positionnement, sans marketing.

• Côté SIEM : il centralise et corrèle des événements.
• Côté XDR : il donne de la visibilité endpoint (et un début de réponse), multi plateforme, avec un agent qui remonte du contexte.

Des cas d’usage concrets que vous verrez vite remonter :

• authentifications suspectes (Windows, Linux, AD),
• brute force (SSH, RDP, VPN),
• élévation de privilèges (ajout au groupe admin, sudo inhabituel),
• modifications système (services, tâches planifiées, registry),
• signaux malware (binaire suspect, persistance basique),
• exfiltration ou comportements anormaux via logs proxy, DNS, firewall.

Ce que Wazuh n’est pas, et autant le dire.

Wazuh n’est pas un EDR propriétaire « full » avec une chasse avancée clé en main, des graphes de causalité ultra riches, et du machine learning opaque. Vous pouvez faire beaucoup, mais il y a des limites. Par exemple, pour de la chasse très avancée sur la mémoire, ou des capacités d’isolation réseau hyper sophistiquées, vous allez compléter avec autre chose.

Pourquoi choisir Wazuh malgré ça ?

Parce que vous gardez le contrôle. Transparence, extensibilité, multi plateforme, et un coût qui permet d’équiper large. Et en sécurité, équiper large, c’est souvent ce qui manque.

Avant de déployer : définir votre périmètre, vos sources de logs et vos priorités de détection

Avant de toucher à l’installation, il faut faire un truc pas très sexy, mais crucial : décider ce que vous voulez détecter. Sinon vous allez collecter « tout », brûler du disque, et ne rien exploiter.

Sources de logs prioritaires

Si vous devez démarrer avec une liste courte, partez sur :

• Windows Event Logs (Security, System, Application).
• Sysmon si vous l’avez (ou si vous pouvez l’ajouter).
• Linux : /var/log/auth.log, /var/log/secure, syslog, journald selon distros.
• Active Directory : événements d’auth, changements de groupes, comptes.
• VPN (Forti, Palo, OpenVPN, etc).
• Pare feu : accept, deny, NAT, menaces si dispo.
• Proxy / SWG : URL, catégories, user, user agent.
• DNS : requêtes, NXDOMAIN, volumes.
• Serveurs web : access logs, erreurs, WAF si présent.
• Cloud : CloudTrail, Azure AD sign in, M365 audit, selon votre réalité.

Un top 10 de scénarios, pas 100

Choisissez 10 scénarios, maximum, pour les premières semaines :

1. brute force SSH,
2. brute force RDP,
3. comptes désactivés réactivés,
4. ajout d’un utilisateur à un groupe admin,
5. exécution PowerShell suspecte,
6. nouvelle tâche planifiée,
7. nouveau service installé,
8. binaire inconnu exécuté depuis un chemin atypique,
9. modification de fichiers critiques (FIM),
10. scans internes (sur logs firewall, IDS, ou même sur certains serveurs).

Contraintes à cadrer tout de suite

• volumétrie et rétention (7 jours, 30 jours, 90 jours, plus),
• RGPD et données sensibles dans les logs,
• cloisonnement réseau (segments, DMZ, sites distants),
• haute dispo ou non,
• effort POC vs effort production.

Un POC tolère des choix « rapides ». La prod, non. En prod, vous parlerez sauvegardes, durcissement, supervision, mises à jour, tests de restauration. Tout de suite.

Pré requis à préparer avant d’installer :

• DNS propre,
• NTP partout (vraiment partout),
• certificats et TLS (ou au minimum une stratégie),
• ports ouverts de façon contrôlée,
• inventaire endpoints et OS,
• un plan de nommage, simple mais cohérent.

Architecture Wazuh recommandée : simple au départ, scalable ensuite

Wazuh, c’est quatre briques principales :

• Wazuh manager (server) : réception, analyse, règles, réponses actives.
• Indexer (OpenSearch) : stockage et recherche.
• Dashboard : visualisation et investigation.
• Agents : collecte et enrichissement sur les endpoints.

Deux approches classiques

Tout en un (lab, petite infra, POC, PME)

Vous mettez manager + indexer + dashboard sur une VM. C’est rapide, c’est pratique. Mais attention aux ressources disque et RAM.

Distribué (production)

Vous séparez les rôles, au minimum :

• un ou plusieurs managers,
• un cluster indexer (souvent 3 nœuds pour du sérieux),
• un dashboard dédié.

Ça améliore la perf, la sécurité, et ça évite qu’un seul serveur devienne un point de douleur permanent.

Emplacement : on prem, VM, cloud

On prem, VM, cloud, tout se fait. Les implications sécurité, elles, ne sont pas optionnelles :

• segmentation réseau (les agents ne doivent pas parler au dashboard),
• bastion d’administration,
• durcissement OS,
• exposition minimale (pas de dashboard sur Internet, par pitié),
• principe du moindre privilège.

Flux réseau à comprendre

• agents → manager
• manager → indexer
• dashboard → indexer

Et votre objectif, c’est que chaque flux soit strictement nécessaire, filtré, journalisé, et si possible chiffré. C’est un outil de sécurité, donc il doit être traité comme une cible.

Stratégie de rétention

Décidez tôt :

• combien de temps en hot (rapide, cher),
• combien en warm (plus lent),
• compression, rotation,
• sauvegardes,
• et surtout : restauration testée. Une sauvegarde non testée, c’est une idée.

Déploiement de Wazuh : installation propre et sécurisée (pas juste « ça marche »)

Méthode d’installation

• Packages officiels : plus contrôlable, plus « sysadmin friendly ».
• Script d’installation : rapide, très bien pour démarrer, mais il faut quand même relire ce qui est exposé et comment c’est configuré.
• Docker : utile pour des labs, des tests, ou des environnements très maîtrisés. En production, ça peut être très bien aussi, mais seulement si votre équipe sait opérer Docker sérieusement. Sinon vous allez perdre du temps sur autre chose que la détection.

L’ordre classique :

1. installer l’indexer,
2. installer le manager,
3. installer le dashboard,
4. valider que tout est sain avant d’onboarder des agents.

Vérifications de base après installation

• services actifs et au boot,
• ingestion : un événement doit arriver, être indexé, visible,
• latence ingestion (secondes, pas minutes),
• santé cluster indexer (green si possible),
• index patterns, permissions, accès dashboard.

Durcissement minimum viable

• comptes admin limités, mots de passe forts, idéalement SSO et MFA côté dashboard si possible,
• firewall : n’exposez que le nécessaire,
• restrictions IP (dashboard accessible uniquement depuis réseau admin ou via VPN),
• TLS partout où c’est réaliste,
• journaux d’administration conservés.

Pièges classiques (ceux qui font perdre une journée)

• NTP pas aligné : événements dans le futur ou le passé, corrélation cassée.
• certificats mal posés : erreurs silencieuses, agents qui n’enregistrent pas.
• disque saturé sur l’indexer : ingestion qui se bloque, puis effet domino.
• JVM heap mal dimensionné : indexer instable.
• logs trop verbeux : vous payez le bruit en stockage.

Onboarding des endpoints : déployer les agents Wazuh (Windows, Linux) sans douleur

Le principe : l’agent collecte, ajoute du contexte (hostname, user, etc), puis envoie au manager. Si l’agent est mal déployé, tout le reste sera bancal.

Windows : points clés

• installer l’agent,
• enregistrer l’agent auprès du manager (clé, méthode d’auth),
• collecter les Event Channels utiles : Security en priorité, Sysmon si présent.

Attention à :

• droits nécessaires (lecture Security log),
• performance si vous activez trop de sources d’un coup,
• cohérence des noms d’hôtes et des tags.

Linux : points clés

• agent + enregistrement,
• collecte auth.log / secure, syslog, journald,
• éventuellement auditd si vous savez pourquoi vous l’activez.

Déploiement standardisé

• Windows : GPO, Intune, SCCM, ou un outil équivalent.
• Linux : Ansible, SSH, scripts, ou votre gestionnaire de config habituel.

Le truc qui change tout : templates de configuration et groupes d’agents.

• tags par environnement (prod, preprod),
• tags par rôle (serveur AD, serveur web, postes),
• configuration appliquée par groupe,
• rollout progressif : 10 machines, puis 50, puis 200.

Validation simple

Après onboarding :

• événement test visible dans le dashboard,
• latence raisonnable,
• consommation CPU/RAM acceptable sur endpoint,
• pas d’erreurs d’agent en boucle.

Centraliser et normaliser : les logs qui comptent (et comment éviter le chaos)

Centraliser n’est pas la fin. Normaliser, c’est ce qui rend la corrélation possible.

Si vos événements parlent tous un langage différent, vous ne pourrez pas faire des règles stables. Et vous finirez à écrire des exceptions, encore et encore.

Pourquoi parsing et champs cohérents sont la clé

Vous voulez des champs stables, du type :

• hostname
• user
• src_ip
• dst_ip
• process_name
• event_id
• action (success, failure)

Même si les sources diffèrent, votre objectif est d’arriver à des patterns de requêtes et de dashboards reproductibles.

Ingestion de logs réseau et applicatifs

Les sources à forte valeur, très vite :

• VPN : connexion, échecs, géolocalisation possible.
• firewall : deny, scans, connexions sortantes atypiques.
• proxy : domaines rares, catégories interdites, volumes.
• DNS : pics, domaines nouveaux, NXDOMAIN.

Et côté technique, vous allez souvent passer par :

• syslog,
• lecture de fichiers,
• intégrations spécifiques.

Structurer la collecte

• conventions de nommage (hosts, sites),
• timezones cohérentes,
• rotation de logs côté sources,
• éviter les logs debug en production.

Sur la volumétrie : oui, vous pouvez limiter. Mais faites le avec prudence. Le sampling aveugle, ça casse des enquêtes.

Mettre en place une baseline

Avant de crier à l’anomalie, il faut savoir ce qui est normal. Une semaine de baseline, parfois deux, ça évite d’ouvrir 200 tickets sur des tâches légitimes.

Détection : règles, corrélation et cas d’usage concrets (ce que vous devez activer en premier)

Wazuh détecte via :

• decoders : parsing des logs,
• règles : conditions, patterns, event ids, champs,
• niveaux de sévérité,
• listes (CDB lists) : allowlists, blocklists, exceptions,
• corrélation : fenêtres temporelles, seuils, agrégation.

Le conseil le plus rentable : commencez par des détections à fort signal.

Cas d’usage 1 : brute force SSH et RDP

Objectif : détecter un volume d’échecs dans une fenêtre de temps, sur un même compte ou depuis une même IP.

À calibrer :

• seuil (ex : 10 échecs en 2 minutes),
• fenêtre temporelle,
• IP sources internes vs externes,
• exceptions (bastion, scanner interne, outil de supervision).

Ensuite seulement, vous discutez blocage automatique. Pas avant.

Cas d’usage 2 : FIM sur chemins critiques

FIM est souvent sous utilisé, alors que c’est un signal très propre.

Sur Linux :

• /etc/passwd, /etc/shadow, /etc/sudoers,
• /etc/ssh/sshd_config,
• répertoires de conf d’app critiques.

Sur Windows :

• répertoires d’applications,
• scripts de démarrage,
• zones de configuration sensibles.

L’idée n’est pas de surveiller tout le disque. C’est de surveiller ce qui ne devrait presque jamais changer. Et quand ça change, vous voulez le savoir tout de suite.

Cas d’usage 3 : détection de vulnérabilités

Wazuh remonte l’inventaire et peut détecter des CVE. La valeur ici, ce n’est pas « j’ai 2000 CVE ». C’est la priorisation :

• hôtes exposés vs internes,
• serveurs critiques,
• CVE exploitées activement,
• présence d’un correctif disponible.

Ça devient une entrée pour votre gestion de patch, pas juste un tableau anxiogène.

Prioriser et itérer

Ne cherchez pas à tout activer.

• démarrez simple,
• mesurez les faux positifs,
• améliorez 2 ou 3 règles par semaine,
• documentez chaque exception.

C’est lent, oui. Mais c’est comme ça que ça tient.

Réponse active : passer de l’alerte à l’action (sans se tirer une balle dans le pied)

La « active response » dans Wazuh, c’est déclencher un script ou une action quand une alerte correspond à certaines conditions.

Exemples :

• bannir une IP après brute force,
• tuer un process suspect,
• notifier Slack ou Teams,
• ouvrir un ticket,
• désactiver un compte compromis.

Mais. Et c’est un gros mais.

Automatiser sur des signaux faibles, c’est dangereux. Vous allez bloquer un VPN parce qu’un utilisateur s’est trompé de mot de passe. Vous allez tuer un process légitime. Et vous allez perdre la confiance des équipes.

Exemples prudents, très prudents

• brute force externe clair : bannir IP temporairement, avec durée limitée.
• alerte critique sur un serveur sensible : notification immédiate + ticket, pas forcément action destructive.
• compte admin utilisé à une heure impossible : escalade humaine, pas désactivation auto.

Traçabilité et rollback

Chaque action doit être journalisée :

• alerte source,
• action déclenchée,
• résultat,
• qui a approuvé si nécessaire.

Et vous devez avoir un plan de retour arrière :

• débannir une IP,
• réactiver un compte,
• restaurer une conf.

Si vous ne pouvez pas rollback vite, vous ne devez pas automatiser.

Visualisation et investigation : dashboards utiles, requêtes et workflow d’analyse

Un bon dashboard SIEM ne cherche pas à être beau. Il cherche à aider à décider.

Ce qui marche vraiment

• top alertes par type,
• top hôtes les plus bruyants,
• top users concernés,
• top IP sources,
• évolution dans le temps (pics).

Puis des vues par périmètre :

• AD et Windows,
• Linux,
• réseau,
• serveurs critiques,
• conformité.

Requêtes pratiques à garder sous la main

• connexions échouées par IP sur 1 h,
• nouvelles tâches planifiées sur 24 h,
• création de nouveaux comptes,
• élévations de privilèges,
• modifications sur fichiers FIM,
• pics d’événements sur un hôte précis.

Et si vous pouvez enrichir, faites le :

• géolocalisation IP,
• réputation (selon intégrations),
• contexte endpoint (rôle, environnement, propriétaire).

Dernier point, souvent oublié : documenter des playbooks courts. Une page. Pas un roman.

Pour chaque alerte importante :

• à quoi ça ressemble,
• première vérif,
• escalade ou non,
• temps cible,
• qui fait quoi.

Intégrations qui changent tout : email, ticketing, threat intelligence et (si besoin) un IDS réseau

Wazuh seul, c’est déjà bien. Branché correctement, c’est autre chose.

Notifications : éviter le spam

• email pour les rapports, les digests, les infos,
• Slack ou Teams pour le temps réel, mais seulement pour les alertes à fort signal.

Utilisez des digests, des seuils, et des regroupements. Sinon, tout le monde mute le canal au bout de 48 heures.

Ticketing

Jira, GLPI, ServiceNow, peu importe. La logique :

• assignation claire,
• SLA,
• historique,
• commentaires d’investigation,
• lien alerte → action.

L’objectif n’est pas d’ajouter de la bureaucratie. C’est d’éviter que les alertes meurent dans un chat.

IDS réseau : Suricata ou Zeek si vous surveillez du trafic

Si vous avez un point de capture pertinent, Suricata ou Zeek apportent un signal réseau que les endpoints ne verront pas. L’idée ensuite est d’envoyer les alertes dans Wazuh, pour centraliser l’investigation.

Attention au piège : centraliser sans dupliquer. Clarifiez la « source of truth » et évitez les doubles alertes sur le même événement.

Sécurité des intégrations

• tokens stockés proprement,
• rotation,
• moindre privilège,
• segmentation réseau.

Une intégration Slack avec un token trop permissif, c’est une nouvelle surface d’attaque. Simple.

Passer en production : tuning, gouvernance des logs, rétention et amélioration continue

Le passage en production n’est pas « on a plus d’agents ». C’est un changement de posture.

Tuning

• réduire faux positifs,
• ajuster niveaux,
• ajuster seuils,
• exclusions documentées (et revues).

L’exclusion non documentée, c’est une dette. Et elle revient toujours.

Gouvernance

Décidez :

• qui possède la plateforme (IT, sécu, SOC),
• qui peut modifier les règles,
• comment on valide un changement,
• comment on versionne.

Même petit, il faut un minimum de process. Sinon vous allez casser la détection en voulant aider.

Sauvegardes et restauration

À sauvegarder :

• indexer (données),
• configurations Wazuh,
• clés et certificats.

Et test de restauration. Obligatoire.

Supervision de la stack

Surveillez :

• disque,
• heap JVM indexer,
• latence ingestion,
• santé cluster,
• files d’attente,
• mises à jour et correctifs.

Roadmap 30, 60, 90 jours

• 30 jours : onboarder les sources prioritaires, stabiliser 3 règles.
• 60 jours : ajouter 5 sources, améliorer 5 règles, mettre 1 dashboard décisionnel par périmètre.
• 90 jours : automatiser 2 réponses actives avec garde fous, former l’équipe, formaliser playbooks.

Conclusion : votre « boucle sécurité » avec Wazuh (collecter → détecter → répondre → apprendre)

Si on résume, Wazuh vous aide à construire une boucle sécurité qui tient :

• collecter (agents, syslog, fichiers),
• détecter (règles, corrélation, FIM, vulnérabilités),
• répondre (active response, ticketing, notifications),
• apprendre (tuning, baseline, amélioration continue).

Le point clé, c’est l’itération. Commencez petit, prouvez la valeur, élargissez.

Mon conseil final, si vous voulez éviter le chaos : choisissez 3 cas d’usage à fort signal. Par exemple brute force, ajout admin, FIM sur chemins critiques. Stabilisez les. Mesurez les faux positifs. Documentez le workflow. Puis seulement, ajoutez le reste.

Et si vous voulez une prochaine étape concrète : faites un POC sur un sous réseau, disons 10 machines. Une semaine. Mesurez le nombre d’alertes utiles, et surtout le temps moyen d’investigation. C’est ça, au final, le vrai KPI. Pas le nombre de logs ingérés.

Questions fréquemment posées

Pourquoi la détection d’intrusion active est-elle devenue indispensable en cybersécurité ?

La détection d’intrusion active est devenue indispensable car les environnements informatiques sont de plus en plus complexes et dynamiques (endpoints multiples, postes nomades, cloud hybride, télétravail). Les attaques ne respectent pas les rythmes de revue traditionnels, rendant insuffisante la simple collecte de logs. La détection active permet de corréler, alerter, enrichir et répondre rapidement aux incidents, réduisant ainsi le bruit et la fatigue liée aux fausses alertes.

Quelle est la différence entre journalisation (logs) et détection d’intrusion active ?

La journalisation consiste à collecter et stocker des données (logs) sans forcément les analyser en temps réel. La détection d’intrusion active va plus loin en corrélant ces données, générant des alertes pertinentes, enrichissant les informations contextuelles et déclenchant des réponses automatiques ou manuelles pour contrer les menaces efficacement.

Quelles sont les fonctionnalités principales de Wazuh en tant que solution XDR/SIEM open source ?

Wazuh offre plusieurs fonctionnalités clés : collecte et analyse centralisée des logs via agents ou syslog, corrélation d'événements grâce à des règles personnalisables, surveillance de l'intégrité des fichiers (FIM), détection de vulnérabilités avec inventaire CVE, conformité réglementaire (PCI DSS, CIS, GDPR), et réponses actives aux incidents lorsque le signal est suffisamment fort.

Quels types d’incidents Wazuh peut-il détecter concrètement ?

Wazuh détecte notamment les authentifications suspectes sur Windows/Linux/AD, tentatives de brute force SSH/RDP/VPN, élévations de privilèges inhabituelles (ajout au groupe admin, sudo anormal), modifications système critiques (services, tâches planifiées, registre), signaux malware (binaire suspect, persistance), ainsi que des comportements anormaux liés à l’exfiltration via logs proxy, DNS ou firewall.

Quelles sont les limites de Wazuh comparé à un EDR propriétaire complet ?

Wazuh n’offre pas certaines capacités avancées comme la chasse approfondie sur la mémoire vive, des graphes de causalité ultra riches ou du machine learning opaque. Il ne propose pas non plus des fonctions sophistiquées d’isolation réseau. Pour ces besoins très spécifiques et avancés, il faudra compléter Wazuh par d’autres outils spécialisés.

Pourquoi choisir Wazuh malgré ses limites ?

Wazuh est choisi pour sa transparence totale en open source, son extensibilité multi-plateforme et son coût faible qui permet un large déploiement. Il offre un bon équilibre entre visibilité endpoint et centralisation SIEM tout en gardant le contrôle du système. En sécurité informatique, équiper largement son infrastructure est souvent un facteur clé pour une protection efficace.