RE: A bit strange ARP queries

["Dave Hawkins" <DaveH () Radware com>]

I have seen and used similar techniques for health checking of a server:
check a static ARP entry by sending an ARP request for the server's IP
to the MAC I trust.  This (to a degree) overcomes IP conflicts and ARP
hijacking.  We did this to produce a failover mechanism - the backup
unit would directly ARP it's primary, and failing to hear a response,
would broadcast a gratuitous ARP taking control of the primary's address
(better living through ARP spoofing?).  This was before we started using
VRRP.

This could also be a method of discovering faulty configurations versus
bad user behavior.  For example, if my ARP monitoring notices two or
three machines MACs using the same source IP, this ARP would tell us if
the activity was a misconfiguration of the machines' nic, or if it was
the result of spoofing software.  Since the IP address may not be bound
to the interface (just put in promisc mode and told to process layer3
traffic), a negative response may indicate the IP was used by a process
that's no longer active.  A positive response might be someone adding an
IP they weren't supposed to use.  This isn't fool-proof (or even a safe
assumption) since it's trivial to overcome... 

-Dave

-----Original Message-----
From: Eygene A. Ryabinkin [mailto:rea () rea mbslab kiae ru] 
Sent: Friday, December 16, 2005 7:27 AM
To: wayne dawson
Cc: incidents () securityfocus com; paul.farrington () goldmedal co uk
Subject: Re: A bit strange ARP queries
I can be wrong, but I can not imagine the unsolicited ARP requests. As
for
replies it is OK, but requests?

 But I worried by the fact that arp who-has packets have the target MAC
in it
(that is supposed to be discovered by the request) and this MAC changes
from
time to time.

 RFC says that the target MAC in the who-has requests has no meaning but
they can be present in the who-has requests. And there was no such
packets
in that net -- they appeared recently. So if the terget MAC is normally
ignored, such packets can be used for ARP spoofing (of any kind) only if
we have some strange ARP stacks that are caching the target MAC's from
the
ARP requests.

 What is wrong in my thoughts?


 Thanks!
-- 
 rea