Centralisez vos logs avec Rsyslog

I. Présentation

La centralisation des logs de plusieurs serveurs sur un seul peut présenter un grand intérêt au niveau de la sécurité au sein d'un système d'information. En effet, il est plus facile pour des outils d'analyse de logs de comparer, lire et scanner des fichiers se situant sur un seul et unique serveur plutôt que de le faire à distance ou via des agents distants. De plus en cas de crash serveur, vous serez capable de récupérer les erreurs et actions menées sur votre serveur avant que celui-ci ne crash, facilitant ainsi la remise en activité de celui-ci et sa sécurisation future.

Par défaut sur la plupart des Linux modernes, l'outil de gestion des logs est Rsyslog, c'est celui-ci que nous allons utiliser dans ce tutoriel. Nous travaillerons sur deux machines sous Debian 7, l'un faisant office de serveur, l'autre de "client" qui enverra ses logs sur le serveur. Dans les deux cas, le fichier de configuration à modifier est toujours "/etc/rsyslog.conf". On peut néanmoins  en mettre dans "/etc/rsyslog.d/" puis faire un "include" dans le fichier de configuration principale pour importer.

II. Configuration du serveur

Pour le serveur, il faut simplement paramétrer le serveur pour qu'il accepte les logs venant de l'extérieur en ouvrant le port adéquate, on va pour l'instant par soucis de simplicité ouvrir le port UDP (514). Pour cela, on va décommenter les deux lignes suivantes :

$ModLoad imudp
$UDPServerRun 514

On pourra alors redémarrer le service rsyslog :

service rsyslog restart

Pour vérifier que notre serveur est bien à l'écoute, on peut effectuer la commande suivante :

netstat -npul

On verra alors notre port 514 ouvert en UDP :

serveur rsyslog linux
Port 514 ouvert en UDP sur notre serveur Rsyslog

III. Configuration du client

Au niveau du client, il faut aller dans ce même fichier puis, pour rediriger tous les logs sur le serveur, ajouter cette ligne à la fin du fichier :

*.* @IP_SERVER:514

Note : Le "@" doit figurer dans la ligne

On va alors redémarrer notre service rsyslog :

service rsyslog restart

Puis on pourra générer des logs (redémarrer un service quelconque par exemple) et aller voir s'ils figurent sur le serveur rsyslog. Par défaut comme nous l'avons fait, les logs des clients se situeront dans le même fichier que les logs du serveur donc par exemple dans le "/var/log/syslog" du serveur. Vous verrez simplement que le nom de l'hôte ayant généré la ligne de log n'est pas celui du serveur mais celui du client.

III TCP/UDP

Nous avons précédemment configuré notre client et notre serveur pour échanger en utilisant le protocole de transport (couche 4) UDP. Brièvement, UDP permet un échange unique pour transmettre un paquet, c'est un protocole qui ne cherche pas à se synchroniser, à suivre l'état des paquets ou des échanges entre deux éléments actifs. Au contraire, TCP va chercher à savoir pour chaque paquet si celui-ci a bien été reçu par le correspondant, ce qui engendre des paquets supplémentaires par rapport à UDP. TCP est ainsi capable de savoir si un échange ou une information n'a pas été reçu et de la retransmettre au besoin, ce que ne fait pas UDP.

Tout cela pour souligner que dans notre cas, les échanges TCP ont un désavantage qu'il faut prendre en compte par rapport à l'UDP. En effet, le TCP va générer plus d'échanges (et donc de consommation de ressource) par rapport à UDP mais va vous assurer que les informations reçu le sont dans le totalité. Il y a donc un choix à faire qui dépend de vos ressources disponibles et du nombre de client et d'informations gérées par votre serveur. Pour mettre les échanges en mode TCP, il faut recommenter ces lignes dans le fichier de configuration serveur, à noter que les deux méthodes peuvent cohabiter si on les met sur des ports différents, par exemple :

Serveur Rsyslog
Configuration du serveur Rsyslog pour recevoir les logs des clients en UDP sur le port 514 et en TCP sur le port 1514

Sinon, il faudra commenter les deux lignes supérieures. Côté client, il faut ajouter cette ligne dans la configuration pour que les échanges s'effectuent en TCP :

*.* @@IP_SERVEUR:1514

Note : Les @@ doivent figurer dans la ligne de commande, le fait qu'il y en ai deux indique que les échanges se feront en TCP.

On peut laisser également deux lignes pour indiquer que les logs seront envoyés une fois en TCP et une fois en UDP. Cela présente peu d’intérêt mais permet de comprendre que l'on peut également envoyer nos logs sur plusieurs serveurs différents si on change l'IP d'une des deux lignes. On va ensuite redémarrer le serveur ainsi que le client si besoin :

service rsyslog restart

 IV. Rediriger ou copier selon la facilitie ou la priorité

