metamorworks - stock.adobe.com

Administration système : centralisez les logs avec rsyslog

Ce guide détaille étape par étape la mise en œuvre d’un processus automatisé de centralisation des logs, en tirant parti des fonctionnalités flexibles de rsyslog.

Les fichiers logs constituent un élément essentiel du travail de tout administrateur Linux. Ils permettent aux administrateurs système de détecter les pannes matérielles, les services mal configurés et d'autres signes avant-coureurs d'un problème.

Les environnements réseau actuels sont plus dispersés que jamais ; il est donc essentiel de trouver un moyen efficace de stocker et d'analyser les fichiers logs. L'accès à ces fichiers est également crucial pour garantir la conformité et respecter les accords de niveau de service.

Le service rsyslog sous Linux facilite ces opérations en permettant le stockage, le tri et la conservation centralisés des fichiers logs essentiels du système d'exploitation et des applications. Il nécessite peu de ressources et est relativement facile à configurer, ce qui en fait une excellente option pour gérer les fichiers logs de serveurs distants tout en maîtrisant les coûts de stockage.

Cet article présente un scénario comprenant un serveur central (siège social) faisant office de référentiel de fichiers logs et plusieurs serveurs distants qui lui transmettent ces fichiers. Il inclut des options de configuration et des commandes, ce qui permet de l'adapter facilement à votre propre environnement.

Adaptez l'exemple de scénario suivant à votre propre environnement :

  • Un serveur de référentiel de logs centralisé fonctionnant sous Linux au siège social.
  • Des serveurs dans des succursales distantes qui transmettront tout ou partie des fichiers logs au serveur du siège social. Dans ce scénario, le serveur distant d'exemple est nommé remote_server1.

Ce dont vous avez besoin pour rsyslog

Choisissez avec soin les composants matériels de votre serveur central de stockage des logs. Bien que rsyslog soit en soi un service léger, il peut néanmoins solliciter fortement les sous-systèmes réseau et de stockage si de nombreux serveurs distants y écrivent simultanément.

Commencez par respecter les spécifications matérielles minimales suivantes :

  • Au moins deux processeurs multicœurs.
  • 4 Go de RAM.
  • Une connectivité réseau de 1 Gbit/s.

Le stockage est le sous-système clé à prendre en compte. Les SSD NVMe constituent un bon choix standard en raison de leur vitesse et de leur fiabilité.

Les configurations de disque sont également essentielles sur ce serveur. Commencez par placer le répertoire Linux /var/log sur une partition distincte de celle du système d'exploitation. L'isolation des deux sur des périphériques de stockage physiques différents réduit la concurrence en matière d'entrée/sortie.

Enfin, activez le chiffrement des disques pour préserver la sécurité et la confidentialité des entrées des fichiers logs. Ce chiffrement pourrait vous être nécessaire pour satisfaire aux exigences de conformité.

Certaines entreprises pourraient sans problème utiliser un Raspberry Pi ou similaire, pourvu qu’il soit équipé d'un stockage haute vitesse.

Activez le serveur rsyslog central

La plupart des distributions Linux destinées aux entreprises intègrent rsyslog par défaut. Utilisez le gestionnaire de paquets recommandé par votre distribution pour installer ou mettre à jour rsyslog avant de modifier son fichier de configuration.

Dans ce scénario, vous utilisez un serveur centralisé au siège. Les succursales transmettent leurs logs à ce serveur, et la majeure partie de votre configuration s'effectuera sur cet appareil.

Sous Red Hat Enterprise Linux, Rocky, AlmaLinux et les distributions similaires, tapez l'une de ces commandes :

dnf install rsyslog

dnf update rsyslog

Sous Debian, Ubuntu Server ou des distributions similaires, tapez l'une des commandes suivantes :

apt install rsyslog

apt update rsyslog

Lancez le service et configurez-le pour qu'il démarre au démarrage du système à l'aide des commandes suivantes :

systemctl start rsyslog

systemctl enable rsyslog

Configurez le serveur rsyslog central

Configurez le serveur central pour qu'il reçoive les fichiers logs provenant des serveurs distants. Commencez par sauvegarder le fichier de configuration par défaut :

cp /etc/rsyslog.conf /etc/rsyslog.conf.orig

Ensuite, ouvrez le fichier /etc/rsyslog.conf à l'aide d'un éditeur de texte, tel que Vim ou Nano.

vim /etc/rsyslog.conf

Déterminez si vous souhaitez que les transferts de logs s'effectuent via TCP ou UDP. Le protocole UDP est souvent acceptable, mais TCP offre une meilleure gestion des erreurs et une plus grande fiabilité. Il gère également plus efficacement la congestion du réseau, ce qui peut s'avérer important dans les environnements à fort trafic.

Décommentez ou ajoutez les lignes du fichier /etc/rsyslog.conf qui correspondent au texte suivant :

module(load="imtcp")

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

