Gestion de logs (RSYSLOG)

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.


Un log c’est un événement qui permet de tracer le fonctionnement du système ou d’une application. Par exemple quand vous lancez le service apache2, un log est crée pour indiquer que le service s’est bien lancé (ou pas). Tous les logs sont stockés dans des fichiers de log.

Sur Linux, les fichiers de log se trouvent dans le répertoire /var/log :

plslogs.png

Dans ce répertoire on trouve des logs système tel que auth.log qui contient le détail de toutes les connexions sur la machine, et des fichiers de log qui correspondent à un service (apache2 par exemple).

Seulement voilà, nos programmes (et le système) écrivent énormément de choses et du coup lire les logs devient vite compliqué. Voyez par vous même le nombre de logs écrits par apache2 en 1 seconde :

logs.png

Illisible non ? Du coup pour retrouver des informations là dedans bah bon courage…

Dans cet article nous verrons tout d’abord quelques commandes de base pour naviguer dans les logs puis nous nous intéresserons à l’outil rsyslog qui nous permettra de centraliser les logs de plusieurs machines.

I/ Naviguer dans les logs

La première commande à connaître par cœur permet d’afficher les logs en temps réel :

tail -f nomdevotrefichierdelog

Si vous hébergez un site web sur un serveur apache et que quelqu’un tente une injection SQL via SQLmap vous verrez le nombre de logs augmenter démentiellement et ce en temps réel.

sqlmap.png

La seconde commande à savoir utiliser est la commande grep qui permet de rechercher un mot dans un fichier. Par exemple si je grep le mot sqlmap via la commande :

grep -i sqlmap access.log

sur le fichier access.log j’obtiens ça :

grep.png

On peut même aller plus loin ! En effet comme vous l’avez vu, on dispose de beaucoup de fichiers de log et parfois il est compliqué de savoir dans quel fichier se trouve le log que l’on recherche. Avec la commande :

grep -irl 'sqlmap' /var/log/

On demande au système de nous retourner tous les fichiers dans lesquels se trouve le mot sqlmap :

greprep.png

A savoir que les options irl (c’est mon moyen mnémotechnique pour m’en rappeler ahah) indique que je recherche de façon récursive, sans me soucier de la case (i) et que je veux seulement avoir les noms des fichiers dans lesquels se trouve l’occurrence « sqlmap » (l).

Voilà pour les quelques commandes de base à connaître. Si vous voulez en savoir plus sur grep et la consultation de log je vous invite à lire cet article.

Ok, maintenant qu’on sait à peu près utiliser les logs on va passer à la vitesse supérieur. Dans un réseau il y a plusieurs machines et qui dit plusieurs machines dit aussi plusieurs fichiers de logs. Or nous on est feignant du coup on aimerait bien réunir tous nos logs dans un seul fichier et si possible l’exporter sur une autre machine (un serveur). Eh bien avec l’outil rsyslog c’est possible !

II/ L’outil rsyslog

Pourquoi est ce qu’on centraliserait nos logs ? Eh bien de base il faut savoir que les logs sont stockés en local. Vous pouvez par défaut y accéder qu’à partir de la machine. Or si cette machine tombe (et est inaccessible) eh bah wallou vos logs 😅 ! Du coup c’est un double (quadruple) bénéfice que nous faisons en les envoyer sur un serveur de logs :

  1. On peut accéder à tous les logs de toutes les machines directement
  2. En cas de crash de la machine on peut quand même accéder à ses logs

En passant ça permet aussi de libérer de l’espace mémoire sur les machines et en cas d’attaque, si un pirate efface les logs pour cacher son intrusion, eh bien on y aura quand même accès puisque ces derniers auront été envoyés sur notre serveur.

Bueno donc pour illustrer cet article je vous invite à monter une VM (peu importe la distribution). Cette fois je vais utiliser la distribution Parrot (parce que je la kiff 😍).