Sous Linux quand on parle de gestion de logs, les facilites sont des catégories dans lesquelles les logs vont se "ranger" afin de mieux les archiver et les trier. Parmi ces facilites, on retrouve par exemple :

  • auth : Utilisé pour des évènements concernant la sécurité ou l'authentification à travers des applications d'accès (type SSH)
  • authpriv : Utilisé pour les messages relatifs au contrôle d'accès
  • daemon : Utilisé par les différents processus systèmes et d'application
  • kern : Utilisé pour les messages concernant le kernel
  • mail :  Utilisé pour les évènements des services mail
  • user : Facilitie par défaut quand aucune n'est spécifiée
  • local7 : Utilisé pour les messages du boot
  • * : Désigne toutes les facilities, par soucis de simplicité c'est ce que nous avons spécifié lors de notre première règle de redirection des logs un peu plus haut
  • none : Désigne aucune facilites

En plus de ces facilites, nous retrouvons pour chaque facilities un niveau de gravité (appelé Priorité) qui va du plus grave à la simple information :

  • Emerg : Urgence, système inutilisable
  • Alert : Alerte. Intervention immédiate nécessaire
  • Crit : Erreur système critique
  • Err : Erreur de fonctionnement
  • Warning :  Avertissement
  • Notice : Évènement normaux devant être signalé
  • Info : Pour information
  • Debug : Message de debogage

On retrouve alors plusieurs façons de spécifier les logs qui nous intéressent et donc ceux que l'on va rediriger. Par exemple si l'on chercher à rediriger vers notre serveur de logs 192.168.19.145 uniquement les messages critiques et supérieurs concernant les mails sur le port UDP 514, on ajoutera la ligne suivante :

mail.err @192.168.19.145:514

On peut également rediriger tous les logs mails :

mail.* @192.168.19.145:514

On peut également saisir en une ligne plusieurs types de facilities et de priorité, on trouve pas exemple dans le fichier de configuration par défaut des lignes comme celles-ci :

*.=debug;\
       auth,authpriv.none;\
       news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
       auth,authpriv.none;\
       cron,daemon.none;\
       mail,news.none          -/var/log/messages

On voit ici que toutes les priorités debug sont redirigées vers le fichier "/var/log/debug" et que toutes les priorités info,notice et warn seront dans "/var/log/messages". Pour que ces filtres soient redirigés vers le serveur de logs, il suffit de spécifier l'IP du serveur ainsi que son port comme fait plus haut à la place du nom du fichier.

V. Rediriger les logs vers un dossier/fichier par host

On peut également, pour faciliter la hiérarchisation et l'archivage de nos logs lorsque l'on a un grand nombre de client Rsyslog utiliser une arborescence avec un dossier/fichier par hôte plutôt que de mettre tous les logs dans le même fichier que le serveur de logs. On va pour cela utiliser une template que nous mettrons après le bloc "RULES" dans le fichier de configuration du serveur :

$template syslog,"/var/log/clients/%fromhost%/syslog.log"

On va ensuite appliquer ce template à tous les logs entrants :

*.* ?syslog

Il nous suffira ensuite de redémarrer notre service rsyslog puis de générer des logs depuis les clients. On se retrouvera alors avec un dossier "/var/log/clients/" contenant un dossier par IP/nom client et contenant respectivement un fichier "syslog.log" avec les logs de chaque client respectif, ce qui simplifie la recherche d'information dans les logs d'un client précis

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Mickael Dorigny

