====== 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) :

{{ ::rsyslogtutotopo.png?400 |Architecture du lab : client et serveur Rsyslog}}
===== 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.
===== Instructions =====

==== Configuration côté serveur ====

Ouvrir le fichier **/etc/rsyslog.conf** avec un éditeur de texte pour le modifier :

<code>nano /etc/rsyslog.conf </code>

Décommenter ou ajouter les instructions suivantes pour activer la réception des logs en UDP :

<code>module(load="imudp")
input(type="imudp" port="514")</code>

Pour garantir l'intégrité des paquets, il est néanmoins plus intéressant d'activer la réception des logs en TCP :

<code>module(load="imtcp")
input(type="imtcp" port="514")</code>

Maintenant, on va définir l'emplacement de destination des logs sur le serveur ainsi que la façon dont ils seront nommés :
<code>$template remote-incoming-logs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?remote-incoming-logs</code>

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.

:?: Par défaut, si rien n'est paramétré, les logs sont stockés dans le répertoire ''/var/log/messages'' du serveur.

On peut aussi ajouter des exceptions à la règle. Par exemple, pour envoyer tous les journaux dans **/var/log/** sauf ceux provenants de la machine **debian03** (envoyés alors dans ''/var/log/messages'') :
<code>:source, !isequal, "debian03" *.* ?remote-incoming-logs</code>

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) :

<code>$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 </code>

:?: Il peut y avoir plusieurs hôtes, réseaux, où domaines par ligne. 

Une fois ceci fait, on peut activer le service rsyslog au démarrage de la machine et le lancer :
<code>systemctl enable rsyslog
systemctl start rsyslog </code>

On peut vérifier s'il y a des erreurs de configuration grâce à la commande suivante :
<code>systemctl status rsyslog</code>

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 :

<code>ss tunlp | grep 514</code>

Ce qui donne :

{{::rsyslogtuto1.png?800|Vérification que la machine écoute bien sur le port 514 en TCP et en UDP}}

==== 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** :

<code>nano /etc/rsyslog.conf</code>

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 :

<code>*.* @192.168.1.202:514</code>

Commençons par lui indiquer l'adresse du serveur (ici 192.168.1.202). 

Pour TCP, c'est légèrement différent :

<code>*.* @@192.168.1.202:514</code>

Puis, pour éviter les pertes de logs, on peut activer la mise en cache des évènements : 
<code>
$ActionQueueFileName queue
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionQueueType LinkedList
$ActionResumeRetryCount -1
</code>

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 :

<code>systemctl enable rsyslog
systemctl start rsyslog </code>

==== 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** :

<code>ls /var/log</code>

On y trouve bien un sous-répertoire **debian01** qui correspond à notre client :
{{::rsyslogtuto2.png?800|Contenu du répertoire /var/logs}}

En regardant ce qu'il contient, on constate que des fichiers de log ont déjà été reçus en provenance du client :

<code>ls /var/log/debian01 -l</code>

{{::rsyslogtuto3.png?550|Les fichiers de log reçus depuis la machine debian01}}

Pour visionner l'arrivée des évènements en direct dans un fichier de log, utiliser la commande suivante :

<code>tail -f /var/log/debian01/fichier.log</code>

:!: 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é) :

{{::rsyslogtuto4.png?600|Contenu du fichier systemd.log du client en direct}}

===== Sources =====

[[https://www.linuxtechi.com/setup-rsyslog-server-on-debian/|Configuration de rsyslog pour Debian 11]]

[[https://www.linuxtricks.fr/wiki/rsyslog-centralisation-des-logs-sous-linux|Ancienne procédure de configuration rsyslog (debian 7) ]]