Analyse du trafic réseau comme base pour la supervision
La supervision a toujours utilisé au même temps l’administration réseau et l’analyse du trafic réseau. Les deux disciplines fournissent des moyens d’obtenir des données qui permettent de déduire des informations sur l’état général de la plate-forme.
Il est facile de comprendre que face, par exemple, à un problème de performance applicative, vous voulez pouvoir observer et évaluer le trafic généré, et c’est exactement ce qui permet l’analyse du trafic réseau.
Cette première impulsion naturelle pour observer le trafic est justifiée, car l’analyse du trafic s’est avérée utile pour identifier des problèmes tels que des erreurs de configuration, une détérioration des performances du serveur, des problèmes de latence dans certains composants du réseau et d’autres conditions d’erreur.
Deux méthodes d’analyse du trafic réseau
Il existe au moins deux façons d’effectuer une analyse du trafic réseau : l’analyse des paquets et l’analyse du flux du trafic réseau.
Dans les deux techniques, bien entendu, l’objectif est le même : obtenir des informations sur le trafic réseau qui peuvent être présentées sur une interface facilitant son évaluation.
Les différences entre l’un et l’autre se concentrent dans la méthodologie utilisée.
L’analyse des paquets offre la possibilité d’évaluer le trafic réseau paquet par paquet, tandis que l’analyse de flux vise à collecter des métadonnées ou des informations sur le trafic et à travers elles faciliter l’analyse statistique.
Prenons le diagramme suivant comme guide pour avancer :
Diagramme montrant la relation entre la supervision et l’analyse du trafic réseau et l’administration réseau.
À propos de l’analyse des paquets
L’analyse des paquets commence par l’application de techniques de capture, telles que la configuration des ports SPAN (Switch Port Analyzer) ou l’installation d’équipements tels que les TAP (Terminal Network TAP) pour accéder au trafic réseau.
En réalité, les dispositifs TAP ont été développés pour couvrir certaines lacunes qui surviennent lors de l’application de ports SPAN, comme la dépendance aux ressources de traitement du commutateur où ils sont configurés et la relation délicate entre la quantité de trafic que nous avons l’intention de capturer et la capacité du port SPAN elle même.
Si elle vous intéresse la spécification des commodités des ports SPAN et des TAP réseau, nous vous recommandons l’article publié dans ce blog, qui se penche sur la capture de paquets à l’aide des TAP réseau.
https://pandorafms.org/blog/network-traffic-capture-with-network-taps/
Une fois le problème de capture résolu, deux problèmes très importants se posent :
- Le stockage du trafic : il s’agit de savoir si on peut faire une analyse en temps réel ou en temps différé et le coût de stockage que l’analyse implique.
- La sélection des packages que vous voulez évaluer : pour résoudre ce problème, les outils qui implémentent l’analyse des packages offrent généralement de nombreuses fonctionnalités qui vous permettent de choisir et de sélectionner les packages que vous voulez évaluer.
Les variables de choix sont généralement nombreuses, dès les adresses IP source et de destination jusqu’à la présence d’une certaine séquence d’octets dans les paquets.
Un autre point important à mentionner concernant l’analyse des paquets est celui correspondant au traitement qui est donné à la partie de données des paquets.
L’analyse traditionnelle des paquets est maintenue dans la revue des en-têtes, laissant la partie correspondant aux données sans visualisation.
Cette approche a trois justifications :
- Avec l’évaluation des en-têtes, beaucoup d’informations peuvent être déduites.
- En ignorant la partie données, les coûts de stockage sont maîtrisés.
- La partie de données contient généralement des informations sensibles pour les utilisateurs et pour l’organisation, de sorte que son évaluation peut nous conduire à enfreindre les réglementations en matière de sécurité et de protection des données.
Cependant, pendant des années, le trafic Internet a été évalué selon les préceptes d’une technique connue sous le nom d’inspection approfondie des paquets.
L’inspection approfondie des paquets comprend la révision et l’évaluation des en-têtes et de la partie de données des paquets.
Récemment, son application a transcendé le domaine du trafic Internet et est passée au trafic commercial, bien sûr avec de nombreuses controverses sur les risques possibles pour la confidentialité des données.
Si le lecteur souhaite en savoir plus sur les implications de l’inspection approfondie des paquets, nous vous recommandons notre article sur ce sujet, publié il y a quelques mois sur ce blog.
https://pandorafms.com/blog/deep-packet-inspection/
Sur l’analyse des flux de trafic
L’analyse des flux de trafic propose les éléments suivants :
- Évaluez le trafic réseau en fonction des caractéristiques communes. En d’autres termes, nous partons d’une abstraction – appelée « flux de trafic » – qui correspond à tout le trafic qui partage certaines caractéristiques communes et se déplace d’un hôte réseau à un autre.
Par exemple, si l’on considère tout le trafic qu’une station et un serveur peuvent partager, le trafic faisant partie de la même conversation ou ayant le même objectif sera considéré comme un flux.
- Le flux n’est pas stocké en tant que tel, uniquement les métadonnées. L’idée est d’utiliser les périphériques impliqués dans le passage du trafic réseau pour générer des informations sur le flux de trafic ou ses métadonnées, sans stocker les paquets qui composent le flux de trafic.
Ces métadonnées doivent ensuite être stockées et retraitées pour être finalement affichées avec l’idée de permettre l’analyse, quels qu’ils soient : supervision, sécurité, légiste, facturation, etc.
L’analyse des flux de trafic a été établie sur la base d’un ensemble de protocoles qui permettent la mise en œuvre des processus de génération, de transport, de stockage et de prétraitement des métadonnées.
Il est important de préciser que ces protocoles ne spécifient pas comment l’analyse doit être effectuée. Cela est laissé aux outils qui utilisent les métadonnées pour atteindre leurs objectifs.
Il existe deux protocoles qui représentent deux approches différentes pour mettre en œuvre l’analyse du flux de trafic : NetFlow et sFlow.
NetFlow
NetFlow est un protocole développé par Cisco qui est devenu un standard pour la mise en œuvre de l’analyse de flux de trafic IP. Outre Cisco, de nombreuses entreprises, à la fois fabricants de périphériques réseau et développeurs de solutions, incluent la prise en charge de ce protocole.
NetFlow présente une architecture qui comprend les composants suivants :
Architecture NetFlow
- Exportateur : Ils sont en charge de collecter les métadonnées des flux de trafic IP entrant et sortant à partir d’un périphérique réseau.
En fait, les exportateurs sont des logiciels contenus dans des périphériques tels que des commutateurs et des routeurs.
Les exportateurs utilisent un référentiel appelé NetFlow Cache pour stocker des informations sur les flux qu’ils capturent lorsque le trafic entre et sort via le commutateur ou le routeur.
- Collecteurs: En charge de recevoir les métadonnées des exportateurs, de les stocker et de les pré-traiter.
- Analyseur : C’est l’élément en charge de permettre l’analyse des informations contenues dans les collecteurs.
En pratique, les fonctions de collecteur et d’analyseur sont régulièrement fournies par des applications utilisant NetFlow.
NetFlow a évolué au fil du temps, de la version 5 à la version 9 ; Des protocoles tels que IPv6 ou des technologies telles que les VLAN, MPLS et BGP ont été inclus.
D’autre part, à partir de la version 9 de NetFlow, un autre protocole a été dérivé appelé IPFIX (IP Flow Information Export), qui vise à réglementer la manière dont les informations sont envoyées des exportateurs aux collecteurs.
IPFIX présente plusieurs améliorations. D’une part, vous avez le support des champs de longueur variable et la possibilité d’inclure des données normalement associées à l’administration réseau (SNMP et Syslog).
Pour le lecteur intéressé à en savoir un peu plus sur les applications NetFlow, nous vous recommandons de lire l’article sur NetFlow publié dans ce blog.
https://pandorafms.com/blog/fr/quest-ce-que-netflow/
sFlow
À partir de NetFlow, d’autres fabricants ont développé leur propre protocole d’analyse de flux ; en général, ils suivent tous la même architecture Exportateurs – Collecteurs – Analyseurs et ils restent dans l’environnement de trafic IP.
Voici une liste de protocoles dérivés de NetFlow :
Protocole Fabricant
NetFlow Cisco
jFlow Juniper
rFlow Ericcson
NetStream Huawei
Comme nous l’avons dit ci-dessus, la plupart sont des approximations de NetFlow sans grande variation. Cependant, quelque chose de différent se produit avec le protocole sFlow.
SFlow (Sampling Flow), qui a été développé par InMon Corporation et publié dans RFC 3176, introduit un changement notable.
https://datatracker.ietf.org/doc/rfc3176/?include_text=1
SFlow ne fonctionne pas avec l’abstraction dont nous avons parlé jusqu’à présent, il s’écoule et se concentre sur l’activité de collecte d’échantillons.
Lors de l’utilisation de sFlow, le rayon d’échantillonnage ¨ n¨ est défini. Ainsi, tous les n paquets, l’exportateur sFlow prélèvera un échantillon des paquets en considérant tous les niveaux, de 2 à 7, dans le modèle OSI et tous les protocoles présents, pas seulement IP.
À partir des échantillons, sFlow conservera les octets initiaux, ajoutera les compteurs et transmettra toutes ces informations aux collecteurs sFlow.
Ainsi, vous obtenez avec NetFlow des informations sur les flux IP, en considérant les couches 3 et 4, tandis qu’avec SFlow vous avez des échantillons de n’importe quel protocole considérant de la couche 2 à la couche 7.
Cela nous amène à considérer sFlow comme un protocole plus large avec moins de consommation de ressources chez les exportateurs, qui évolue bien mais, étant basé sur l’échantillonnage, peut laisser du trafic sans évaluation.
Cela dit, le lecteur peut supposer à juste titre qu’il y a une controverse. Quel protocole est le meilleur ?
Le lecteur intéressé par cette polémique peut se tourner vers cet article publié dans comparitech et celui publié dans pcwdld pour entrer dans le sujet.
https://www.comparitech.com/net-admin/netflow-vs-sflow/
https://www.pcwdld.com/netflow-vs-sflow
NetFlow et Pandora FMS
Pandora FMS, en tant qu’outil de supervision à usage général, comprend l’utilisation de techniques d’analyse du trafic réseau.
En fait, Pandora FMS inclut l’intégration aux équipements de capture de trafic tels que les TAP et prend également en charge NetFlow.
L’intégration avec NetFlow est réalisée en établissant le serveur Pandora FMS en tant que collecteur et analyseur NetFlow. Cette intégration implique l’utilisation d’un outil logiciel libre appelé nfcap.
Une fois l’outil installé, le démon démarrera automatiquement et le schéma présenté par Pandora FMS proposera alors un schéma de filtrage très flexible qui vous permettra de choisir précisément le trafic que vous souhaitez évaluer.
Pour le lecteur intéressé par l’examen d’un schéma d’intégration Pandora FMS et NetFlow, à l’aide d’un appareil Raspberry, nous vous recommandons de consulter cet article intéressant
https://pandorafms.com/blog/netflow-probe-using-raspberry/
Bien entendu, la prise en charge de NetFlow n’est que l’une des nombreuses fonctionnalités fournies par Pandora FMS.
Si le lecteur souhaite mieux connaître la portée de Pandora FMS, nous l’invitons à entrer ce lien.
https://pandorafms.com/fr/supervision-reseau/
Si vous voulez mieux savoir ce que Pandora FMS peut vous offrir, vous pouvez entrer ici : https://pandorafms.com/fr/
Si vous avez plus de 100 appareils à superviser, vous pouvez nous contacter via le formulaire suivant : https://pandorafms.com/fr/contact/
Sachez également que si vos besoins en supervision sont plus restreints, vous disposez de la version OpenSource de Pandora FMS. Trouvez plus d’informations ici : https://pandorafms.org/
N’hésitez pas à envoyer vos questions. L’équipe de Pandora FMS sera ravie de vous aider !
