Quand on administre un seul serveur, consulter les logs est simple.
Quand on en administre cinq, dix ou cinquante… ça devient vite un enfer.

Connexion SSH → journalctl → /var/log/auth.log → /var/log/nginx/error.log → serveur suivant → etc.

En cas d’attaque ou d’incident, perdre 30 minutes à naviguer entre les machines peut coûter cher.

La solution : centraliser les logs sur un serveur dédié.

Dans cet article, on va mettre en place une architecture simple, efficace et sécurisée avec rsyslog.

Pourquoi centraliser ses logs ?

Voici les bénéfices concrets :

• ✅ Analyse rapide en cas d’intrusion
• ✅ Historique conservé même si un serveur est compromis
• ✅ Audit et conformité sécurité
• ✅ Détection d’anomalies plus simple
• ✅ Base pour un futur SIEM (Wazuh, ELK, etc.)

Un attaquant qui efface les logs d’un serveur ne pourra pas effacer ceux du serveur central.

Architecture retenue

On va utiliser :

• 1 serveur dédié aux logs (log-server)
• Plusieurs serveurs clients
• Transmission TCP (plus fiable que UDP)
• Option TLS pour sécuriser le transport

Schéma simple :

Serveur 1  ─┐
Serveur 2  ─┼──► Log Server (rsyslog)
Serveur 3  ─┘

Étape 1 : Installer le serveur de logs

Sur le serveur central :

apt update
apt install rsyslog

Vérifier que le service tourne :

systemctl status rsyslog

Activer la réception distante

Éditer :

nano /etc/rsyslog.conf

Décommenter ou ajouter :

module(load="imtcp")
input(type="imtcp" port="514")

Redémarrer :

systemctl restart rsyslog

Vérifier que le port 514 écoute :

ss -tulnp | grep 514

Organiser les logs par machine

Créer un fichier :

nano /etc/rsyslog.d/remote.conf

Ajouter :

$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

Créer le dossier :

mkdir -p /var/log/remote
chown syslog:adm /var/log/remote

Désormais, chaque machine aura son propre dossier.

Étape 2 : Configurer les serveurs clients

Installer rsyslog si nécessaire :

apt install rsyslog

Créer :

nano /etc/rsyslog.d/remote.conf

Ajouter :

*.* @@IP_DU_SERVEUR_LOG:514

Les deux @@ indiquent TCP.

Redémarrer :

systemctl restart rsyslog

Tester

Sur un client :

logger "Test Ninja Linux"

Sur le serveur central :

tail -f /var/log/remote/NOM_DU_CLIENT/syslog.log

Si le message apparaît → c’est fonctionnel.

Sécuriser la transmission avec TLS

Transmettre des logs en clair sur un réseau public est une mauvaise idée.

On peut activer TLS avec :

module(load="gtls")

Puis configurer :

$DefaultNetstreamDriver gtls
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode x509/name

Cela nécessite :

• Une autorité de certification (CA)
• Un certificat serveur
• Un certificat client

Pour un petit réseau privé (VLAN, WireGuard), TCP simple peut suffire.
Pour un environnement exposé → TLS obligatoire.

Ajouter de la rotation et du stockage long terme

Les logs grossissent vite.

Configurer logrotate :

nano /etc/logrotate.d/remote

Exemple :

/var/log/remote/*/*.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
}

Bonnes pratiques terrain

• 🔒 Restreindre l’accès SSH au serveur de logs
• 📦 Sauvegarder le dossier /var/log/remote
• 🔍 Surveiller l’espace disque
• 🧠 Coupler avec Fail2Ban ou Wazuh
• 🧱 Isoler le serveur dans un VLAN ou derrière WireGuard

Aller plus loin

Cette architecture peut évoluer vers :

• Stack ELK
• Wazuh manager
• Grafana Loki
• SIEM professionnel

Mais pour 80 % des usages, rsyslog centralisé suffit largement.

Conclusion

Centraliser ses logs est une mesure simple mais extrêmement puissante.

Ce n’est pas “complexe”, ce n’est pas “cloud”, ce n’est pas “buzzword”.
C’est juste une bonne pratique d’administration système.

Si vous gérez plusieurs VPS, c’est probablement l’amélioration la plus rentable que vous puissiez mettre en place cette semaine.