Splunk, une usine à gaz ? (1/2)

Vous êtes de plus en plus nombreux à connaître Splunk mais également de plus en plus nombreux à avoir quelques inquiétudes sur le temps nécessaire à la mise en place de Splunk au sein de votre environnement. Je comprends parfaitement, mais en un sens, c'est un faux problème. Et ici malheureusement, la solution souffre un peu de sa force. Là où on demande à un serveur DNS de servir de serveur DNS, on ne demande pas à Splunk de ne faire QUE du log management (trop facile). Et forcément, plus on va aller loin dans l'exploitation du produit, plus on va avoir besoin de temps pour la configuration et plus les nouveaux besoins vont être précis et vont demander du temps pour que la configuration mise en place y réponde. "Nouveau besoin" est peut-être un mot clé ici d'ailleurs. Si la solution n'était pas magique ... on se poserait moins de questions et ce serait beaucoup plus rapide à intégrer (voir l'exemple du serveur DNS plus haut, avec tout le respect que j'ai pour mes collègues qui mettent en place des serveurs DNS ;) ). Et si on se posait moins de questions, on ferait beaucoup moins de choses "sexy" (globalement on ferait ce que sait faire la concurrence) ! Mais dans le cas de Splunk ... On commence par du log management, et comme ça marche ... on se dit qu'on va faire du reporting sur chaque brique de notre SI. Et comme ça marche ... on se dit qu'on va faire de l'alerting poussé. Et comme ça marche ... on se dit qu'on va faire de la corrélation. Et comme ça marche ... on se dit qu'on va utiliser la solution pour obtenir des infos vraiment "business" qui peuvent (doivent ?) avoir un impact au niveau décisionnel. Et comme ça marche ... on se lâche complètement et on se fait couler automatiquement un café après plus de 5 minutes de navigation sur des sites "récréatifs". Et comme ça marche ... bref, je l'aurai un jour, je l'aurai ! Complexe ? Non, comme n'importe qu'elle solution du marché, il faut la découvrir, l'appréhender et comprendre son fonctionnement avant de se lancer Long à mettre en place ? Forcément, certains besoins demandent plus de temps de travail que d'autres mais les résultats en sortie sont en général plus qu'à la hauteur de l'investissement. Le but de ce qui suit est de découper le produit en plusieurs fonctionnalités et de vous montrer que, globalement, il n'y a rien d'insurmontable (à partir du moment où on maîtrise Splunk ou qu'on Splunk "noir" comme diraient certains). First things first : it's software ! Splunk est un logiciel. Il n’est donc pas lié à un équipement spécifique au sens « hardware ». La solution est disponible sous plusieurs formes et permet d’être installée comme n'importe quel autre logiciel sur des systèmes d’exploitation divers et variés :

• Windows
• Linux
• AIX
• HP
• Solaris
• Mac OS

A noter aussi que Splunk peut s’installer aussi bien sur un système d’exploitation 32 bits que 64 bits. Enfin, il n’y a aucune contre-indication à l’installation de Splunk sur une machine virtuelle au sein d’un environnement VMWare par exemple. Cependant, il faudra s’assurer que le « sizing » de la machine virtuelle en question est réalisé selon les meilleures pratiques définies par Splunk, en particulier en ce qui concerne les accès disque, la RAM et le nombre de CPU. Facilité de mise en oeuvre et de configuration de la solution La mise en œuvre et la configuration basique de la solution Splunk s’effectuent en 5 minutes. L’indexation des logs de l’ensemble du SI et le déploiement d’une infrastructure d’envergure demandent quand à elle une réflexion en amont afin de mettre en place une solution adaptée à l’environnement dont il est question. Tout est fait au niveau de Splunk pour faciliter le déploiement et limiter au maximum le temps nécessaire à la mise en place de « l’ossature » de Splunk (grâce au deployment server notamment). L’installation et la configuration de base peuvent être réalisées en moins d’une journée. On comptera un maximum de trois jours pour des déploiements plus complexes. La configuration poussée de la solution (reporting précis et alerting, corrélation, etc) est la principale « charge » en termes de temps de travail dans le cadre d’un projet Splunk. Collecter et recevoir La grande force de Splunk est sa capacité à traiter tous les types de logs, quelle que soit la source et quelle que soit la méthode d’accès aux données. L’indexation de ces logs s’effectue sans avoir à développer de parsers spécifiques ou de connecteurs pour un équipement en particulier. Tous les équipements et toutes les applications (y compris des applications spécifiquement développées pour un environnement précis) à partir du moment où les logs en question sont accessibles (quelle que soit la méthode d’accès). A partir de l’interface web d’administration de la solution il est possible d’indexer des logs en provenance de :

