Questions de Newbie

Bonjour,

100% novice dans le monde ELK, j'ai quelques questions très basiques (je crois) que j'ai du mal à répondre.
Je cherche pas la réponse "toute mâchée" mais des avis ou conseils pour m'orienter vers l'information concrète que peut m'aider à arriver au but.

Mes besoins:

Migrer la gestion de l'information netflow actuellement sous NFSEN vers ELK
Migrer un centralisation de logs avec syslog vers ELK pour mieux les stocker/interroger

Mon scenario actuel

Netflow
J'ai plusieurs routers ( +/- 30 ) qui m'envoient l'information du trafic réseau via NetFlow, vers un serveur avec NFSEN
Ces routers sont placés derrière des ip publiques dynamiques.
Pour savoir à quel router correspond chaque fluxe de données, avec NFSEN j'ouvre un port différent pour chaque router ("exporters" dans nomenclature ELK-netflow?) et alors, pas de problème (port 8541 -> routerA, port 8542 -> routerB, port 8543 -> routerC... et ainsi) et je peux définir un "channel" dans nfsen, qui pointe vers l'information reçue par un port en concret.
Si j'ai besoin d'interroger le trafic d'un router déterminé, simplement je dois me tourner vers le channel correspondant, et là j'ai le bucket de données de ce router.
NFSEN c'est bien, mais si j'ai besoin de l'interroger pour avoir information d'un fluxe, d'une période entre deux dates..., c'est vraiment trop lent, vraiment.

Syslog
Ces routers génèrent des logs syslog que j'ai centralisé dans un serveur rsyslog, de façon à avoir un fichier de log per chaque router.
Fonctionne comme il se doit, mais pour accéder à l'information et jeter un coup d'œil au contenu spécifique de chaque log de chaque router (voir si une ip a fait ou non quelque chose, quête d'un message d'erreur concret...) implique que je dois accéder au serveur syslog par shell, et chercher l'info à coup de grep.

Mon scenario idéal (et mes doutes)
Migrer le tout vers ELK. Allez, c'est tout, merci, je ferme la porte en sortant.

J'ai mis en place la solution dockerisée [Elastiflow] (https://github.com/robcowart/elastiflow) pour l'ingestion/stockage et interrogation des données NetFlow.

Netflow
Actuellement j'ai un de mes routers qui envoie l'info netflow vers logstash et je peux la voir dans Kibana, avec des dashboards tout prêts, nickel.
Malheureusement, si je veux filtrer par qui m'a envoyé l'information (donc, le router) avec le filtre de l'exporter (champ que indique l'ip de l'émetteur netflow) je peux sélectionner que l'adresse ip. En savant quelle est dynamique et que j'ai pas une liste historique de quelle ip avait quel router en une date déterminée... je perds le fil de à qui appartient l'information que je reçois.
Je sais pas si je pourrais faire comme avec Nfsen et ouvrir un port diffèrent pour chaque router, au moins ainsi je poudrais savoir à qui appartient l'info de chaque flux netflow, non?. Est-il faisable? J'ai tort? Contraintes?

Une autre possible option serait configurer un client ddns à chaque router. Mon doute est le suivant: savez-vous s'il y a une résolution DNS inverse à l'instant de recevoir un flux d'information ? Ou cette possible résolution inverse se fait pendant la query quand je interroge elastic?
Avez-vous une autre idée/solution? Conseil?

Syslog
J'ai vu que logstash est considéré aujourd'hui deprecated pour la collecte de logs type syslog et il est conseillé d'utiliser filebeats. Je dos étudier comment faire avec filebeats.
Je crois que j'ai deux options:
Chaque router envoie ses logs au module filebeats.
Je centralise les logs de mes routers dans un syslog local au host ELK et de là, je les intègre dans ELK.
Selon votre expérience, la quelle est plus logique ? Avez-vous d'autres conseils?

Questions générales

Je craints que le volume de données au fil du temps soit assez conséquente. Pendant mes tests, un router pas trop chargé, en 24h génère dans ELK unes 100MB de données (je peux me tromper, savez-vous comment calculer l'espace en disque occupé par ces données (index?)). Si je multiplie par 30 routers, cela fait 3GB par jour... En sachant que j'ai un disque de 300GB, j'ai de la place pour 100 jours. Les données netflow je dois les stocker pendant 1 an. Je devrais faire du ménage chaque trimestre.
Est-il assez "simple" de demander a ELK d'exporter les données d'une période déterminée (bucket) et de les effacer d'ELK (une fois surs que l'exportation est protégée ailleurs). Si besoin, est aussi "facile" d'importer un bucket, si besoin?

Une fois les données de netflow et de syslog dans ELK, j'imagine que je pourrais faire des liaisons entre tous ces données (exemple: cherche dans les syslogs l'ip a.b.c.e et si tu la trouves, va chercher tous les flows de netflow ou la source ou destination c'est cette ip), je me trompe?

Merci beaucoup pour votre temps et merci en avance pour toute réponse

Cordialement

D.

Pour cela tu dois donc enrichir tes logs avec une identification, pour cela plusieurs moyens logstash ou filebeat.

Logstash et Filebeat n'ont pas exactement les mêmes rôles, je ne pense pas que logstash soit déprécié.

Dans une architecture de collecte de logs classique tu peux utiliser filebeat qui envoit vers elasticsearch ou bien logstash qui écoute des flux de logs ( syslog, http ou même fichiers )

Là ou ces deux outils se démarquent c'est pour le besoin d'une architecture distribué ou l'analyse et l'enrichissement des logs à travers le concept de "pipelines" te permet de formater tes documents et d'enrichir tes données à travers les différents filtres pour logstash ou processors pour filebeat.

Suivant tes besoins le type d'architecture peux varier là je n'ai pas assez de données pour pouvoir te conseiller. Par exemple le plus simple pour toi serait d'utiliser un ou plusieurs serveurs filbeat suivant tes contraintes pour écouter les flux syslog, modifier les logs en y ajoutant un tag ou un hostname en fonction des ip source et les renvoyer vers elastic.

Je ne manipule pas de gros volume de données a un instant T avec elastic, de ce que je comprends c'est pour des besoins légaux d'archivage ? Si c'est le cas tu peux simplement exporter les flux vers des fichiers de logs compréssés en plus de la base elastic.

C'est le genre de requêtes qu'il est possible de faire !

1 Like

Tout à fait, ma faute, le warning je l'avais lu dans l'info du module Netflow pour logstash, j'ai mélangé sans me rendre compte

Merci, je prends bonne note, je crois que je vais faire un "mix" de ces recommandations.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.