Salut à tous, j’espère que vous avez passé des bonnes vacances ? Aujourd’hui on continue la série d’article sur Splunk et on va intégrer des logs dans Splunk sans utiliser une application existante. On va développer notre propre App Splunk de type « TA » pour intégrer des logs VSFTPD. La documentation officielle de Splunk sur le sujet est ici et là.
C’est quoi une « App » Splunk déjà ?
Techniquement, une App Splunk est un ensemble d’éléments Splunk parmi des scripts, rapports, commandes de recherche, d’entrées de données, de sourcetypes, de lookups, d’alertes, etc. packagés ensemble pour une technologie ou un cas d’usage spécifique dans le but de faciliter la vie des utilisateurs, opérateurs ou des admins.
Dans ces Apps, vous entendrez aussi parler d’Add-on de Splunk, il s’agit également d’applications au sens technique, mais dépourvu d’interface graphique.
Et encore parmi ces Add-on, on trouve encore les « TA » (pour « Technology Add-on ») qui sont des Add-on spécialisés dans la collecte, l’analyse et la normalisation (au sens CIM) de sources de données particulières pour aider à leur intégration dans Splunk. Si vous vous souvenez, mes TP Splunk sur Nginx et iptables se basaient sur ce type d’Add-ons pour intégrer les données.
Et Splunk supporte très bien l’intégration d’Add-on communautaire ou carrément maison et à même documenté précisément comment faire avec le Splunk Add-on Builder que vous trouverez ici.
Splunk Add-on Builder
On va pas chercher midi à 14 h, Splunk propose une App dédié pour le développement de ses propres Add-on, on va donc l’utiliser. L’installation est documentée ici, donc je vous laisse suivre les instructions, c’est pas bien compliqué. Notez tout de même la dépendance au Splunk Common Information Model Add-on.
/opt/splunk/bin/splunk install app splunk-add-on-builder_220.tgz /opt/splunk/bin/splunk install app splunk-common-information-model-cim_4110.tgz service splunk restart
Vous trouverez alors l’App dans le sélecteur d’App en haut à gauche.
Activer les logs vsftpd
Le sujet de ce TP n’étant pas d’installer le serveur ftp, je suppose que vous en avez déjà un. Néanmoins, je préfère vous préciser comment configurer les logs de vsftpd dans le fichier /etc/vsftpd.conf :
## logging # Utiliser 2 fichiers distincts (pour les commandes FTP et les transferts) dual_log_enable=YES # Activer le logging des uploads/downloads dans un fichier dédié.. xferlog_enable=YES xferlog_file=/var/log/vsftpd.xfer.log # activer les logs des commandes FTP log_ftp_protocol=YES vsftpd_log_file=/var/log/vsftpd.log
Extrait du manuel à lire avec « man vsftpd.conf ». Bon à noter, vsftpd est également capable de pousser en syslog ses données si vous êtes dans un environnement réparti.
Créer son App Splunk
Notez qu’il existe déjà une application TA non officielle pour vsftp sur GitHub, je ne l’ai pas testé même si j’ai relu les sources pour préparer ce post. Si ça se trouve elle fait le boulot bien mieux que ce que je vais faire… Mais bon, because we can, hein. Bref, accéder à l’application et créer un nouvel Add-on nommé TA-vsftpd. Une fois l’Add-on créé vous vous retrouverez sur cette page :
Alors les bonnes nouvelles, c’est que puisqu’on va simplement superviser un fichier de log, on a pas besoin de configurer la collecte de donnée, ni de configurer une page d’installation. Et on peut donc passer directement à la configuration du sourcetype. Dans notre App Splunk, il suffit de cliquer sur « Manage Source Types » en haut, puis sur le bouton ajouter nouveau sourcetype. Nommez le vstftpd:log et téléversé un exemple de données pour pouvoir travailler sur votre sourcetype.
Créer le sourcetype
La première étape consiste à indiquer ce qui sépare nos événements entre eux. Ici c’est le cas le plus simple : chaque ligne est un événement distinct. Il faut ensuite s’attacher à extraire la date de l’évènement de son texte. Pour cela le mode auto fonctionne vu que vsftpd utilise un format de date assez classique. Mais on peut aussi le préciser comme ci-dessous dans l’interface en mode avancé avec une description au format strptime (man). Ici le format complet c’est « %A %b %d %H:%M:%S %Y » donc, notez que j’ai réduit le paramètre « Anticipation » de 128 à 32, les logs vsftpd commençant toujours par la date, pas besoin d’aller chercher très loin si Splunk ne la trouve pas en début de ligne.
Remarquer pour la suite que votre configuration se retrouve copiée dans la partie avancé avec les paramètres TIME_FORMAT et MAX_TIMESTAMP_LOOKAHEAD par exemple. À ce stade vous pouvez cliquer sur Enregistrer. Et pour finir ce paragraphe, je vous repointe un peu de doc pour les sourcetypes.
Parser les données : extraire les champs
Assez logiquement on clique sur l’onglet Extraction de champs en haut de la page. Après on a le choix entre une extraction « automatique », une extraction manuelle et une transformation manuelle. Les deux premières permettent de définir une expression régulière pour séparer les données et extraire les différents blocs. La dernière permet d’effectuer des modifications sur les champs (par exemple : remplacer un code http par son texte 200->success, 404->not_found, etc.).
Dans notre cas, on a pas besoin de modifier nos données donc c’est un mode automatique ou manuel d’extraction, à choisir selon que vous êtes un regex-guru ou pas ! Ici on est des bons geeks, donc on va faire ça avec une jolie regex ! De toute façon, le mode automatique ne s’en sort pas super bien dans ce cas de donnée non structurée.
Manual extraction of vsftpd.log with a regex
Lorsque vous cliquer sur Manual Extraction vous pouvez choisir d’ouvrir l’extracteur de champs ou de créer une nouvelle extraction de champs. Ouvrez l’extracteur et sélectionner le sourcetype vsftpd:log. Sélectionner un événement type, qui servira d’exemple pour la suite. Cliquez sur suivant et sélectionner la méthode par expression régulière. L’outil vous demande de surligner les champs à extraire, c’est automatique mais pas forcément très efficace, Je vous conseille donc d’éditer vous-même l’expression régulière. Par exemple avec quelques lignes de logs sur le site regex101. Si vous n’y connaissez rien en regex, ce n’est pas l’objet de ce TP, mais je vous conseille de vous y mettre rapidement si vous devez faire du Splunk à l’avenir.
Bref, dans le cas de mes logs vsftpd, la regex pourrait être celle-ci :
^[^\[]+ \[pid (?<pid>\d+)\] (\[(?<user>\w+)\])?\s?(?<result>\w+)\s?(?<vendor_action>[^:]+)?: Client \"(?<src_ip>[^\"]+)(\", \"(?<cmd>.+)(\"$|\", )((?<size>\d+) bytes, (?<speed>\d+.\d+)(?<speed_unit>.*$))?)?\"?$
Les plus attentifs auront noté que je match les adresses IP avec [^\ »]+. Déjà parceque c’est plus lisible pour l’article, en particulier si on veut supporter IPv6 sans se casser la tête à matcher avec une regex valide uniquement sur des IPs. Tout dépend si vous voulez des erreurs dans vos logs Splunk quand ça ne match pas ou une valeur aberrante mais que Splunk à correctement extrait. Dans le cas d’une extraction de log c’est tout à fait pertinent, le jour ou vous faites de la validation de données, ne faites surtout pas ça hein…
Cliquer sur suivant et vérifier que tout vos évènements matchs bien avec votre regex et modifiez si besoin celle-ci pour matcher le maximum d’évènements avant de terminer.
Recommencez la même opérations pour les logs de transfert, il vous faudra recréer un sourcetype vsftpd:xfer et un field extraction. Je vous laisse celles-ci pour les transferts en exercice avec une solution ci-dessous, elle n’a rien de plus compliquée que celle au-dessus avec cette doc.
^([^\s]+\s+){5}(?<transfert_duration>\d+) (?<src_ip>[^ ]+) (?<bytes>[0-9.]+) (?<file>[^ ]+) (?<transfer_type>\w) (?<special_action_flag>\w) (?<direction>\w) (?<access_mode>\w) (?<user>\w+) (?<service_name>\w+) (?<authentication>\d+) (?<authenticated_user_id>[^ ]+) (?<commpletion_status>\w)$
CIM compliant vsftpd data model
Bon nos champs que j’ai extrais ont des noms arbitraires, ce serait bien si ma TA pouvait être compatible avec le CIM de Splunk. Et ça tombe bien la doc de Splunk explique cette partie en détails dans les pages suivantes : ici, là, là, et encore là. Les tags qui vont fonctionner avec notre modèle de données sont change et authentication selon nos types d’évènement (action sur des fichiers ou login sur le service FTP). Notez que l’application TA non officielle pour vsftp sur GitHub dont je vous parlais plus haut implémente le modèle CIM. Ça peut vous donner un exemple de ce qu’il faut faire. Mais pour faire simple, vous devez :
- Identifier quelle table du CIM Standard Splunk correspondent à vos évènements (ce qui définira des tags).
- Faire correspondre par des EVAL ou des ALIAS des champs de vos évènements à des champs valide dans le data model (exemple dans notre cas : result correspond à status dans change, et vendor_action à action toujours dans change, etc.).
C’est un peu répétitif et pas vraiment utile si vous avez peu de données dans votre Splunk. Ça devient carrément indispensable quand vous avez plusieurs dizaines d’index et des gros volumes de données à croiser dans votre Splunk.
Dans notre cas on pourrait avoir deux « eventype » : les actions sur les fichiers/répertoires et les actions de login avec les définitions suivantes :
Il vous faut ensuite construire les champs CIM valides à partir de ceux de vos évènements et les taguer correctement par type d’évènement.
Exemple :
Tous les évènements de type vsftpd_change_file définit ci-dessus matchent avec la catégorie CIM « Change Analysis->FileSystem change » et on peut mapper les champs file_size, command, dest, src, user, vendor_product et action via des alias des eval de nos champs déjà définis.
Il suffit ensuite de refaire de même pour chaque type d’évènements que vous souhaitez créer.
Validation pour une App Splunk certifiée
À partir de là vous avez terminé votre App Splunk, si le cœur vous dit vous pouvez vérifier que celle-ci suit les best-practice Splunk et éventuellement corriger les bugs qu’il vous remonte.
Et lorsque que votre App est prête rien ne vous empêche de la soumettre pour publication sur splunkbase.splunk.com. Et c’est d’ailleurs comme ça que cette App splunk s’est retrouvée ici. Je l’ai mise sous licence MIT, donc feel free de modifier, corriger si elle ne vous semble pas correcte.
Byz !
PS : quelques sources en vrac pour créer un votre propre App Splunk :
- http://docs.splunk.com/Documentation/Splunk/7.1.1/Knowledge/AboutSplunkregularexpressions
- http://docs.splunk.com/Documentation/AddonBuilder/2.2.0/UserGuide/ExtractFields#Manual_extraction
- http://docs.splunk.com/Documentation/Splunk/7.1.1/Knowledge/ExtractfieldsinteractivelywithIFX
- http://dev.splunk.com/view/addon-builder/SP-CAAAFCC
- http://docs.splunk.com/Documentation/AddonBuilder/2.2.0/UserGuide/Overview
Merci pour la typo, c’est corrigé, et ton message !
Bonjour Etienne, petite coquille :
« Splunk propose une App dédié pour le développement (de) ses propres Add-on »
Merci pour cette série super interessante