Communication sur la MAC Adresse

[ggbce]

Bonjour,

J'ai un gros problème avec un équipement hardware, je ne possède plus l'adresse IP de cet équipement et il n'est pas possible de faire un RESET pour lui donner une adresse IP par défaut.

L'équipement est un peu spécial, ce n'est pas un router, switch mais un équipement industriel spécifique à une tâche.

La seule chose que je connais c'est sa MAC Adresse. Ce type d'équipement peut être remis à zéro en envoyant un fichier BIN via FTP... qui requiert une protocole TCP.... Est-ce que quelqu'un sait un logiciel me permettrait de faire qqchose du genre TCP/MAC au-lieu de TCP/IP ?

Sinon, pour peut-être diagnostiquer, un simple logiciel qui me permetrait de faire un genre de PING en MAC, qqchose qui me permet de savoir si l'équipement répond sur le câble réseau en MAC ?

Tout outil qui fonctionne au niveau des adresses MAC est le bienvenue (Windows ou Linux).

Merci beaucoup.

[Hassassin]

Te rapelle-tu au moins de la classe d'adresse IP ?

Si c'est le cas tu pourras toujours faire un ping en mass avec des outils comme IPscan32.

(Voilà pourquoi tout mon réseau est en DHCP )

Sinon une solution toute con.

Branche ton périphérique sur une NeufBox v4.

Dans l'interface de gestion la neufbox liste les équipements qui lui sont reliés aux fesses. Oui je sais... encore faut-il trouver une neufbox...

Sinon en fesant une tite recherche google j'ai trouvé ça :

http://www.vjgamer.com/programs/pcfinder/index.html

A voir...

Possible Uses:

1. Scan computers to determine if there is an unauthorized device on your network.

2. Use to create a list of MAC Addresses to allow for Wireless Access.

3. Confirm that your networks Computer Name Scheme has been followed.

4. Determine if a PC is powered on or not.

5. Locate a PC's IP Address by it's name or it's MAC Address.

[PoSKaY]

Pas la peine d'avoir une neufbox, un simple routeur liste les périphériques connectés.

[Amour]

La seule chose que je connais c'est sa MAC Adresse

Donc en ajoutant une entrée ARP dans votre système (que ce soit Windows ou Linux) il y aura une IP associée

arp -s adresse_ip adresse_mac

exemple :

arp -s 192.168.0.100 00:09:AB:CD:4E:12

et une fois que tout sera terminé (équipement réinitialité) il faudra supprimer l'entrée arp via arp -s

[gougou59]

Ouai sauf que si l'équipement distant n'a pas l'adresse 192.168.0.100, il refusera les paquets IP adressés à cette adresse

Tu peux peut-être voir si le serveur n'est pas déjà dans la table ARP avec un "arp -a"

[ggbce]

Salut,

Si la solution d'ajouter une entrée statique pour la résolution ARP ne fonctionne pas... puisque je l'avais déjà testé. Peut-on conclure que l'équipement souffre d'un problème de fonctionnement matériel ?

Est-ce possible que lorsque je fais le test que l'équipement essait de retourner ses paquets via son adresse IP configurée interne ? Je donne exemple:

1- Je connais la MAC adresse de l'équipement, disons: 00-AA-BB-CC-DD-EE

2- Le PC et l'équipement en question sont reliés entre eux directement avec un câble X-Over (ou sur un concentrateur qui n'a rien d'autre)

3- Je configure ma carte réseau du PC avec une adresse IP statique sur 10.0.0.1/24

4- Sur mon PC, j'ajoute une entrée statique: arp -s 10.0.0.2 00-AA-BB-CC-DD-EE

Logiquement rendu là ça devrait fonctionner

Mais disons que je sais que l'équipement en question pourrais avoir une adresse IP statique qui serait 192.168.1.2.

Lorsque je transmets le paquet vers 10.0.0.2, est-ce qu'il est possible que l'équipement veux retourner les infos vers le réseau 192.168.1.x car sa config interne est à 192.168.1.2 ou bien c'est certain que le paquet pourra retouver son chemin de retour en se fiant à la MAC adresse ?

Je pose la question car j'ai testé avec un autre équipement identique, que celui-ci je sais qu'il fonctionne bien, et ça ne marche pas la méthode ARP -s IP_ADDR MAC_ADDR

Merci pour votre aide !!!

[Amour]

Peut-être qu'avec un sniffer réseau du type Wireshark il y aura plus d'infos en retour, mais là j'avoue que je ne vois pas vraiment quoi faire...

[neologix]

Je ne vois pas le problème.

Il suffit de faire un ping sur l'adresse de broadcast (option -b).

Si ta machine répond au ping, tu auras l'adresse IP.

Si elle ne répond pas, tu peux toujours lancer un scanner sur l'adresse de broadcast sur le port ftp (nmap xxx.xx.xxx.xxx -p 21).

Si tu ne vois rien, c'est que la machine est plantée. Ou alors que sa pile TCP/IP a un _gros_ problème...

[Hassassin]

@neologix

oO

ping -b ??

Tu ne serais pas sous linux par hasard ?

