RE: ARP Spoof Question

["David Gillett" <gillettdavid () fhda edu>]

  Hardware MAC addresses are supposed to be globally unique.  All
that really matters, though, is that they be unique within a given
network.
  If you have duplicate MAC addresses on a shared-media network,
you can get weirdness like you describe, although if the TCP
sequence numbers are verified then it gets harder -- C's attempt
to disrupt the conversation may get discarded at the TCP layer.
  If you have duplicate MAC addresses on a *switched* network,
this looks to the switches like a loop in the network.  Most
implement STP (Spanning Tree Protocol) to detect loops and break
them by shutting down just enough interfaces to make the loop 
go away, so odds are that one of the duplicates gets disconnected.

David Gillett


> -----Original Message-----
> From: Stuart [mailto:secmail () patchsupplier dyndns org]
> Sent: July 24, 2003 10:04
> To: gillettdavid () fhda edu; security-basics () securityfocus com
> Subject: RE: ARP Spoof Question
>
>
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks for clearing that up, 
> I remember reading an article a while back about sending frequent
> spoofed ARP packets to receive packets but have been unable to locate
> the article. You can specify your own Mac address on some network
> cards in windows now, if this was set wouldn't this prevent proper
> communications between hosts?
> Such as A sending a SYN packet
> B replying with SYN/ACK
> And C (change MAC) replying with FIN
> Will this cause the connection to close preventing connectivity?
>
> Thanks
>
> Stu
>  
>
> - -----Original Message-----
> From: David Gillett [mailto:gillettdavid () fhda edu] 
> Sent: 24 July 2003 17:39
> To: 'Stuart'; security-basics () securityfocus com
> Subject: RE: ARP Spoof Question
>
>   A switch should *always* be learning.  A destination MAC 
> address should always fall into one of two categories:
>
> 1.  I have it in my switch table (NOT *ARP*, per se), because
> I saw traffic from it on interface X within the last N time-units.
>
> 2.  It's not in my tables -- send this packet to every port and
> assume we'll see a packet from it soon so it will get added to
> my switch table.
>
>   Switch table entries could get created when ARP response packets
> are seen -- or ARP requests, or DHCP broadcasts, or ....
>
> David Gillett
>
>
> > -----Original Message-----
> > From: Stuart [mailto:secmail () patchsupplier dyndns org]
> > Sent: July 23, 2003 16:13
> > To: security-basics () securityfocus com
> > Subject: RE: ARP Spoof Question
> >
> >
> > If we use a Cisco switch for example, don't they have a 
> > learning period?
> > I would presume that the switch would go through the process 
> > of building
> > its ARP tables again.
> >
> > Stu
> >
> > -----Original Message-----
> > From: Simon Gray [mailto:simong () desktop-guardian com] 
> > Sent: 23 July 2003 17:10
> > To: vineet () linux com kw; security-basics () securityfocus com
> > Subject: Re: ARP Spoof Question
> >
> > > Q1.My Question is, Node C will also reply to that request of 
> > Node A. SO
> > > now Node A has 2 different MAC for the same IP. How is Node 
> > A handling
> > > this situation???
> > > Q2.The switch also updates its table of IP/MAC address 
> > bindings, so how
> > > is switch handling this situation???
> > > Is it "first-come-first-serve" methodology which Node 
> > A/Switch takes???
> >
> > I don't know how correct this is, but I would of thought the Node
> > A/Switch
> > would update whatever stored record of IP/MAC it has with the new
> > details.
> >
> > Simon
> >
> >
> > --------------------------------------------------------------
> > ----------
> > ---
> > --------------------------------------------------------------
> > ----------
> > ----
> >
> >
> >
> > --------------------------------------------------------------
> > -------------
> > --------------------------------------------------------------
> > --------------
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.2
>
> iQIVAwUBPyARjZMRMj30dWmZAQIQVw//Z/h3UPG4X3eg29UGr9OChIXHQj+bc90j
> 5WLIXXZ9ec5yBHCkqqz6wjbY1foUmqzAsVakjnSLjidy7LyRbJhTLTJsopp9s92B
> L/hMh4HxLEBuHe7L5hMh5KKAsldeorycF0S/Sgfjm/5DRkL2xpSfqtJQttSqPMrL
> jxWn2EF5vbaRKUX/CsGPWKPKSnwZ85zaYxWUIatM3uyiotaeDsYdzgupKOHdqaHm
> FxUT4qKINE5z2kXuUBUyOiypwd/FgabPmy6bg5IV9wLthfQCSUpnjqe2ObwWmaCT
> JkWFtBpn3lWBy2qwNahFrzSdPVTDJ6Mo+Hjb6ZAfGvGqVoz99VdR+7zpJaoMC9mD
> 6aQRWkgZrxJKYzgXLxhxAdliOa/ovTGaz1y0bv1hfjuuvRPuwjdpT7DcpOwscQNY
> kBlCfkhuzJ1gD2A0PE62iDdUdnJeBPWVUVAKRkPQfV1d9k2J5k6UxYxfQPbO4ZfM
> NVnR1RszjLl38eTeQpq3uD0K2BK0vjquOvBh/fZF92W+ctrkfecrubCIl0MC1S9q
> RReJqjGxxj7qZs/sCtrKZt+3T7ahSkuMuvlYwcEw4UBnPpDtl0iacabVZjHuu+lE
> 3uD+UAxbRaNxG+fX7IOQNQy0LvJgx9Zg2G2pTsrNLUawpNOAT6Y/z4Zb00Fgu9xU
> 8UgW8toGn20=
> =/E3X
> -----END PGP SIGNATURE-----

---------------------------------------------------------------------------
----------------------------------------------------------------------------