Journal Centralisation des logs Windows vers Linux via syslog

Posté par (page perso) . Licence CC by-sa
21
12
jan.
2012

Intro

Lorsqu'on gère un parc de serveur qui comprend malheureusement des serveurs Windows, on souhaite centraliser leurs logs, voir même recevoir des alertes en fonction du contenu. C'est simple à faire sous Linux avec rsyslog, avec lequel je transmets les syslogs vers l'excellent Graylog2. Par contre dans le monde Windows il n'y a pas de serveur syslog natif. J'avais donc trouvé MonitorWare Agent un impressionnant logiciel propriétaire qui permet de définir des services qui vont lire n'importe quel type de logs, puis associer à ces services des ruleset qui vont déclencher une action comme faire suivre les logs vers un serveur syslog. L'interface graphique permet de créer un nombre de services et de rulesets impressionnants pour enchaîner des actions les plus tordus.
Le seul problème est le coût de la licence à environ 200€ par serveur, ce qui peut être bloquant.

NXLOG

Prêt à laisser tomber, j'ai finalement trouvé le logiciel libre nxlog qui permet de faire exactement la même chose, sans interface graphique mais ça nous fait pas peur. Après de nombreux tâtonnement et quelques mails sur la liste j'ai pu transmettre les logs d'une application qui rotate elle meme ses logs en donnant un nouveau nom au log en cours (gruik)... Cependant nxlog permet d'utiliser des wildcard sur les noms des fichiers (*.log par ex) et même d'être récursif en allant lire tous les logs dans chaque sous répertoire. Un processor transformer permet de formater le log selon la RFC syslog voulue.
La doc montre le workflow très poussé de nxlog qui permet des enchaînements vraiment tordu, genre intégrer un schéduler dans un module input, surveiller un fichier de log et le convertir en CVS vers un autre fichier xm_csv_example. Il intègre également un langage qui permet par exemple de tester une expression régulière sur un flux en entrée :

if $Message =~ /^Test (\S+)/ log_info("captured: " + $1);

Workflow

En entrée on choisi un input module (fichier, sgbd, syslog, tcp/udp, ..), puis un processor module qui va transformer ou filtrer les datas, puis un output module (sgbd, syslog, tcp/udp, file, ..) enfin via la directive route on enchaîne ces modules entre eux. Je n'ai que survolé les possibilités du soft, mais au vu de sa richesse et de sa licence GPL/LGPL je suis plutôt surpris de ne pas le trouver dans les dépôts debian/ubuntu.

Config basique fichiers de logs (*.log) -> serveur Graylog2 Linux (syslog)

Voici ma config qui fonctionne. Le serveur Windows communique avec Graylog2 sous Linux via OpenVPN. Pour aider au paramétrage j'ai lancé sur le Linux un tcpdump pour vérifier que les paquets arrivaient bien, avec la facility voulue :

tcpdump -i tap0 "udp port 514"

Le fichier de conf nxlog.conf

## This is a sample configuration file. See the nxlog reference manual about the
## configuration options. It should be installed locally and is also available
## online at http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.html

## Please set the ROOT to the folder your nxlog was installed into,
## otherwise it will not start.

define ROOT C:\Program Files\nxlog
# define ROOT C:\Program Files (x86)\nxlog

define CERTDIR %ROOT%\cert
define CONFDIR %ROOT%\conf
define LOGDIR %ROOT%\data

Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
LogLevel INFO


<Extension syslog>
    Module  xm_syslog
</Extension>

<Input in>
    Module  im_file
    File    "C:\monapp\log\\*.log" # lit tous les .log dans tous les sous répertoires !
    Exec    $Message = $raw_event;
    SavePos TRUE
    Recursive TRUE
</Input>

<Processor transformer>
    Module  pm_transformer        
    Exec        $SyslogFacilityValue = syslog_facility_value("local2");
    OutputFormat syslog_rfc3164
</Processor>

<Output out>
    Module      om_udp
    Host        10.8.0.1 # IP du serveur Linux sur lequel écoute graylog2 server
    Port        514