Une machine en 192.168.1.1 peut pinguer une machine 192.168.100.1 ?

[neologix]

Oui, j'utilise Linux, je ne connais pas très bien windows.

Bref, une petite explication.

En IP (v4, v6, v12 si c'est une grosse cylindrée :-), seule l'adresse de destination compte. L'adresse source, on s'en fout (sauf s'il y a un firewall, mais là c'est un autre problème). Au niveau du routage, tu peux mettre n'importe quelle adresse source, ça ne change rien. C'est pour cela qu'il est aussi facile de spoofer une adresse IP (bon, le problème c'est que les réponses seront routées vers l'IP spoofée, donc c'est pas évident de les choper). Je précise en IP unicast ou broadcast, parce que par exemple quand tu fais de l'IP multicast, l'adresse IP source est utilisée dans le routage, parce que tu ne bases plus sur des tables, mais sur des arbres couvrants, enfi bref.

Maintenant, une adresse de broadcast, c'est juste une adresse qui va désigner tout le monde. Donc ta machine, elle est censée y répondre, si tu lui envoie un ping braodcast.

L'adresse MAC, en fait elle n'a de sens que sur un même segment (en gros le cable réseau). Dès que tu as un routeur entre les deux, et bah elle ne vaut rien. Le routage se fait au niveau IP, en utilisant juste l'adresse de destination, et une fois que tu arrives au dernier "hop", là le routeur voisin de la machine cible émet ce que l'on appelle un requête ARP, où en gros il demande "quelle est l'adresse MAC correspondant à l'IP xxx.xxx.xxx.xxx"?). Tu peux le voir par exemple avec un tcpdump. Si j'ai le temps, je posterai un exemple. Et là, la machine cible ne récupère les trames (paquest) qui passent sur le segment (en gros le cable) que si elles ont comme adresse MAC de destination la sienne.

Alors la question à 200 euros c'est comment ça se fait que les machines répondent à un ping sur une adresse de broadcast, puisqu'il faut spécifier leur adresse MAC? Le réponse : comme en IP, il existe une adresse MAC de broadcast, FF:FF:FF:FF:FF:FF (48 bits, en hexa), qui désigne toutes les machines. Donc, ta carte réseau elle voit l'adresse de broadcast MAC, elle se dit que c'est (aussi) pour elle, elle enlève le header MAC, et file le bébé au système d'exploitation qui, si sa pile réseau n'est pas complètement pourrave, répond au ping.

Voilà.

Ah, sinon, un détail. Comment font les méchants pour écouter le traffic qui passe sur un segment (cable réseau), quand l'adresse MAC de destination n'est pas la leur, et pas celle de broadcast? La réponse : certaines cartes permettent de se mettre en mode promiscuous, où elles passent à l'OS tous les paquets, sans regarder l'adresse MAC de destination. C'est vachement utile pas seulement pour casser la clé WEP de ton voisin, mais aussi pour voir ce qui se passe sur ton LAN (virus, routeur pourri, ton windows qui envoit des informations à la NSA, etc).

Et voilà.

[crocodudule]

Ca peut être un peu long mais, wireshark (ex-ethereal) en écoute sur ton IP, et en même temps ip-scanner "pinguant" la ou les plages. Les pings terminés, tu ajoutes le filtre de la mac voulue dans wireshark et tu auras l'ip

(le filtre ca doit être eth.addr == la_mac_avec_les_" : " )

[gougou59]

Je ne vois pas le problème.

Il suffit de faire un ping sur l'adresse de broadcast (option -b).

Si ta machine répond au ping, tu auras l'adresse IP.

Si elle ne répond pas, tu peux toujours lancer un scanner sur l'adresse de broadcast sur le port ftp (nmap xxx.xx.xxx.xxx -p 21).

Si tu ne vois rien, c'est que la machine est plantée. Ou alors que sa pile TCP/IP a un _gros_ problème...

Généralement, les machines ne répondent pas à un ping en broadcast. Question de sécurité!! Il y a eu des attaques à une époque qui utilisaient çà et çà fait très mal!! Un bot floodait des pings en broadcast, toutes les machines répondaient, le réseau s'écroulait!

Donc, je pense que la solution du sniffer est la solution. Tu écoutes en mode promiscuous et tu filtres sur l'adresse mac du serveur comme indiqué par crocodudule

[neologix]

Comme je l'ai dit, si la pile TCP/IP de l'OS en question n'est pas pourrie.

Une RFC (je ne sais plus laquelle) dit que les machines doivent répondre à un ping sur une adresse de broadcast.

Linux, par défaut, le fait :

$ cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

0

Après, je pense qu'il n'y a que ces comiques de microsoft qui n'ont pas compris à quoi servait le protocole ICMP, et qui le bloquent par défaut, broadcast ou pas.

$ ping microsoft.com -c 5

PING microsoft.com (207.46.197.32) 56(84) bytes of data.

--- microsoft.com ping statistics ---

5 packets transmitted, 0 received, 100% packet loss, time 3999ms

ICMP, ça sert justement à ce genre de cas. Bloquer l'echo reply pour des mesures de sécurité, il faut vraiment être stupide, et faire exprès de ne pas suivre les RFCs.

