Flash The Tigre

Petit exemple d’utilisation de Wireshark, l’analyseur réseau.

Depuis quelque temps, des paquets étaient bloqués sur le pare-feu d’origine interne vers une destination ne correspondant pas à une adresse existant sur internet.

Données du problème :

Mon réseau : 192.168.0.1/24

Paquets bloqués :

Bloqué - src 192.168.0.1 - dst : 169.254.27.213 - port : netbios-nt/137 - protocol : udp

Soit 192.168.0.1 une de mes machines, appelons la A.

et 169.254.27.213 une machine inconnue, appelons la @Inconnue.

La machine A veut entrer en contact avec @Inconnue à propos de résolution netbios (port 137). Elle passe par le pare-feu qui lui coupe la transmission.

Si le pare-feu coupe la communication, c’est parce qu’elle ne fait pas partie d’une communication déjà autorisé et que ce genre de communication (résolution netbios) n’est pas autorisée à commencer (de mon côté comme ici mais également depuis l’extérieur).

Or, j’ai deux moyens de ne pas être sur mon réseau, en partant sur le pare-feu ou par la passerelle VPN spécialisé qui donne accès à mes sites distants.

C’est les sites distants qui donnent le moyen de les joindre à la passerelle VPN et il arrive que cette information soit perdu ou incorrect.

Quand l’information pour joindre un site distant est perdu, les communications sont retournés au pare-feu parce que la passerelle VPN pense que c’est à lui de les gérer. Le pare-feu bloque alors ces communications car elles ne correspondent pas à ce qu’il autorise.

Première Analyse :

On pourrait penser que le problème vient de la passerelle VPN et d’un site distant. Mais, avec Wireshark, on peut déterminer plus précisément d’où vient ces paquets bloqués, c’est à dire l’origine de cette communication.

Car pour l’instant, on ne sait pas si c’est bien la machine A qui répond à @Inconnu ou si c’est la machine A qui commence la conversation.

L’adresse dst : 169.254.27.213 est une adresse de type ARPA, c’est à dire une adresse qu’obtient une machine configurée pour obtenir automatiquement une @IP mais n’ayant rien reçu comme offre. Cela permet de mettre en place un réseau sans avoir de DHCP.

Sur mon réseau, j’ai un DHCP qui fournit des adresses sur le réseau 192.168.0.1/24. Je vérifie le service : journal de log, adresses disponible, en service, …

A priori pas de problème côté dhcp, il fait son boulot, @inconnue devrait obtenir une IP de mon réseau.

Lancement des recherches, qui est @Inconnu :

La machine A est branchée sur un switch, ce qui complique la tâche (les machines sur un switch ne se parlent qu’entre eux) et en plus elle est en agrégation de port (elle utilise deux ports sur le switch).

Sur le switch, je peux configurer un port pour qu’il renvoi une copie de tous ce qu’il voit sur un autre port (Port monitoring). Je branche une machine équipée de wireshark sur le port de monitoring et j’écoute tout ce qui concerne la communication de la machine A après avoir configurer un des deux ports pour la copie.

Je finis par voir la machine A tenter de dialoguer avec @Inconnue (tenter parce que le pare-feu reçoit la communication et la bloque).

Dans les informations, récoltées, je vois que c’est @Inconnu qui demande la résolution netbios en premier et que la machine A ne fait que tenter de lui répondre.

Je récupère également l’adresse machine de @Inconnue.

J’en profite pour faire une résolution et wireshark la définit en tant que machine du constructeur Dell.

Je n’ai pas de machine Dell sur les sites distants ce qui élimine cette possibilité, déjà on avance.

J’ai par contre un certain nombre de machine Dell dans mon réseau. Comme je sais que le pare-feu n’a pas laissé passer une machine extérieur pour demander des résolutions netbios et qu’il ne devrait pas avoir de machine Dell sur un site distant (il faut se méfier avec les conclusions hâtives). J’ai à priori une machine dans mon réseau qui fait des siennes.

Avec l’adresse Mac, je peux interroger le switch où est branché la machine A, pour savoir où il a vu cette adresse de connecté (sur quel port). Il m’indique alors un port qui est lui même connecté à un autre switch. J’interroge ce nouveau switch, et j’apprends qu’il a vu l’adresse mac de @Inconnu sur sa deuxième unité sur tel port. Ce port est lui raccordé à une prise, j’arrive donc dans un bureau.

Surprise, c’est dans mon bureau !

Sur cette prise, j’ai de nouveau un switch qui lui ne permet pas d’être interroger. Il me reste la dernière méthode, vérifier sur chaque machine raccordé à ce switch leur adresse mac et trouver le coupable. Normalement, vous devriez avoir la liste de toutes les adresses mac de vos machines ce qui vous épargne la remonté de la source mais dans le doute de ne pas avoir cette machine dans ma liste, j’ai préféré la remontée.

La machine @inconnue enfin découverte, je fais un ipconfig /all pour vérifier les paramètres réseaux. L’interface virtuel est la responsable des paquets, elle est en automatique mais ne reçoit pas d’offre et passe en adressage ARPA. On règle le problème selon les besoins, dans mon cas, l’interface virtuelle n’est pas utile, je la désactive.

Note : Il y a d’excellent tutoriel sur l’utilisation proprement dite de WireShark. Ici, je ne montre qu’une de ses nombreuses utilitées.