</Output>

<Route 1>
    Path        in => transformer => out
</Route>

  • # logs système windows

    Posté par (page perso) . Évalué à  3 .

    J'ai oublié de préciser que l'on peut aussi transmettre tous les logs systèmes Windows via ce module :

    <Input in2>
        Module im_mseventlog
    <Input>
    
    

    En numérotant les input on peut ainsi définir plusieurs routes :

    <Route 2>
        Path        in2 => transformer => out2
    </Route>
    
    

    Par contre bizarrement j'ai reçu tous les logs système du Windows daté au 31.12.2012 alors que sa date système est bonne, donc dans graylog2 je ne voyais plus les autres logs timestampé correctement :/

    http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

  • # Ben syslog quoi..

    Posté par (page perso) . Évalué à  4 .

    De toutes façons à part les BSOD y'a pas grand chose de natif sous Windows.
    Mais pourquoi ne pas avoir essayé le plus simple d'entre eux: http://syslog-win32.sourceforge.net/index.html
    Ou alors l'excellent syslog-ng: http://www.syslog.org/logged/running-syslog-ng-on-windows/

    • [^] # Re: Ben syslog quoi..

      Posté par (page perso) . Évalué à  3 .

      Il ne me semble pas avoir vu que ces serveurs syslog gèrent les wildcard (*.log) et la récursivité des répertoires, or c'est pour moi un impératif. Et nxlog est vraiment loin devant en features, mais je me trompe peut être.

      http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

      • [^] # Re: Ben syslog quoi..

        Posté par (page perso) . Évalué à  1 .

        Je ne suis pas certain de comprendre exactement ton histoire de wildcard. J'avais cru qu'il ne s'agissait que des logs du journal des événements (les logs Windows centralisés quoi), mais si tu veux récupérer de simples fichiers logs créés par une appli quelconque alors là effectivement syslog et consorts ne peuvent rien faire. A une époque je balançait tout vers un syslog-ng qui redirigeait vers une base Postgresql. Ensuite avec des triggers je créais tout ce que je voulais pour la supervision.
        Merci pour ton retour d'expérience en tous cas.

        • [^] # Re: Ben syslog quoi..

          Posté par (page perso) . Évalué à  4 .

          Mon problème est que j'ai une application proprio qui écrit des logs dans c:\app\log\app-"timestamp".log. Par rapport à un service Linux classique qui écrit toujours dans le même nom de fichier, genre /var/log/apache.log, cette app change régulièrement le nom de son fichier de log courant. D'ou le besoin de wildcard c:\app\log*.log pour lire les prochains fichiers créés.
          Enfin la wildcard est pratique si l'on ne veut pas faire un input file par fichier de log, il suffit de mettre /var/log/*.log avec Recursive TRUE pour que nxlog lise tous les logs dans tous les sous rep de /var/log/

          http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

  • # Bien sur que ca existe

    Posté par . Évalué à  1 .

    http://msdn.microsoft.com/en-us/library/windows/desktop/bb427443(v=vs.85).aspx

    You can subscribe to receive and store events on a local computer (event collector) that are forwarded from a remote computer (event source). The Windows Event Collector functions support subscribing to events by using the WS-Management protocol. For more information about WS-Management, see About Windows Remote Management.

    Sur ce, je retourne a mon hibernation.

    • [^] # Re: Bien sur que ca existe

      Posté par . Évalué à  6 .

      Sur ce, je retourne a mon hibernation.

      Ça sent le réveil là quand même :) Ça fait plaisir de voir que tu n'es pas mort.

      Quand à ta proposition. Après une trop rapide lecture en diagonale du lien sus-cité, l'outil que tu proposes permet de centraliser les logs entre serveurs Windows. Mais je n'ai pas l'impression que cela réponde vraiment à la problématique exprimé par l'auteur du journal.

  • # snare

    Posté par (page perso) . Évalué à  3 .

    J'utilise snare depuis des années, sans soucis : facile d'installation et d'utilisation

    réferences :

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.