5

I'm scratching my head about this question... I have a debian squeeze machine that is connected to an internal lab network. We have a lot of machines that have default proxy-arp configurations on them, and occasionally one of those machines starts hijacking a lot of lab addresses.

After resolving the latest Proxy-ARP incident which brought down most of our lab, I found a few residual entries like this in /var/log/syslog (below). For those not accustomed to reading arpwatch logs, the machine that owns 00:11:43:d2:68:65 is fighting with 192.168.12.102 and 192.168.12.103 about who owns those address.

Sep 13 14:25:27 netwiki arpwatch: flip flop 192.168.12.103 00:11:43:d2:68:65 (84:2b:2b:4b:71:b4) eth0
Sep 13 14:26:24 netwiki arpwatch: flip flop 192.168.12.103 84:2b:2b:4b:71:b4 (00:11:43:d2:68:65) eth0
Sep 13 14:29:03 netwiki arpwatch: flip flop 192.168.12.102 00:26:b9:4e:d3:71 (00:11:43:d2:68:65) eth0
Sep 13 14:29:03 netwiki arpwatch: flip flop 192.168.12.102 00:11:43:d2:68:65 (00:26:b9:4e:d3:71) eth0

The very alarming thing is that 00:11:43:d2:68:65 belongs to the same machine I was running arpwatch on... First, I validated that /proc/sys/net/ipv4/conf/eth0/proxy_arp is 0. Next, I used tshark to validate that my machine really is spoofing ARPs to others...

[mpenning@netwiki ~]$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:11:43:d2:68:65 brd ff:ff:ff:ff:ff:ff
    inet 192.168.12.239/24 brd 192.168.12.255 scope global eth0
    inet6 fe80::211:43ff:fed2:6865/64 scope link
       valid_lft forever preferred_lft forever
[mpenning@netwiki ~]$
[mpenning@netwiki ~]$ arp -an
? (192.168.12.46) at 00:15:c5:f5:81:9d [ether] on eth0
? (192.168.12.236) at 00:1e:c9:cd:46:c8 [ether] on eth0
? (10.211.180.1) at 00:1e:49:11:fe:47 [ether] on eth1
? (192.168.12.20) at f0:4d:a2:02:81:66 [ether] on eth0
[mpenning@netwiki ~]$ cat /proc/sys/net/ipv4/conf/eth0/proxy_arp
0
[mpenning@netwiki ~]$ sudo tshark -i eth0 arp and ether src 00:11:43:d2:68:65
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
  0.000000 Dell_d2:68:65 -> Dell_02:81:66 ARP 192.168.12.102 is at 00:11:43:d2:68:65
 84.954989 Dell_d2:68:65 -> Dell_f5:81:9d ARP 192.168.12.103 is at 00:11:43:d2:68:65
[mpenning@netwiki ~]$ uname -a
Linux netwiki 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux
[mpenning@netwiki ~]$

The facts are undeniable. I have a debian box that is spoofing ARPs and I have no idea why. I am the only user on this machine, I run fail2ban to prevent brute-force attacks, and it's on an internal lab network behind a door that requires a badge for entry; I highly doubt it has been hacked.

Three questions...

  1. First, is there any cause I may have missed? What steps should I use to isolate whether this is an application or kernel problem?
  2. If this is a kernel bug, which mailing-list should I report it on? FYI, the normal kernel.org bug reporting tool seems to be down right now.
  3. Is there anything I can do to to solve the problem other than waiting for a patch?
xhienne
  • 17,075
  • 2
  • 52
  • 68
Mike Pennington
  • 2,452
  • 4
  • 31
  • 40

1 Answers1

4

I found the problem... I was demonstrating how proxy-arp worked on a spare ethernet interface a few weeks ago and left the configs on the machine (although I had the interface DOWN).

When I removed these entries for 192.168.12.0/24 from eth2, I no longer had the problem.

[mpenning@netwiki ~]$ ip add show eth2
4: eth2: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:10:18:02:32:86 brd ff:ff:ff:ff:ff:ff
    inet 192.168.12.100/24 scope global eth2
    inet 192.168.1.100/24 scope global eth2
    inet 192.168.12.101/24 scope global secondary eth2
    inet 192.168.12.102/24 scope global secondary eth2
    inet 192.168.12.103/24 scope global secondary eth2
    inet 192.168.12.104/24 scope global secondary eth2
    inet 192.168.12.105/24 scope global secondary eth2
[mpenning@netwiki ~]$

I still think this is a bug and it needs to be filed. I will update with the bug information when it is completed.

Mike Pennington
  • 2,452
  • 4
  • 31
  • 40