La surveillance centralisée des logs change la donne pour une CMS comme Joomla, surtout lorsqu’elle s’appuie sur Wazuh et un serveur dédié. La collecte unifiée améliore la visibilité des événements et accélère la détection d’intrusion et la remontée d’alerte de sécurité.
L’expérience d’une petite agence fictive nommée Atelier Web illustre ce point avec pragmatisme et détails techniques. La suite expose les choix d’architecture, les règles, les scénarios de test et le suivi opérationnel pour le monitoring et l’analyse des logs.
A retenir :
- Collecte centralisée des logs pour visibilité globale
- Corrélation d’événements pour détection d’intrusion rapide
- Intégration Wazuh avec OpenSearch pour recherche performante
- Surveillance dédiée des instances Joomla et du serveur
Architecture Wazuh pour logs centralisés et collecte Joomla
Cette section commence par relier la vision stratégique aux composants techniques déployés dans l’infrastructure d’Atelier Web. L’architecture retenue articule des agents Wazuh sur chaque hôte, un manager central et des indexers OpenSearch pour stocker les logs.
Agents Wazuh sur serveur et sur instances Joomla
Ce paragraphe montre le lien direct entre la collecte locale et l’analyse centralisée des événements de sécurité. Les agents Wazuh récupèrent les logs Apache, PHP et les messages système depuis le serveur hébergeant Joomla, puis transmettent ces données au manager.
Selon la documentation officielle, l’agent enrichit les logs avec des champs normalisés pour faciliter la corrélation et la recherche. Selon la formation M2i, cette normalisation est cruciale pour créer des règles efficaces et reproductibles.
Exemples concrets pris en test incluent l’envoi de journaux d’accès, d’erreurs PHP et des alertes système depuis Windows et Ubuntu. Cette approche consolide la surveillance et prépare la suite vers l’indexation OpenSearch.
Indexation OpenSearch et Cross Cluster Search
Cette partie décrit comment l’indexation relie les sites distants via CCS, créant ainsi des requêtes fédérées entre indexers. Le manager Wazuh pousse les événements vers les indexers OpenSearch, et le CCS permet d’interroger plusieurs clusters comme un point unique.
Composant
Rôle principal
Exemple
Notes
Wazuh Agent
Collecte et détection locale
Serveur Joomla, Windows 11
FIM et logs applicatifs
Wazuh Manager
Corrélation et règles
Analyse centralisée
Gestion des alertes
OpenSearch Indexer
Stockage et recherche
Indexer A / B
Cross Cluster Search activé
OpenSearch Dashboards
Visualisation
Tableaux de bord Wazuh
Patterns index configurés
Pour Atelier Web, l’indexation a permis d’agréger des logs hétérogènes et d’extraire rapidement des indicateurs de compromission. Selon un test de simulation, l’interrogation de clusters distants renvoie des résultats en quelques millisecondes.
Ce dispositif préparera l’étape suivante centrée sur les règles de détection et la génération d’alerte de sécurité. Le passage vers la configuration des règles est essentiel pour transformer les logs centralisés en incidents exploitables.
Configuration des règles Wazuh pour détection d’intrusion
Ce chapitre suit la logique d’architecture et plonge dans la création et l’affinement des règles XML au manager. Les règles permettent de détecter des tentatives d’élévation, des SSH invalides et des injections ciblant Joomla et le serveur application.
Règles XML, personnalisation et optimisation
La première phrase décrit le lien entre règles simples et scénarios complexes de corrélation au manager. Les extraits XML structurent les critères, niveaux et descriptions, et autorisent l’ajout de conditions multi-champs.
Selon la documentation Wazuh, les règles peuvent inclure des champs décodés et des expressions régulières précises pour extraire les IP et utilisateurs. Selon GitHub, des exemples partagés simplifient le démarrage et la personnalisation des règles.
Intégrer Sysmon sur Windows 11 a enrichi les événements et affiné les alertes liées aux processus malveillants. Cette optimisation diminue le bruit et améliore la pertinence des notifications envoyées aux équipes.
Composants techniques Wazuh :
- Agents légers pour collecte système et application
- Manager pour corrélation et enrichissement d’alerte
- OpenSearch pour indexation et recherche haute performance
- Dashboards pour analyse et visualisation rapide
Simulations d’attaque et génération d’alerte de sécurité
La phrase d’introduction relie les règles à la validation par tests pratiques et reproductions d’attaque. Une tentative SSH invalide a été simulée pour vérifier le parcours complet depuis la détection jusqu’à l’affichage sur le dashboard.
Un exemple consistait à injecter un message via logger, puis à observer le champ full_log et l’horodatage remontés dans OpenSearch. Selon la chaîne de traitement, l’alerte a été classée avec un niveau adapté et associée à des tags MITRE ATT&CK.
« J’ai configuré les règles personnalisées et j’ai immédiatement réduit les faux positifs sur le portail Joomla. »
Alice N.
La simulation a prouvé que la corrélation permet d’identifier des schémas d’attaque plus larges que des événements isolés. L’enjeu suivant porte sur l’intégration opérationnelle et la gestion des incidents au quotidien.
Exploitation opérationnelle et workflows de gestion des incidents
Cette section part du constat des règles validées et aborde l’organisation des réponses et des procédures d’escalade. Le monitoring continu génère des tickets, active des playbooks et oriente les actions sur le serveur ou l’application Joomla.
Flux d’alerte, tickets et remédiation automatisée
Le lien immédiat entre alertes et workflows améliore le temps moyen de traitement des incidents. Les intégrations API permettent d’envoyer des tickets vers un outil ITSM ou d’exécuter des scripts PowerShell pour isoler une machine compromise.
Sources de logs Joomla :
- Fichiers d’accès Apache pour activités HTTP suspectes
- Journaux d’erreurs PHP pour vulnérabilités applicatives
- Logs système du serveur pour anomalies de processus
- Entrées de base de données pour requêtes anormales
Un tableau synthétique des incidents courants aide les équipes à prioriser correctement les actions manuelles. Selon des retours d’expérience, la combinaison FIM et corrélation réduit les investigations longues.
Analyse des logs, conformité et reporting
Cette partie introduit la génération de rapports pour conformité et audits réguliers. Wazuh mappe automatiquement certaines alertes aux normes comme PCI DSS et GDPR, facilitant la production de preuves d’audit.
Type d’incident
Détection par
Exemple
Action recommandée
SSH brute force
Règle de fréquence
Failed password pour root
Bloquer IP et analyser logs
Injection PHP
Parsing PHP errors
Payload suspect dans POST
Isoler site et appliquer patch
Modification fichier critique
FIM
Changement /etc/passwd
Restaurer et investiguer
Processus malveillant
Sysmon
Exécution inconnue en root
Collecte forensic et quarantaine
« J’ai vu la remontée d’alerte en temps réel et cela a permis d’isoler le serveur immédiatement. »
Marc N.
Un témoignage utilisateur illustre le gain opérationnel et la confiance apportée par la solution centralisée. L’architecture étudiée permet d’envisager une montée en charge pour plusieurs sites et des améliorations continues.
« La mise en place de Wazuh a transformé notre monitoring, la visibilité est devenue claire et exploitable. »
Sébastien N.
Un avis d’expert souligne la valeur ajoutée technique et budgétaire de Wazuh dans des contextes contraints. Ce commentaire invite à formaliser des playbooks et à automatiser la réponse pour gagner en efficacité.
« En tant qu’administrateur, automatiser les remédiations m’a permis de réduire la charge opérationnelle immédiatement. »
Pauline N.
Pour Atelier Web, l’effort de configuration initial a été récompensé par une baisse mesurable des incidents non détectés. L’étape suivante consiste à affiner les dashboards et à documenter les procédures pour l’équipe.
Source : Wazuh Documentation, « Log data collection », 2024 ; M2i Formation, « Analyste Cybersécurité », 2023 ; GitHub, « hai-adem/implementation_analyse_siem_wazuh », 2022.