> I don't think this attack will be very effective. The real machine can
> reply before the enemy machine. The switch will also not switch the packet
> to the fake MAC. The switch will see packet from the real MAC and have that
> in the MAC address table. This could cause the switch to think there is a
> loop (don't know that much about Spanning Tree yet. Have the CCIE switching
> book on order) and shut down one of the port. You will know when this
> happen real fast.
>
I am not too sure about this... The problem here is there is no
fake MAC... We could think about this as an IP conflict issue, the problem
is that its intentional and the IP is not really bound to the interface
and will respond only to the targeted session/s. I guess the only way
around this would be to have static arp entries on every machine.
The real machine could reply before the enemy machine but I guess
if you time it right you could send the real machine some spoofed
preloaded pings/smurf every few milliseconds (compensate for arp cache
timeout, in theory) and keep its buffer full and keep it from
responding... (session hijacked!)...
> dsniff (IIRC). The basic operation is as follows:
>
> * enemy spoofs an ARP reply to a target host/client for the victim's
> IP, but supplies it's own MAC address.
> * target stashes this in it's ARP table, subsequent IP packets are
> sent to the enemy's MAC.
###> * enemy copies the packet and forwards on to the victim. ###
Would this defeat the purpose of your attack if you forward the
packets to the victim, and allow it to respond back to the target
host/client? The target host/client will have a new mac address for the IP
that was spoofed? I guess this would depend on how arp refresh are
implemented after the timeout....
Nimesh.
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
