Centraliser et exporter les journaux Linux avec rsyslog vers un serveur de logs distant¶

Contexte¶

Quand on gère plusieurs serveurs (web, base de données, pare-feu…), chaque machine conserve ses propres journaux dans /var/log/. En cas d'incident — une intrusion, un service qui tombe, une saturation disque — il faut se connecter à chaque machine pour reconstituer le scénario. C'est lent, et les attaquants savent effacer leurs traces localement.

La bonne pratique, recommandée notamment par l'ANSSI, est la centralisation des journaux : expédier en temps réel les logs vers un serveur dédié, idéalement en accès très restreint. rsyslog est l'outil de référence pour cela sur Debian/Ubuntu : il est déjà installé, parle le protocole Syslog normalisé par la RFC 5424, et sait router les messages selon l'hôte source, la priorité ou le programme émetteur.

Ce TP reproduit une chaîne de centralisation minimale mais réaliste, entièrement reproductible dans un lab avec deux machines virtuelles.

Prérequis¶

• Deux machines virtuelles (ou conteneurs LXC) sous Ubuntu 24.04 ou Debian 12 :
  • logs-srv (serveur de collecte) — IP 192.168.56.20
  • web-client (client qui exporte) — IP 192.168.56.21
• Accès sudo sur les deux machines.
• Les deux VM doivent pouvoir se pinguer :

  # Depuis web-client
  ping -c 2 192.168.56.20
  

• rsyslog est présent par défaut. Vérifier :

  systemctl is-active rsyslog
  # attendu : active
  rsyslogd -v
  

• Pare-feu désactivé ou configuré (voir Étape 1 côté serveur) sur le port 514/UDP.

Architecture du lab¶

┌─────────────────┐   UDP 514    ┌─────────────────────┐
│   web-client    │ ───────────▶ │      logs-srv       │
│  192.168.56.21  │  /var/log/*  │  192.168.56.20      │
│  rsyslog client │              │  rsyslog serveur    │
└─────────────────┘              │  /var/log/remote/   │
                                 └─────────────────────┘

Le client envoie une copie de tous ses journaux ; le serveur les range dans un dossier dédié, un fichier par hôte source, ce qui permet de relire les logs de web-client sans mélange.

Procédure¶

Étape 1 : Configurer le serveur de collecte (logs-srv)¶

rsyslog modules et règles se configurent dans /etc/rsyslog.conf et dans des fichiers /etc/rsyslog.d/*.conf. On va :

1. Activer la réception UDP sur le port 514.
2. Créer un template qui range les logs distants dans /var/log/remote/<nom-hôte>.log.
3. Stocker les logs reçus via le réseau avant les règles de fichiers locaux, pour éviter qu'ils ne tombent dans /var/log/syslog.

Créer un fichier dédié (plus propre que d'éditer rsyslog.conf) :

sudo nano /etc/rsyslog.d/10-remote.conf

Coller :

# 1. Charger le module de réception UDP
module(load="imudp")
input(type="imudp" port="514")

# 2. Template : un fichier par hôte source, horodaté
template(name="RemotePerHost" type="string"
         string="/var/log/remote/%fromhost%/%$year%%$month%%$day%.log")

# 3. Router les messages reçus du réseau vers le template
if ($inputname == "imudp") then {
    action(type="omfile" dynaFile="RemotePerHost")
    stop   # ne pas retomber dans les règles par défaut (syslog)
}

Explications :

• module(load="imudp") active la entrée UDP ; input(...) ouvre le port 514.
• %fromhost% est une propriété dynamique : rsyslog injecte le nom d'hôte du client émetteur, donc chaque machine source obtient son propre dossier sous /var/log/remote/.
• stop arrête le traitement du message : il va dans le fichier distant dédié, pas dans /var/log/syslog.

Créer le dossier de stockage et redémarrer :

sudo mkdir -p /var/log/remote
sudo chown syslog:adm /var/log/remote
sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager

Vérifier que le port 514 écoute :

sudo ss -lntu | grep ':514'
# attendu : udp  UNCONN  ...  0.0.0.0:514  ...

Si ufw est actif, ouvrir le port :

sudo ufw allow 514/udp

Étape 2 : Configurer le client (web-client)¶

Côté client, on charge le module de sortie réseau et on déclare une règle *.* @@serveur:514 qui expédie tout vers le serveur.

sudo nano /etc/rsyslog.d/20-forward.conf

Coller :

# Charger le module de sortie réseau
module(load="omudp")

# Expedier TOUS les journaux (toutes priorités) vers logs-srv en UDP
*.* action(type="omudp" target="192.168.56.20" port="514")

Syntaxe alternative sans module explicite : *.* @192.168.56.20:514 (un seul @ = UDP ; @@ = TCP). C'est la forme historique, toujours valable.

Conserver une copie locale (les logs restent dans /var/log/syslog sur le client) — c'est le comportement par défaut, on n'a rien à interdire. On a donc à la fois :

• les logs locaux (pour un débogage immédiat) ;
• les logs centralisés sur logs-srv (pour la post-mortem et l'audit).

Redémarrer :

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager

Étape 3 : Émettre un message de test et vérifier la chaîne¶

Depuis web-client, générer un message Syslog avec logger (commande fournie par util-linux, déjà installée) :

logger -t LAB_TEST "salut depuis web-client, test de centralisation"

Côté serveur logs-srv, vérifier l'arrivée :

sudo ls /var/log/remote/
# attendu : un dossier portant le nom (ou l'IP) de web-client

sudo find /var/log/remote/ -type f -exec tail -n 5 {} +

On doit voir apparaître une ligne du type :

Jul  4 19:42:11 web-client LAB_TEST[1234]: salut depuis web-client, test de centralisation

Si rien n'arrive, passer à la section « Dépannage » ci-dessous.

Étape 4 : Filtrer et ne router que certaines priorités¶

Envoyer tout (*.*) est simple mais verbeux. En pratique, on peut vouloir n'expédier que les erreurs et alertes pour économiser la bande passante. Sur le client, remplacez la règle 20-forward.conf par :

module(load="omudp")

# N'expédier que les priorités WARNING (4) et plus graves (0=emerg ... 3=err)
*.warning;*.err;*.crit;*.alert;*.emerg action(type="omudp" target="192.168.56.20" port="514")

Tester avec deux messages de priorité différente :

logger -p user.info "INFO — ne doit PAS partir vers le serveur"
logger -p user.warning "WARN — doit arriver sur logs-srv"

Sur logs-srv, seules les lignes de priorité warning et supérieure doivent apparaître dans /var/log/remote/web-client/AAAAMMJJ.log.

Étape 5 : Garder une trace durable avec logrotate¶

Un collecteur qui ne rotated pas ses fichiers finit par saturer son propre disque. logrotate est déjà présent sous Ubuntu/Debian ; on ajoute une politique pour le dossier distant.

sudo nano /etc/logrotate.d/remote-logs

Coller :

/var/log/remote/*/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog adm
}

