>> M$-windows of course pops up a friendly dialog box, indicating that the
ip
>> has been detected in use by someone else, and courteously disables that
>> ethernet interface for you :) :)
> M$ farts out prodigeous numbers of broadcast packets and expects
>to seen prodigeous numbers of broadcast packets. It spots the fact that
>someone else sends out a packet with your IP address in the src address.
>(at least that's one way they detect it). Amusing random acts of terrorism
>can result including some spectacular denial of service attacks (think
>about it for a second).
This is perhaps misworded. As with most systems, Windows sends a
"gratuitous ARP" for an IP address the IP address is bound (see, e.g.,
TCP/IP Illustrated Volume 1 for an explanation of gratuitous ARPs) and waits
for an (Ethernet) unicast ARP reply, which indicates that somebody else is
using the same address. The denial of service you hint at only works
locally; machines can't (bugs aside) propagate ARP requests to a remote
network.
>> The question:
>
>> linux does not seem to indicate if anyone else answers arp requests for
>> its own ip's (correct me if i am wrong); how does one tell if the ip is
in
>> use [short of unplugging the box or querying someone else's arp tables :)
>> :)]?
> Detecting the arp replies would not work on a switched network.
A gratuitous ARP is an ARP request, which uses the layer2 broadcast
mechanism for delivery. A straight Ethernet switch (e.g., not configured
for multiple VLANs) honors Ethernet broadcasts by transmitting them on all
ports. If they didn't, many things would not work. The purpose of a
gratuitous ARP request is to identify whether another system is using your
IP address. If you are using a particular IP address and you receive an ARP
request for that address, you should send an ARP reply (unicast to
requesting MAC address). Normally, the station that sent the gratuitous ARP
will disable their local use of the IP address in response to the ARP reply.
At this point, the station that sent the ARP reply has two choices. Windows
and Mac, for example, disable their local use of the IP address. At least
some versions of DUX follow their ARP reply with another ARP request. They
do this so that other stations on the same netblock will re-update their ARP
cache. Two DUX boxen doing this, of course, leads to an ARP storm... On
the other hand, if they didn't do this, a handy man-in-the-middle attack
becomes possible.
>You generally need to see another system (one with a MAC address you
>don't own) claiming to be an IP address which you claim. On a switched
>network, this generally must be a broadcast packet and you examine the
>source IP and source MAC (consider the case where YOU have two network
>cards on the same cable - this can be a non-trivial exercise with
>unexpected surprises).
> Keying off of arp replies or broadcast packet source addresses
>opens up some nasty DoS attacks. I could just flood the network with
>fake packets claiming to be different MAC addresses and IP addresses of
>systems I want to shut down. Do it with Windows named datagrams (UDP port
>137) and older windows systems just fall over very nicely and hit the
floor.
>It's tougher to do with newer Windows systems and there are much more fun
>games you can play with the name caches instead.
>> I would think a syslog entry would be most helpful to a lot of people on
>> dhcp-run networks!
> Dhcpd (at least the ISC one) attempts to ping the address before
>assigning a lease. If it gets a ping response, the address is flagged
>as "abandoned" in the leases file. Hijacked addresses are thus avoided
>and not leased out. Then, when you find your leases file full of abandoned
>entries, you get to track down the guilty parties and deliver a rubber hose
>IP release datagram to them. Repeatedly. :-)
>> -g
> Mike
|