Skip to main content

NXLog : configuration sur un serveur membre

Contexte

Un serveur membre n’a pas les mêmes besoins qu’un contrôleur de domaine. Pas de Kerberos, pas de réplication AD, pas de gestion de comptes. Le filtrage Security est donc plus simple et orienté vers la détection d’activités suspectes locales.

La configuration de base ci-dessous convient à la plupart des serveurs membres (fichiers, applications, etc.). On verra ensuite comment l’adapter selon le rôle du serveur.

Configuration de base

Panic Soft

define ROOT     C:\Program Files (x86)\nxlog
define LOGDIR   %ROOT%\data
define LOGFILE  %LOGDIR%\nxlog.log

LogFile   %LOGFILE%
Moduledir %ROOT%\modules
CacheDir  %ROOT%\data
Pidfile   %ROOT%\data\nxlog.pid
SpoolDir  %ROOT%\data

<Extension _gelf>
    Module xm_gelf
</Extension>

<Input in_system>
    Module im_msvistalog
    Query <QueryList>\
      <Query Id="0">\
        <Select Path="System">*</Select>\
      </Query>\
    </QueryList>
    ReadFromLast TRUE
    SavePos TRUE
</Input>

<Input in_application>
    Module im_msvistalog
    Query <QueryList>\
      <Query Id="0">\
        <Select Path="Application">*</Select>\
      </Query>\
    </QueryList>
    ReadFromLast TRUE
    SavePos TRUE
</Input>

<Input in_setup>
    Module im_msvistalog
    Query <QueryList>\
      <Query Id="0">\
        <Select Path="Setup">*</Select>\
      </Query>\
    </QueryList>
    ReadFromLast TRUE
    SavePos TRUE
</Input>

<Input in_security>
    Module im_msvistalog
    Query <QueryList>\
      <Query Id="0">\
        <Select Path="Security">*</Select>\
      </Query>\
    </QueryList>

    Exec if not defined($EventID) drop();

    # Filtrage Security pour un serveur membre
    Exec $keep = ( \
        # Authentification
        $EventID == 4624 or $EventID == 4625 or $EventID == 4634 or \
        $EventID == 4648 or \
        $EventID == 4672 or \
        # Creation de processus et services
        $EventID == 4688 or \
        $EventID == 4697 or \
        # Taches planifiees
        $EventID == 4698 or $EventID == 4699 or $EventID == 4700 or $EventID == 4701 or $EventID == 4702 or \
        # Strategie d'audit et effacement de logs
        $EventID == 4719 or \
        $EventID == 1102 \
    );

    Exec if $keep != TRUE drop();

    ReadFromLast TRUE
    SavePos TRUE
</Input>

<Output out_gelf>
    Module      om_tcp
    Host        graylog_server
    Port        12201
    OutputType  GELF_TCP

    Exec $gl_role = "srv-membre";
    Exec $gl_env  = "prod";
</Output>

<Route r_base>
    Path in_system, in_application, in_setup, in_security => out_gelf
</Route>

Explication du filtrage

Par rapport à la configuration DC, on a retiré :

  • Les événements de gestion de comptes/groupes (4720-4757) : les comptes sont gérés sur le DC
  • Les événements Kerberos (4768-4776) : pas de KDC sur un serveur membre
  • Les modifications AD (5136-5141) : pas de base NTDS
  • La modification de GPO (4739) : se détecte sur le DC

On garde :

  • 4624 / 4625 / 4634 : qui se connecte sur cette machine, et les échecs
  • 4648 : utilisation de RunAs ou d’identifiants explicites
  • 4672 : connexions avec des privilèges administrateur
  • 4688 : création de processus (détection de commandes suspectes)
  • 4697 : installation de services (persistance)
  • 4698-4702 : tâches planifiées (persistance)
  • 4719 : modification de la stratégie d’audit locale
  • 1102 : effacement du journal Security

Adapter selon le rôle

Serveur de fichiers

Ajouter les accès aux partages SMB :

# Ajouter dans la liste $keep :
        $EventID == 5140 or $EventID == 5145 or \
  • 5140 : accès à un partage réseau
  • 5145 : accès détaillé à un fichier via un partage (utile pour détecter les ransomwares qui parcourent les partages)

Note : l’audit d’accès aux objets doit être activé dans la GPO pour que ces événements soient générés.

Serveur RDS (Bureau à distance)

Ajouter le channel TerminalServices :

<Input in_rds>
    Module im_msvistalog
    Query <QueryList>\
      <Query Id="0">\
        <Select Path="Microsoft-Windows-TerminalServices-LocalSessionManager/Operational">*</Select>\
      </Query>\
    </QueryList>
    ReadFromLast TRUE
    SavePos TRUE
</Input>

Et l’ajouter dans la route :

<Route r_base>
    Path in_system, in_application, in_setup, in_security, in_rds => out_gelf
</Route>

Ce channel contient les connexions/déconnexions RDP avec les IP sources, ce qui est plus lisible que le 4624 avec LogonType 10.

Serveur IIS

Ajouter le channel IIS :

<Input in_iis>
    Module im_msvistalog
    Query <QueryList>\
      <Query Id="0">\
        <Select Path="Microsoft-Windows-IIS-Logging/Logs">*</Select>\
      </Query>\
    </QueryList>
    ReadFromLast TRUE
    SavePos TRUE
</Input>

On peut aussi collecter les fichiers de log IIS directement avec le module im_file si on préfère le format W3C.

Déploiement

Pour déployer la configuration sur plusieurs serveurs, on peut :

  • Copier le nxlog.conf via GPO (préférences de fichier)
  • Utiliser un outil de gestion de configuration (Ansible, etc.)
  • Scripter le déploiement en PowerShell

La seule valeur à adapter par serveur est $gl_role dans le bloc Output, pour identifier chaque machine dans Graylog.

Vérification

PS> Restart-Service nxlog
PS> Get-Content "C:\Program Files (x86)\nxlog\data\nxlog.log" -Tail 20

Si tout est bon, les messages apparaissent dans Graylog avec les champs standard (source, EventID, Channel) et les champs personnalisés (gl_role, gl_env) renseignés.