Ces lignes spécifient le protocole TCP sur le port rsyslog standard 514. Cependant, vous pouvez configurer des numéros de port personnalisés pour chaque serveur distant afin de mieux organiser les données entrantes. Par exemple, si vous attribuez le port 10514 à remote_server1, vous pouvez alors configurer le serveur central pour qu'il reconnaisse les données provenant de ce périphérique grâce à ce numéro de port. Modifiez l'entrée comme suit :

input(type="imtcp" port="10514")

Vous devrez très certainement gérer un espace de stockage distinct pour les fichiers logs de chaque serveur distant. Pour ce faire, utilisez les règles rsyslog. Cet exemple classe les logs par nom de serveur distant, dans ce cas remote_server1 :

ruleset(name="remote_server1") {

  action(type="omfile"

file="/var/log/remote/server1/%HOSTNAME%/%PROGRAMNAME%.log")

   }

input(type="imtcp" port="10514" ruleset="remote_server1")

Répétez cette opération en adaptant le nom du serveur à votre environnement. Vous pouvez également personnaliser les règles afin de rediriger les logs spécifiques à certains services vers des fichiers particuliers.

Vous devez également configurer le pare-feu du serveur central pour qu'il accepte les connexions réseau entrantes sur le port TCP 514. Utilisez les commandes suivantes si votre serveur prend en charge les firewalls :

firewall-cmd --permanent --zone=public --add-port=514/tcp

firewall-cmd --reload

Modifiez ces commandes en fonction de la zone et des ports souhaités. Veillez à ajouter les numéros de port personnalisés que vous avez éventuellement choisis pour chaque serveur distant.

Enfin, mettez en place un outil de gestion tel que logrotate pour archiver les logs sur le serveur central. L'archivage est essentiel pour gérer efficacement le stockage des logs.

Configurez les clients rsyslog des succursales

La configuration est nettement plus simple sur les serveurs distants des succursales. Si nécessaire, installez rsyslog sur chaque appareil. Modifiez le fichier de configuration /etc/rsyslog.conf pour transférer soit tous les logs, soit certains fichiers logs sélectionnés.

Pour transférer tous les logs via TCP, ajoutez la ligne suivante à la section Rules du fichier de configuration :

*.* @@central_server:514

Si vous avez configuré le serveur central pour des connexions UDP, utilisez plutôt un seul caractère @. Si vous utilisez des numéros de port personnalisés pour identifier les serveurs, définissez-les à la place du port par défaut 514.

Utilisez les paramètres suivants pour transférer les logs de services spécifiques, tels que les entrées du journal FTP :

ftp.* @@central_server:514

Veillez à redémarrer le service rsyslog après avoir modifié le fichier de configuration à l'aide de la commande suivante :

systemctl restart rsyslog

Vous pouvez également modifier les niveaux de gravité que rsyslog enregistre dans les fichiers logs. Voici les niveaux de gravité disponibles :

emerg = 0

alert = 1

crit = 2

error = 3

warn = 4

notice = 5

info = 6

debut = 7

Vérifiez votre configuration chaque fois que vous apportez des modifications à ces serveurs. Certains services ajoutent des configurations de fichiers logs à rsyslog. Par exemple, le serveur web Apache, très répandu, s'appuie sur rsyslog et peut transférer ses fichiers logs à l'aide de cette configuration.

Il peut parfois s'avérer utile de centraliser les logs des postes de travail Linux en plus des entrées des serveurs. Ils utiliseront une configuration similaire. Notez que macOS prend en charge rsyslog, vous pouvez donc également intégrer ces systèmes à votre architecture de journalisation. Étant donné que de nombreux périphériques réseau sont basés sur Linux, envisagez de les ajouter à cette conception.

Testez la configuration

Utilisez la commande logger pour générer des messages de test à partir de chaque serveur distant. Vérifiez que les messages sont bien arrivés sur le serveur central. Vérifiez les entrées du fichier de configuration et les paramètres du pare-feu si vous rencontrez des problèmes.

Rsyslog est un mécanisme fiable. Suivez les bonnes pratiques suivantes pour en tirer le meilleur parti :

  • Utilisez des périphériques de stockage rapides et fiables.
  • Envisagez de placer les logs récents sur un stockage à accès rapide.
  • Envisagez de placer les logs archivés sur un stockage à accès lent.
  • Répartissez les fichiers logs des serveurs dans des répertoires spécifiques.
  • Utilisez le protocole TCP pour une fiabilité optimale.
  • Sécurisez vos fichiers logs à l'aide des permissions Linux, de SELinux et du chiffrement de disque.
  • Effectuez la rotation et l'archivage de vos fichiers logs à l'aide d'outils tels que logrotate.

Assurez-vous que vos fichiers logs respectent les accords de niveau de service et les exigences de conformité. Et surtout, lisez vos logs. Que vous utilisiez l'automatisation ou un processus de vérification manuelle, examinez vos fichiers logs pour détecter les anomalies, les activités suspectes et les erreurs de configuration. Vérifiez régulièrement la configuration de rsyslog pour vous assurer que vous consignez les informations dont vous avez besoin provenant des services, des applications et du système d'exploitation.

Cet article est initialement paru en anglais sur SearchStorage.

Pour approfondir sur Administration de systèmes