Re: Arp Warnings on @Home Network

["Forrester, Mike" <mforrester () HSACORP NET>]

First I want to apologize for beating a dead horse, but I'm still trying to
get a full understanding of how this is happening (there are more logs at
the end).  I'll going to dig out Stevens (TCP/IP Illustrated) here
shortly...

> If I had to take a wild guess, I'd say that @home uses Cisco for their
routers, and not Macs. :)

That's what I figured too, but hey, this is @Home.  They seem to do some
pretty odd stuff.  I have two static IP's and they are on different subnets
(one is on a /21 and the other a /24) which seems odd to me.  BTW - doesn't
this ip scheme make managing the network a bit more difficult than it should
be?  I'm never managed a network anywhere near their size, but this doesn't
seem like a good practice to me, IMHO.

> A decent attacker would forward the packet after he got it, and your
connection would still work, albeit sniffed.

That's why I'm not too worried about it, but interested none the less.

> That's actually the most interesting aspect of your post...what flavor of
@Home are you on?  Out here, AT&T @Home doesn't seem to send packets down
your wire if they aren't for you.

I'm on an old COM 21 system and the cable modem I have routes all downstream
traffic out the Ethernet port.  The newer systems use cable modems that act
as a learning bridge and only route packets that are destined for MAC
addresses on the other side.

> If you're able to sniff your neighbors, then a successful version of the
default router hijack would work just great for an attacker that knew what
they are doing.  But that's really only interesting to do as a way to sniff
traffic.. which it seems is easier than that.  Now, if one wanted to hijack
connections... being a router in the middle helps a lot.

Since I can only see the downstream, I can't get any passwords or other
juicy info (the fact that one of my neighbors visits s3x () pe com on a regular
basis is on no interest to me).  However, I probably could if I tried to be
the mail server.  However, if they were telneting from work to their system
at home, I could probably sniff the password.

> That's about all you can do.  Let us know what they do when you tell them
you've been sniffing traffic. :)

You won't tell, will you? :)

> BTW, if you're just trying to get the annoyance to go away, look at the
man pages for the ARP command.  You should be able to hard-code the right
MAC address.

Yeah I thought about putting in a static entry in the arp table, but right
now this is more fun.  Maybe not for those on the list, but it is for me.

Below is output from /var/log/messages:
Feb  6 22:51:10 ironman /bsd: arp info overwritten for 24.1.8.1 by
08:00:07:c4:28:53 on fxp0
Feb  6 22:51:10 ironman /bsd: arp info overwritten for 24.1.8.1 by
00:01:63:f1:d8:80 on fxp0

Below is tcpdump -envv output (minus irrelevant traffic) that I logged while
downloading files from ftp.openbsd.org and when the above messages were
logged.

Lines 1-5 show traffic happily going back and forth between my system and
the gateway.
Line 6 shows the arp broadcast by the Mac system.
Lines 7-8 show more data going to my system from the gateway
Line 9 shows system sending a response to the Mac (with no captured return
packet).
Line 10 shows the @Home router taking control back.
Lines 11- 14 show the traffic back to normal.

The part I don't understand is Line [6].  This appears to me to be an arp
request by the Mac system to see if the ip address 24.1.14.32 is available
for use.  Why is this causing my OpenBSD box to change the MAC address in
it's arp table?

Mike

0:90:27:73:fa:ca - the MAC of my OpenBSD box
0:1:63:f1:d8:80 - the MAC of @Home's router
8:0:7:c4:28:53 - the MAC of the Mac :)

[1]22:51:10.819066 0:90:27:73:fa:ca 0:1:63:f1:d8:80 0800 66: 24.1.x.y.16166
> 129.128.5.191.42408: . [tcp sum ok] ack 3394385 win 17376
<nop,nop,timestamp 23217 917238081> [tos 0x8] (ttl 64, id 14619)
[2]22:51:10.824136 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514:
129.128.5.191.42408 > 24.1.x.y.16166: . 3394385:3395833(1448) ack 1 win
10136 <nop,nop,timestamp 917238082 23217> (DF) (ttl 242, id 32334)
[3]22:51:10.827563 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514:
129.128.5.191.42408 > 24.1.x.y.16166: . 3395833:3397281(1448) ack 1 win
10136 <nop,nop,timestamp 917238082 23217> (DF) (ttl 242, id 32335)
[4]22:51:10.827647 0:90:27:73:fa:ca 0:1:63:f1:d8:80 0800 66: 24.1.x.y.16166
> 129.128.5.191.42408: . [tcp sum ok] ack 3397281 win 17376
<nop,nop,timestamp 23217 917238082> [tos 0x8] (ttl 64, id 14501)
[5]22:51:10.912669 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514:
129.128.5.191.42408 > 24.1.x.y.16166: . 3397281:3398729(1448) ack 1 win
10136 <nop,nop,timestamp 917238091 23217> (DF) (ttl 242, id 32336)
[6]22:51:10.944844 8:0:7:c4:28:53 ff:ff:ff:ff:ff:ff 0806 60: arp who-has
24.1.14.32 (ff:ff:ff:ff:ff:ff) tell 24.1.8.1
[7]22:51:10.950313 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1018:
129.128.5.191.42408 > 24.1.x.y.16166: . 3398729:3399681(952) ack 1 win 10136
<nop,nop,timestamp 917238095 23217> (DF) (ttl 242, id 32337)
[8]22:51:10.952362 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514:
129.128.5.191.42408 > 24.1.x.y.16166: . 3399681:3401129(1448) ack 1 win
10136 <nop,nop,timestamp 917238095 23217> (DF) (ttl 242, id 32338)
[9]22:51:10.952450 0:90:27:73:fa:ca 8:0:7:c4:28:53 0800 66: 24.1.x.y.16166 >
129.128.5.191.42408: . [tcp sum ok] ack 3401129 win 17376 <nop,nop,timestamp
23218 917238091> [tos 0x8] (ttl 64, id 12395)
[10]22:51:10.952509 0:1:63:f1:d8:80 ff:ff:ff:ff:ff:ff 0806 60: arp reply
24.1.8.1 is-at 0:1:63:f1:d8:80 (0:1:63:f1:d8:80)
[11]22:51:10.954049 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514:
129.128.5.191.42408 > 24.1.x.y.16166: P 3401129:3402577(1448) ack 1 win
10136 <nop,nop,timestamp 917238095 23217> (DF) (ttl 242, id 32339)
[12]22:51:10.954147 0:90:27:73:fa:ca 0:1:63:f1:d8:80 0800 66: 24.1.x.y.16166
> 129.128.5.191.42408: . [tcp sum ok] ack 3402577 win 17376
<nop,nop,timestamp 23218 917238095> [tos 0x8] (ttl 64, id 4157)
[13]22:51:10.969148 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514:
129.128.5.191.42408 > 24.1.x.y.16166: . 3402577:3404025(1448) ack 1 win
10136 <nop,nop,timestamp 917238097 23217> (DF) (ttl 242, id 32340)
[14]22:51:10.970044 0:90:27:73:fa:ca 0:1:63:f1:d8:80 0800 66: 24.1.x.y.16166
> 129.128.5.191.42408: . [tcp sum ok] ack 3404025 win 17376
<nop,nop,timestamp 23218 917238097> [tos 0x8] (ttl 64, id 7442)