[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |