Centralisez vos logs avec Rsyslog

I. Présentation

La centralisation des logs de plusieurs serveurs sur un seul peut présenter un grand intérêt au niveau de la sécurité au sein d'un système d'information. En effet, il est plus facile pour des outils d'analyse de logs de comparer, lire et scanner des fichiers se situant sur un seul et unique serveur plutôt que de le faire à distance ou via des agents distants. De plus en cas de crash serveur, vous serez capable de récupérer les erreurs et actions menées sur votre serveur avant que celui-ci ne crash, facilitant ainsi la remise en activité de celui-ci et sa sécurisation future.

Par défaut sur la plupart des Linux modernes, l'outil de gestion des logs est Rsyslog, c'est celui-ci que nous allons utiliser dans ce tutoriel. Nous travaillerons sur deux machines sous Debian 7, l'un faisant office de serveur, l'autre de "client" qui enverra ses logs sur le serveur. Dans les deux cas, le fichier de configuration à modifier est toujours "/etc/rsyslog.conf". On peut néanmoins  en mettre dans "/etc/rsyslog.d/" puis faire un "include" dans le fichier de configuration principale pour importer.

II. Configuration du serveur

Pour le serveur, il faut simplement paramétrer le serveur pour qu'il accepte les logs venant de l'extérieur en ouvrant le port adéquate, on va pour l'instant par soucis de simplicité ouvrir le port UDP (514). Pour cela, on va décommenter les deux lignes suivantes :

$ModLoad imudp
$UDPServerRun 514

On pourra alors redémarrer le service rsyslog :

service rsyslog restart

Pour vérifier que notre serveur est bien à l'écoute, on peut effectuer la commande suivante :

netstat -npul

On verra alors notre port 514 ouvert en UDP :

III. Configuration du client

Au niveau du client, il faut aller dans ce même fichier puis, pour rediriger tous les logs sur le serveur, ajouter cette ligne à la fin du fichier :

*.* @IP_SERVER:514

Note : Le "@" doit figurer dans la ligne

On va alors redémarrer notre service rsyslog :

service rsyslog restart

Puis on pourra générer des logs (redémarrer un service quelconque par exemple) et aller voir s'ils figurent sur le serveur rsyslog. Par défaut comme nous l'avons fait, les logs des clients se situeront dans le même fichier que les logs du serveur donc par exemple dans le "/var/log/syslog" du serveur. Vous verrez simplement que le nom de l'hôte ayant généré la ligne de log n'est pas celui du serveur mais celui du client.

III TCP/UDP

Nous avons précédemment configuré notre client et notre serveur pour échanger en utilisant le protocole de transport (couche 4) UDP. Brièvement, UDP permet un échange unique pour transmettre un paquet, c'est un protocole qui ne cherche pas à se synchroniser, à suivre l'état des paquets ou des échanges entre deux éléments actifs. Au contraire, TCP va chercher à savoir pour chaque paquet si celui-ci a bien été reçu par le correspondant, ce qui engendre des paquets supplémentaires par rapport à UDP. TCP est ainsi capable de savoir si un échange ou une information n'a pas été reçu et de la retransmettre au besoin, ce que ne fait pas UDP.

Tout cela pour souligner que dans notre cas, les échanges TCP ont un désavantage qu'il faut prendre en compte par rapport à l'UDP. En effet, le TCP va générer plus d'échanges (et donc de consommation de ressource) par rapport à UDP mais va vous assurer que les informations reçu le sont dans le totalité. Il y a donc un choix à faire qui dépend de vos ressources disponibles et du nombre de client et d'informations gérées par votre serveur. Pour mettre les échanges en mode TCP, il faut recommenter ces lignes dans le fichier de configuration serveur, à noter que les deux méthodes peuvent cohabiter si on les met sur des ports différents, par exemple :

Sinon, il faudra commenter les deux lignes supérieures. Côté client, il faut ajouter cette ligne dans la configuration pour que les échanges s'effectuent en TCP :

