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

RE: [Xen-API] XCP antispoofing (idea and working patch)



Hi George,

I've cc:d Alex and Rob, who both might have useful thoughts on this.

> Good day.
> 
> I like to raise a question which bother me (and not only me) long time.

It bothers me too :-)

> How we can protect one guest form malicious actions from other guest?
> One of the simplest way to break network is spoofing (usurping) some
> IP/mac addresses on network by abusing ARP or (even) simply assign
> wrong IP to guest machine network interface.
> 
> Classic Xen shipped with antispoofing scripts, but XCP is not.
> 
> What problem we shall solve for quality antispoofing?
> 
> Restriction:
> 1) Shall be configurable (some interface must be restricted, some not)
> 2) must be applying on EVERY host in the pool
> 3) Shall be removed when VM is down or mirgrated out (do not disturb
> any other VM)
> 4) Shall survive reboot (when dom ID and vif interface int dom0
> changing)
> 5) Shall survive migration
> 6) shall restrict both IP and mac usage.

I think these requirements are sensible.

> I create some simple patch to /etc/xensource/scripts/vif (it called
> every time new vif initializing or deinitializing).

Looks good...

> It depends on openvswitch (and does not work with classic brtools),

This is fine.

> using /etc/xensource/ip_restriction.conf with following syntax:
> 
> vif-uuid ip
> (one per line), f.e.
> 25ca3ed1-06ea-5f58-9283-f2af3e8b373e 192.168.1.144
> 
> This file must be identical on every host in the pool.
> 
> If vif uuid is not listed it this file, it silently do nothing. If
> openvswitch is not used, it silently do nothing.
> 
> If IP (right now only ipv4) is assigned to vif-uuid, that vif is
> restricted to it mac (autodetected via xenstore) too.
> 
> When vif is down (vm down, migrated or rebooted) it clear all
> restriction on openvswitch port right before port unplugging.

Sounds good.

> The main concern is usage of configuration file instead xapi. I think
> it
> must be placed somewhere to vif's other config (but it far beyond my
> knowledge, and I except some help with this). xapi shall place
> ip_restriction to other config and copy it to xenstore for vif to be
> readable from scripts/vif script.

This part needs a bit more thought. I was wondering if we wanted to have 
first-class fields for this kind of VIF/switch configuration... something like

Network.default_secure: bool -- if true then unconfigured VIFs have no access, 
otherwise they have full access
VIF.allowed_addresses: some encoding of values like
  Some (list of (MAC, IPv4) pairs) -- specific addresses to limit the VIF to. 
Probably need '*, *'
  None -- no configuration

What do you think, Rob/ Alex?

Also adding explicit openflow rules will conflict with any attached openflow 
controller (eg nox) so we should make it an explicit choice: disable these 
rules and enable a controller, or disable a controller and enable these rules.

Cheers,
Dave

> 
> This patch is against XCP 0.5 (not 1.0b)
> 

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api

 


Rackspace

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