Centralisation et exploitation des journaux

système

Jonathan Schaeffer
OSU IUEM, service informatique
Technopole Brest Iroise
rue Dumont D’Urville
29 280 Plouzané

Résumé
Les journaux d’événements des systèmes et des services sont une ressource indispensable pour l’adminis-
trateur. On les exploite pour analyser une activité, pour détecter une anomalie ou pour déclencher des
alertes.
La multiplication des serveurs virtuels et des services à exploiter introduit un éclatement de ces journaux en
une multitude de fichiers sur un nombre important de serveurs. Les administrateurs doivent intégrer d’autres
contraintes. D’une part le législateur nous demande d’être en mesure de fournir les journaux d’activité sur
une année, d’autre part l’ANSSI préconise de gérer de façon centralisée cette mine d’information, dans le
cadre d’une démarche pour améliorer la sécurité d’un parc de serveurs. Il devient maintenant crucial de
gérer de façon fiable le volume de données produites par les journaux système.
Si des solutions simples existent pour concentrer les journaux (rsyslog, syslog-ng), elles ne consti-
tuent que la première partie d’une série de problématiques :
— déployer à grande échelle la concentration de logs ;
— s’assurer que ces configurations sont toujours en bon état ;
— exploiter la masse d’information qui sera concentrée.
Nous proposons ici des éléments de solution à ces trois problématiques. Ils sont déployés en production à
l’Institut Universitaire Européen de la Mer et s’appuient sur plusieurs éléments logiciels détaillés dans cet
article.

Mots clefs
Syslog, Gestion d’infrastructure.

1 Contexte de mise en œuvre

1.1 Recommandations et bonnes pratiques
L’Agence Nationale pour la Sécurité des Systèmes d’Information a publié une note technique rassemblant
un ensemble de 24 recommandations autour de la mise en œuvre d’une journalisation des systèmes d’infor-
mation 1 .
Parmi celles-ci, on trouve notamment l’export des journaux et leur centralisation sur un serveur dédié et la
mise en place d’outils de traitement, d’alertes et de consultations.
1. http://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Journalisation_NoteTech.pdf

JRES 2015 - Montpellier 1/7

1.2 Contexte local
L’infrastructure informatique de l’IUEM est devenue massivement virtualisée depuis plusieurs années. L’é-
quipe d’administration système a notamment appliqué la philosophie de l’isolation des services en déployant
de nouvelles machines virtuelles pour chaque nouveau besoin. Cette nouvelle pratique a augmenté de façon
radicale le nombre de systèmes en production. Une des contraintes qui accompagne cet accroissement est
la multiplication des journaux système et leur dispersion.
Une solution de gestion centralisée est rapidement devenue un enjeu important pour la surveillance, l’analyse
et la résolution des problèmes.

2 Objectifs et contraintes
Les objectifs du projet sont les suivants :
— sécuriser les journaux système ;
— proposer un outil de recherche et d’exploitation des journaux ;
— disposer d’un outil d’alertes basé sur les événements consignés.

2.1 Caractéristiques de la solution recherchée

La solution retenue respecte aussi les contraintes suivantes :
— fiabilité ;
— liberté des technologies ;
— s’appuyant sur des standards existants ;
— adapté à l’environnement GNU/Linux, mais pouvant collecter des journaux issus de systèmes Micro-
soft Windows ;
— modularité des ressources mises en œuvre.
Sur ce dernier point il est important de noter que les dimensions d’une infrastructure informatique évoluent
très vite. Nous voulons pouvoir renforcer les ressources de traitement des journaux de façon transparente et
fluide.

2.2 Centralisation traditionnelle

