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 qui se sont produits sur le système au cours d’une période de temps spécifique à partir des fichiers journaux stockés dans le système dans le répertoire /var/log.
Le serveur syslog sur une machine Linux peut agir comme un 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 journal principal préinstallé, suivi du démon de journal Systemd (journald).
Serveur Rsyslog en tant que service d’architecture client / serveur et peut atteindre les deux rôles simultanément. Il peut s’exécuter en tant que serveur et collecter tous les journaux transmis par d’autres périphériques 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 en même temps.
Le serveur Syslog exploite n’importe quel message de journal en utilisant le schéma suivant:
type (facility).priority (severity) destination(where to send the log)
D. Les données d’installation ou de type sont représentées par les processus internes du système qui génèrent les messages. Sous Linux, les processus internes (installations) qui génèrent des journaux sont normalisés comme suit:
- auth = messages générés par les processus d’authentification (login).
- cron = messages générés par des processus planifiés (crontab).
- daemon = messages générés par des 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 normalisés. Chaque priorité est attribuée avec 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.
- emerg = Emergency–0
- alert=Alertes–1
- err=Erreurs –3
- warn= Avertissements–4
- notice=Notification–5
- info= Information–6
- debug= Débogage – 7
Mots-clés Rsyslog spéciaux:
- * = toutes les installations ou priorités
- aucune = les installations n’ont pas de priorités données, par exemple : courrier.aucun
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 dans le répertoire /var/log/) ou à acheminer vers un autre processus local ou à envoyer à une console utilisateur locale (vers stdout), ou envoyer le message à un serveur syslog distant via le protocole TCP/UDP, ou même rejeter 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 où tous les fichiers journaux sont enregistrés est suffisamment grande (quelques Go minimum) pour pouvoir stocker tous les fichiers journaux qui seront envoyés par d’autres périphériques. 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
- RHEL 7.3 Procédure d’installation
Comment configurer Rsyslog dans le serveur CentOS/RHEL 7
1. Par défaut, le service Rsyslog est automatiquement installé et devrait s’exécuter dans CentOS/RHEL 7. Afin de vérifier si le démon est démarré dans le système, émettez 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 avez l’intention d’utiliser en tant que 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 faire sur le système pour configurer le démon rsyslog en tant que serveur de journaux centralisé, afin qu’il puisse recevoir des messages de journaux pour les clients externes, consiste à ouvrir et à 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 le port 514. UDP est le protocole standard utilisé pour la transmission de journaux par Rsyslog.
$ModLoad imudp $UDPServerRun 514
4. Le protocole UDP n’a pas la surcharge TCP, ce qui le rend plus rapide pour la transmission de données que le protocole TCP. D’autre part, 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 dans /etc/rsyslog.fichier conf afin de configurer le démon Rsyslog pour lier et écouter un socket TCP sur le port 514. Les sockets d’écoute TCP et UDP pour la réception peuvent être configurés 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 réseau syslog. Le modèle doit être ajouté avant le début du bloc DIRECTIVES GLOBALES comme illustré dans l’extrait ci-dessous.
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" . ?RemoteLogs & ~
La directive RemoteLogs aboveTemplate 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 cliente et de l’installation du client distant (application) qui a généré les messages en fonction des propriétés définies présentes dans la configuration du modèle : %HOSTNAME% et %PROGRAMNAME%.
Tous ces fichiers journaux seront écrits dans le système de fichiers local dans un fichier dédié nommé d’après le nom d’hôte de la machine cliente et stocké dans le répertoire /var/log/.
La règle de redirection &~ indique au serveur Rsyslog local d’arrêter le traitement du message de journal reçu et de supprimer les messages (pas de 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 que vous trouvez le mieux adapté à votre modèle.
Afin d’écrire tous les messages reçus des clients dans un fichier journal unique 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 où tous les messages avec l’indicateur d’installation d’authentification seront enregistrés dans un modèle nommé « TmplAuth ».
$template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" authpriv.* ?TmplAuth
Voici 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 de 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 de Rsyslog en émettant man rsyslog.commandez 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 émettant la commande suivante:
# service rsyslog restart
7. À présent, le serveur Rsyslog doit être configuré pour agir comme un 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 pour 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 pour ouvrir les 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 maintenant configuré en mode serveur et peut centraliser les journaux 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 de surveillance central pour les messages de journal distants, vous pouvez inspecter les fichiers journaux et observer l’état de santé des clients ou déboguer plus facilement les problèmes du client lorsque les systèmes tombent en panne ou subissent une attaque.