Comment usurper une IP sans c onsequence pour la "victime" ?
11 réponses
nospam
Bonjour,
Dans le cadre de vérification par la pratique des ACL de mes routeurs,
j'aimerais lancer une série de scans de port à partir d'un certain
nombre de machines, vers un certain nombre de cibles.
Il ne me sera pas possible d'installer nmap sur chaque machine source
testée.
Je pense donc faire mes tests à partir d'un portable que je déplacerai
de réseau en réseau. Mais comment lui faire prendre l'IP de la machine
"source" à tester, sans causer des problèmes à cette même machine
source?
J'ai pensé à de l'arp spoofing pour faire passer pendant le scan tout
le traffic de l'IP testée par mon portable, mais comment faire le tri
entre les packets du portscan, et les packets à rediriger vers la
machine usurpée ?
Y aurait il un moyen plus simple ?
Dans le cas d'un réseau switché, l'attaque est de type "man in the middle" ce qui fait que les packets passent par la machine sniffant et donc nmap recoit les packets (l'adresse ip est differente, mais comme l'adresse mac correspond, le kernel remonte les packets a l'appli, et nmap est heureux)
Heu, je ne pense pas que TCP/IP fonctionne comme ca. La couche 2 recoit la trame, l'adresse de destination est bien celle de la carte réseau, elle renvoit donc l'info à la couche 3. La couche 3 recoit le datagramme, l'adresse de destination n'est pas celle d'une des interfaces, le paquet doit donc être routé... et n'arrive jamais à Nmap. A moins de faire une modification de l'adresse destination avec iptables par exemple.
le scan fonctionne terrible ... A scanne C en se faisant passer pour B, alors qu'elles sont toutes les 3 sur un switch, et B n'y voit rien ...
Et ca marche comment ?
Dans le cas d'un hub, c plus délicat, le mode promiscous de la carte permet de recevoir les packets, et je m'attendais a avoir un problème pour les remonter a nmap (en effet, la mac de destination est differente tant qu'on ne fait pas d'arp spoofing)... mais le probleme est avant : je ne vois meme pas de reponse au scan! Là mystere ! nmap envoie son scan plusieurs fois, et termine finalement en me disant que les ports sont "filtered" (il a meme pas eu de RST pour lui dire que le port etait fermé). Le problème est donc le suivant : sur un reseau non commuté, comment faire pour lancer de A un nmap spoofé en "-S @B" vers C et d'obtenir les reponses de C. Bizarrement, mon tcpdump me dit que C fait le mort.
Tu vois tes paquets sortir ? parceque s'ils sortent, C répondra.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Florent Carli" <nospam@tomcat.ca.tc> wrote in message
news:6d12cccb.0307230232.1bc22177@posting.google.com
Dans le cas d'un réseau switché, l'attaque est de type "man in the
middle" ce qui fait que les packets passent par la machine sniffant et
donc nmap recoit les packets (l'adresse ip est differente, mais comme
l'adresse mac correspond, le kernel remonte les packets a l'appli, et
nmap est heureux)
Heu, je ne pense pas que TCP/IP fonctionne comme ca.
La couche 2 recoit la trame, l'adresse de destination est bien celle de
la carte réseau, elle renvoit donc l'info à la couche 3. La couche 3
recoit le datagramme, l'adresse de destination n'est pas celle d'une
des interfaces, le paquet doit donc être routé... et n'arrive jamais
à Nmap.
A moins de faire une modification de l'adresse destination avec
iptables par exemple.
le scan fonctionne terrible ... A scanne C en se
faisant passer pour B, alors qu'elles sont toutes les 3 sur un switch,
et B n'y voit rien ...
Et ca marche comment ?
Dans le cas d'un hub, c plus délicat, le mode promiscous de la carte
permet de recevoir les packets, et je m'attendais a avoir un problème
pour les remonter a nmap (en effet, la mac de destination est
differente tant qu'on ne fait pas d'arp spoofing)... mais le probleme
est avant : je ne vois meme pas de reponse au scan!
Là mystere ! nmap envoie son scan plusieurs fois, et termine
finalement en me disant que les ports sont "filtered" (il a meme pas
eu de RST pour lui dire que le port etait fermé).
Le problème est donc le suivant : sur un reseau non commuté, comment
faire pour lancer de A un nmap spoofé en "-S @B" vers C et d'obtenir
les reponses de C. Bizarrement, mon tcpdump me dit que C fait le mort.
Tu vois tes paquets sortir ? parceque s'ils sortent, C répondra.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Dans le cas d'un réseau switché, l'attaque est de type "man in the middle" ce qui fait que les packets passent par la machine sniffant et donc nmap recoit les packets (l'adresse ip est differente, mais comme l'adresse mac correspond, le kernel remonte les packets a l'appli, et nmap est heureux)
Heu, je ne pense pas que TCP/IP fonctionne comme ca. La couche 2 recoit la trame, l'adresse de destination est bien celle de la carte réseau, elle renvoit donc l'info à la couche 3. La couche 3 recoit le datagramme, l'adresse de destination n'est pas celle d'une des interfaces, le paquet doit donc être routé... et n'arrive jamais à Nmap. A moins de faire une modification de l'adresse destination avec iptables par exemple.
le scan fonctionne terrible ... A scanne C en se faisant passer pour B, alors qu'elles sont toutes les 3 sur un switch, et B n'y voit rien ...
Et ca marche comment ?
Dans le cas d'un hub, c plus délicat, le mode promiscous de la carte permet de recevoir les packets, et je m'attendais a avoir un problème pour les remonter a nmap (en effet, la mac de destination est differente tant qu'on ne fait pas d'arp spoofing)... mais le probleme est avant : je ne vois meme pas de reponse au scan! Là mystere ! nmap envoie son scan plusieurs fois, et termine finalement en me disant que les ports sont "filtered" (il a meme pas eu de RST pour lui dire que le port etait fermé). Le problème est donc le suivant : sur un reseau non commuté, comment faire pour lancer de A un nmap spoofé en "-S @B" vers C et d'obtenir les reponses de C. Bizarrement, mon tcpdump me dit que C fait le mort.
Tu vois tes paquets sortir ? parceque s'ils sortent, C répondra.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
