> 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. -- meem _______________________________________________ networking-discuss mailing list [email protected]
