Un échec SSH, une rafale de 404 Nginx et un redémarrage de conteneur peuvent être sans rapport. Un SIEM utile conserve assez de contexte pour les relier, sans remplir son stockage de chaque requête de supervision.
1. Définir l'architecture et le budget de collecte
Le pilote suppose une installation Wazuh fonctionnelle et compatible : agents Linux → manager pour décodage et règles → indexer Wazuh → dashboard. Utilisez les composants et versions supportés ensemble, pas un OpenSearch arbitraire substitué à l'indexer. Protégez les transports, certificats, interfaces et comptes ; gardez indexer et dashboard sur un réseau d'administration.
Prévoyez un agent de test, Nginx, Docker Compose, rsyslog, un accès sudo, des sauvegardes de configuration et des horloges synchronisées. Ici, Linux écrit ses authentifications dans /var/log/auth.log ; adaptez si votre distribution utilise secure ou uniquement journald.
timedatectl statussudo systemctl status wazuh-agent --no-pagersudo journalctl -u docker --since '-1 hour'docker compose pssudo du -sh /var/log/nginx /var/log/auth.logMesurez événements par seconde, octets par jour et délai entre événement et indexation. Estimez le stockage à partir d'une journée représentative, puis incluez réplication et marge. Définissez une rétention par besoin d'enquête, avec suppression automatique et sauvegardes testées.
Conservez hôte, service, environnement, heure UTC, résultat, IP client fiable et identifiant de requête. Ne collectez pas tokens, cookies, corps de requêtes ni paramètres d'URL contenant des secrets. Une IP issue d'un proxy non approuvé est une donnée falsifiable.
2. Raccorder une source à la fois
Pour une application Compose de test, un pilote syslog évite de lire aveuglément tout le stockage interne Docker. Fragment à fusionner dans le service concerné :
services: app: logging: driver: syslog options: syslog-address: "unixgram:///dev/log" syslog-format: "rfc3164" tag: "shop-app"Sur l'hôte, créez le répertoire de destination avec des droits compatibles avec rsyslog, puis une règle dédiée dans /etc/rsyslog.d/35-shop.conf :
if $programname == 'shop-app' then { action(type="omfile" file="/var/log/containers/shop.log") stop}Validez avant de recharger :
sudo rsyslogd -N1sudo systemctl restart rsyslogdocker compose configLe changement de pilote ne modifie pas un conteneur existant ; sa recréation nécessite une fenêtre ou un déploiement progressif. Ce choix peut modifier le comportement de docker logs : vérifiez le secours local avant production.
Dans le ossec.conf de l'agent, à l'intérieur de ossec_config, ajoutez seulement les sources absentes :
<localfile> <location>/var/log/auth.log</location> <log_format>syslog</log_format></localfile><localfile> <location>/var/log/nginx/access.log</location> <log_format>apache</log_format></localfile><localfile> <location>/var/log/containers/shop.log</location> <log_format>syslog</log_format></localfile><localfile> <location>/var/log/shop/security.json</location> <log_format>json</log_format></localfile>L'exemple Nginx suppose un format combined compatible ; un format JSON demande log_format=json et des tests de décodage. Le fichier applicatif contient un objet JSON par ligne, pas un tableau. Le message du conteneur enveloppé en syslog peut nécessiter un décodeur propre ; ne supposez pas que les champs JSON internes seront automatiquement normalisés.
Sur le manager, ajoutez un fichier /var/ossec/etc/rules/shop_rules.xml, après vérification que ces identifiants sont libres :
<group name="shop,"> <rule id="100510" level="5"> <decoded_as>json</decoded_as> <field name="event">^auth_failed$</field> <description>Shop authentication failure</description> </rule> <rule id="100511" level="10" frequency="8" timeframe="120"> <if_matched_sid>100510</if_matched_sid> <same_field>client_ip</same_field> <description>Repeated authentication failures</description> </rule></group>Ce seuil est une proposition de départ, à tester avec votre version et le comportement réel du compteur. Le champ client_ip doit être présent et issu d'une source fiable.
3. Valider une alerte, puis étendre
Sur le manager, lancez sudo /var/ossec/bin/wazuh-logtest et soumettez plusieurs lignes synthétiques :
{"event":"auth_failed","client_ip":"192.0.2.8"}Contrôlez le décodeur, les champs, la règle simple puis la corrélation. Rechargez le manager et l'agent selon la procédure de votre installation seulement après validation. Émettez ensuite un événement applicatif de test par le vrai chemin de collecte et retrouvez-le dans le dashboard ; logtest seul ne prouve pas le transport.
Ajoutez progressivement : authentification réussie après échecs, nouvelle origine d'administration, nombreuses routes 404 distinctes par IP, rafales de 5xx par service, modifications de comptes et redémarrages inattendus. Les seuils de scan doivent exclure les sondes connues sans masquer tout leur trafic.
Surveillez agents silencieux, pertes de file, décalage d'horloge, erreurs de parsing, délai d'ingestion, disque de l'indexer et alertes sans propriétaire. Réduisez les health checks au niveau de la source, mais conservez les événements d'authentification et de modification. N'activez pas l'archivage massif de tous les événements par défaut.
Pour le rollback, restaurez les fichiers précédents, retirez uniquement les nouveaux blocs et règles, puis rechargez. Revenir au pilote Docker précédent exige une nouvelle recréation contrôlée. Préservez les logs déjà collectés. En production, déployez par petits groupes : collecte et indexation consomment CPU, I/O et réseau, et une saturation de logs ne doit pas entraîner une panne applicative.
Sources : Wazuh, collecte des logs, Wazuh, règles personnalisées.