Oyez ! Oyez ! Débutants ou experts en architecture réseaux, je sollicite une audience.
Depuis 3 jours maintenant, je bloque au niveau du TP ARP cache poisonning issu du cours sur les réseaux TCP/IP.
Je vous expose mon souci : au moment de lancer "l'attaque" en utilisant scapy et en tapant ./arpcachepoison.py 192.168.0.1 192.168.0.3 sur la machine 192.168.0.2, scapy fonctionne, je remarque bien les petits points qui apparaissent. J'appuie donc sur ctrl + c pour stopper scapy.
Lorsque je vérifie si l'attaque a fonctionné en tapant sur la machine 192.168.0.1 : arp-an, celle-ci m'indique l'adresse IP de la machine 192.168.0.3 et celle de la machine 192.168.02, ainsi que leur adresses MAC qui sont identiques.
Première interrogation : je ne comprends pas pourquoi l'adresse IP de la machine 192.16.0.2 figure sur la table arp de la machine 192.168.0.1. Je ne l'ai à aucun moment pinguée et vice-versa !?
Je poursuis tout de même le TP, on me demande de pinguer la machine 192.168.0.3 à partir de la machine 192.168.0.1. On m'explique alors qu' aucun paquet ne sera réceptionné par la machine 192.168.0.3, or justement tous les paquets envoyés sont réceptionnés par cette même machine.
J'ai l'impression que l'origine du problème ne vient pas de mon utilisation de scapy (j'ai respecté scrupuleusement les consignes), mais pourrait venir de mon paramétrage réseau sur VirtualBox.
Je vous décris donc comment j'ai configuré le réseau des 3 machines mentionnées plus haut sous VirtualBox :
- Je crée, en premier, un nouveau réseau NAT avec 192.168.0.0/24 comme adresse CIDR.
- Ensuite je crée la machine virtuelle nommée 192.168.0.1. Ce processus de création se fait en prenant votre image debian, celle que vous proposez en téléchargement. Je connecte cette machine au réseau NAT 192.168.0.0/24.
- Je clone ensuite deux fois la machine 192.168.0.1 afin d'obtenir mes deux autres machines nommées 192.168.0.2 et 192.168.0.3. Elles sont toutes deux sous le réseau 192.168.0.0/24 (elles sont clonées), comme c'est le cas pour la machine 192.168.0.1.
- j'allume ma machine 192.168.0.1, puis je tape : ifconfig eth0 192.168.0.1 netmask 255.255.255.0 afin qu'elle possède bien l'adresse IP de son nom.
- j'allume ma machine 192.168.0.2, puis je tape : ifconfig eth0 192.168.0.2 netmask 255.255.255.0 afin qu'elle possède bien l'adresse IP de son nom.
- j'allume ma machine 192.168.0.3, puis je tape : ifconfig eth0 192.168.0.3 netmask 255.255.255.0 afin qu'elle possède bien l'adresse IP de son nom.
C'est à partir de là que je débute le TP et que très tôt, je m'aperçois qu'il y a un problème, celui que j'ai mentionné au début de ce message.
Si vous aviez une suggestion, une idée afin que je puisse continuer ce TP, je suis tout ouïe.
En creusant un peu plus profondément dans les sujets de ce forum, j'en ai trouvé un similaire au mien, celui de :
NCZ, paru le 7 juin 2018, dont le nom est [ARP cache poisoning] Echec d'interception.
Ainsi, IL NE FAUT SURTOUT PAS OUBLIER DE LANCER L'ATTAQUE EN CONTINU.
Si cette inhumation peut éviter à d'autres de perdre autant de jours à tourner en rond... éh bien tant mieux.
TP ARP cache poisonning
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.