Fondateur d'IT-Connect.fr et d'Information-security.fr. Auditeur sécurité chez Amossys.

    mickael a publié 475 articles sur IT-Connect.See all posts by mickael

    20 réactions sur “Centralisez vos logs avec Rsyslog

    • 12/07/2014 à 04:07
      Permalink

      Merci ! Le tuto fonctionne parfaitement chez moi !!! Testé avec comme serveur un Raspberry Pi (Raspbian), et comme clients 2 Ubuntu, 18 serveurs Debian (6 et 7 mélangés), 1 Ubuntu-Server et quelques autres équipements pour un total de 27 clients sur le même serveur. J’ai laissé en UDP vu le trafic que cela pourrait occasionner. Merci encore pour ce bon tuto, je le recommanderai à coup sûr!

      Répondre
    • 11/09/2014 à 21:22
      Permalink

      Bonjour,
      J’aurais une petite question :
      J’aimerais effectuer les memes procedures que ci dessus .. càd un serveur log regoupant tous mes log de serveurs dans 1 (un serveur linux) mais parmis ceux-ci il y a des serveurs windows 2008R2 et 2012R2 dont je voudrais egalement transferer les log vers mon « serveur LOg Linux  » .. est il possible de faire cela ?
      Merci

      Répondre
      • 11/09/2014 à 21:45
        Permalink

        Bonjour,

        Pour obtenir de l’aide, veuillez utiliser notre forum SVP afin que les membres vous viennent en aide.
        Pensez à décrire au maximum votre problème/demande.

        Merci.
        Florian

        Répondre
    • Ping : AdminRezo | Vos logs centralisés dans une page Web

    • 29/12/2014 à 11:37
      Permalink

      salut merci pour le tuto mais j’aimerai savoir car j’ai un probéme ,
      j’ai un serveur de centralisation et d’autre serveur client je recois bien les logs de touts les clients mais les noms des logs et le premiers octect de l’adresse ip =213 mais du coups touts les clients commencent par 213 en adresse ip donc pourrrais tu me dire comment corriger cela .

      Répondre
    • 01/03/2016 à 08:52
      Permalink

      bonjour je souhaiterais faire la même manipulation avec un os ipfire et une debian. Mais l’os ipfire ne supporte plus le rsyslog mais syslog-ng. Comment dois-je procéder pour réaliser la même configuration d’export de logs vers la machine sous debian.

      Merci d’avance.

      Répondre
    • 23/03/2016 à 10:11
      Permalink

      Salut, comment je pourrai faire pour remplacer l’ip de la machine par un nom, au niveau du template en tout dernier, car avec un mv cela ne marche pas, a chaque reboot, un nouveau fichier avec l’adresse ip de mon client se recrée pour stocker les log, et ne se dirige pas vers l’ancien fichier que j’ai renommer ?

      Répondre
      • 23/03/2016 à 12:52
        Permalink

        Bonjour,

        Si le fichier est renommé, il est normal qu’un autre soit recréé car rsyslog ne peut pas savoir que le fichier qu’il utilisais à simplement changé de nom. Je te conseils d’essayer un lien symbolique entre le fichier nommé avec l’iP et le fichier que tu souhaites créer avec le nom de machine.

        Je ne sais pas s’il y a un moyen permettant de créer le fichier directement avec son nom d’hôte. A voir si, dans la résolution DNS de ta machine ou ton fichier /etc/hosts (coté serveur rsyslog), la machine distante peut déjà être joignable via son nom DNS.

        Répondre
    • 06/04/2016 à 11:11
      Permalink

      salut,

      je voulais savoir si on peut rediriger les logs reçu sur notre rsyslog vers une solution Siem tel que ossim?
      si oui comment faire ??

      en gros :

      equipement —> Rsyslog –> ossim

      Répondre
    • 02/05/2016 à 13:29
      Permalink

      Bonjour ,

      j’ai configuré tous les local de (0 à 7) pour 8 switchs et ça marche très bien mais il me reste deux autres switchs à configurer .

      le nombre max pour les local facility est 8

      Comment ajouter New Facility pour les switchs qui restent ?

      Répondre
    • 24/05/2016 à 15:06
      Permalink

      bonjour je rencontre un problème lorsque je tape /etc/rsyslog.conf dans la machine cliente je ne trouve pas les règles

      Répondre
    • 11/07/2016 à 15:08
      Permalink

      Bonjour Mr Mickael je un petit soucis je suis etudiant e terminal mon sujet traite sur l’itinerance de profil quand j’utilise le profil itinerant de windows ou samba est ce que ce possible de voir mon profil sur linux ou windows ou vice versa ????????????????????????????????????????????????????????????

      Répondre
    • 22/08/2016 à 12:13
      Permalink

      Bonjour,

      le client nxlog envoi bien les logs vers le serveur rsyslog…
      mais problème les logs ton crypté en hexa alors que sur le serveur windows 2012 ils sont bien en ascii… pourrais-je avoir votre aide svp ? Merci

      Cordialement,

      Said

      Répondre
    • 25/12/2016 à 15:58
      Permalink

      Pour conserver vos logs, vos journaux d’événements ou vos données de connexion, en toute tranquillité et en toute sécurité, utilisez la solution de log management LogSanctuary : https://www.logsanctuary.com. Les données sont hébergées en France et vous respectez les durées de conservation et de rétention.

      Répondre
    • 08/02/2017 à 10:22
      Permalink

      Bonjour,

      Synthétique, précis et efficace.
      En moins de 30 minutes, je redirige, en triant, les logs de toutes mes vm.

      Merci beaucoup

      Répondre
    • 06/04/2017 à 15:33
      Permalink

      Bonjour,

      Merci beaucoup pour ce guide et la vidéo associées.

      Cependant, un question me vient.
      => Les log cron sont très verbeux et j’aimerai pouvoir ne pas les envoyer sur le serveur syslog distant. Je n’arrive pas à trouver la bonne syntaxe.
      J’ai bien essayé de faire
      *.*;cron.none -@hostname:514 mais cette syntaxe n’est pas bonne.

      Auriez-vous une idée.

      Merci d’avance

      Répondre
    • 10/04/2017 à 14:53
      Permalink

      Bonjour,

      Comment récupérer les log Windows, y ait-il un tuto détails comme celui là

      Merci comme même c’est super tuto

      Répondre

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *