30 juillet 2012

Dans le journal d’un splunker, je me lance à la découverte Splunk et vous fais partager mes avis et impressions. Au programme d’aujourdhui, la récupération et le traitement des logs Fortinet.

 

Vous avez raté l’épisode précédent ? Rendez-vous sur Journal d’un Splunker : Day 2.

 

Commençons donc doucement avec un firewall Fortinet.

Tout comme un certain nombre d’équipements, les logs des fortigates sont assez propres. Ils peuvent être transmis via syslog et se présentent sous la forme champ=valeur. On va voir dans les lignes qui suivent que c’est particulièrement intéressant pour Splunk.

La première chose à faire est de trouver un administrateur du firewall qui accepte de faire une petite modification pour l’envoi des logs en syslog. En environnement PCI DSS il faut bien entendu remplir les onze formulaires qui permettent de créer une demande, envoyer une photocopie de ses sept dernières cartes d’identités et un extrait de casier judiciaire datant de moins de 3 jours et faire valider ladite demande par un manager. Par chance, on n’est pas encore soumis à la norme en interne. Du coup, je vais voir mon administrateur préféré, lui promets une bière s’il accepte de faire une petite modification pour moi sur la fortigate et le tour est joué !

 

J’essaie discrètement de voir son mot de passe (c’est mal mais ça va me coûter cher en bière si je vais le voir pour tous les équipements du réseau), je repère la configuration sur le Fortinet et je griffone quelques notes sur un post-it pour savoir le refaire en cas de besoin. De retour à mon bureau et après quelques minutes passées à déchiffrer ma propre écriture, j’arrive à quelque chose d’à peu près cohérent :

– Log & Report / Log Config / Log Setting
– Cocher syslog
– Renseigner les champs IP et Port
– Choisir un « niveau » minimum
– Cocher / Décocher les types d’événements à logger
Il ne reste plus qu’une chose à faire, expliquer à Splunk qu’il doit écouter sur le port UDP 514 pour pouvoir reçevoir les logs envoyés par la fortigate. Sur l’interface graphique (je ferai le MacGyver via la CLI un peu plus tard), je vois un joli bouton « Add data » et je choisis de configurer l’écoute sur le port en question, tout me semble d’équerre. Petite astuce au passage, en allant faire un tour dans « More Settings » on peut choisir si la source sera identifiée sur Splunk avec son IP ou son nom DNS, pratique. On peut aussi restreindre l’écoute à une IP spécifique, encore plus intéressant.

Une fois tous les champs renseignés, je valide le tout et je retourne sur l’application Search. Ô Magie,voilà mes premiers logs sur Splunk. La première idée qui me vient en tête est pleine de bonnes intentions, vite ajouter les logs du proxy pour valider que les utilisateurs ne sont pas forcés à naviguer vers des sites potentiellement dangereux (et non pas pour faire du flicage et voir qui se connecte le plus souvent sur Facebook).

Donc, j’ai des logs, je constate en plus de ça que Splunk a reconnu lui-même un certain nombre de champs (et ce sera le cas pour tous les logs au format champ=valeur) comme illustré dans ma capture d’écran sur la gauche. J’ai donc déjà toutes mes IPs source, mes IPs destination, les protocoles, les ids des règles matchées, magnifique !

Je vais donc pouvoir commencer à faire des rapports et des graphiques sur tout ce qui m’intéresse. Je jette un oeil sur un lexique des commandes utiles pour la mise en forme et je vois que les commandes « top » et « rare » permettent respectivement d’afficher les 10 champs présentant les plus ou le moins d’événements sur la période choisie.

 

Je commence donc par un top dst pour voir les destinations les plus prisées par les flux qui passent par le firewall. Je présente ça sous la forme d’un camembert et voici ce que ça donne (j’ai supprimé les adresses IP pour éviter les mauvaises surprises en tous genres) :

 

Deuxième tentative avec un rare policyid pour afficher les règles les moins matchées sur mon firewall (mais matchées au moins une fois). Pour varier un peu la mise en forme, j’opte pour un affichage sous forme de barres, voici ce que ça donne :

 

Je continue à m’amuser avec tous les logs et après une grosse heure, j’arrive à avoir une vraie visibilité par VDOM sur les flux qui circulent sur mon réseau. IPs qui génèrent le plus de traffic, pays de destination des flux sortants, IPs sources qui génèrent le plus de deny, etc etc. En creusant un peu plus (et avec un petit coup de main de Ludo), j’arrive à fournir des stats sur l’utilisation CPU, le nombre de sessions simultanées et je vois ce qui se passe sur notre Wifi guest aussi (Fortigate Wifi Controller).

J’ai donc intégré un seul équipement dans Splunk (pas n’importe lequel, certes) et les résultats sont immédiats, les premiers petits correctifs peuvent être apportés à droite à gauche. Me voilà donc convaincu. Splunk m’a donné plein d’idées et va pouvoir nous être utile sur de nombreux points et pas seulement au niveau technique. On devrait pouvoir obtenir pas mal d’infos « business » avec les logs de l’application utilisée par le support et les logs du site Internet, mais ça c’est pas pour tout de suite. Prochaine étape, les logs de notre passerelle VPN SSL.

 

 

 

Partager :

Auteurs