Wazuh 005 – Filter Apache logs to block IPs (AlienVault)

TL;DR

Wazuh est une plateforme open source de sécurité utilisée pour centraliser des événements, détecter des comportements suspects, suivre la conformité et investiguer des incidents. Dans cet épisode, le sujet central est: Filter Apache logs to block IPs (AlienVault). L objectif est de relier la démonstration du dépôt Xavki à une compréhension exploitable en contexte SIEM/XDR.

La vidéo de référence

Vidéo: https://www.youtube.com/watch?v=rkUIoi-PR3o

Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWoCKf3PDJYT2ihAd0hPZ0uM

Le dépôt support est disponible ici: https://gitlab.com/xavki/tutorials-wazuh. Le support de ce chapitre se trouve dans 05-example-apache-logs-alienvault/slides.md.

Wazuh et Filter Apache logs to block IPs (AlienVault): c est quoi exactement ?

Pour les attaques web, Wazuh dépend beaucoup de la qualité des logs applicatifs et reverse-proxy. Les outils comme Nikto ou DVWA servent de générateurs d événements de lab, pas de preuve de sécurité complète.

Le vrai sujet de ce chapitre est de analyser des attaques web, enrichir la lecture des logs Apache et préparer des actions de blocage ou de corrélation. Le dépôt Xavki sert de colonne vertébrale factuelle: il expose les slides, commandes et fichiers utilisés pendant les démonstrations. La documentation Wazuh complète ensuite le contexte officiel: architecture, installation, agents, règles, intégrations et capacités.

Points clés vus dans le support Xavki

• install apache on target server
• edit wazuh-agent configuration to collect apache logs
• add alienvault ip list on wazuh server
• add another ip
• use the wazuh script to convert the list in cbd format
• test logs parsing and rules
• change rule level for webserver logs with /var/ossec/ruleset/rules/0245-web_rules.xml
• change to store logs temporarly in archive with /var/ossec/etc/ossec.conf
• check with archive logs
• add a new specific rule for alienvault ip list

Ces points doivent être lus comme une progression: d abord comprendre le signal collecté, ensuite vérifier la collecte, puis seulement interpréter l alerte dans Wazuh.

Modèle mental minimal

Un flux Wazuh se résume ainsi: endpoint -> agent -> Wazuh server -> rules/decoders -> indexer -> dashboard. Si une alerte manque, il faut diagnostiquer cette chaîne dans l ordre. Si une alerte existe mais n est pas utile, le problème vient souvent du bruit, du contexte ou du seuil de règle.

Notions et définitions sécurité

• **SIEM**: Security Information and Event Management. Un SIEM centralise des journaux, applique des règles de corrélation et aide les équipes sécurité à investiguer des événements. Wazuh couvre ce rôle en collectant, normalisant, stockant et affichant des alertes.
• **XDR**: Extended Detection and Response. Un XDR élargit la détection au-delà du simple log management: endpoints, comportements, réponse active, cloud, conteneurs et menaces. Dans Wazuh, cette dimension apparaît avec les agents, les capacités endpoint, la conformité et les intégrations.
• **Agent**: Composant installé sur une machine surveillée. Il collecte des logs, fichiers, événements système, inventaires, métriques ou signaux de sécurité, puis les transmet au serveur Wazuh.
• **Decoder**: Un decoder transforme un événement brut en champs compréhensibles: source IP, utilisateur, programme, message, code, chemin de fichier. Sans décodage correct, une règle peut ne jamais se déclencher.
• **Rule**: Une règle Wazuh évalue un événement décodé et produit éventuellement une alerte avec un niveau, des groupes, une description et des métadonnées. Les règles sont le cœur de la détection.
• **Faux positif**: Alerte techniquement déclenchée mais non pertinente dans le contexte. Un outil de sécurité utile doit gérer les faux positifs avec du tuning, des exceptions documentées et des seuils adaptés.
• **Indicateur de compromission**: Un IOC est un signal qui peut indiquer une activité malveillante: IP, hash, domaine, chemin, comportement, signature IDS ou motif dans un log. Il doit toujours être interprété avec du contexte.
• **WAF vs SIEM**: Un WAF bloque ou filtre du trafic web en ligne. Un SIEM comme Wazuh collecte et corrèle les événements. Les deux peuvent coopérer, mais ils ne jouent pas le même rôle.
• **Réputation IP**: Information externe associée à une adresse IP: connue comme malveillante, scanner, proxy, botnet ou source douteuse. Elle enrichit l analyse mais ne doit pas être le seul critère de blocage.

Ces définitions sont volontairement pratiques. L objectif n est pas de réciter un glossaire, mais de savoir où placer chaque notion dans la chaîne de détection: collecte, décodage, corrélation, alerte, investigation et réponse.

Approfondissement spécifique

Pour les épisodes web, le sujet est la transformation d une requête HTTP en signal sécurité. L URI, le status code, le user-agent, l IP source et le contexte applicatif sont plus importants qu une alerte isolée.

