Graylog à l'usage - retour d'utilisation

Dans un précédent billet, je me suis concentré sur l’installation de Graylog sur mon serveur auto-hébergé. Dans ce qui suit, je ne me propose pas de tout détailler, notamment parce que la documentation est déjà assez bien faite [Documentation]. Ici, nous allons plutôt faire un peu plus connaissance avec l’outil pour en ressortir ce qui me semble important et pour comprendre la logique de son fonctionnement.

Les entrées (Input)

C'est une partie que j’ai mentionnée dans le billet précédent. Pour pouvoir récupérer des logs, il faut avant toute chose définir par quel biais on va être amené à les récupérer sur nos serveurs. La quasi-totalité de mes machines tournant sous GNU/Linux, je ne me suis pas compliqué la vie et j'ai simplement paramétré une entrée en "Syslog UDP" et une autre en "Syslog TCP" pour la forme (bien que je puisse me passer de cette dernière en fait ; à voir ensuite si je dois la supprimer ou non). Pour ces deux entrées, j'ai spécifié qu'elles devaient tout récupérer (cocher "global") et j'ai indiqué le port à regarder (1514 ; souvenez-vous que je redirige tout ce qui arrive sur le port 514 vers le pour 1514). Pas de chiffrement des données dans mon cas lors du transfert.

Rechercher de la donnée intéressante

À ce stade, on doit voir les premiers logs affluer lorsque l'on se rend dans le menu "search". Chaque log est décomposé en plusieurs champs (application_name, facility, level, message, process_id, source et timestamp). Il est possible d'afficher ou non, de manière globale, chacun de ces paramètres.

Rapidement, il est souhaitable de rechercher l’information pertinente dans ce flot de logs. Pour avoir un ordre d'idée, mon serveur une fois en place, réceptionne environ 20000 lignes de log quotidiennement et on ne parle ici que d'un petit serveur auto-hébergé faisant tourner peu de services. Graylog propose donc différents outils pour rechercher dans les log. Du haut de l’interface vers le bas on trouve :

• La période temporelle de recherche (en absolu ou en relatif).
• Le ou les filtres à appliquer.
• Pour chaque champ de log, on peut choisir l’affichage du graphe ou du compteur associé.

Si l'on souhaite par exemple afficher toutes les logs contenant un code erreur HTTP 404 durant la journée passée, il suffit de procéder comme suit :

• Sélectionner "search in the last 1 day" dans le fenêtre temporelle (relatif donc).
• Dans le champ de recherche, taper :
  application_name:apache && message:404

Le graphe temporel et les logs associés vont alors s'afficher. L'étendue des possibilités de recherche est bien entendu beaucoup plus large que celle de ce petit exemple [Documentation "Search"]. Il est possible ensuite d'affiner la recherche en sélectionnant avec la souris la zone sur le graphe qui nous intéresse particulièrement.

Tableaux de bord (Dashboard)

Voir les données et les manipuler en temps réel c'est bien mais les suivre sur la durée, c'est encore mieux. Les tableaux de bord sont faits pour ça et ils se créent en trois temps.

• Il faudra tout d'abord créer un (ou plusieurs) tableau(x) de bord en donnant à chaque fois un titre et une description à celui que l'on crée. À ce stade, ils sont encore vides.
• Pour remplir un tableau de bord, rien de plus simple. Depuis le menu "search", il y a à côté de chaque graphe ou compteur, un bouton permettant de l'ajouter à un tableau de bord. Dès qu'un graphe est pertinent, on peut donc l'ajouter à un tableau de bord en particulier.
• Une fois le tableau de bord rempli, il ne reste qu'à organiser les différents élément à l'intérieur. La réorganisation se fait par glisser/déposer, on peut agrandir ou étirer un peu comme on veux les diverses ressources à l'intérieur. Cela permet de hiérarchiser l'information par exemple.

Les extracteurs (Extractor)

Pour chaque entrée de log (voir précédemment), on peut définir ce que l'on appel des extracteurs. L'idée est que dans les logs, il y a de l'information qui mérite d'être stockée dans un champ à part dans la base de Graylog. Pour créer un extracteur, il faut donc se rendre dans l'entrée qui nous intéresse et choisir "manage extractors". L'extracteur va opérer sur un seul champ des logs. On peut choisir un type d'extracteur pour le champ retenu (split, regex, sous-chaîne, ...). Une fois cela fait, il reste à définir exactement ce que l'on veux extraire.

Le cas d'école est l'adresse IP contenue dans une large proportion de champs "messages" des logs. Là, il suffit de choisir un "regex" appliqué au champ "message" et d'y rechercher les paterns correspondants à l'adresse IP :

(([0-9]{1,3}\\.){3}[0-9]{1,3})

Reste à définir le nom du champ où doit être rangé la donnée extraite lorsqu'elle est identifiée. Une fois l'extracteur en place, les nouveaux logs sont traités et ce champ commence lui aussi à se remplir.

Géolocalisation (approximative)

A titre indicatif, il peut être intéressant de connaître l'origine géographique des différentes requêtes. Avant toutes choses, les résultats doivent être interprétés avec une certaine précaution pour deux raisons :

• D'une part elles peuvent être affectées à une entité à un instant donné et passer à une autre peu de temps après. La précision dépend donc de la fraîcheur de la base d'IP que l'on emploie.
• Un utilisateur de VPN ou de Tor peut sortir n'importe où sur internet et cela quel que soit l'endroit où il se trouve réellement. La géolocalisation de l'IP perd dans ce cas de son sens.

