Ceci est une ancienne révision du document !
Configuration de la collecte de logs avec RSyslog
Introduction
Ce tutoriel a pour but la mise en œuvre d'une collecte de logs sous Linux via le protocole Syslog.
RSyslog est un outil client-serveur permettant d'envoyer et recevoir des logs, généralement intégré par défaut aux distributions Linux modernes. On le configure par le biais du fichier /etc/rsyslog.conf que ce soit côté client ou côté serveur.
Topologie du LAB
Dans ce tutoriel, nous aurons 2 machines sous Debian 11. L'une enverra ses logs (le client), et l'autre les recevra (le serveur) :
Pré-requis
Dans le cadre de ce tutoriel, nous aurons seulement besoin de 2 machines sous Linux (Debian, CentOS, ou RHEL de préférence) sur le même réseau IP.
Mise en place
Configuration côté serveur
Ouvrir le fichier /etc/rsyslog.conf avec un éditeur de texte pour le modifier :
nano /etc/rsyslog/conf
Décommenter ou ajouter les instructions suivantes pour activer la réception des logs en UDP :
module(load="imudp") input(type="imudp" port="514")
Pour garantir l'intégrité des paquets, il est néanmoins plus intéressant d'activer la réception des logs en TCP :
module(load="imtcp") input(type="imtcp" port="514")
Maintenant, on va définir l'emplacement de destination des logs sur le serveur ainsi que la façon dont ils seront nommés :
$template remote-incoming-logs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" *.* ?remote-incoming-logs
Ci-dessus, on indique que les logs reçus par le serveur seront stockés dans un sous-répertoire spécifique de /var/log en fonction de la machine émettrice. La variable %HOSTNAME% correspond au nom du client qui envoie les logs et %PROGRAMNAME%, à celui du programme qui produit les logs.
Enfin, pour sécuriser davantage le système, il est possible de whitelister les hôtes, les réseaux, ou les domaines autorisés à envoyer des logs au serveur (une ligne par protocole) :
$AllowedSender UDP, 127.0.0.1/24, 192.168.1.0/24, *.nocterie.local $AllowedSender TCP, 127.0.0.1/24, 192.168.1.20/24, *.nocterie.local
Une fois ceci fait, on peut activer le service rsyslog au démarrage de la machine et le lancer :
systemctl enable rsyslog systemctl start rsyslog
On peut vérifier s'il y a des erreurs de configuration grâce à la commande suivante :
systemctl status rsyslog
Le service doit être actif et aucune erreur ne doit ressortir pour passer à la suite.
On peut également vérifier que la machine est bien en écoute sur le port 514 en TCP et en UDP :
ss tunlp | grep 514
Ce qui donne :
Configuration côté client
Passons sur la machine cliente. Le paramétrage de l'envoi des logs se fait également par le biais du fichier /etc/rsyslog.conf :
nano /etc/rsyslog.conf
Commençons par lui indiquer l'adresse du serveur (ici 192.168.1.202).
Pour l'envoi des logs en UDP il faut l'écrire de cette façon :
*.* @192.168.1.202:514
Commençons par lui indiquer l'adresse du serveur (ici 192.168.1.202).
Pour TCP, c'est légèrement différent :
*.* @@192.168.1.202:514
Puis, pour éviter les pertes de logs, on peut activer la mise en cache des évènements :
$ActionQueueFileName queue $ActionQueueMaxDiskSpace 1g $ActionQueueSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1
Dans l'exemple ci-dessus, le client pourra mettre en cache jusqu'à 1gb d'évènements qui seront envoyés lorsque le serveur sera à nouveau joignable.
Enfin, activer le service au démarrage et le lancer comme pour le serveur :
systemctl enable rsyslog systemctl start rsyslog
Vérifications
Afin de s'assurer que la collecte de logs est fonctionnelle, il suffit de regarder le contenu du répertoire où sont stockés les évènements sur le serveur. Dans notre cas /var/log :
ls /var/log
On y trouve bien un sous-répertoire debian01 qui correspond à notre client :
En regardant ce qu'il contient, on constate que des fichiers de log ont déjà été reçus en provenance du client :
ls /var/log/debian01 -l
Pour visionner l'arrivée des évènements en direct dans un fichier de log, utiliser la commande suivante :
tail -f /var/log/debian01/fichier.log
Remplacer fichier.log par le nom du fichier à lire
Ici le fichier surveillé est systemd.log, qui retrace les démarrages et les arrêts de services sur la machine cliente. On peut y voir que le service Bluetooth vient d'être redémarré (en quasi instantané) :
