Comment créer un serveur de journaux centralisé avec Rsyslog dans CentOS/RHEL 7

Pour que l'administrateur système puisse identifier ou résoudre un problème sur un système serveur CentOS 7 ou RHEL 7, il doit connaître et afficher les événements survenus sur le système dans un environnement spécifique. période de temps à partir des fichiers journaux stockés dans le système dans le répertoire /var/log.

Le serveur Syslog sur une machine Linux peut servir de point de surveillance central sur un réseau où tous les serveurs, périphériques réseau, routeurs, commutateurs et la plupart de leurs services internes qui génèrent des journaux, qu'ils soient liés à un problème interne spécifique ou simplement à des messages informatifs, peuvent envoyer leurs journaux. .

Sur un système CentOS/RHEL 7, le démon Rsyslog est le serveur de journaux principal préinstallé, suivi du Systemd Journal Daemon (journald fort>).

Le serveur Rsyslog est construit en tant que service d'architecture client/serveur et peut remplir les deux rôles simultanément. Il peut fonctionner en tant que serveur et collecter tous les journaux transmis par d'autres appareils du réseau ou il peut s'exécuter en tant que client en envoyant tous les événements système internes enregistrés à un serveur Syslog de point de terminaison distant.

Lorsque rsyslog est configuré en tant que client, les journaux peuvent être stockés localement dans des fichiers sur le système de fichiers local ou peuvent être envoyés à distance plutôt que de les écrire dans des fichiers stockés sur la machine ou d'écrire des fichiers journaux d'événements localement et de les envoyer à un serveur Syslog distant à l'adresse suivante. le même temps.

Le serveur Syslog gère n'importe quel message de journal en utilisant le schéma suivant :

type (facility).priority (severity)  destination(where to send the log)

A. Les installations ou les données de type sont représentées par les processus système internes qui génèrent les messages. Sous Linux, les processus internes (installations) qui génèrent des journaux sont standardisés comme suit :

auth = messages générés par les processus d'authentification (connexion).
cron= messages générés par les processus planifiés (crontab).
démon = messages générés par les démons (services internes).
kernel = messages générés par le noyau Linux lui-même.
mail = messages générés par un serveur de messagerie.
syslog = messages générés par le démon rsyslog lui-même.
lpr = messages générés par des imprimantes locales ou un serveur d'impression.
local0 – local7 = messages personnalisés définis par un administrateur (local7 est généralement attribué pour Cisco ou Windows).

B. Les niveaux de priorité (gravité) sont également standardisés. Chaque priorité se voit attribuer une abréviation standard et un numéro comme décrit ci-dessous. La 7ème priorité est le niveau le plus élevé de tous.

emerge = Urgence – 0
alerte = Alertes – 1
err = Erreurs – 3
warn = Avertissements – 4
avis = Notification – 5
info = Informations – 6
debug = Débogage – 7

Mots-clés Rsyslog spéciaux :

*=toutes les installations ou priorités
aucun=les installations n'ont pas de priorités données. Ex : mail.none

C. La troisième partie du schéma syslog est représentée par la directive destination . Le démon Rsyslog peut envoyer des messages de journal à écrire dans un fichier sur le système de fichiers local (principalement dans un fichier du répertoire /var/log/) ou à rediriger vers un autre processus local ou à envoyer à un console utilisateur locale (vers stdout), ou envoyez le message à un serveur Syslog distant via le protocole TCP/UDP, ou même supprimez le message vers /dev/null.

Afin de configurer CentOS/RHEL 7 en tant que serveur de journaux central, nous devons d'abord vérifier et nous assurer que la partition /var sur laquelle tous les fichiers journaux sont enregistrés est suffisamment grande ( quelques Go minimum) afin de pouvoir stocker tous les fichiers logs qui seront envoyés par d'autres appareils. C'est une bonne décision d'utiliser un lecteur séparé (LVM, RAID) pour monter le répertoire /var/log/.

Exigences

Procédure d'installation de CentOS 7.3
Procédure d'installation de RHEL 7.3

Comment configurer Rsyslog sur le serveur CentOS/RHEL 7

1. Par défaut, le service Rsyslog est automatiquement installé et doit être exécuté sous CentOS/RHEL 7. Afin de vérifier si le démon est démarré dans le système, exécutez la commande suivante avec les privilèges root.

systemctl status rsyslog.service

Si le service n'est pas exécuté par défaut, exécutez la commande ci-dessous afin de démarrer le démon rsyslog.

systemctl start rsyslog.service

2. Si le package rsyslog n'est pas installé sur le système que vous souhaitez utiliser comme serveur de journalisation centralisé, exécutez la commande suivante pour installer le package rsyslog.

yum install rsyslog

3. La première étape que nous devons effectuer sur le système afin de configurer le démon rsyslog en tant que serveur de journaux centralisé, afin qu'il puisse recevoir des messages de journal pour les clients externes, est d'ouvrir et de modifier, à l'aide de votre éditeur de texte préféré, le fichier de configuration principal de /etc/rsyslog.conf, tel que présenté dans l'extrait ci-dessous.

vi /etc/rsyslog.conf

