Re: [Xen-users] Re: Live Migration Config

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Anthony Liguori wrote:

> Alan Greenspan wrote:
>
> > I think its got to work as Ian outlined with proper configurable 
> > access controls like any other inet service.   Look to other services 
> > as examples, e,g, rsync, ftp, nfs, etc.   Mucking with iptables isn't 
> > for the average consumer (or even the average management tool).
>
> Yeah, iptables is definitely a beast.  In this case though, the 
> commands are pretty sane:
> If you care about security, always run:
>
>  iptables -D INPUT -p tcp --destination-port 8002 -j REJECT
This of course should be:

iptables -A INPUT -p tcp --destination-port 8002 -j REJECT

Regards,

Anthony Liguori

> This inserts a rule to disable all traffic to port 8002.  This 
> effectively shuts migration off (#5).  To enable migration from 
> specific addresses, you would then say:
>  iptables -I INPUT -p tcp --source 192.168.1.100 --destination-port 
> 8002 -j ACCEPT
> Which allows migrations to originate from 192.168.1.100.  If you later 
> change your mind, you can say:
>  iptables -D INPUT -p tcp --source 192.168.1.100 --destination-port 
> 8002 -j ACCEPT
> Which disallows migrations from 192.168.1.100.   For added security, 
> you can only enable migration from a given address before you do the 
> migration and then immediately disable it after the migration is done.
> You can replace 192.168.1.100 with a hostname or even a netmask 
> (either in the form 192.168.1.100/8 or 192.168.1.100/255.255.255.0).
> Best of all, you don't have to restart Xend for the rules to take affect.
>
> Regards,
>
> Anthony Liguori
>
> > Alan
> >
> > > > > 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.
> > > > 1, 2 & 5 are already possible; 4 is simple and is on the todo 
> > > > list[*]. 3
> > > > is more of a higher level tools issue.
> > > >
> > > > The correct soloution is probably to have an 'xm migraterx' command 
> > > > that
> > > > generates a session key that has to be handed to 'xm migratetx'. The
> > > > actual transfer can then be authenticated, and potentially encrypted.
> > > > However, this will not be in 3.0.0.
> > > With an SSL Xend interface, this would work quite well.  
> > > Unfortunately, this is a bit of work because Python doesn't have 
> > > server-side SSL support (doh!).
> > > > [*] The intention is that the set of allowable hosts be specificed in
> > > > xend-config.sxp e.g.: (migration-hosts-allow "*.test.xensource.com"
> > > > "129.34.45.0/24" "xenbits.xs.org" )
> > > This might be a bit of overkill.  Any basic firewall can provide 
> > > this functionality already.  What would be nice is to have some 
> > > common firewall configurations for dom0 in the Users Manual.  I'll 
> > > write up something for Shorewall this week.
> > > Regards,
> > >
> > > Anthony Liguori
> > >
> > > > It would be good if someone could knock the above up.
> > > >
> > > > Ian
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-users mailing list
> > > > Xen-users@xxxxxxxxxxxxxxxxxxx
> > > > http://lists.xensource.com/xen-users
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users

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