Re: Arp Warnings on @Home Network

[Dragos Ruiu <dr () KYX NET>]

I'd bet dollars to donuts you are seeing a common problem on large public
networks, typically using DHCP addressing assignment, namely duplicate
addressing.  Though this could be a hijack attack, just before we all start
freaking out, we should consider that the majority of these cases are actually
just natural occurrences usually involving a DHCP lease expiring and
being assigned before the last owner (or potetially dubious dhcp software
ont heir computer) decides to give it up.

In this case it would look like a Macintosh on your local segment is flipping
addresses with a remote user which to your computer would look like traffic
from the router (that Cisco mac address).  If it is a persitent condition you
should either track down the duplicate or start worrying about if you have any
protocols or applications that are vulnerable to session hijack...

You might try pinging, tracerouting an nmapping the offending duplicate
with your system down to see what you may glean about what is really
going on.

Another solution if you are in dynamic addressing is to release your address
lease and get a new one. (take the I/F down and run dhcpcd again under
Linux/BSD, use the release and renew all buttons in winipcfg, or use
ipconfig /somethingorother in win2k) See if that helps the problem any.

The problem should be sporadic, and the worst I have ever seen in natural
occurences is burst of such activity over short periods in a day. If it really
is persitent, and it follows you to different addresses, then you are either
blessed with being in one of the more abysmal corners of the @home abyss
(unfortunately most likely) or you have someone who is taking some unusual
interest in your networks.

 chers,
--dr

On Tue, 06 Feb 2001, Mike Forrester wrote:
> Greetings,
> I started getting arp warnings the console to my OpenBSD system at home (no
> pun intended :-) ).  Below are excerpts from /var/log/messages and the
> ethereal decoding of one of those packets.  To me it appears that someone is
> either trying to be the default router on their network or mis-configured
> their new Mac.  08:00:07 a vendor id for Apple Computer and 00:01:63 is a
> vendor id for Cisco.  Is there a way to determine who is the correct host?
> Either MAC could be spoofed and the packet logs from tcpdump (on the OpenBSD
> system) or from Ethereal (on my Windows 98 system), don't really give any
> detailed info.
>
> My guess is that someone just bought a new Mac and connected it to their
> cable modem.  They don't know what they are doing and put the wrong ip
> address in the wrong field.  If I am downloading a file when this happens,
> the connection gets reset.  I believe that this is due to my reply packets
> getting temporarily re-routed to the bogus gateway.  Since their system
> doesn't have a connection open on that port, their system sends a reset
> packet which drops the connection.  I'm still in the process of trying to
> get a tcpdump when this happens while downloading a file, but getting the
> timing right has been difficult.  Since I am on what is essentially an
> unswitched cable network, my logs fill up quickly with all my neighbors
> downstream traffic.
>
> I have contacted @Home and their generic support people have been getting a
> lot of calls about failed downloads.  I talked to someone in their NOC and
> they are looking into the problem.
>
> I'm just curious as to others thoughts on this as I have not played around
> too much with arp.  I do however, have a few questions:
>
> 1) Is it standard practice for certain systems to use an IP already in use?
> 2) Is there a tool that could be used at the Ethernet level (layer 2) to try
> and get more information from a system if you know it's MAC address?
>
> Mike
>
> > From /var/log/messages:
>
> Feb  6 20:27:09 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:27:09 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:36:32 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:36:32 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:37:06 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:37:10 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:37:57 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:37:57 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:37:59 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:37:59 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:38:12 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:38:12 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:38:17 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:38:17 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:38:38 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:38:38 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:38:38 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:38:39 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:38:40 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:38:40 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:38:57 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:38:57 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:39:09 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:39:09 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:39:36 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:39:36 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:40:00 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:40:02 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 20:40:19 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 20:40:19 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 21:00:22 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 21:00:22 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
> Feb  6 21:11:06 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 08:00:07:c4:28:53 on fxp0
> Feb  6 21:11:06 ironman /bsd: arp info overwritten for 24.1.8.1 by
> 00:01:63:f1:d8:80 on fxp0
>
> Ethereal decoded packet:
> Frame 14 (60 on wire, 60 captured)
>     Arrival Time: Feb  6, 2001 13:10:34.4509 <-- ingnore :)
>     Time delta from previous packet: 0.007676 seconds
>     Time relative to first packet: 0.349069 seconds
>     Frame Number: 14
>     Packet Length: 60 bytes
>     Capture Length: 60 bytes
> Ethernet II
>     Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
>     Source: 08:00:07:c4:28:53 (08:00:07:c4:28:53)
>     Type: ARP (0x0806)
>     Trailer: 00000000000000000000000000000000...
> Address Resolution Protocol (request)
>     Hardware type: Ethernet (0x0001)
>     Protocol type: IP (0x0800)
>     Hardware size: 6
>     Protocol size: 4
>     Opcode: request (0x0001)
>     Sender hardware address: 08:00:07:c4:28:53
>     Sender protocol address: 24.1.8.1
>     Target hardware address: ff:ff:ff:ff:ff:ff
>     Target protocol address: 24.1.14.32
--
Dragos Ruiu <dr () dursec com>   dursec.com ltd. / kyx.net - we're from the future
gpg/pgp key on file at wwwkeys.pgp.net or at http://dursec.com/drkey.asc
CanSecWest/core01: March 28-30, Vancouver B.C.
Speakers: a whole bunch of cool guys and the massive sig was a pain.... see http://dursec.com