La centralisation des journaux n’est pas un besoin neuf, et des solutions existent déjà avec une solide ex-
périence. Le protocole Syslog est devenu incontournable dans les environnements UNIX. Bien qu’existant
depuis les années 80, il fait l’objet d’une première RFC (RFC3164) en 2001 et d’une mise à jour plus récente
(RFC5424) datant de 2009.
Ainsi, un format d’échange qui a été créé pour un besoin spécifique et étendu progressivement à cause de
son succès, fait maintenant l’objet d’un formalisme qui permet à beaucoup d’implémentations de co-exister.
Parmi les implémentations de la RFC Syslog les plus répandues dans les environnement GNU/Linux on
peut citer rsyslog ou syslog-ng.
Ces outils permettent de facto l’export des logs sur le réseau et leur centralisation.
La solution choisie s’appuie sur ces éléments éprouvés.

JRES 2015 - Montpellier 2/7

2.3 Les nouveaux acteurs de la gestion de logs
Depuis quelques années, on voit émerger de nouvelles approches et de nouveaux outils pour la gestion des
journaux. Les logiciels que nous explorerons dans le cadre de ce projets sont libres.

2.3.1 Elasticsearch

Tout d’abord, les bases de données non-relationnelles (NoSQL) sont d’excellents supports pour le stockage
des journaux et leur exploitation. Les bases NoSQL s’appuient sur des paires clés/valeurs et des index afin
de manipuler efficacement un grand nombre de données non structurées. Le projet elasticsearch 2 est
un bon exemple de cette technologie, il est conçu comme une base de données distribuée, ce qui permet
de répartir son déploiement sur plusieurs postes de travail. Citons également redis 3 , un autre système
NoSQL permettant de gérer des queues de messages.

2.3.2 Logstash

On voit également arriver de nouveaux projets pour la gestion des logs, avec des partis pris différents.
Parmi eux, le très populaire logstash 4 gère les journaux en 4 étapes :
La collecte : Les événements peuvent être extraits d’une grande quantité de sources différentes ;
La normalisation : Les événement collectés peuvent être transformés de façon très permissive, pour par
exemple devenir conformes à la RFC Syslog ;
Le transfert : logstash fonctionne en architecture client-serveur pour transporter les événements sur le
réseau ;
Le stockage : De nombreuses possibilités de stockage sont disponibles pour l’administrateur, et parmi elles
l’enregistrement dans une base elasticsearch.

2.3.3 Kibana

Enfin, tirant parti des possibilités de la base NoSQL elasticsearch et des technologies issues du dé-
veloppement Web, le projet Kibana 5 propose une interface d’exploration des logs très efficace à partir d’un
navigateur web.
Ces trois briques étant souvent assemblées, on les désigne fréquemment sous leurs initiales ELK.

3 Mise en œuvre
La solution mise en œuvre dans le système d’information de l’IUEM s’appuie à la fois sur les technologies
éprouvées et sur les nouvelles possibilités offertes par les nouveaux acteurs.
La figure 1 décrit l’infrastructure mise en œuvre. Celle ci est décrite, brique par brique dans les sections
suivantes.
Si le traitement des messages traverse de nombreuses étapes, l’ensemble reste robuste et résilient. Notre
implémentation ne prévoit pas de redondance mais il est possible de la mettre en œuvre pour chaque brique.
2. https://www.elastic.co/products/elasticsearch
3. http://redis.io/
4. https://www.elastic.co/products/logstash
5. https ://www.elastic.co/products/kibana

JRES 2015 - Montpellier 3/7

 Syslog NG

Elasticsearch

Logstash Logstash
Redis
shipper Indexer

Figure 1 - Architecture du système

3.1 La collecte et l’expédition

Ce travail a lieu sur chaque système de l’infrastructure. Il s’agit de collecter les journaux système pour les
expédier vers le serveur centralisé.
Cette étape est critique et nous voulons qu’elle réponde à un critère de fiabilité fort.
Au moment de la mise en œuvre de ce projet, logstash semblait plein de promesses mais trop jeune pour
être déployé massivement, notre choix s’est donc porté sur syslog-ng, une implémentation libre du RFC
Syslog et développé par l’entreprise Balabit, réputé pour sa fiabilité et son efficacité.
Tous les systèmes de notre infrastructure déploient syslog-ng avec une configuration leur permettant
d’exporter ces messages.

