TA pour fail2ban, ma nouvelle App Splunk

Salut à tous, il y a quelques temps je vous ai proposé une App Splunk pour gérer les logs de VSFTPD et cette semaine j’ai réalisé une TA pour fail2ban. On va profiter de l’occasion pour s’attarder sur la structure d’un App Splunk en détaillant le contenu.

Pour ceux qui débarque la précédente App fail2ban proposée sur la splunkbase ne fonctionne pas, date de 2013, et n’est notée compatible qu’avec Splunk 6… Plus exactement, le format de log qu’elle supporte ne correspond plus du tout avec celui de fail2ban en 2019…

Du coup, j’ai fait une TA supportant le format de log de fail2ban actuel (testé sur les versions 0.9.6 et 0.10.2). J’ai appliqué la même démarche que pour VSFTPD et créé l’App via le Splunk Add-on Builder. Je vous laisse rejeter un œil à mon précédent article si vous voulez savoir comment on fait pour développer une App dans Splunk.

« TLDR », elle est où ta TA pour fail2ban ?

Comme celle pour VSFTPD, mon Technology Add-on Splunk pour Fail2ban est sur la Splunkbase. Enjoy !

Regex d’analyse des logs fail2ban

Il y a un élément dans le travail que j’ai fait pour cette App qui mérite d’être documenté spécifiquement ici : l’expression régulière de traitement des logs fail2ban. Donc sans transition :

(?J)^[^f]+ (?\\<vendor_product>[^\.]+).(?\<vendor_module>[^\s]+)\s+\[(?\<pid>[\d]+)]:\s(?\<vendor_level>[\w]+)\s+(\[(?\<jail>[^\]]+)]\s)?(?\<vendor_message>(?\<vendor_action>Found|Ban|Unban|Restore Ban)?\s?(?\<src>(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\s?(?\<vendor_action>already banned|is not banned| - ((?\<initial_date>.*))?)?|.*)$

Notez le (?J) au départ qui permet d’activer le mode PCRE2_DUPNAMES et autoriser plusieurs groupes de captures avec le même nom. Néanmoins, si l’option est bien détectée et supporté par Splunk, elle ne fonctionne pas avec Splunk, au moment au je rédige ces lignes, et j’ai dû ruser un peu dans l’App pour fusionner les valeurs. Voir Regex101 si vous voulez jouer.

Analyse des fichiers de l’App

Comme annoncé au départ, je ne vais pas vous parler de comment on développe une App, ça c’était le TP sur VSFTPD.

On va plutôt s’intéresser à la structure d’une application dans Splunk. Lorsque vous installez une application dans Splunk (que ce soit en important le fichier .spl/.tgz ou via l’interface) Splunk va en fait créer un dossier dans $SPLUNK_HOME/etc/dir (par défaut /opt/splunk/etc/apps/ donc). Dans ce dossier de l’App on va trouver les éléments suivants (voir doc et doc):

• app.manifest : le fichier App manifest est un JSON avec les informations de l’App : version, auteur, nom, description, etc.
• bin/ : Ce dossier contient les script personnalisé par exemple pour les entrées en script Python. Dans notre cas, celui-ci est vide, mon App de définissant pas d’entrée de donnée.
• default/ : Contient les éléments pré-configuré par votre App relatif à l’interface utilisateur : Dashboards dans le sous-dossier data/[views|htm] ou les configuration des menus de l’interface associés dans data/nav. Ils ne doivent pas être modifié en local.
• local/ : Contient les éléments de configuration local à votre App et qui peuvent être modifiés par les utilisateurs. Par exemple, si default/ contient des modèles de dashboard génériques. Vous devrez les éditer dans local pour les faire correspondre à votre configuration Splunk.
  • Mais surtout C’est dans local que vous trouverez les fichiers de configuration app.conf, eventtypes.conf, inputs.conf, props.conf et tags.conf.
    Il me semble important de détailler ces fichiers de configurations :
    • app.conf : contient les informations de configuration de l’App : activée/désactivée; visible dans l’interface, nécessité de redémarrer Splunk en cas de modification etc.
    • eventtypes.conf : comme son nom l’indique, ce fichier défini les type d’évènements qui sont proposés par votre App. Dans notre cas, je n’en défini qu’un : fail2ban_log. Mais par exemple concernant VSFTPD on y définissait 4 eventtype différent (attention un sourcetype est différent d’un eventtype)
    • inputs.conf : C’est ici que sont définies vos entrées de données. Par exemple, si vous monitorez le fichier /var/log/fail2ban.log avec l’App Fail2ban, c’est ici que sera enregistrer cette configuration.
    • props.conf : Surement le fichier le plus important dans la configuration d’un sourcetype. C’est ici que sont stockées les informations concernant le traitement des évènements. En particulier : la détection de date des évènement, l’extraction des champs (i.e. la regex plus haut), les transforms, ou encore les définitions d’EVAL ou d’ALIAS permettant la mise en cohérence avec le modèle CIM.
    • tags.conf : Comme son nom l’indique, le fichier permet de configurer les tags associé à vos évènements (attack, ids, network, authentication, etc.).
• metadata/ : comme son nom ne l’indique pas, le dossier contient respectivement les permissions par défaut de l’App et les modifications locales de ces permissions dans des fichiers .conf du même nom.
• README/ : Le dossier README est supposé contenir la liste des paramètre de votre App dans des fichiers .spec et un exemple de configuration dans un fichier .example.
• README.txt : le classique fichier README de votre App.
• static/ : Contient les ressources statiques de votre comme par exemple les icônes de l’application !

Il est important de connaitre ces fichiers au moins de nom, car le modèle de configuration de Splunk permet en effet d’intégrer plusieurs fois le même fichier et règle de configuration à différents niveaux.

C’est un peu trop long pour l’expliquer dans ce post mais je vous invite à lire attentivement la documentation sur le sujet et à creuser l’usage de la commande btool. Je reviendrai peut-être sur ce sujet à l’occasion.

Dashboard Fail2ban

En attendant je vous propose ce petit screenshot de dashboard pour fail2ban que j’ai donc pu réaliser facilement grâce à ma TA.

Voilà et bon fail2ban à tous.