From owner-freebsd-questions@FreeBSD.ORG Thu Feb 11 12:50:25 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B530B106566B for ; Thu, 11 Feb 2010 12:50:25 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0741F8FC1E for ; Thu, 11 Feb 2010 12:50:24 +0000 (UTC) Received: from vhoffman.lon.namesco.net (187.70-246-213.ippool.namesco.net [213.246.70.187]) (authenticated bits=0) by unsane.co.uk (8.14.3/8.14.3) with ESMTP id o1BCoMsZ029340 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 11 Feb 2010 12:50:23 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4B73FD0E.6050409@unsane.co.uk> Date: Thu, 11 Feb 2010 12:50:22 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: yikes! MAC address changed ?? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 12:50:25 -0000 On 11/02/2010 11:00, James Smallacombe wrote: > > Sorry for replying to myself (AND top-posting!) twice in a row, but > this is become a huge concern. My first thought is that my provider > changed routers or router Ethernet ports, hence the MAC address > change. They deny this, plus I find the two MAC addresses: > > 00:17:e0:4f:b9:c0 to 00:13:e0:4f:b9:c0 > If it wasnt for the 00:17 to 00:13 change I would suggest that it was a HSRP/VRRP change, (Virtual ip used by 2 routers in a fail over fashion) as I see this message often on one of my boxes which are on a LAN with a pair of ZXTM Load balancers, when one moves from active to passive and the other takes over (at least I assume thats what they are doing as apparently they arent running active-active.) arp: 85.233.xxx.xxx moved from 00:30:48:d4:8c:2a to 00:30:48:d4:8e:86 on em0 arp: 85.233.xxx.xxx moved from 00:30:48:d4:8e:86 to 00:30:48:d4:8c:2a on em0 arp: 85.233.xxx.xxx moved from 00:30:48:d4:8c:2a to 00:30:48:d4:8e:86 on em0 arp: 85.233.xxx.xxx moved from 00:30:48:d4:8e:86 to 00:30:48:d4:8c:2a on em0 arp: 85.233.xxx.xxx moved from 00:30:48:d4:8b:c9 to 00:30:48:d4:8e:d1 on em0 arp: 85.233.xxx.xxx moved from 00:30:48:d4:8e:d1 to 00:30:48:d4:8b:c9 on em0 However in your case, while 00:17:E0 is reasonable (a cisco mac address) 00:13:E0 is a little worrying as apparently its a Murata Manufacturing(whoever they are) mac address (see http://www.coffer.com/mac_find/?string=00%3A13%3Ae0%3A4f%3Ab9%3Ac0) you can check if its a static entry in your arp tables using arp -a | grep permanent The only permanent entries should be your local IPs (whatever you have configured on your interfaces) unless you have any others you have put in yourself. so for my server i have root@seaurchin ~]# arp -a | grep permanent seaurchin.the.namesco.net (85.233.xxx.xxx) at 00:11:43:d8:2c:df on em0 permanent [ethernet] ? (10.20.0.3) at 00:11:43:d8:2c:df on em0 permanent [ethernet] (10.20.0.3 is a jail) If i manually add an arp entry [root@seaurchin ~]# arp -s 85.233.xxx.254 00:30:48:b8:55:ff [root@seaurchin ~]# arp -a | grep permanent ? (85.233.xxx.254) at 00:30:48:b8:55:ff on em0 permanent [ethernet] seaurchin.the.namesco.net (85.233.xxx.xxx) at 00:11:43:d8:2c:df on em0 permanent [ethernet] ? (10.20.0.3) at 00:11:43:d8:2c:df on em0 permanent [ethernet] Hope this helps a little. Vince > too close to each other for comfort. My obvious concern here is that > the recent php compromises somehow allowed an attacker to alter the > ARP table entry of the default gateway. Specific questions are as > follows: > > 1) If this were done via a perl or php script, presumably executing > an 'arp -s' command, would it show up in the log like that? I've > never changed an ARP entry (except to delete it using 'arp -d'), so > I've only seen log entries like that due to external changes, like > somebody changing IPs on the LAN from one Ether to another. > > 2) Could an Ethernet card defect or re0 driver problem cause anything > like this? Other bug? > > 3) If this was an attacker using a local script, how the hell does he > get a php or perl script owned by UID 80 (or worst case, a user), > to do this? > > Thanks again for any insight...appreciate a reply to both list and > directly. > > On Wed, 10 Feb 2010, James Smallacombe wrote: > >> >> Please disregard this...sleep deprication...the IP in questions >> (which I should have disfuised anyway) was not my server's IP, but >> that of the default gateway...the problem was external. >> >> On Wed, 10 Feb 2010, James Smallacombe wrote: >> >>> >>> This freaked me out a bit, so I'm just running it past the list to >>> make sure this is just a hardware issue...I've never seen it before. >>> >>> My dedicated server provider replaced my defective server that had >>> been up for 6 months after it had apparent failures of a NIC and >>> hard drives. It had also recently been the victim of the Zen Cart >>> exploits (I posted about this not long ago). >>> >>> Tonight I lost connectivity to it, got in via KVM/IP and saw this in >>> the syslog: >>> >>> Feb 10 20:42:51 mail kernel: arp: 209.17.170.1 moved from >>> 00:17:e0:4f:b9:c0 to 00:13:e0:4f:b9:c0 on re0 >>> >>> My first reaction was that somebody else on the LAN had used my IP >>> address, which would have explained the connectivity issues. >>> However, the IP couldn't be pinged and I also noticed that only one >>> number in the address had changed...the odds of somebody else having >>> it were long. ifconfig showed the I/F down, no carrier. >>> >>> I rebooted and then it came up with yet a third MAC address, >>> 00:14:d1:3c:1e:31 Not really even close. Still no carrier. >>> Provider swaps out the Realtek NIC for a new one and it's working >>> (for now). >>> >>> Questions that come to mind: could their be a DoS perhaps from a bot >>> or c99shell I didn't find? Even if their was, would it be possible >>> for the "www" user, with no priveleges to even cause this kind of >>> problem? I had disabled suhosin after customers patched their Zen >>> Carts, because it interfered with it. >>> >>> Or...could this be a bug in the re0 driver? It's just weird. >>> >>> James Smallacombe PlantageNet, Inc. CEO and Janitor >>> up@3.am http://3.am >>> ========================================================================= >>> >>> >> >> James Smallacombe PlantageNet, Inc. CEO and Janitor >> up@3.am http://3.am >> ========================================================================= >> >> > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up@3.am http://3.am > ========================================================================= > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org"