Tester sans attendre le lendemain :

sudo logrotate -d /etc/logrotate.d/remote-logs   # simulation (dry-run)
sudo logrotate -f /etc/logrotate.d/remote-logs   # force réelle

Vérification¶

Dépannage¶

Activer le debug de rsyslog côté serveur pour voir le flux entrant :

sudo systemctl stop rsyslog
sudo rsyslogd -dn   # debug interactif, Ctrl+C pour quitter

Aide-mémoire¶

Glossaire¶

rsyslog

Daemon de gestion des journaux issu du projet Debian/Ubuntu, dérivé du syslogd classique. Surcouche très performante (multifilaire, plus de quarante modules) du protocole Syslog original.

Syslog

Protocole et format de message normalisé par la RFC 5424 ("The Syslog Protocol"). Chaque message contient une priorité (facility + severity), un horodatage, un nom d'hôte, un programme et un texte.

Facility / Severity

Deux axes de classification d'un message Syslog. La facility identifie l'origine (kern, user, mail, auth…), la severity la gravité (de emerg=0 à debug=7).

Template

Structure de mise en forme ou de routage de rsyslog. Permet, par exemple, de décider dynamiquement du nom de fichier de sortie en fonction de l'hôte source (%fromhost%).

logrotate

Outil standards de rotation/compression des fichiers de logs sous Linux. Exploité ici pour limiter la croissance du dossier /var/log/remote/.

Ressources¶

• Documentation officielle rsyslog — Référence des modules imudp, omudp, templates, actions.
• RFC 5424 — The Syslog Protocol (IETF) — Format normalisé des messages Syslog.
• Ubuntu Server Guide — Logging — Vue d'ensemble de rsyslog sur Ubuntu Server.
• Debian Administrator's Handbook — syslog & rsyslog — Comprendre l'écosystème Syslog sous Debian.
• ANSSI — Recommandations relatives à l'exploitation des journaux — Guide d'hygiène : justifications de la centralisation des logs en environnement professionnel.
• Manpage locale : man rsyslogd, /usr/share/doc/rsyslog/.