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

Re: Re: [Xen-users] XCP antispoof


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: George Shuklin <nge@xxxxxxxx>
  • Date: Tue, 11 May 2010 12:47:13 +0400
  • Delivery-date: Tue, 11 May 2010 01:48:16 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

I look deeper in openswitch... I found no way to have nice spoofing protection 
without openflow controller. And yes, spoofing is possible, I check it.

Following lines to ovs-ofctl enables mac security (drop any traffic from VM 
with incorrect combination of MAC address and IP, settings work only for 
certain MAC/IP):

ovs-ofctl add-flow xenbr0 "dl_src=36:75:e2:35:d7:ea priority=39000 
dl_type=0x0800 nw_src=18.93.16.25 idle_timeout=65000 action=normal"
ovs-ofctl add-flow xenbr0 "dl_src=36:75:e2:35:d7:ea priority=38000 
dl_type=0x0800 nw_src=ANY idle_timeout=65000 action=drop"


And we can bind mac to interface (port security):

ovs-ofctl add-flow xenbr0 "in_port=2 priority=39000 dl_type=0x0800  
nw_src=188.93.16.253 idle_timeout=65000 action=normal"
ovs-ofctl add-flow xenbr0 "in_port=2 priority=38500 dl_type=0x0806 
idle_timeout=65000 action=normal" #пока пускаем ARP без контроля.
ovs-ofctl add-flow xenbr0 "in_port=2 priority=38000 idle_timeout=65000 
action=drop"

The main problems I see here is:
1) Those line washed away after idle_timeout.
2) They are not associated with vm migration process
3) Port number hard to obtain (about 3 greps from xe/ovs output).


I still did not tried to install/use openflow controller (may be this will be 
gold solution?), but direct control of openflow for OVS is very tricky and may 
cause some unpleasant results in product environment.

11.05.10, 11:39, "Matthew Law" <matt@xxxxxxxxxxxxxxxxxx>:

> Before you did this did you test to see if the standard XCP setup with
>  openvswitch is in fact 'spoofable'?
>  
>  You may be able to accomplish the same results by using flows in
>  openvswitch itself rather than going to the trouble of using iptables
>  rules. It might be worth asking the ovs mailing list.
>  
>  Interested to know how you get on,
>  
>  Matt.
>  
>  On Mon, May 10, 2010 8:46 pm, C V wrote:
>  > Thanks
>  > I got the xt_physdev.ko from /lib/modules/ inside the DDK VM and copied it
>  > to dom0 /lib/modules/...
>  > I ran depmod inside dom0 and modprobe xt_physdev in dom0 results in the
>  > same problem.
>  >
>  > ----- Original Message ----
>  > From: Jorge Armando Medina 
>  > To: xen-users@xxxxxxxxxxxxxxxxxxx
>  > Sent: Mon, May 10, 2010 12:03:46 PM
>  > Subject: Re: [Xen-users] XCP antispoof
>  >
>  > C V wrote:
>  >> I've been trying to emulate the Xen antispoof features in XCP. This
>  >> requires the xt_physdev iptables extension. Here's what I've done:
>  >> 1. Downloaded the XCP DDK VM and installed it
>  >> 2. Downloaded the Dom0 kernel sources from
>  >> http://www.xen.org/files/XenCloud/Software/latest/sources/source-1.iso
>  >> to a running DDK VM instance
>  >> 3. make menuconfig inside the kernel sources and enable physdev inside
>  >> Networking->Network Packet Filtering->Core Netfilter
>  >> Configuration->physdev match support
>  >> 4. make modules modules_install inside the kernel sources
>  >> 5. Copy resulting xt_physdev.ko to dom0
>  >>
>  > I think step 4 will copy the modulo in /lib/modules/kern-version/..
>  >> 6. insmod results in an error:
>  >> insmod ./xt_physdev.ko
>  >> insmod: error inserting './xt_physdev.ko': -1 Unknown symbol in module
>  >>
>  > Did you depmod after installing the modules?
>  >
>  >> dmesg shows the error to be:
>  >> xt_physdev: disagrees about version of symbol xt_register_matches
>  >> xt_physdev: Unknown symbol xt_register_matches
>  >> Modinfo reports the correct version:
>  >> # modinfo xt_physdev.ko
>  >> filename:       xt_physdev.ko
>  >> alias:          ip6t_physdev
>  >> alias:          ipt_physdev
>  >> description:    Xtables: Bridge physical device match
>  >> author:         Bart De Schuymer 
>  >> license:        GPL
>  >> srcversion:     4D030E98D0F909D8DA92F33
>  >> depends:        x_tables
>  >> supported:      yes
>  >> vermagic:       2.6.27.42-0.1.1.xs0.1.1.737.1065xen SMP mod_unload
>  >> modversions Xen 686
>  >>
>  >>
>  >> It seems that it requires a complete kernel rebuild and re-install. Can
>  >> anybody confirm this or help me with an alternate way of building
>  >> required iptables extensions?
>  >>
>  >> Thanks
>  >> --
>  >> C V
>  
>  
>  _______________________________________________
>  Xen-users mailing list
>  Xen-users@xxxxxxxxxxxxxxxxxxx
>  http://lists.xensource.com/xen-users
>  
>  

-- 
wBR,George.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

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