Enfin bref, sinon il y a toujours la solution du scanner, bien plus rapide qu'un sniffer:

$ nmap -PN 192.168.0.*

Starting Nmap 4.53 ( http://insecure.org ) at 2008-03-30 19:13 CEST

Interesting ports on 192.168.0.1:

Not shown: 1711 filtered ports

PORT STATE SERVICE

135/tcp open msrpc

139/tcp open netbios-ssn

445/tcp open microsoft-ds

Interesting ports on 192.168.0.2:

Not shown: 1710 closed ports

PORT STATE SERVICE

135/tcp open msrpc

139/tcp open netbios-ssn

445/tcp open microsoft-ds

5000/tcp open UPnP

Interesting ports on 192.168.0.3:

Not shown: 1712 filtered ports

PORT STATE SERVICE

139/tcp open netbios-ssn

445/tcp open microsoft-ds

All 1714 scanned ports on 192.168.0.4 are closed

[ggbce]

Une machine va répondre à un PING sur le broadcast uniquement si la requête provient d'une machine de la même plage, les routers bloquent ce type de requête par défaut maintenant (à cause du flood justement).

Hassassin dit:

Une machine en 192.168.1.1 peut pinguer une machine 192.168.100.1 ?

Neologix répond:

Oui, j'utilise Linux, je ne connais pas très bien windows.

Moi j'ajoute:

??? Oui on peut faire un PING vers une machine 192.168.100.1 depuis une machine 192.168.1.1 sur entre les 2 les routes existent pour se parler (ou bien que le masque soit (255.255.0.0), mais ce n'est pas possible de faire le PING en connectant les 2 machines entre elles directement, ni même possible de faire un PING sur le broadcast 192.168.100.255 depuis 192.168.1.1 s'il n'y a pas de routes disponible.

Ce qui revient à ma question: Comment communiquer en TCP/IP vers un équipement dont on ne connait pas l'adresse IP qui est connecté directement sur le même réseau (en plus simple, sur un câble X-Over directement) ?

NOTE: Cet équipement ne possède pas d'interface graphique, ni de bouton RESET pour mettre des paramètres par défaut. Le seul moyen de le gérer c'est via le réseau. En temps normal, l'équipement reçoit une adresse IP via BOOTP que le PC fournit via un logiciel d'adressage BOOTP/DHCP, mais là l'équipement ne veut rien savoir... et le seul moyen de faire le "RESET" est de pousser un firmware de réinitialisation via FTP ou TFTP.

Si je comprends bien, normallement on peut forcer une adresse IP avec une entrée statique ARP dans la méthode (ARP -s 192.168.1.2 AA:BB:CC:DD:EE:FF) et si ça ne marche pas c'est que l'équipement est probablement planté dans son interface réseau ?

J'ai essayé pour le fun avec un équipement fonctionnel la méthode d'entrée statique ARP, mais ça ne marche pas... Est-ce que quelqu,un a déjà réellement fait le test ? Par exemple sur le PC A avoir une adresse IP fonctionnelle (10.0.0.1) sur un PC B avoir une adresse "noname" (169.142.2.34) de brancher ces 2 PC sur le même réseau physique, d'ajouter une entrée statique ARP du PC B sur le PC A (évidemment en connaissant le MAC adresse du PC B) comme ceci: ARP -s 10.0.0.2 AA:BB:CC:DD:EE:FF et de faire un PING (ou autre requête vers un service actif) vers ce PC B ?

Merci

[Hassassin]

Ha c'est bien ce qui me semblait...

Frenchement la technique la plus simple pour raisoudre ton problème dans l'urgence c'est de le brancher sur un routeur ou FAIbox et de voir les machines qui lui sont connectés.

[gougou59]

Comme je l'ai dit, si la pile TCP/IP de l'OS en question n'est pas pourrie.

Une RFC (je ne sais plus laquelle) dit que les machines doivent répondre à un ping sur une adresse de broadcast.

Linux, par défaut, le fait :

$ cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

0

Après, je pense qu'il n'y a que ces comiques de microsoft qui n'ont pas compris à quoi servait le protocole ICMP, et qui le bloquent par défaut, broadcast ou pas.

$ ping microsoft.com -c 5

PING microsoft.com (207.46.197.32) 56(84) bytes of data.

--- microsoft.com ping statistics ---

5 packets transmitted, 0 received, 100% packet loss, time 3999ms

ICMP, ça sert justement à ce genre de cas. Bloquer l'echo reply pour des mesures de sécurité, il faut vraiment être stupide, et faire exprès de ne pas suivre les RFCs.

Pour ton information : http://en.wikipedia.org/wiki/Smurf_attack

Tous les OS bloquent désormais les réponses ICMP sur l'adresse de broadcast.

Et aussi, vu que tu parles de respect des RFC : http://tools.ietf.org/html/rfc2644

Enfin bref, sinon il y a toujours la solution du scanner, bien plus rapide qu'un sniffer:

$ nmap -PN 192.168.0.*

[...]

Ca, çà peut être une bonne solution

Par contre, faut connaitre le sous-réseau...