Rsyslog 2021
Rsyslog 2021
Rsyslog 2021
Definitig Logs
Les logs sont en réalité des fichiers texte qui recensent chronologiquement tous les événements
qui se sont déroulés sur un système informatique, que ce soit au niveau du système
d’exploitation ou des applications qu’il héberge.
On retrouvera dans des logs par exemples, les redémarrages des services, les connexions des
utilisateurs, les erreurs rencontrées par le système ou les logiciels…
Ce sont des fichiers très précieux pour comprendre la source d’un problème, le déboguer et
surveiller l’état de santé d’une machine.
C’est pourquoi, exporter les journaux événements de tous ses serveurs sur une seule et même
machine dédiée, est une bonne pratique. Et en y ajoutant une interface graphique, ils pourront
mieux être triés, classés et consultés, par source, par criticité etc…
Pour permettre cette centralisation des journaux, le protocole initialement utilisé est le protocole
syslog. Le protocole syslog permet justement le transfert des informations sur le port UDP 514.
De nos jours, on préférera utiliser un protocole TCP qui accusera réception des données
contrairement au protocole UDP qui lui ne se souciera pas de la bonne/mauvaise transmission des
informations.
Le logiciel de gestion des logs que nous allons utiliser, Rsyslog, utilise justement son propre
protocole réseau, le protocole RELP (Reliable Event Logging Protocol) qui, étant un protocole
TCP, offre une meilleure garantie de réception des événements par le serveur.
Afin d’avoir un accès plus « graphique » des journaux d’événements, nous allons utiliser
l’interface web LogAnalyzer qui va nous permettre de voir et analyser les logs en temps réel
mais également de les trier selon ce que l’on souhaite.
Trier ses logs justement, syslog le fait déjà un peu pour nous…
En effet, lorsque l’on s’attaque à la configuration de logs, on est forcément confronté aux notions
de “facilities” et de “severities“ (aussi appelées “priorities“). Ce sont des concepts importants
dans la gestion des logs.
Ce qu’on appelle une “facility” est en fait une catégorie de logs qui correspond à un type de
service. Les facilities permettent de filtrer les logs et les ranger selon leur type. Elles s’appliquent
par un système de “code“, au nombre de 24, chaque code correspondant à une catégorie. Voici un
tableau récapitulatif des facilities :
fig 2 : Tableau des codes des facilities
Quant aux “severities”, ce sont les niveaux de gravité des erreurs de logs. Ces niveaux sont au
nombre de 8 et fonctionnent comme les facilites, avec un système de code couplé à un keyword. Il
faut savoir que plus le niveau de gravité est proche de la valeur 0, plus l’erreur sera grave. On
parle d’urgence absolue pour la machine concernée. Voici le tableau recensant les severities :
Attention, plus le niveau de gravité défini sera proche de 7, la valeur la moins « importante »
donc, plus il y aura de logs générés, plus ou moins utiles selon ce que vous souhaitez. Si l’on
définit sur une machine la severity 6 par exemple, cela signifie que TOUS les niveaux précédents
seront aussi activés ! Si on définit une severity 3, on aura alors les logs de sévérité error + critical
+ alert + emergency.
Partie II : Mise en place d’un serveur et des clients logs
Prérequis
On suppose que vous avez déjà installé mysql-server que vous detenez le mot de place de
l’administrateur de votre Base de données car il vous sera demandé pour créer automatiquement la
base Syslog au moment de l’installation de rsyslog-mysql
root@Kam-ims:~# mysql
Database changed
mysql> show tables;
+------------------------+
| Tables_in_Syslog |
+------------------------+
| SystemEvents |
| SystemEventsProperties |
+------------------------+
2 rows in set (0,00 sec)
2. 4- Configuration du serveur
Poursuivons en activant la réception des logs sur le serveur dédié. Modifiez le fichier de
configuration de rsyslog :
Dans le fichier
root@Kam-ims:~# nano /etc/rsyslog.conf
On constate que le serveur rsyslog tourne bien sur le port 514 en UDP et TCP
*.* @192.168.0.5:514
*.* @@192.168.0.5:514
La première ligne concerne l’envoi des log par UDP alors que la deuxième concerne l’envoi des log
par TCP
On constate que le client alain-Virtualbox a bien envoyé des logs qui sont stockés dans la base
Syslog du serveur comme le montre la capture suivante :
Passons maintenant à la mise en place d’un outil graphique d’analyse des logs
root@Kam-ims:~# cd /usr/local/
root@Kam-ims:/usr/local# wget http://download.adiscon.com/loganalyzer/loganalyzer-4.1.8.tar.gz
on désarchive
Ces paramètres vont en réalité créer des tables supplémentaires dédiées à LogAnalyzer dans
notre base de données Syslog. La partie “Table prefix” peut être laissée par défaut. Cliquez sur
“Next“.
L’étape 4 indique que la connexion à la base de données définie à l’étape 3 a bien réussi et que
les tables pour LogAnalyzer seront créées à l’étape suivante. Cliquez sur “Next“.
Fig3.5 étape 5 d’installation
L’étape 5 valide la création des tables. Cliquez sur “Next“.
Fig 3.6 etape 6 d’installation
Il faut maintenant paramétrer la source des logs comme étant notre base de données. Renseignez le
champ “Name of the Source” en indiquant par exemple “base de données Sysslog” ou ce que vous
voulez.
Modifiez le champ “Source Type” en sélectionnant “MYSQL Native“ ce qui déroulera le menu
inférieur des options de base de données.
Fig 3,7 choix de table à utiliser par loganalyzer
Fig 3.8 : fin d’installation
fig 3.9 Première connexion à l’interface de loganalyzer
fig 3.10 : authentification en tant qu’administrateur de loganalyzer
Fig 3.11 : interface de loganalyzer
Pour obtenir des informations sur un événement, cliquez le message le concernant dans la
colonne de droite ce qui ouvrira une fenêtre avec le message complet.
Fig 3.12 obtention d’information sur un evenement choisi
Pour effectuer un tri ou des recherches particulières, par nom d’hôte, par criticité, ou encore par
service par exemples, vous pouvez utiliser la zone de recherche en saisissant un mot clé et
appuyant sur le bouton « Search ». L’affichage vous montrera par exemple uniquement les
événements se rapportant du service SSH.
Fig 3.13 Tri selon un critere
si on clique sur l’evenement ayant l’adresse 192.168.1.125, on voit les détails d’échec de connexion
de l’utilisateur bouki
mail_location = maildir:~/Maildir
#mail_location = mbox:~/mail:INBOX=/var/mail/%u
On constate que les ports 110 et 143 de pop et imap sont ouverts
Etape 1 :
On redemarre apache2
Etape 2 : configuration du webmail roundcube pour lui indiquer l’adresse du serveur imap et
celle du serveur SMTP
root@Kam-ims:/usr/local# cd /var/lib/roundcube/config
root@Kam-ims:/var/lib/roundcube/config# nano config.inc.php
$config['default_host'] = 'rtn.sn';
$config['smtp_server'] = 'localhost';
$config['smtp_port'] = 25;
$config['smtp_user'] = '';
$config['smtp_pass'] = '';
192.168.0.5 rtn.sn
ce qui permet de faire la correspondance entre le nom rtn.sn et l’adresse ip 192.168.0.5 qui est
l’adresse de notre serveur IMAP
NB : cette correspondance local n’est pas nécessaire si on dispose d’un serveur DNS
si Toto veut envoyer un mail et s’il commence par saisir m on voit que le nom mamadou ndiaye
apparaît
Fig 4,15 : Proposition automatique des contact d’un utilisateur
Fig 4.16 : Envoi de mail à un contact