*.* @@IP_SERVEUR:1514

Note : Les @@ doivent figurer dans la ligne de commande, le fait qu'il y en ai deux indique que les échanges se feront en TCP.

On peut laisser également deux lignes pour indiquer que les logs seront envoyés une fois en TCP et une fois en UDP. Cela présente peu d’intérêt mais permet de comprendre que l'on peut également envoyer nos logs sur plusieurs serveurs différents si on change l'IP d'une des deux lignes. On va ensuite redémarrer le serveur ainsi que le client si besoin :

service rsyslog restart

 IV. Rediriger ou copier selon la facilitie ou la priorité

Sous Linux quand on parle de gestion de logs, les facilites sont des catégories dans lesquelles les logs vont se "ranger" afin de mieux les archiver et les trier. Parmi ces facilites, on retrouve par exemple :

• auth : Utilisé pour des évènements concernant la sécurité ou l'authentification à travers des applications d'accès (type SSH)
• authpriv : Utilisé pour les messages relatifs au contrôle d'accès
• daemon : Utilisé par les différents processus systèmes et d'application
• kern : Utilisé pour les messages concernant le kernel
• mail :  Utilisé pour les évènements des services mail
• user : Facilitie par défaut quand aucune n'est spécifiée
• local7 : Utilisé pour les messages du boot
• * : Désigne toutes les facilities, par soucis de simplicité c'est ce que nous avons spécifié lors de notre première règle de redirection des logs un peu plus haut
• none : Désigne aucune facilites

En plus de ces facilites, nous retrouvons pour chaque facilities un niveau de gravité (appelé Priorité) qui va du plus grave à la simple information :

• Emerg : Urgence, système inutilisable
• Alert : Alerte. Intervention immédiate nécessaire
• Crit : Erreur système critique
• Err : Erreur de fonctionnement
• Warning :  Avertissement
• Notice : Évènement normaux devant être signalé
• Info : Pour information
• Debug : Message de debogage

On retrouve alors plusieurs façons de spécifier les logs qui nous intéressent et donc ceux que l'on va rediriger. Par exemple si l'on chercher à rediriger vers notre serveur de logs 192.168.19.145 uniquement les messages critiques et supérieurs concernant les mails sur le port UDP 514, on ajoutera la ligne suivante :

mail.err @192.168.19.145:514

On peut également rediriger tous les logs mails :

mail.* @192.168.19.145:514

On peut également saisir en une ligne plusieurs types de facilities et de priorité, on trouve pas exemple dans le fichier de configuration par défaut des lignes comme celles-ci :

*.=debug;\
       auth,authpriv.none;\
       news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
       auth,authpriv.none;\
       cron,daemon.none;\
       mail,news.none          -/var/log/messages

On voit ici que toutes les priorités debug sont redirigées vers le fichier "/var/log/debug" et que toutes les priorités info,notice et warn seront dans "/var/log/messages". Pour que ces filtres soient redirigés vers le serveur de logs, il suffit de spécifier l'IP du serveur ainsi que son port comme fait plus haut à la place du nom du fichier.

V. Rediriger les logs vers un dossier/fichier par host

On peut également, pour faciliter la hiérarchisation et l'archivage de nos logs lorsque l'on a un grand nombre de client Rsyslog utiliser une arborescence avec un dossier/fichier par hôte plutôt que de mettre tous les logs dans le même fichier que le serveur de logs. On va pour cela utiliser une template que nous mettrons après le bloc "RULES" dans le fichier de configuration du serveur :

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

On va ensuite appliquer ce template à tous les logs entrants :

*.* ?syslog

Il nous suffira ensuite de redémarrer notre service rsyslog puis de générer des logs depuis les clients. On se retrouvera alors avec un dossier "/var/log/clients/" contenant un dossier par IP/nom client et contenant respectivement un fichier "syslog.log" avec les logs de chaque client respectif, ce qui simplifie la recherche d'information dans les logs d'un client précis

Mickael Dorigny Co-founder

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

See Full Bio