On Thu, 11 Feb 2010, Matthew Seaman wrote:
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
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:
They're not just close: it's a single bit change between the two MACs
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.
You'ld need root level access to change something like that, no matter
if it was from the shell or via some scripting language. If an attacker
has the capability to do that to you, then it's *game* *over* -- wipe
the box and start again. Of course, that's a pretty bizarre thing for
an attacker to do. It draws attention to itself by disrupting your
network communications and there isn't any obvious advantage to be
gained by doing that. [There might be if the MAC was changed to
collide with another one on the same network segment but I believe that
is not the case here.]
I figure root at some point is needed, but wondered if there was another
POA I had to worry about. In effect, I already "wiped out" this server a
few days ago...new drives with new / FS from 7.2-RELEASE. However, I did
copy over /usr/local and /home file systems from the old server's drive,
and parts of /var. Everything in / (including /usr) is fresh.
It's not 'arp -s' that is used to change the MAC address on an
interface, but ifconfig(8) -- something like this:
# ifconfig re0 ether 00:17:e0:4f:b9:c0
See my second post. I screwed up in my first post. It wasn't the MAC
address of my NIC that changed, it's the MAC address of the DEFAULT
GATEWAY that changed. I believe that would use 'arp', not 'ifconfig',
right?
2) Could an Ethernet card defect or re0 driver problem cause anything
like this? Other bug?
Yes -- this is the most likely cause. Hardware problems. The MAC
address is built into the network card using an EEPROM or such like,
and those can conceivably go bad. Replace the NIC and see if the
problems go away.
Ok, longer shot here...could a hardware problem on my box screw up the MAC
address of the default gateway? It should be noted that when I did and
ifconfig -a during this down time, the Ether showed "no carrier". Could
messed up ARP tables even do that? I would think that the carrier just
needs a cable plugged from the NIC into a switch?
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?
You don't. You need root access to change the MAC on a network
interface. Same as for changing the IP number on the interface.
Check /etc/rc.conf -- if there aren't ifconfig commands in there
to modify the ether or link address, and if the modified MAC survives
a system reboot, then it's almost certainly hardware going kaput.
Even if the MAC does recover on reboot, it still might be flakey
hardware.
Still had no carrier after reboot. Only after swapping the NIC. Does a
reboot wipe out the ARP tables?
James Smallacombe PlantageNet, Inc. CEO and Janitor
[email protected] http://3.am
=========================================================================
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"
