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

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



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


 


Rackspace

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