3.2 La centralisation
Un serveur dédié est chargé de collecter les événements. La collecte se fait aussi par syslog-ng qui a
deux fonctions :
Tout d’abord, il copie des événements dans une arborescence de fichiers permettant de retrouver les évé-
nements par système source et par type. Ensuite, il transmet les événements, sans les modifier, au point
d’entrée pour leur bancarisation. Ce message transite par protocole UDP sur le même serveur, vers un port
tenu par le shipper logstash.

3.3 La bancarisation
Les journaux étant maintenant centralisés, nous souhaitons les enregistrer dans une base de données non-
relationnelle. Pour cela, nous avons mis en place une grappe (cluster) elasticsearch. En pratique,
cette grappe n’est composée que d’un seul nœud, mais au besoin, il est possible de l’étendre sur un nombre
arbitraire de nœuds.
Le service de centralisation syslog-ng ne peut pas écrire directement dans la base elasticsearch
(toutefois, cette fonctionnalité a été ajoutée à la version 6.4 de rsyslog et à la version 3.7 de syslog-ng,
au prix d’une emprunte mémoire importante).

JRES 2015 - Montpellier 4/7

Pour compléter cette chaîne de traitement, nous utilisons un intermédiaire : le service redis, un gestion-
naire de file FIFO qui stockera les événements en attente de bancarisation. redis, comme elastic-
search est distribué par design. Il est donc possible de le renforcer par plusieurs autres instances afin
d’améliorer la résilience.
Maintenant, afin d’écrire dans la file redis d’une part et d’en lire et traiter les messages d’autre part, nous
faisons entrer en scène deux instances logstash.
La première instance (le shipper) écoute les événements sur un port UDP et les transmet à la queue
redis.
La deuxième instance (l’indexer), récupère les messages de la queue redis afin d’effectuer plusieurs
traitements.
Tout d’abord, en appliquant une série de règles l’indexer peut lever des alertes. Nous détaillerons cette
étape dans la section 3.5.
Ensuite, logstash enregistre l’événement dans la base de données elasticsearch.

3.4 L’exploitation
La solution décrite est distribuée. Chaque élément peut être déployé sur un ou plusieurs serveurs, tout en
conservant le point d’entrée unique pour l’interrogation des messages.
La base elasticsearch, l’indexer logstash, le gestionnaire de files redis, le shipper log-
stash, et le centralisateur de logs peuvent être répartis en plusieurs instances et sur plusieurs serveurs, afin
de s’adapter aux dimensions de l’architecture.
Par ailleurs, il est possible d’arrêter des éléments de cette chaîne sans perdre de messages. Ainsi, faire des
mises à jour de chaque élément du système peut se faire sans arrêt.
Enfin, les messages stockés en fichiers ou dans la base elasticsearch sont nettoyés une fois par mois
afin d’éliminer les informations trop anciennes.

3.5 Les alertes

Afin de lancer des messages d’alerte aux administrateurs ou aux utilisateurs, nous nous servons de l’indexer.
logstash est capable d’interpréter le contenu des messages de logs. On a défini des règles permettant, en
fonction d’une expression régulière, de la sévérité du message, du programme l’ayant généré, de lancer un
message d’alerte par voie de messagerie instantanée (protocole XMPP) aux administrateurs systèmes.
Par exemple, une connexion SSH sur tel serveur par tel utilisateur peut déclencher l’envoi d’un message.
Pour réaliser ce système d’alertes, il suffit de configurer une sortie au niveau de l’indexer, spécifiant
une condition sur la teneur du log et une méthode de sortie. La condition peut être par exemple sur le
programme émetteur du log (sshd) et le contenu du message (une connexion de l’utilisateur lagaffe). La
sortie sera un message XMPP à destination de Joseph Longtarin. Le code listé dans la figure 2 montre un
extrait de configuration de logstash.

3.6 Le tableau de bord