Ma machine physique jouera le rôle de serveur tandis que la VM jouera le rôle du client. Sur la VM nous allons configurer un serveur Apache et le but ça sera d’envoyer les logs du serveur Apache directement sur le serveur (la machine physique).

Première chose à faire : installer rsyslog sur le serveur et sur le client. Pour cela on utilise la commande suivante :

sudo apt install rsyslog

Il existe un seul fichier de configuration pour rsyslog disponible dans le répertoire /etc. Ce fichier est utilisable à la fois pour les clients et pour le serveur.

  • Configuration du serveur :

Pour le serveur c’est très simple, ouvrez le fichier de configuration et décommenter  ces deux lignes (enlever les #) :

decommenter.png

En faisant ça on indique à rsyslog qu’il doit se mettre à l’écoute sur le port 514 UDP pour recevoir les logs venant des clients. Puis lancer ou relancer le service rsyslog :

sudo /etc/init.d/rsyslog start
ou
sudo /etc/init.d/rsyslog restart

Avant d’aller plus loin on va vérifier que le service rsyslog est fonctionnel et qu’il écoute bien sur le port 514. Pour checker le service il suffit d’entrer cette commande :

servicersyslog.png

Le petit  » +  » veut dire que le service est up. Puis pour vérifier que le port est bien en écoute on utilise cette commande :

sudo netstat -nulp

netstatnulp.png

L’option -n permet d’afficher  le port utilisé, l’option -u indique que l’on ne s’intéresse qu’à l’UDP, l’option -l permet de lister les ports en écoute et l’option -p permet d’afficher le PID ainsi que le nom du service à l’écoute.

La configuration du serveur est terminée. Passons au client !

  • Configuration du client :

Rendez vous sur votre VM, dans le fichier de configuration rsyslog et ajoutez cette ligne dans le bloc  RULE:

*.* @IP_SERVEUR:514

Attention, le « @ » est obligatoire ! Il indique à rsyslog que le protocole de communication à utiliser est UDP. Si vous voulez passer par du TCP il faudra modifier le fichier de configuration du serveur ET ajouter un deuxième @. Dans mon cas voici ce que ça donne :

rules.png

Maintenant on recharge le service rsyslog :

sudo /etc/init.d/rsyslog restart

Retournez sur le client, tapez la commande su pour passer admin :

suf.png

Regardez les logs de votre serveur :

logs.png

Voici les logs de notre client ! Alors ici on remarque que le nom de l’host est localhost (c’est normal puisque nous utilisons une VM). Dans des conditions réelles on aurait le nom de la machine ou au moins son adresse IP.

Parfait tout ça ! Seul bémol, les logs de nos clients sont mélangés au log de notre serveur et ça c’est pas cool. Ça serait mieux si les logs de nos clients étaient rangés dans un dossier qui leur appartient. A vraie dire ça serait mieux si on pouvait choisir d’envoyer qu’une certaine catégorie de logs (les plus critiques par exemple). Et pour ça on dispose des facilities et des priorités !

III/ Gestion des facilities et priorités

Les facilities ce sont des catégories dans lesquelles on « range » les logs. Il existe plusieurs  facilities, voici la liste officiel du standard syslog :

facilities.png

Merci Wikipédia 😄😄😄 ! Remarquez qu’il y a plusieurs facilities non utilisées ( de 16 à 23), ça nous sera très utile 😉 ! A ces facilities on assigne un niveau de criticité défini par le standard :

criticity.png

Tout à l’heure je vous ai dit qu’il fallait ajouter cette ligne dans le fichier de conf du client :

*.* @IP_SERVEUR:514

Sans vous expliquer pourquoi. En fait le  » *.*  » indique à rsyslog que l’on veut envoyer au serveur de logs tous les logs disponibles (toutes les facilities symbolisé par la première *) de tous les niveaux de criticité (symbolisé par la deuxième *).

On peut aussi très bien filtrer l’envoi des logs en choisissant par exemple d’envoyer toutes les facilities dont la criticité est « Emergency » :

*.emmerg @IP_SERVEUR:514

Ou encore d’envoyer seulement les message relatifs à l’authentification pour tous les niveaux de priorité :

auth.* @IP_SERVEUR:514

A vous de voir ce que vous voulez envoyer ou non. Il nous reste une dernière chose à régler pour avoir un système de logs propres : hiérarchiser l’archivage de nos logs en fonction des clients. Pour cela nous utiliserons un template qu’il faudra définir dans le fichier de configuration /etc/rsyslog.conf (côté serveur) et ajouter sous le bloc « RULE » la ligne suivante :

$template syslog,"/var/log/clients/%fromhost%/syslog.log"

Puis on va spécifier, toujours côté serveur, que le template doit s’appliquer à tous les logs :

*.* ?syslog

Et maintenant si je crée du log sur mon client j’ai un répertoire clients :

clients.png

dans lequel on trouve les noms (ou les IP’s de mes clients) :

ip.png

Qui contient le fichier de log syslog.log avec à l’intérieur les logs du client :

sysloglog

Encore une fois, libre à vous de créer plusieurs templates pour chaque facilities ou pour chaque niveau de criticité. Reprenez les deux lignes de configuration vues plus haut et ajustez les 😊 !

Bon c’est cool mais au début de l’article je vous avais dit qu’on voulait recevoir les logs d’apache sur notre serveur de logs. Pour le moment on n’y est pas… Mais vous allez voir que c’est pas bien compliqué 😉 !

IV/ Exporter les logs des services

La plupart des services créent -au moins- un fichier de configuration supplémentaire dans le répertoire /var/log. Pour Apache on peut voir que c’est carrément un répertoire qui est crée et dans ce répertoire on retrouve ces fichiers de logs :

apacherep.png

Cela veut dire qu’il va falloir rediriger les logs directement depuis les fichiers de configuration d’Apache2. Pour cela, éditez le fichier :

/etc/apache2/sites-available/000-default.conf

Le répertoire /sites-available contient l’ensemble des fichiers de configuration relatifs aux hosts. Sachez qu’il est possible d’héberger plusieurs sites sur un même serveur apache2 justement grâce à ce genre de fichiers.

Le seul qui est défini pour le moment c’est celui par défaut dont la configuration est faite dans le fichier 000-default.conf. Commentez ces deux lignes :

commenter.png

Et ajoutez ces deux là :

ErrorLog "|/usr/bin/logger -t apache -p local0.info"
CustomLog "|/usr/bin/logger -t apache -p local0.info" combined

Cette commande, qui peut paraître barbare, est en fait toute simple. Logger est la commande  à utiliser quand on veut ajouter manuellement dans rsyslog un log. L’option -t permet de lui attribuer une étiquette et enfin la partie local0.info permet d’indiquer qu’on log la facilitie local0 et toutes les criticités de log.

Maintenant retournez dans le fichier de configuration rsyslog du client et ajoutez-y cette règle :

local0.* @IP_SERVEUR:514

Rechargez Apache2 puis rsyslog, connectez vous à votre serveur web via un navigateur et observez les logs sur votre serveur :

logsapache

On a bien réussi à exporter les logs de notre serveur Apache2 ! Ce qu’on peut faire ensuite c’est rediriger tous les logs vers un outil comme Splunk qui permet de faire de l’analyse de logs mais ça, on le verra plus tard 😋 !


Cet article est terminé j’espère que vous y aurez appris des choses ! Personnellement j’ai beaucoup aimé travailler sur ce sujet, c’est que quelque chose que je pourrais très facilement réutilisé en entreprise donc c’est tout bénéf !

Comme d’hab si vous avez des questions n’hésitez pas à me contacter via ma page Facebook 🙂 !

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s