[Xen-users] Re: Live Migration Config

["Alan Greenspan" <alan@xxxxxxxxxxx>]

Network security is usually policy driven by the IT department.   I don't 
think Xen can mandate a network security model - VPNs, VLANs, etc..  Some 
organizations don't need strict network security, but still need to protect 
against bugs or control certain types of access within an unprotected 
network segment.   It's unreasonable to require firewalling or VPNs as a 
prerequisite to installing Xen.
My subnet is generally open.   However, that doesn't mean I configure my 
machine to allow my neighbors to rsync or NFS mount my disks.    I'm more 
worried about mistakes rather than security.   I certainly don't want the 
guy next door to type "xm migrate ...", finger fumble an IP address and 
shoot my machine with a domU that inadvertently scribbles on my disks.
Most, if not all inet services provide some level of access control within 
their own config files and/or via host_access(5).   You'd hard pressed to 
find a service that didn't do this, but punted to the IT department for 
protection instead.
The following configurable controls should be implemented for Xen migration.

1. The migration port.
2. The network interface(s) that the migration service listens on.
3. The maximum # of allowed concurrent incoming migrations from a foreign 
host.
4.  Observance of the /etc/hosts.allow and /etc/hosts.deny access controls 
(or the same within a Xen config file).
5.  Some simple way to turn off incoming migration completely.

Alan

> Message: 2
> Date: Sat, 29 Oct 2005 22:00:00 -0500
> From: Charles Duffy <cduffy@xxxxxxxxxxx>
> Subject: [Xen-users] Re: Live Migration Config
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Message-ID: <43643730.50407@xxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Mark Williamson wrote:
> > Xend trusts anything the incoming config tells it...  Could get nasty
> > very
> > quickly from both security and DoS perspectives.
> I haven't heard objections raised to my suggestion of running a VPN over
> your regular network for the purpose. This allows encryption, validation
> and access control; the thing it lacks is *fine-grained* control -- a
> Dom0 is either part of the VPN or it isn't -- but this shouldn't be a
> concern if your Dom0s are adequately secured. Ideally, they should be
> accessible *only* via VPN connections or via direct console
> communication. If you need remote administration, do that -- but guard
> the key zealously.
>
> Since your Dom0s are accessible *only* via console or VPN access from
> another system, and the other VPNned systems are likewise only
> accessible via console or VPN (except for your administrative system),
> there's not much by way of risk that one of your Dom0s *can* be
> penetrated, so long as your console access is physically secure.
>
>
> So -- so long as your Dom0s are secured via a VPN with a firewall
> preventing all non-VPN access, I really don't see the concern being as
> substantial as you make it to be.

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