Quand le titre parle de blocage ou d AlienVault, il faut séparer enrichissement, décision et action. Une IP suspecte ne doit pas être bloquée sans comprendre quelle règle a déclenché et quel impact opérationnel le blocage peut avoir.

Le dépôt fournit aussi des fichiers concrets pour ce chapitre: 05-example-apache-logs-alienvault/slides.md. Ils servent à retrouver les commandes, scripts de test, sorties ou configurations utilisées dans la démonstration.

Ce que cet épisode cherche à modifier

• produire du trafic web identifiable avec DVWA, Nikto ou Teler
• collecter les logs Apache ou applicatifs utiles
• enrichir ou filtrer les événements avec réputation IP ou règles adaptées

Chemin de diagnostic recommandé

• collecter les logs Apache ou applicatifs
• identifier source IP, URI, status code et user-agent
• relier les alertes à des règles Wazuh
• préparer une réponse active seulement après validation

• preuve attendue: produire du trafic web identifiable avec DVWA, Nikto ou Teler
• preuve attendue: collecter les logs Apache ou applicatifs utiles
• preuve attendue: enrichir ou filtrer les événements avec réputation IP ou règles adaptées

Points de vigilance sécurité

• bloquer une IP uniquement sur réputation externe
• oublier de vérifier le log Apache brut
• confondre scanner de lab et attaque applicative réelle

Commandes et fichiers du chapitre

• sudo apt install apache2
• sudo systemctl start apache2
• curl 127.0.0.1
• sudo netstat -ntaup
• sudo systemctl restart wazuh-agent
• sudo wget https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/alienvault_reputation.ipset -O /var/ossec/etc/lists/alienvault_reputation.ipset
• sudo echo "<hacker_ip>" >> /var/ossec/etc/lists/alienvault_reputation.ipset
• sudo wget https://wazuh.com/resources/iplist-to-cdblist.py -O /tmp/iplist-to-cdblist.py
• sudo /var/ossec/framework/python/bin/python3 iplist-to-cdblist.py /var/ossec/etc/lists/alienvault_reputation.ipset /var/ossec/etc/lists/blacklist-alienvault
• sudo chown wazuh:wazuh /var/ossec/etc/lists/blacklist-alienvault
• sudo rm -rf /var/ossec/etc/lists/alienvault_reputation.ipset
• sudo rm -rf iplist-to-cdblist.py

Liens utiles

• Dépôt Xavki tutorials-wazuh
• Playlist YouTube Wazuh Xavki
• Documentation officielle Wazuh
• Wazuh Quickstart
• Architecture Wazuh
• Wazuh agents
• Wazuh ruleset, decoders et rules
• Documentation complémentaire Wazuh
• Documentation complémentaire Wazuh
• Documentation complémentaire Wazuh
• 05-example-apache-logs-alienvault/slides.md

Liens internes conseillés

• Parcours Kubernetes si vous voulez relier Wazuh à la supervision de plateformes conteneurisées.
• Prometheus, Grafana et observabilité pour distinguer métriques, logs et alertes sécurité.
• RabbitMQ sur Kubernetes pour comparer supervision applicative, messaging et signaux de sécurité.

Pour poursuivre la progression, consultez aussi Wazuh 006 – File Integrity Monitoring et Who-Data.

FAQ

Wazuh est-il plutôt un SIEM ou un XDR ?

Wazuh couvre des usages SIEM comme la centralisation, la corrélation et l analyse de logs, mais aussi des usages XDR comme la détection endpoint, la réponse active, la conformité, le FIM, la sécurité conteneur et l intégration de sources externes.

Faut-il installer un agent partout ?

Pas forcément partout dès le début. Il faut prioriser les machines critiques, les serveurs exposés, les bastions, les workloads sensibles et les environnements de test. L agent apporte la visibilité endpoint, mais il faut gérer bruit, charge et configuration.

Pourquoi mes alertes Wazuh ne remontent-elles pas ?

Les causes courantes sont une source de log absente, un agent non connecté, un mauvais chemin dans la configuration, une règle non déclenchée, un filtre dashboard trop restrictif ou un événement qui n est pas décodé comme prévu.

Wazuh remplace-t-il Prometheus ou Grafana ?

Non. Wazuh est orienté sécurité, conformité et détection. Prometheus et Grafana sont orientés métriques, SLO, tableaux de bord techniques et observabilité. Les deux approches se complètent.

Conclusion

Cet épisode 5 ajoute une brique à la compréhension de Wazuh. La bonne méthode consiste à partir du signal brut, vérifier la collecte, lire les règles déclenchées, puis seulement interpréter l alerte dans un contexte de sécurité réel. Le dépôt Xavki donne le lab, la documentation Wazuh donne le cadre officiel, et le deep dive permet de transformer la démonstration en méthode de diagnostic.