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