Dans le fichier de configuration principal de rsyslog, recherchez et décommentez les lignes suivantes (supprimez le signe hashtag # au début de la ligne) afin de fournir une réception de transport UDP au serveur Rsyslog via 514. port. UDP est le protocole standard utilisé pour la transmission des journaux par Rsyslog.

$ModLoad imudp 
$UDPServerRun 514

4. Le protocole UDP n'a pas de surcharge TCP, ce qui le rend plus rapide pour la transmission des données que le protocole TCP. En revanche, le protocole UDP n'assure pas la fiabilité des données transmises.

Cependant, si vous devez utiliser le protocole TCP pour la réception des journaux, vous devez rechercher et décommenter les lignes suivantes du fichier /etc/rsyslog.conf afin de configurer le démon Rsyslog pour lier et écouter un socket TCP sur 514. port. Les sockets d'écoute TCP et UDP pour la réception peuvent être configurées simultanément sur un serveur Rsyslog.

$ModLoad imtcp 
$InputTCPServerRun 514

5. À l'étape suivante, ne fermez pas encore le fichier, créez un nouveau modèle qui sera utilisé pour recevoir des messages distants. Ce modèle indiquera au serveur Rsyslog local où enregistrer les messages reçus envoyés par les clients du réseau Syslog. Le modèle doit être ajouté avant le début du bloc GLOBAL DIRECTIVES comme illustré dans l'extrait ci-dessous.

$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" 
. ?RemoteLogs & ~

La directive $template RemoteLogs ci-dessus demande au démon Rsyslog de collecter et d'écrire tous les messages de journal reçus dans des fichiers distincts, en fonction du nom de la machine client et de l'installation client distante (application) qui a généré les messages en fonction du propriétés définies présentes dans la configuration du modèle : %HOSTNAME% et %PROGRAMNAME%.

Tous ces fichiers journaux seront écrits sur le système de fichiers local dans un fichier dédié nommé d'après le nom d'hôte de la machine client et stocké dans le répertoire /var/log/.

La règle de redirection & ~ indique au serveur Rsyslog local d'arrêter de traiter davantage le message de journal reçu et de supprimer les messages (et de ne pas les écrire dans des fichiers journaux internes).

Le nom RemoteLogs est un nom arbitraire donné à cette directive de modèle. Vous pouvez utiliser le nom qui vous convient le mieux pour votre modèle.

Afin d'écrire tous les messages reçus des clients dans un seul fichier journal nommé d'après l'adresse IP du client distant, sans filtrer l'installation qui a généré le message, utilisez l'extrait ci-dessous.

$template FromIp,"/var/log/%FROMHOST-IP%.log" 
. ?FromIp & ~

Un autre exemple de modèle dans lequel tous les messages avec l'indicateur de fonction d'authentification seront enregistrés dans un modèle nommé « TmplAuth ».

$template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" 
authpriv.*   ?TmplAuth

Vous trouverez ci-dessous un extrait d'une définition de modèle du serveur Rsyslog 7 :

template(name="TmplMsg" type="string"
         string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
        )

L'extrait du modèle ci-dessus peut également être écrit comme suit :

template(name="TmplMsg" type="list") {
    constant(value="/var/log/remote/msg/")
    property(name="hostname")
    constant(value="/")
    property(name="programname" SecurePath="replace")
    constant(value=".log")
    }

Pour écrire des modèles Rsyslog complexes, lisez le manuel du fichier de configuration Rsyslog en exécutant la commande man rsyslog.conf ou consultez la documentation en ligne de Rsyslog.

6. Après avoir modifié le fichier de configuration Rsyslog avec vos propres paramètres comme expliqué ci-dessus, redémarrez le démon Rsyslog afin d'appliquer les modifications en exécutant la commande suivante :

service rsyslog restart

7. À présent, le serveur Rsyslog doit être configuré pour agir en tant que serveur de journaux centralisé et enregistrer les messages des clients Syslog. Pour vérifier les sockets réseau Rsyslog, exécutez la commande netstat avec les privilèges root et utilisez grep pour filtrer la chaîne rsyslog.

netstat -tulpn | grep rsyslog

8. Si SELinux est activé dans CentOS/RHEL 7, exécutez la commande suivante pour configurer SELinux afin d'autoriser le trafic rsyslog en fonction du type de socket réseau.

semanage -a -t syslogd_port_t -p udp 514
semanage -a -t syslogd_port_t -p tcp 514

9. Si le pare-feu est activé et actif, exécutez la commande ci-dessous afin d'ajouter les règles nécessaires à l'ouverture des ports rsyslog dans Firewalld.

firewall-cmd --permanent --add-port=514/tcp
firewall-cmd --permanent --add-port=514/udp
firewall-cmd –reload

C'est tout! Rsyslog est désormais configuré en mode serveur et peut centraliser les logs des clients distants. Dans le prochain article, nous verrons comment configurer le client Rsyslog sur le serveur CentOS/RHEL 7.

En utilisant le serveur Rsyslog comme point central de surveillance des messages de journaux à distance, vous pouvez inspecter les fichiers journaux et observer l'état de santé des clients ou déboguer les problèmes du client plus facilement lorsque les systèmes tombent en panne ou sont soumis à une sorte d'attaque.