Classement par critère

1. Capture

Nous avons généré un flux de trames de 64 octets avec un espace intertrame le plus faible possible. Grâce à leurs buffers (mémoire tampon), les analyseurs capturent les trames pour les décoder. Les paramètres qui servent à évaluer un buffer sont la taille, les différents modes de gestion de la file d’attente et la capacité à ne pas perdre des trames. Tous les analyseurs testés possèdent les modes de gestion de buffer fini (si le buffer est plein, toute nouvelle trame est rejetée) et circulaire (les trames les plus anciennes sont détruites et les nouvelles acceptées). Les fonctions d’arrêt et de déclenchement d’une capture sur un événement étant communes à tous, la différence se fait sur la complexité du paramétrage : tandis que les analyseurs de Network Associates et d’Agilent proposent des solutions assez intuitives, ceux de Fluke et Shomiti sont plus complexes à utiliser. La note intègre la perte des trames entre l’émission et la réception (seul Sniffer en a perdu, mais 6 sur 102 400 000).

2. Filtrage

La fonction de filtrage permet de faire un tri des trames et de ne s’intéresser qu’au flux que l’on désire analyser (HTTP, FTP…). Pour ce test, nous avons mis en communication deux machines situées sur un réseau 100Base-T. Le trafic est ensuite dupliqué sur le port Gigabit d’un commutateur auquel est raccordé l’analyseur. Ce critère n’a pas permis de différencier les équipements, car tous ont des fonctions de filtrage bien développées. Ils ont entre autres des capacités de filtrage des adresses MAC, des adresses IP, des VLAN, pré et postcapture, la possibilité de combiner plusieurs filtres, etc.

3. Décodage

Le décodage permet à l’utilisateur de déterminer le protocole contenu dans la trame, de détecter les trames contenant des erreurs, etc. Nous avons utilisé la même plate-forme que pour le filtrage. Agilent Advisor est le seul à offrir la possibilité de décodage des trames en temps réel. Les autres équipements identifient et décodent les trames uniquement après que la capture est terminée. Le décodage se fait sur une visualisation à 3 fenêtres (trame, détail, hexadécimal) avec une identification par couleur de la couche OSI. Seul Agilent Advisor ne permet pas de créer une nomenclature spécifique pour décoder un protocole non reconnu par l’analyseur en standard. Les autres analyseurs se servent d’un PDK (Protocol Decode Kit) non fourni pour les tests. Enfin, aucun ne décode RTSP et MMS (protocoles de streaming).

4. Ergonomie

Nous nous sommes penchés sur la facilité d’utilisation et de paramétrage du filtrage, du décodage, des statistiques et du mode Expert. Tous les logiciels pilotes sauf celui d’Agilent proposent une visualisation du remplissage du buffer en temps réel. La visualisation sous 3 fenêtres (trame, Ascii, hexadécimal) est disponible chez tous les constructeurs. En revanche, seul Agilent Advisor propose une aide contextuelle et une aide au démarrage. De plus, son utilisation est intuitive et ne demande pas de formation particulière. En revanche, l’interface des logiciels de Shomiti et Fluke manque de souplesse.

5. Diagnostic

Tous les matériels testés, sauf Agilent, disposent de fonctions de diagnostic (mode Expert) qui leur permettent d’interpréter des événements survenant sur le réseau (erreurs, collisions…). Nous avons cherché à savoir si les analyseurs pouvaient être d’une aide utile en matière de sécurité. Les sondes sont en mesure de détecter de nouvelles machines sur le réseau, mais n’ont pas de fonctions d’alerte spécifiques sur ce point, pas plus que de fonctions de détection de tentative de login ou de scan des ports. Seuls ceux de Shomiti et de Fluke sont dotés d’une fonction de détection d’attaque sur TCP (non vérifiée). Le diagnostic des perturbations de flux de voix sur IP a également été étudié. Enfin, chacune des sondes distribuées propose des fonctions d’alerte sur incidents (par e-mail ou fichier log).

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.