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]