• Flux réseau (y compris universal forwarder )
• Fichiers ou dossiers
• Scripts
• Bases de données

La configuration de l’écoute sur un port spécifique, typiquement syslog, s’effectue en moins de 30 secondes. Cependant, certains équipements ne permettent pas l’envoi de logs via un flux réseau. Pour les configurations plus avancées et les équipements « exotiques », le couplage peut demander plusieurs heures sans dépasser toutefois la demi-journée. A titre d’exemple, le couplage de Splunk avec un firewall Checkpoint réclame une configuration un peu plus poussée (configuration OPSec LEA, échange de certificats, etc). Il est également possible d’utiliser un logiciel nommé « splunk universal forwarder » à installer sur un serveur ou un poste pour gérer directement l'envoi des logs vers un indexeur Splunk. Recherches et alerting Splunk est en quelque sorte un moteur de recherche sur les données IT comme Google peut l’être sur des pages web. Le fonctionnement de type « moteur de recherche » sur vos données vous permet d’accéder simplement à toute information à partir d’un mot clé tel qu’un nom d’utilisateur, un login ou tout autre identifiant. De nouvelles recherches peuvent être lancées à tout moment mais il est également possible de lancer des recherches enregistrées au préalable. Splunk propose également un mécanisme d’automatisation afin d’envoyer par exemple les résultats d’une recherche par mail tous les matins. Dans Splunk l’alerting peut permettre l’envoi d’un email, l’écriture dans un flux RSS ou le déclenchement d’un script en fonction de nombreux critères à définir comme par exemple : - Détection en temps réel d’un événement redouté ; - Détection d’un nombre d’événements supérieur à un seuil prédéfini sur une période donnée (trois échecs de login pour le même utilisateur en moins d’une minute par exemple) ; - Total d’événements bien supérieur ou inférieur à la moyenne ou à une valeur habituelle constatée sur les derniers mois (20% d’augmentation du nombre de virus détectés par rapport à la semaine passée par exemple). A noter que l’exécution d’un script suite en guise d’alerte offre des possibilités infinies sur les actions entreprises suite à une alerte. Cela permet notamment à Splunk de s’interfacer avec des outils de ticketing pour déclarer automatiquement un nouvel incident. Universal forwarder Afin de permettre l’envoi des logs depuis des serveurs ou des postes ne proposant pas de fonctionnalité de type syslog, Splunk met à disposition un logiciel nommé « universal forwarder ». Celui-ci peut être installé sur n’importe quel système d’exploitation et permettra notamment l’envoi des logs vers un indexeur Splunk. Il offre également des possibilités complémenataires en termes de sécurité telles que le chiffrement des communications et l’authentification mutuelle par certificat ou par mot de passe. Splunk offre également la possibilité d’installer un « deployment server ». Cette instance de Splunk n’engendre pas de coûts supplémentaires et permet de déployer le package « universal forwarder » ainsi qu’une configuration spécifique à un groupe de serveurs donné. Ainsi, il est possible de configurer rapidement de nombreux serveurs ou postes à partir desquels on souhaite récupérer des logs. And so much more ... La suite au prochain épisode, on parlera notamment de stockage, de segmentation entres les différents types de logs, de gestion des rôles, d'archivage, de corrélation et de plein d'autres choses si j'ai des idées sympas d'ici là !