L’interface d’interrogation des événements ainsi centralisés est servie par le projet Kibana. Il s’agit d’une
interface web permettant de construire un tableau de bord personnalisé et qui affiche à la fois les messages
et les métriques.

JRES 2015 - Montpellier 5/7

 output {
if [syslog_program] == "sshd" {
if [@message] =~ /(lagaffe)|(jules-de-chez-smith-en-face)/ {
xmpp {
message => "Connexion sur la machine '%{@source_host}':
'%{@message}'"
password => "devine!"
user => "monitor@jabber-iuem.univ-brest.fr"
users => ["joseph.longtarin@jabber-iuem.univ-brest.fr"]
} } } }

Figure 2 - Extrait de configuration logstash pour une alerte par messagerie instantanée

Il est possible de construire plusieurs tableaux de bords correspondants aux besoins de plusieurs vues. Par
exemple, mettre en évidence les accèes SSH refusés par serveur sur les 2 derniers jours, compter le nombre
de messages d’erreurs par hôte, ou encore montrer une répartition des événements par sévérité.
La figure 3 montre un exemple simple de tableau de bord avec un histogramme du nombre de logs de sévérité
supérieure à ”warning”.

4 Retour d’expérience
Le système décrit ci-dessus est en production depuis 2 ans. Il a prouvé sa robustesse et sa capacité à répondre
aux attentes de notre équipe d’exploitation.
Voici quelques éléments chiffrés sur les dimensions de notre système :
Serveurs collectés 118
Nombre de messages 487 millions
Nombre de messages par mois 27 millions
Taille de la base 195Go
L’architecture décrite est déployée sur un seul serveur virtuel qui est correctement dimensionné pour le parc
considéré.
Cette solution a aussi eu un effet de bord très positif. En effet, nous utilisons de façon plus systématique
le protocole syslog dans tous les développements d’outils d’administration ou les produits déployés (par la
commande logger ou les bibliothèques de différents langages de programmation).
C’est un bénéfice considérable pour la surveillance de l’activité des tâches automatiques et pour le débogage,
car l’interface de consultation centralisée et le système d’alerte sont une valeur ajoutée immédiate.

5 Conclusion
Avec cette architecture, nous répondons aux recommandations ANSSI suivantes :
R5 export des journaux ;
R6 centralisation des journaux ;
R7 possibilité de redondance de l’infrastructure de gestion des journaux ;
R9 transfert en temps réel de journaux ;

JRES 2015 - Montpellier 6/7

 Figure 3 - Capture d’écran du tableau de bord

R10 ne pas effectuer de traitement avant le transfert ;

R11 envoi par protocole TCP ;
R16 stockage des journaux sur un espace dédié ;
R17 stockage sous forme d’arborescence par serveur ;
R22 consultation des journaux par un outil spécifique ;
Les autres recommandations découlent naturellement et directement de l’architecture principale (horoda-
tage, collecte par des process non-privilégiés, rotation des événements collectés, ...).
La consultation et la recherche d’événements par l’interface web Kibana est à la fois intuitive et efficace. Elle
remplace avantageusement les recherches dans des fichiers textes séparés par jours et compressés. Toutefois,
son usage nécessite une prise en main et un changement de paradigme de la part des administrateurs qui n’ont
pas acquis le réflexe de la consulter.
En deux ans, le projet logstash a acquis une maturité et une notoriété satisfaisante. elasticsearch et
logstash sont sur le point de publier leurs versions 2.0. Par ailleurs, rsyslog et syslog-ng ont tous deux
évolué dans la même période de temps et tiennent compte de ces nouveaux acteurs en proposant l’export
des journaux vers redis ou vers elasticsearch.
Ces progrès offrent des perspectives d’amélioration du système présenté, notamment la possibilité pour
syslog-ng d’enregistrer des messages directement dans redis ou dans elasticsearch. Ainsi, une
évolution possible constituerait à s’affranchir de plusieurs briques de l’architecture présentée ici et de la
simplifier radicalement.

JRES 2015 - Montpellier 7/7