Voici un article publié dans le site web Securisa.com le 29 mars 2006 et dans le bulletin « La sécurité simplifiée », vol. 2, no.16:
Selon nos propres observations, l’analyseur de protocole réseau ou communément appelé « sniffer » n’est presque exclusivement utilisé qu’à deux usages: soit pour régler des problèmes de télécommunication et soit pour pirater. Il semble que bien peu s’en servent pour améliorer la sécurité des systèmes. Pourtant… Il faut l’avouer, un « sniffer », ça fait un peu peur. Il s’agit tout de même d’un logiciel technique dans lequel on retrouve dans l’interface utilisateur à peu près tous les acronymes du jargon des télécommunications.
Il permet, un peu comme le fait parfois la police, d’enregistrer toutes les conversations des ordinateurs voisins (et quelque fois des autres) et de restituer toute cette séquence de bits aléatoires sous une forme cryptique que seul les experts semblent être capables de lire.
Cependant, en faisant abstraction des détails inutiles qui sont affichés, le « sniffer » est l’outil idéal pour « contre vérifier » les résultats d’un balayeur de vulnérabilités par exemple ou identifier les ports de communication utilisés par des progiciels. (NDLR : il est surprenant de voir que, dans le cadre d’un exercice de sélection de logiciels, même les manufacturiers auront de la peine à vous indiquer quels sont les ports de communication utilisés par leurs propres produits! … surtout dans le cas de plages de ports TCP dynamiques)
Par exemple, la plupart des logiciels de vérification de sécurité (i.e. ISS Internet Scanner, twwwscan, arirang, whisker, etc.) basent leurs résultats sur les réponses obtenues à la suite d’attaques tests qu’ils ont eux-même lancé. De façon surprenante, ces outils ne peuvent pas faire la différence entre une attaque réussie (une attaque qui peut être soit positive: -indication qu’il y a une vulnérabilité – soit négative : – indication qu’il n’y a pas de vulnérabilité-) et une attaque ratée (comme lorsqu’il n’y a eu aucune connexion réelle par exemple). Ainsi, un balayeur de vulnérabilité HTTP (WEB) utilisé pour tester un serveur SSL (HTTPS) identifiera à coup sûr plusieurs vulnérabilités alors que l’on sait pertinemment qu’il n’y a eu aucune connexion! (NDLR : pour tester un serveur WEB avec HTTPS/SSL, il faut évidemment envoyer des données avec HTTPS/SSL !).
Tel un mouchard, le « sniffer » peut donc indiquer ce qui s’est réellement passé et apporter un complément d’explication aux comportements de sécurité observés.
Malheureusement, un tel outil (et encore moins une telle vérification avec ce même outil) ne semble pas faire partie de la trousse d’audit des vérificateurs en sécurité, du moins ceux que l’on a rencontré jusqu’à présent. Plusieurs tirent leurs conclusions sur les oui-dire de leurs outils sans avoir vérifié les faits avec le « sniffer ».
Pourtant, l’analyseur de protocole, même dans d’autres domaines d’intervention demeure le témoin par excellence qui peut contribuer à confirmer l’identité d’un système responsable de la dégradation de la performance ou contribuer à optimiser un ensemble de traitements distribués entre un extranet et un intranet.
[maxbutton id= »4″]