Yes
Many
Why?
--sk
Jason King wrote:
Do you by any chance have boxes running Windows with broadcom NICs and
are using their teaming software?
On Thu, Aug 13, 2009 at 7:58 AM, Stuart Kendrick<[email protected]> wrote:
Ahh. I've been staring at a lot of ARP frames these last few days. But I
hadn't thought through this.
I see three classes of ARP gleaning, all of them rely on the entry already
existing in Solaris' cache, per your point.
(1) Remote station emits a gratuitous broadcast ARP: Solaris updates its
cache
(2) Remote station emits a gratuitous unicast ARP: Solaris updates its
cache
(3) Remote station emits an ARP Request for the Solaris box's address:
Solaris
responds *and* uses the information in the ARP Request to update its
cache
#3 is where I'm encountering confused machines: the source IP address in
these ARP Requests is accurate, but the source MAC address is not.
And I can see how failover schemes might use any or all of these techniques
to propagate a change in their IP address <==> MAC address mappings. Dang.
I don't see a way to harden against this, at the host level, not without
getting into static ARP mappings, which looks like a swamp to me.
Thanx for the explanation,
--sk
Peter Memishian wrote:
> Is there a way to disable ARP gleaning under Solaris?
Solaris will not track the ARP mappings for random on-link hosts -- the IP
address will need to already be in its cache for some reason. My guess
would be that the Solaris box was already communicating with 10.1.2.9 and
then got the bogus ARP packet from 10.1.2.3 and dutifully updated its
cache with the bogus information. There's really nothing Solaris can do
about this case -- it is core to many failover technologies that Solaris
updates its ARP cache in this situation.
> I have broken end-stations which emit confused ARP responses, mixing up
their > MAC addresses with other end-stations' IP addresses.
> > e.g.
> Sender MAC address: 00:11:22:33:44:55 (correct)
> Sender IP address: 10.1.2.9 (INCORRECT)
> Target MAC address: 00:aa:bb:cc:dd:ee
> Target IP address: 10.1.2.20
> > In this case, the sender's actual IP address is, say, 10.1.2.3,
*NOT* 10.1.2.9. > 10.1.2.9 in fact belongs to a legitimate end-station.
But not this one. > Solaris gleans the IP address / MAC address mapping
from watching this traffic, > updates its ARP cache with this incorrect
entry ... and then starts addressing > frames to 10.1.2.9 using MAC address
00:11:22:33:44:55 ... and this of course > doesn't work too well.
> > I have a number of these confused boxes, and I am gradually hunting
them down. > In the meantime, I'm wanting to harden my Solaris boxes
against gleaning these > addresses. Actually, even once I've cleaned up my
confused end-stations, I'd > like to harden Solaris against this kind of
experience ... this smells like a > classic man-in-the-middle vulnerability
to me. If Solaris wants a MAC address, > let it ARP for it ... I don't
want it trying to save a little work by gleaning.
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
