Système de détection d'intrusion basé sur l'hôte avec Wazuh¶

1. Objectif du cours¶

Apprendre à déployer et configurer Wazuh (HIDS) sur environnements hétérogènes, adapter les règles de détection aux hôtes et intégrer Wazuh avec l'écosystème de sécurité pour une surveillance hôte centrale et scalable.

2. Notions et définitions essentielles¶

HIDS : système de détection d'intrusion basé sur l'hôte (surveille l'activité interne des machines).
Agent Wazuh : composant installé sur chaque système qui collecte logs, processus et FIM.
Serveur Wazuh : centralise l'analyse, applique les règles, génère alertes et expose l'API REST.
Elastic Stack : Elasticsearch (stockage/indexation) + Kibana (visualisation).
FIM (File Integrity Monitoring) : surveillance des empreintes/hash, attributs et créations/suppressions de fichiers.
Niveaux de sévérité : échelle Wazuh de 0 (info) à 15 (critique).

3. Fonctionnement et principes¶

Architecture distribuée : séparation des rôles collecte (agents), traitement/alerte (serveur) et stockage/visualisation (Elastic Stack) pour scalabilité.
Flux : agents envoient de manière chiffrée (AES) leurs données au serveur ; le serveur applique règles prédéfinies/ personnalisées et produit des alertes.
Modules complémentaires : FIM pour modifications de fichiers, module anti-malware/rootkit (signatures + comportemental), analyse corrélée des logs pour détecter séquences multi-étapes.
Corrélation : règles composites basées sur fenêtres temporelles et conditions (utilisateur, IP, ressource) permettant d'élever la criticité d'une séquence d'événements apparemment isolés.

4. Commandes et manipulations¶

Non abordé dans ce cours.

5. Sécurité et bonnes pratiques¶

Chiffrement des communications agents-serveur : vérifiez l'utilisation d'AES pour protéger les données en transit.
Gestion des clés d'enrôlement : générer côté serveur, copier de manière sécurisée ; pour grands déploiements, privilégier l'enrôlement automatique avec clé temporaire.
Intégrations sécurisées : utiliser TLS pour les échanges entre Wazuh et SIEM/EDR/API, comptes de service avec privilèges minimaux.
Privilèges agents : exiger élévation (droits administrateur/root) documentée lorsque nécessaire (détection de rootkits).
macOS : configurer permissions de sécurité/confidentialité spécifiques pour l'agent.
FIM : exclure répertoires temporaires et logs rotatifs pour réduire le bruit ; limiter extensions surveillées pour optimiser perf.
Gouvernance : documenter groupes, noms et modifications de règles ; réviser régulièrement seuils d'alerte pour éviter fatigue des alertes.

6. Points essentiels à retenir pour le TSSR¶

Architecture = serveur Wazuh + agents + Elastic Stack (Elasticsearch + Kibana).
ossec.conf centralise la configuration serveur (règles, niveaux, notifications, rétention).
FIM surveille contenu (hash), attributs (permissions/propriétaire/taille) et créations/suppressions.
Enrôlement automatique recommandé pour déploiements massifs ; sinon clé pré-partagée générée par le serveur.
Communications agents-serveur chiffrées (AES) ; vérifier via le tableau de bord.
Règles Wazuh : pattern, sévérité (0-15), conditions (fréquence/corrélation), actions ; adapter pour réduire faux positifs.
Niveaux critiques (12-15) nécessitent action immédiate et notifications différenciées (SMS/appel/email).
Corrélation d'événements : définir fenêtres temporelles, règles composites et prioriser corrélations critiques (coût CPU).
Grouper agents par fonction/localisation/criticité facilite déploiement et application de configurations partagées.
Kibana : créer tableaux de bord ciblés par profil utilisateur (exécutif, opérationnel, admin).

7. Tableau récapitulatif¶

Élément	Usage / Action
Serveur Wazuh	Centralise analyse, règles, API REST
Agents Wazuh	Collecte locale : logs, processus, FIM ; envoient au serveur
Elasticsearch vs Kibana	Stockage/indexation vs visualisation et reporting
FIM vs Détection malware	FIM = changements fichiers; Anti-malware = signatures + comportemental/rootkits
Niveaux 0-3 / 4-6 / 7-11 / 12-15	Info/debug / Notable / Suspect (SIEM) / Critique (action immédiate)

8. Vérifications pratiques¶

Vérifier la connectivité agent→serveur (tous les agents communiquent correctement).
Confirmer dans le tableau de bord que la communication agent-serveur est chiffrée (AES).
Valider l'impact performance via déploiement pilote sur serveur de test avant mise en prod.
Contrôler que les agents disposent des privilèges requis pour détections (ex. rootkit).
S'assurer que les alertes sont envoyées selon la configuration (ex. emails pour niveaux ≥12) et que les configurations de groupe sont synchronisées à la connexion de l'agent.

9. Flashcards Anki¶

Quelles sont les trois composantes principales de l'architecture Wazuh ? :: Le serveur Wazuh, les agents Wazuh et la pile Elastic Stack Quel fichier centralise la configuration critique du serveur Wazuh ? :: ossec.conf Quel chiffrement est utilisé pour protéger les communications agents-serveur ? :: AES Quels sont les trois types de changements surveillés par le module FIM ? :: Contenu (hash), attributs (permissions/propriétaire/taille) et créations/suppressions de fichiers Quelle méthode d'enrôlement est recommandée pour un déploiement à grande échelle ? :: Enrôlement automatique Quels niveaux de sévérité Wazuh correspondent aux alertes critiques ? :: 12 à 15 Quel module combine signatures et analyse comportementale pour détecter malwares ? :: Module de détection de malwares et rootkits Où sont stockées les configurations partagées appliquées aux groupes d'agents ? :: Sur le serveur central sous forme de fichiers de configuration spécifiques à chaque groupe Quel composant fournit les capacités d'indexation et lequel la visualisation ? :: Elasticsearch pour indexation/stockage et Kibana pour visualisation Pourquoi la détection de rootkits nécessite-t-elle des privilèges élevés ? :: Parce que certaines techniques comparent informations système obtenues par différents moyens nécessitant des droits administrateur