[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] [SECURITY] preventing Hwaddr spoofing on bridge

  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Andy Smith <andy@xxxxxxxxxxxxxx>
  • Date: Sun, 25 Nov 2007 07:50:23 +0000
  • Delivery-date: Sat, 24 Nov 2007 23:51:12 -0800
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Openpgp: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc

Hi Stefan,

On Sun, Nov 25, 2007 at 02:53:04AM +0100, Stefan de Konink wrote:
> Hi Andy,
> Andy Smith schreef:
> > On Sun, Nov 25, 2007 at 02:30:54AM +0100, Stefan de Konink wrote:
> >> It is *not* the IP addy that borks. It is a duplicate mac address in the
> >> bridge. So I 'virtually' take over a MAC address belonging to someone
> >> else on the bridge. Binding an IP address to a MAC address is too simple.
> > 
> > I hard code all MAC addresses in the domain config file and when I
> > last tested any attempt to change the vif's MAC address after that
> > results in no connectivity.  Is it still possible?
> Just do a xm console host2, then your host2 will be connected...
> (basically simulates a 'script' running)

I see your point.  I hadn't thought of that problem before.  I have
done some preliminary testing with ebtables and the following seems
to work:

ebtables -t nat -A PREROUTING -i some-vif -s ! aa:00:00:6a:38:0c --log-level 
debug --log-prefix 'SPOOF:' -j DROP

In this example I have a domU on some-vif with MAC address
aa:00:00:6a:38:0c.  I then log into console and issue:

# ifdown eth0
# ifconfig eth0 hw ether 00:16:4e:14:ae:10
# ifup eth0

00:16:4e:14:ae:10 is a MAC address of another domU on the same

I then see in dom0's syslog:

Nov 25 07:28:03 kwak kernel: SPOOF: IN=some-vif OUT= MAC source = 
00:16:4e:14:ae:10 MAC dest = 33:33:00:00:00:16 proto = 0x86dd
Nov 25 07:28:04 kwak kernel: SPOOF: IN=some-vif OUT= MAC source = 
00:16:4e:14:ae:10 MAC dest = 33:33:ff:14:ae:10 proto = 0x86dd

I receive no kernel message in domU about duplicate MAC addresses,
as I have previously when attempting this.  The bridge does not see
the MAC address shift from one port to another.  Connectivity to the
victim domU does not die as it had previously.

So, I think this may be what is required.  I will keep the rule in
place for my test domains for a while just to check that it doesn't
get triggered incorrectly.

Can you still find a way to break it after using this method?


Attachment: signature.asc
Description: Digital signature

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.