Graylog : Article
Problématique
Contexte
C'est la que les logs deviennent importants. Ils permettent d'étudier le comportement exact du système et aussi de tracer la cause du problème :
Qui, quoi, quand, comment et pourquoi ?
Le Log Management
Le log management, ou «gestion d’historique» en français, est un ensemble de pratiques permettant la collecte et la manipulation des journaux d’événements produits par des équipements informatiques. Cela consiste plus précisément en plusieurs pratiques qui permettent d’aboutir à un résultat plus simple à comprendre et à analyser, plutôt que la consultation directe des logs par un humain.
Plusieurs raisons peuvent motiver la mise en place d’une solution de gestion de logs :
Vitesse de génération : Les logs sont générés dès lors qu’un événement se produit et bien que les logs soient générés dans des fichiers liés au service qu’il concerne, on ne peut parfois pas suivre le déroulement des événements aussi vite qu’ils se produisent. On parle parfois de plusieurs dizaines d’événement à la seconde par service
Volume des données : Bien qu’étant des fichiers textes, les logs sont produits en permanence et parfois très rapidement, par chaque service et par chaque système. La quantité de données est très grande et nécessite des tailles de stockage potentiellement immenses suivant la stratégie de collection et de rétention.
Normalisation : Les logs sont des lignes de texte, mais ces lignes ne sont pas toujours formalisées de la même façon. Il est nécessaire de savoir normaliser leur génération afin de réduire les formats et de les rendre plus facilement lisibles par les collecteurs.
Véracité :
Tous les logs sont-ils utiles ? De la même façon qu’un administrateur réseau peut paraître inutile lorsque tout son système fonctionne, les logs sont-ils intéressants même quand tout va bien ? La première réponse est oui, il est impossible de pouvoir certifier que tout va bien et encore moins que la situation ne sera pas amenée à changer. Il est donc important d’avoir une génération constante des logs pour s’assurer de comprendre la situation en cas de perturbation. Ensuite, comment peut-on valider que tout fonctionne parfaitement ? Certains services peuvent très bien continuer de fonctionner malgré des erreurs (parfois non critiques). Leur configuration peut aussi être non optimale et entraîner un comportement du système normal pour lui mais non désirable pour l’utilisateur.trice. L’observation des logs peut aider à corriger ces problèmes voire à les anticiper.
Tous les logs sont-ils pertinents ? Certains systèmes produisent des logs d’alerte en se basant sur des principes de détection d’erreur, d’intrusion ou produisent simplement des logs avec une criticité très faible. Il est normal d’avoir des logs peu pertinents voir même des fausses alertes qui « polluent » le fil de logs.
L'utilité pour notre entreprise
Graylog
Puissant outil de log management, Graylog se base sur des produits fiables et propose de nombreuses fonctionnalités. C’est un produit extensible en fonction de nos besoins, il répond globalement à toutes les problématiques et à l’avantage d’être gratuit et open source.
L'installation d'un serveur Graylog permet de mettre en place une collecte de logs provenant de sources multiples,sous multiples formats et d'en effectuer une gestion fine au sein d'une plateforme commune.
Technologies utilisés par Graylog dans cet article :
Schéma de fonctionnement
Configuration multi-serveurs détaillée
Récupérer des logs et construire une requête
Configuration de la source
Sans agent : La plupart des équipements générants des logs utilisent des formats de log standards
(syslog, RFC 5424) et prennent en charge la redirection des logs vers un serveur de log distant. Il faut configurer les sources de logs en spécifiant au moins le serveur de log distant (le serveur Graylog), le port utilisé.
Avec agent : Certains systèmes génèrent des logs avec des formats spécifiques (Windows et son observateur d'événements par exemple). Ceux la necessitent un agent (aussi appellé “collecteur”) qui, une fois installé et configuré s'occupera de “traduire” puis d'envoyer les logs sur le serveur de gestion des logs.
Création de l'input : Il est nécessaire de configurer Graylog pour qu'il accepte des sources et formats de logs qui lui sont envoyés.
Établir la demande :
Rechercher les messages
Rechercher le log exact donné lors d'une authentification échouée :
Afficher la liste des messages en question via la recherche de Graylog:
gl2_source_input:'votre input' AND source:'votre pare-feu' AND message:"could not authenticate"
Créer un dashboard (étape optionnelle mais permettant d'avoir une vue rapide sur les logs):
Un premier tableau listant l'ensemble des logs liés à l'authentification VPN pour cette source
Un compteur des erreurs d'authentifications
Un diagramme permettant de visualiser rapidement le taux de réussite d'authentification
Définir un événement via l'onglet Alerts et via “Create Event Definition” : Cette étape définit les critères de déclenchement des alertes.
Spécifier la requête exacte, dont les résultats définissent l'apparition d'un événement.
Spécifier le Stream, qui défini les sources de logs à utiliser
Déterminer la fréquence de vérification
Dans notre cas :
-
Il reste bien entendu possible d'effectuer des requêtes différentes, de personnaliser les tableaux en fonction de la requête et de changer la définition d'un événement, en se basant sur la fréquence d'apparition d'un log plutôt que sur son existence.
Exemples
Exemples d'utilisation de Graylog
Conclusion
Problématiques soulevées
La quantité de données est énorme, le choix de rétention sur la rétention des logs est à étudier et doit être réfléchi afin de ne pas se retrouver avec des disques durs saturés de données ou à l'inverse de ne pas avoir récupéré assez d'information.
Quelle solution optimale dans le cas de l'entreprise ? Centraliser ? Décentraliser ? Dans le cas de l'infogérance de notre infrastructure multi-sites, il faut bien établir la façon dont seront collectés les logs :
en local via un serveur de log dédié chez chaque client qui retransmet les informations à un serveur distant Graylog central.
en distanciel, les logs seront envoyés directement vers le serveur central ?
via des serveurs Graylog locaux (des nodes) qui seront ensuite accessibles et gérés depuis un serveur central distant?
Comment intégrer et faire évoluer notre façon de travailler à l'aide d'une solution de log management ? Le log management permet de nombreuses opportunités, au niveau le plus technique comme pour du support utilisateur, il est important que cet outil soit maîtrisé et intégré à nos habitudes de travail.
Quelle importance y attribuer ? La collecte des logs, la mise en place de tableaux de bord, la création d'alertes pertinentes, l'affinage des recherches, cela représente un temps de configuration relatif à l'importance qu'on y attribue.
Évolution
Cet article est une introduction au log management et présente la puissance d'un tel outil. Nous pourrons aborder dans un futur article l'utilisation des fonctions avancées de Graylog (Decorateurs, Streams, Pipelines…) qui n'ont pas été toutes abordées ici.
Nous avons intégré Graylog à notre routine de résolution des incidents et nous continuons d'adapter cet outil a notre cycle de travail. C'est à dire faire en sorte que l'information que Graylog collecte, analyse et nous retransmet soit pertinente, lisible et accessible. L'objectif serait aussi de proposer nos solutions à la communauté, Graylog mettant en place des outils de communication et de partages des contenus créés par ses utilisateurs.