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
|
Home