NXLog : intégration avec Graylog

Contexte

NXLog collecte et envoie les logs. Graylog les reçoit, les indexe et permet de les exploiter. Cet article couvre la configuration côté Graylog pour recevoir les logs NXLog en GELF, et quelques pistes pour structurer les dashboards.

Créer l’input GELF TCP

Dans Graylog, aller dans System > Inputs et créer un nouvel input :

• Type : GELF TCP
• Port : 12201
• Bind address : 0.0.0.0
• Titre : NXLog - Windows Events

Démarrer l’input. Si les agents NXLog sont déjà configurés et que le réseau est ouvert, les premiers messages arrivent immédiatement.

Vérifier la réception

Dans Search, chercher les messages récents. Les champs GELF suivants doivent être présents :

• source : le hostname du serveur (champ GELF standard)
• EventID : l’EventID Windows (champ natif im_msvistalog)
• Channel : le journal d’origine (Security, System, Application, etc.)
• gl_role : le rôle configuré dans NXLog (dc01, srv-membre, etc.)
• gl_env : l’environnement (prod, preprod, etc.)

Si ces champs n’apparaissent pas, vérifier le bloc Output dans le nxlog.conf.

Extracteurs utiles

Les messages GELF envoyés par NXLog contiennent déjà les champs Windows (EventID, Channel, etc.), mais on peut ajouter des extracteurs Graylog pour enrichir les données :

Extraire le LogonType depuis le message

Pour les EventID 4624/4625, le corps du message contient le type d’ouverture de session. Un extracteur regex peut isoler cette valeur :

• Type : Regex
• Source field : message
• Regex : Logon Type:\s+(\d+)
• Store as field : logon_type

Les valeurs courantes :

Extraire le nom d’utilisateur cible

• Type : Regex
• Source field : message
• Regex : Account Name:\s+(\S+)
• Store as field : target_account

Streams

Les streams permettent de séparer les logs par catégorie. Créer au minimum :

• Windows - Security : rule Channel = Security
• Windows - System : rule Channel = System
• Windows - DC : rule gl_role contains dc

Les streams facilitent les recherches et permettent d’appliquer des règles de rétention différentes (garder les logs Security plus longtemps que les logs System par exemple).

Alertes de base

Quelques alertes à mettre en place dès le départ :

Effacement du journal Security

• Condition : EventID = 1102
• Sévérité : haute
• Pourquoi : un attaquant qui efface les logs essaie de couvrir ses traces

Échecs d’authentification en masse

• Condition : EventID = 4625, count > 50 sur 5 minutes
• Sévérité : moyenne
• Pourquoi : brute force ou password spraying

Création de service

• Condition : EventID = 4697
• Sévérité : moyenne
• Pourquoi : un service inconnu peut indiquer une persistance malveillante

Modification de la stratégie d’audit

• Condition : EventID = 4719
• Sévérité : haute
• Pourquoi : un attaquant peut désactiver l’audit pour devenir invisible

Dashboard de base

Un dashboard utile pour commencer :

• Widget 1 : nombre total d’événements par serveur (source) - histogramme
• Widget 2 : top 10 des EventID les plus fréquents - bar chart
• Widget 3 : échecs d’authentification (4625) par source IP - tableau
• Widget 4 : connexions avec privilèges (4672) par compte - tableau
• Widget 5 : derniers événements critiques (1102, 4719, 4697) - liste

Rétention

Configurer la rétention dans System > Indices :

• Index Security : rétention longue (90 jours minimum, 365 si possible)
• Index System/Application : rétention courte (30 jours)

Le volume dépend du nombre de serveurs et du filtrage NXLog. Avec un filtrage correct côté agent, un DC génère environ 5-15 Go/mois de logs Security indexés.

Résumé de la série

Cette série d’articles couvre la chaîne complète de centralisation des logs Windows :

1. Audit des événements Windows : configurer ce que Windows génère
2. NXLog : installation et présentation : comprendre l’outil de collecte
3. NXLog : configuration sur un DC : collecte complète pour un contrôleur de domaine
4. NXLog : configuration sur un serveur membre : collecte adaptée avec variantes par rôle
5. NXLog : intégration avec Graylog : réception, exploitation et alertes