Sans redécrire la procédure, il faut avoir en tête qu'il n'est possible de procéder à la géolocalisation par l'adresse IP que lorsque l'on dispose d'un champ contenant exclusivement une adresse IP. Il faudra donc impérativement avant mettre en place l'extracteur qui va bien (voir plus haut) pour isoler l'adresse IP.

Une fois cette opération effectuée, on voit apparaître de nouveaux champs au niveau des logs. Si l'on s'est basé sur un champs nommé "IP", on retrouvera suite à la mise en place de la géolocalisation IP sur ce champ les champs "IP_city_name", "IP_country_code" et "IP_geolocalisation". Il sera alors possible de travailler sur ces champs comme sur les autres (filtrage, ajout à des tableaux de bord).

Recevoir des notifications en cas de problème

Il est possible de paramétrer l'envoi de notifications en cas de problème détecté dans les logs. Je ne vais pas décrire ici comment procéder dans le détail (la doc est bien faite et on trouve facilement des ressources tierces où cela est bien expliqué aussi) mais juste la logique de la chose.

Dans un premier temps, il faut définir le périmètre que l'on souhaite surveiller. Pour cela, il faut se rendre dans le menu "Streams". On utilisera donc soit le flux par défaut, soit un flux que l'on créera pour l'occasion. Si l'on opte pour cette seconde voie, seuls les logs qui correspondent aux critères que l'on aura défini seront routés sur le flux en question.

Dans un second temps, il faut définir les critères permettant de lever une alerte. Pour cela, il faut se rendre dans le menu "Alerts". Dans le sous-menu "Conditions", on choisira d'ajouter une nouvelle condition sur le flux précédemment créé et selon un type de critère (correspondance sur un champ, correspondance sur plusieurs champs ou compteur d'évènements). Selon le type de critère retenu, on pourra alors définir précisément les critères permettant de lever une alerte. À ce stade les alertes qui sont générées restent au niveau de Graylog.

Enfin, il faut donc configurer la notification des alertes. Toujours dans le menu "Alerts", dans le sous-menu "Notifications", créer une nouvelle notification. On choisit le stream précédemment créé puis le type de notification.

À l'usage

Le but n'est pas uniquement de jouer avec des log et de s'émerveiller devant. Avant que je ne centralise mes logs, il était fastidieux d'identifier des faits liés à des erreurs de configuration de ma part ou à des actes malveillants. J'avais bien quelques scripts qui tournaient mais uniquement sur des points très précis et forcement, cela se faisait machine par machine.

Je perçois tout d'abord l'intérêt énorme d'une représentation graphique de ce qui se passe sur mes machines. En un coup d'œil, je vois un passer un certain nombre de choses et je peux être assez réactif. S'agissant par exemple des erreurs HTTP 404, je me suis rendu compte qu'une grosse part étaient liées à l'absence de fichier "robots.txt" ou de "favicon.ico" sur mon blog, ce qui pouvait déclencher un bannissement abusif de certains bots par fail2ban. Accessoirement, cela n'aidait pas à mettre en évidence les autres erreurs de ce type.

Cette centralisation des logs m'a aussi permis de mettre en évidence le fait que des outils que j'avais mis en place afin de faire des tests étaient toujours en fonctionnement (alors que je pensais les avoir désactivés). Typiquement, j'ai testé il y a quelques semaines un outil de filtrage en fonction de la géolocalisation IP et j'ai pour cela tiré 5 pays au hasard. Le test ne devait pas durer et pourtant, il était toujours en cours. La remontée s'est faite par une personne ayant consulté mon blog depuis l'étranger et en regardant attentivement les codes erreur HTTP 403, j'ai constaté que 5 pays d'origine étaient systématiquement rejetés. J'ai très vite désactivé cette fonctionnalité et tout est rentré dans l'ordre. Au passage, désolé encore pour ceux qui ont été impactés par cette action de ma part.

Quand on commence à résoudre tout ces petits problèmes de configuration on commence donc à voir émerger les vrais comportement anormaux et potentiellement malveillants. Je sais bien entendu qu'il y en a déjà un certain nombre sur des patterns que j'ai déjà identifié (scans permettant d'identifier si mon blog tourne sous Wordpress ou d'autre CMS, recherches de dossiers faisant référence à phpmyadmin, ...). Toutefois, je peux à présent plus facilement et rapidement identifier d'autres tentatives sortant elles un peu plus de l'ordinaire. Pour rappel, à l'époque où j'utilisais Wordpress, j'ai mis plusieurs mois avant de me rendre compte (par hasard) que mon blog avait été compromis alors même que j'avais remarqué qu'il se passait quelque chose d'anormal avec mon serveur apache au moment même de l'attaque. Aujourd'hui si ça se reproduisait, je serais alerté en temps réel et je pourrais donc être plus réactif.

Graylog utilise Elasticsearch et Mongodb. Pour autant, cela est totalement transparent une fois la solution en place et on n'agit en fait que sur Graylog.

Sans trop attendre, j'ai intégré la quasi-totalité de mes machines virtuelles ou physiques à cet outil de centralisation des logs. Il me reste encore à affiner certains réglages concernant les alertes ou les données que je souhaite suivre mais globalement, tout est déjà en place.