Hi, How does one configure the live migration facility? Is there a configuration file to allow a foreign dom0 to migrate a domU to the local dom0? Or can any dom0 migrate a domU to any other dom0? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> How does one configure the live migration facility? Is there a > configuration file to allow a foreign dom0 to migrate a domU to the local > dom0? Or can any dom0 migrate a domU to any other dom0?It''s pretty much free for all as far as dom0s are concerned ;-) Basically if one dom0 can reach another over a network, it can migrate stuff there! Right now, it''s more or less expected that an organisation''s dom0s are isolated on a vlan (or separate ethernet). Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Friday 28 October 2005 00:26, Mark Williamson wrote:> > How does one configure the live migration facility? Is there a > > configuration file to allow a foreign dom0 to migrate a domU to the local > > dom0? Or can any dom0 migrate a domU to any other dom0? > > It''s pretty much free for all as far as dom0s are concerned ;-) Basically > if one dom0 can reach another over a network, it can migrate stuff there! > Right now, it''s more or less expected that an organisation''s dom0s are > isolated on a vlan (or separate ethernet).Supposing the domain has not been isolated, supposing you were trying to transfer the domain on an open link across a subnet to another datacenter (for migratory purposes to another location entirely) - is there not some kind of way of preventing migration, or am I being stupid, and everyone firewalls their server to prevent this? I say this as my Xen units are on a private network, completely unfirewalled at this time, and am considering going live with a public IPv6 implementation. Matthew Walster _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
This is not good. I''m going to have a devil of a time selling this into enterprises of any size. Are there any plans to provide filtering rules, authentication, authorization facilities in the works? Any bolt-ons? We''re looking at a serious show-stopper in organizations large enough to have an information protection department, or even security-minded clueful personnel. As long as I can fire up the Xen Live CD on my laptop and shoot domU missiles at a production Xen instance and have them happily migrate we''re at a standstill. The security people will demand, at a minimum, that we do not run xfrd on the production node. There goes a monster selling point and my entire position against VM-Ware. I am a professional C/Unix coder. Can I help provide this functionality? It seems fairly trivial. On 10/27/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> > > How does one configure the live migration facility? Is there a > > configuration file to allow a foreign dom0 to migrate a domU to the > local > > dom0? Or can any dom0 migrate a domU to any other dom0? > > It''s pretty much free for all as far as dom0s are concerned ;-) Basically > if > one dom0 can reach another over a network, it can migrate stuff there! > Right > now, it''s more or less expected that an organisation''s dom0s are isolated > on > a vlan (or separate ethernet). > > Cheers, > Mark >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > It''s pretty much free for all as far as dom0s are concerned ;-) > > Basically if one dom0 can reach another over a network, it can migrate > > stuff there! Right now, it''s more or less expected that an organisation''s > > dom0s are isolated on a vlan (or separate ethernet). > > Supposing the domain has not been isolated, supposing you were trying to > transfer the domain on an open link across a subnet to another datacenter > (for migratory purposes to another location entirely) - is there not some > kind of way of preventing migration, or am I being stupid, and everyone > firewalls their server to prevent this? > > I say this as my Xen units are on a private network, completely > unfirewalled at this time, and am considering going live with a public IPv6 > implementation.Right now (and particularly with Xen 2.0, since it exports the management interface over HTTP), the rule is basically not to have anything you don''t trust be able to access dom0 over the network. Even in Xen 3.0, the migration code doesn''t really distinguish friend / foe, so anyone on the same network could migrate stuff to your machine (although it shouldn''t be a security risk, it could get quite annoying!!!). Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> This is not good. I''m going to have a devil of a time selling this into > enterprises of any size. Are there any plans to provide filtering rules, > authentication, authorization facilities in the works? Any bolt-ons?Talking about Xen 3.0: It''s been talked about for some time. For now the solution is to use vlans for your dom0s, or (equivalently) physically separate networks. dom0s are your management infrastructure, and they really need protecting from interference. You can''t have dom0s on a hostile network if you want to prevent these "rogue migrations". Note that you can''t force an outgoing migration from a node, so nobody can "steal" your running domUs. However, if someone gets on a segment of network that can reach your dom0s they could send you some domUs of their own - shouldn''t be a security issue (the domUs will still be isolated by Xen) but could get quite annoying ;-)> looking at a serious show-stopper in organizations large enough to have an > information protection department, or even security-minded clueful > personnel. As long as I can fire up the Xen Live CD on my laptop and shoot > domU missiles at a production Xen instance and have them happily migrate > we''re at a standstill.Only if the laptop is on your management network...> The security people will demand, at a minimum, that > we do not run xfrd on the production node. There goes a monster selling > point and my entire position against VM-Ware.:-( If you''re running Xen 2.0, it''s even more important to run dom0 on a separate network - the management interface is also exported over TCP. By default, it only accepts connections from localhost but it does mean you must trust all local users on the system. IIRC, the Xensource public servers just use a separate management network for the dom0s.> I am a professional C/Unix coder. Can I help provide this functionality? It > seems fairly trivial.Something using SSL certificates would probably do what you want. There are probably other ways to do this stuff, too. Patches to provide this functionality would be very welcome, although I guess we''d prefer them to be against Xen 3.0. HTH, Mark> On 10/27/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote: > > > How does one configure the live migration facility? Is there a > > > configuration file to allow a foreign dom0 to migrate a domU to the > > > > local > > > > > dom0? Or can any dom0 migrate a domU to any other dom0? > > > > It''s pretty much free for all as far as dom0s are concerned ;-) Basically > > if > > one dom0 can reach another over a network, it can migrate stuff there! > > Right > > now, it''s more or less expected that an organisation''s dom0s are isolated > > on > > a vlan (or separate ethernet). > > > > Cheers, > > Mark_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>You can''t have dom0s on a hostile network if you want to prevent these "rogue >>migrations". Note that you can''t force an outgoing migration from a node, so >nobody can "steal" your running domUs. However, if someone gets on a segment >of network that can reach your dom0s they could send you some domUs of their...>own - shouldn''t be a security issue (the domUs will still be isolated by Xen) >but could get quite annoying ;-)It''s actually a huge security hole since a migrating domU carries its device mappings to the target machine. Basically, you could create domU, map one of its disks to say /dev/hdb, migrate it to a target machine and gain access to /dev/hdb on the target. Same goes for any file used as a disk on the source/target dom0. Minimally, Xen should implement a simple hosts.allow hosts.deny mechanism for migration so that a host can limit which other hosts can migrate in. Relying on network isolation using a separate management network isn''t always practical. Alan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Matthew Alton wrote:> This is not good. I''m going to have a devil of a time selling this > into enterprises of any size.This has been discussed a lot--it''s a well known weak point of Xen. The problem is complex and has a lot to do with performance, but suffice to say, it will be solved. Most likely not for 3.0 but likely for the 3.1 timeframe.> Are there any plans to provide filtering rules, authentication, > authorization facilities in the works?Right now, you can achieve reasonable security by using firewall rules. You can use this to provide host-level filtering at least. That doesn''t solve spoofing/sniffing/authentication/etc though.> Any bolt-ons? We''re looking at a serious show-stopper in > organizations large enough to have an information protection > department, or even security-minded clueful personnel. As long as I > can fire up the Xen Live CD on my laptop and shoot domU missiles at a > production Xen instance and have them happily migrate we''re at a > standstill. The security people will demand, at a minimum, that we do > not run xfrd on the production node. There goes a monster selling > point and my entire position against VM-Ware.Live migration is very performance sensitive. There are concerns about the overhead of encrypting the data. If you on an insecure network, you want to do something like: safemigrate() { xm save $1 /tmp/xen-temp-$1.img && \ scp /tmp/xen-temp-$1.img $2:/tmp && \ ssh $2 xm restore /tmp/xen-temp-$1.img && \ rm /tmp/xen-temp-$1.img } safemigrate WebServer root@destination.host.domain You''ll get 10s of seconds to a few minutes of down time but you''ll have excellent security. If you want subsecond down-time, you need an isolated network.> I am a professional C/Unix coder. Can I help provide this > functionality? It seems fairly trivial.Xend needs some rearchitecting to make secure live migration possible. It''s too much change for 3.0 to do it right. However, if you want to help out for 3.1, patches are always appreciated :-) Regards, Anthony Liguori> On 10/27/05, *Mark Williamson* < mark.williamson@cl.cam.ac.uk > <mailto:mark.williamson@cl.cam.ac.uk>> wrote: > > > How does one configure the live migration facility? Is there a > > configuration file to allow a foreign dom0 to migrate a domU to > the local > > dom0? Or can any dom0 migrate a domU to any other dom0? > > It''s pretty much free for all as far as dom0s are concerned > ;-) Basically if > one dom0 can reach another over a network, it can migrate stuff > there! Right > now, it''s more or less expected that an organisation''s dom0s are > isolated on > a vlan (or separate ethernet). > > Cheers, > Mark > > >------------------------------------------------------------------------ > >_______________________________________________ >Xen-users mailing list >Xen-users@lists.xensource.com >http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Williamson wrote:>>I am a professional C/Unix coder. Can I help provide this functionality? It >>seems fairly trivial. >> >> > >Something using SSL certificates would probably do what you want. There are >probably other ways to do this stuff, too. Patches to provide this >functionality would be very welcome, although I guess we''d prefer them to be >against Xen 3.0. > >Python doesn''t have a native SSL server socket :-( We''ll have to write our own OpenSSL python bindings most likely. SSL is also sort of overkill and will have non-neglible overhead. You really just want integrity verification. The only concern then is having the domain''s memory being readable over the network. That''s not acceptable for certain workloads (anything containing private data) but acceptable for the majority (for instance, a static webserver without any sort of password database). You certainly need the option of encrypting the migration traffic though for those workloads where privacy matters. Authentication is the trickier part of this all. Especially since there will be a strong desire to tie into larger-scale authentication infrastructures. Proxying everything over an SSH connection is probably the best long term solution. However, I''ve not been able to figure out how to disable privacy in ssh :-/ Have I mentioned this is a hard problem? ;-) Regards, Anthony Liguori>HTH, >Mark > > > >>On 10/27/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote: >> >> >>>>How does one configure the live migration facility? Is there a >>>>configuration file to allow a foreign dom0 to migrate a domU to the >>>> >>>> >>>local >>> >>> >>> >>>>dom0? Or can any dom0 migrate a domU to any other dom0? >>>> >>>> >>>It''s pretty much free for all as far as dom0s are concerned ;-) Basically >>>if >>>one dom0 can reach another over a network, it can migrate stuff there! >>>Right >>>now, it''s more or less expected that an organisation''s dom0s are isolated >>>on >>>a vlan (or separate ethernet). >>> >>>Cheers, >>>Mark >>> >>> > >_______________________________________________ >Xen-users mailing list >Xen-users@lists.xensource.com >http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Alan Greenspan wrote:> >You can''t have dom0s on a hostile network if you want to prevent > these "rogue > >>migrations". Note that you can''t force an outgoing migration from a > node, so > >nobody can "steal" your running domUs. However, if someone gets on a > segment > >of network that can reach your dom0s they could send you some domUs > of their > ... > >own - shouldn''t be a security issue (the domUs will still be isolated > by Xen) > >but could get quite annoying ;-) > > It''s actually a huge security hole since a migrating domU carries its > device mappings to the target machine. Basically, you could create > domU, map one of its disks to say /dev/hdb, migrate it to a target > machine and gain access to /dev/hdb on the target. Same goes for any > file used as a disk on the source/target dom0.The migration port should be firewalled if dom0 is connected to an untrusted network.> Minimally, Xen should implement a simple hosts.allow hosts.deny > mechanism for migration so that a host can limit which other hosts can > migrate in. Relying on network isolation using a separate management > network isn''t always practical.This can be achieved with iptables. Host level access control is generally a weak security mechanism. It''s far too easy to spoof or steal ip addresses. Regards, Anthony Liguori> > Alan > >------------------------------------------------------------------------ > >_______________________________________________ >Xen-users mailing list >Xen-users@lists.xensource.com >http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Anthony Liguori wrote:> Proxying everything over an SSH connection is probably the best long > term solution. However, I''ve not been able to figure out how to disable > privacy in ssh :-/You use rsh :). But yes, everything Anthony said, spot on.. thanks, Nivedita _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Date: Fri, 28 Oct 2005 17:23:05 +0100 > From: Mark Williamson <mark.williamson@cl.cam.ac.uk> > Subject: Re: [Xen-users] Live Migration Config > To: xen-users@lists.xensource.com > Cc: Matthew Walster <matthew@walster.org> > Message-ID: <200510281723.05926.mark.williamson@cl.cam.ac.uk> > Content-Type: text/plain; charset="utf-8" > > Right now (and particularly with Xen 2.0, since it exports the management > interface over HTTP), the rule is basically not to have anything you don''t > trust be able to access dom0 over the network.If this migration happens via http, you can probably firewall the port on your dom0 to only accept connections from certain ip adresses ? Or am I missing something ? greets, Staf. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Matthew Alton wrote:> This is not good. I''m going to have a devil of a time selling this into > enterprises of any size. Are there any plans to provide filtering > rules, authentication, authorization facilities in the works? Any > bolt-ons?Use iptables to prevent the dom0 from engaging in any communication except over a VPN. That way you have the VPN''s authentication and encryption facilities available, and keep untrusted boxen away. (OpenVPN is a hammer I''m quite fond of, so I see a lot of nails). _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > Right now (and particularly with Xen 2.0, since it exports the management > > interface over HTTP), the rule is basically not to have anything you > > don''t trust be able to access dom0 over the network. > > If this migration happens via http, you can probably firewall the port > on your dom0 to only accept connections from certain ip adresses ? > Or am I missing something ?Yes, firewalling is also fine; of course you still have to trust that no machines on the same network are capable of IP address spoofing (or trust them not too). Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> It''s actually a huge security hole since a migrating domU carries its > device mappings to the target machine. Basically, you could create domU, > map one of its disks to say /dev/hdb, migrate it to a target machine and > gain access to /dev/hdb on the target. Same goes for any file used as a > disk on the source/target dom0.Yeah OK, it''s horrid actually :-) Xend trusts anything the incoming config tells it... Could get nasty very quickly from both security and DoS perspectives.> Minimally, Xen should implement a simple hosts.allow hosts.deny mechanism > for migration so that a host can limit which other hosts can migrate in. > Relying on network isolation using a separate management network isn''t > always practical.True... But it only really works if you''re reasonably sure attackers can''t get root on any system. If you have virtual machines that could have been rooted by someone malicious they can still spoof IP addresses, sniff the contents of other domUs that are currently being migrated, etc. At least using a separate virtual lan would be nice, but there should still be more support in Xend for a sanely secure mixed network. It''ll come, eventually... Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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@lists.xensource.com http://lists.xensource.com/xen-users
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@spamcop.net> > Subject: [Xen-users] Re: Live Migration Config > To: xen-users@lists.xensource.com > Message-ID: <43643730.50407@spamcop.net> > 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@lists.xensource.com http://lists.xensource.com/xen-users
> 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. [*] 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" ) It would be good if someone could knock the above up. Ian _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, 30 Oct 2005, Ian Pratt wrote:> > > 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.1 is a parameter to xfrd when it is started. 5 is (obviously) part of the xen startup scripts... 3 is (IMHO) bizarre. xfrd isn''t a daemon you expect to be making frequent connections to. It could even be single threaded. IMHO, 2 doesn''t work the way most people want it to. If you have two boxes next to each other, you can route the 127.0.0.0/8 subnet to your neighbour and connect the 127.0.0.1 on your neighbour. To achieve the "only accept xfrd requests on one interface", I believe you have to use your firewall rules... yes, binding to 127.0.0.1 makes it unlikely that you''re going to be connected to from the wild internet.> 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.hhmm, In that line of thought, I''d probably suggest 6. some form of authentication, anything, even a simple shared "secret" would be better than wide open. I''ll post some firewall rules shortly. I meant to do it last night. -Tom> > [*] 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" ) > > It would be good if someone could knock the above up. > > Ian > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >---------------------------------------------------------------------- tbrown@BareMetal.com | "The Internet is a world of ends. You''re at one http://BareMetal.com/ | end, and everybody and everything else are at the web hosting since ''95 | other ends." - http://www.worldofends.com/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tom Brown
2005-Oct-30 18:05 UTC
Re: [Xen-users] (securing dom0 - firewall rules. was: ) Re: Live Migration Config
There needs to be either some documentation about how to secure your xen
host, or the default configuration needs to be changed to be far "less
permissive" :-) and documentation added about how to relax the security.
Even being able to bind xferd to a specific IP address (e.g. 10.0.0.1)
would be a start (not "secure" but I''d rather have to deal
with "only" the
clients of a big co-lo (or if you''re lucky, your own lan) instead of
the
whole internet)...
Here''s a start... This isn''t rock solid, but it is a million
times better
than being wide open. It blocks the xen (http and event) and xfrd ports,
the console ports for doms numbered 1 to 99. Increase 9699 if you cycle
through a lot of domUs. It is Linux/bash specific, and assumes you have
iptables enabled on the dom0. I have also used the REJECT target, but you
could use DENY if REJECT wasn''t enabled in your kernel compile.
And of course, all of this might be obsolete for xen 3
#!/bin/bash
FW=/sbin/iptables
# accept any traffic that comes in the loopback interface
# this should cover ALL legit traffic to 127.0.0.1
$FW -A INPUT -i lo --jump ACCEPT
# hhm, this should deny remaining traffic to 127.0.0.1
# that should block traffic where outside systems have routed
# 127.0.0.1 to us.
$FW -A INPUT -p TCP -d 127.0.0.1 --jump REJECT
# add explicit rules here to allow access
# $FW -A INPUT -p TCP -s OPENIP --dport OPENPORT --jump REJECT
#block everything else
for port in 8000 8001 8002 ; do
$FW -A INPUT -p TCP --dport $port --jump REJECT
done
console=9600
while [ $console -lt 9699 ] ; do
$FW -A INPUT -p TCP --dport $console --jump REJECT
let console=$console+1
done
On my 2.0.7 boxes it looks like the xen http interface is on ports
8000 and maybe 8001 (but those are bound to 127.0.0.1) and xfrd is on 8002
- the first two seem to be specified in /etc/xen/xend-config.sxp (hhmm,
8002 seems to be in xfrd.h, used by a compiled C program xfrd, it can be
specified as a command line option though...)
# Port xend should use for the HTTP interface.
(xend-port 8000)
# Port xend should use for the event interface.
(xend-event-port 8001)
and for consoles the following seem relevent:
(console-port-base 9600)
(console-address ''localhost'')
however, my port 8000 and 8001 daemons are _also_ bound to
localhost...
[root@xen2 /etc/xen]# netstat -atn | grep LIST
tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8002 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:9605 0.0.0.0:* LISTEN
(9605 being a console port)
[root@xen2 /etc/xen]# xm list
Name Id Mem(MB) CPU State Time(s) Console
Domain-0 0 123 0 r---- 21371.7
audio 5 255 1 -b--- 199561.7 9605
Anyhow, the above seems like a pretty lousy start, but if it
inspires someone to improve on it, then great!
Note: I suggested earlier that disabling xfrd was probably just a change
to the startup scripts. That doesn''t seem to be correct. It appears to
be
started from the main xend python script... and that only seems to take
stop/start/restart options. (I''m not python literate.)
-Tom
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Ian Pratt wrote:> > > >>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@lists.xensource.com >http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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). 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@lists.xensource.com >>http://lists.xensource.com/xen-users >> >> >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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@lists.xensource.com >>> http://lists.xensource.com/xen-users >>> >>> >> > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 10/31/05, Anthony Liguori <aliguori@us.ibm.com> wrote:> > [...] To enable migration from specific > addresses, you would then say: > > iptables -I INPUT -p tcp --source 192.168.1.100 <http://192.168.1.100>--destination-port > 8002 -j ACCEPTOr from anyone claiming to have ip address 192.168.1.100<http://192.168.1.100>... I''m quite sure that the best (for my definition of ''best'' of course) way to do this is not via firewalling, because of the above spoofing possibilities, but also not by complicating the xen tools themselves. I''d like to come back again to the ''VPN'' type solution discussion. I know that a full VPN setup is sufficiently complex that I''ve always been scared away from trying, but I have the feeling that it wouldn''t be too terribly difficult to setup some wrapper type functionality so that ssh could be used to build a ''tunnel'' to the target machine and connections to the target xfrd could then be made from, and limited to, 127.0.0.1<http://127.0.0.1>on the target machine. While I haven''t plunged through the xfrd code to see how a tunnel create/destroy script could be built in I don''t imagine it would be too terrible. There is a lot of precedent for using ssh this way (''rsync -e ssh'' etc), it is as secure as you are likely to want, and it''s easier than trying to add credential support directly into the tools themselves, as well as being more in the *nix spirit of combining what you already have. For small setups, this could be done statically using port forwarding (with something like Vtun, if you prefer virtual devices) ... the dynamic variant would only be needed where there are too many systems to build static interconnects from everywhere to everywhere else. In security terms, if ssh is compromised on any of my systems they''re dead in the water anyway, so using ssh for this wouldn''t seem to add any risk that I haven''t already accepted. I''m going to try this out as soon as my day job leaves me enough time ... which won''t be for a while I''m afraid. Now, as this is surely not fresh news to most of you, what is wrong with my definition of ''best'' ?? -- N. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
For Xen to go mainstream, I think this needs to be easier for the average user. I know I''m repeating myself, but it really should use ordinary config file settings like virtually all other inet services. Also, in whatever config file this is going to appear in, the default setting for migration should be "all hosts denied". Alan> > 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. >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, 31 Oct 2005, Alan Greenspan wrote:> For Xen to go mainstream, I think this needs to be easier for the average > user.I''d like to know what kind of mainstream average user needs live migration? :-) I know I''m repeating myself, but it really should use ordinary config> file settings like virtually all other inet services. Also, in whatever > config file this is going to appear in, the default setting for migration > should be "all hosts denied". > > AlanRight, and how many major internet applications have _NOT_ had problems with their built in security mechanisms? The list of applications that HAVE had issues is very long and quite thorough. Setting up a basic first line of defense at the IP layer is _extremely good_ security practice, and anyone worried about security should already be doing this. XENs control ports do not need to be accessible to the wild internet, it would be a risk with zero benefit to leave them wide open. If you trust your local network segment enough to assume there are no eavesdroppers and you assume the the router you talk to hasn''t been compromised, IP based access control can be sufficient. And if you''ve got folks walking around plugging machines into your network, you are already in trouble... I don''t currently have time to be that paranoid. XEN is quite useful without _any_ migration capabilities. ... thus my suggestion that a good first step is to know what it is we need to control access to. You''re welcome to sit back and wait for the developers to implement your chosen features... All I need to do is block a couple of ports to make my xen servers secure. If live migration isn''t secure, fine, I won''t use it.... but then I haven''t managed to build a filesystem that could be migrated and allows high performance... so it isn''t much of a loss :) [nfs works, but performance bites when compared to a fully cached local block device... anyone wanna start a new thread?] -Tom _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nigel Head wrote:> I know that a full VPN setup is sufficiently complex that I''ve always > been scared away from trying[PLUG] Try OpenVPN -- it''s much easier to configure than a full IPsec-based solution, and by all indications is comparably secure when appropriately configured. [/PLUG] _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nigel Head wrote:> > On 10/31/05, *Anthony Liguori* <aliguori@us.ibm.com > <mailto:aliguori@us.ibm.com>> wrote: > > [...] To enable migration from specific > addresses, you would then say: > > iptables -I INPUT -p tcp --source 192.168.1.100 > <http://192.168.1.100> --destination-port > 8002 -j ACCEPT > > > Or from anyone claiming to have ip address 192.168.1.100 > <http://192.168.1.100> ...Yeah, IP based filtering is only going to help you if 1) you''re on a trusted subnet 2) you trust that the router between your subnet and the rest of the world is going to prevent spoofing to your subnet Without IP based filtering, you''re additionally assuming: 3) the subnet is not accessible to the outside world This means you have to have your dom0''s configured to be on a physically isolated network. Having a truly secure migration session means that you could do migrations over an untrusted subnet. This is going to have a performance impact though. This scenario also is not going to work out of the box in 3.0. You can get that though with an SSH tunnel. It should Just Work too. It would be interesting to know the performance impact of migrating over an SSH tunnel. Regards, Anthony Liguori> I''m quite sure that the best (for my definition of ''best'' of course) > way to do this is not via firewalling, because of the above spoofing > possibilities, but also not by complicating the xen tools themselves. > I''d like to come back again to the ''VPN'' type solution discussion. > > I know that a full VPN setup is sufficiently complex that I''ve always > been scared away from trying, but I have the feeling that it wouldn''t > be too terribly difficult to setup some wrapper type functionality so > that ssh could be used to build a ''tunnel'' to the target machine and > connections to the target xfrd could then be made from, and limited > to, 127.0.0.1 <http://127.0.0.1> on the target machine. > > While I haven''t plunged through the xfrd code to see how a tunnel > create/destroy script could be built in I don''t imagine it would be > too terrible. There is a lot of precedent for using ssh this way > (''rsync -e ssh'' etc), it is as secure as you are likely to want, and > it''s easier than trying to add credential support directly into the > tools themselves, as well as being more in the *nix spirit of > combining what you already have. > > For small setups, this could be done statically using port forwarding > (with something like Vtun, if you prefer virtual devices) ... the > dynamic variant would only be needed where there are too many systems > to build static interconnects from everywhere to everywhere else. > > In security terms, if ssh is compromised on any of my systems they''re > dead in the water anyway, so using ssh for this wouldn''t seem to add > any risk that I haven''t already accepted. > > I''m going to try this out as soon as my day job leaves me enough time > ... which won''t be for a while I''m afraid. > > > > Now, as this is surely not fresh news to most of you, what is wrong > with my definition of ''best'' ?? > > > -- > N. > >------------------------------------------------------------------------ > >_______________________________________________ >Xen-users mailing list >Xen-users@lists.xensource.com >http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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 REJECTThis 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@lists.xensource.com >>>> http://lists.xensource.com/xen-users >>>> >>>> >>> >> >> > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nate Carlson
2005-Oct-31 21:18 UTC
Filesystems that support migration [Was: Re: [Xen-users] Re: Live Migration Config]
On Sun, 30 Oct 2005, Tom Brown wrote:> but then I haven''t managed to build a filesystem that could be migrated > and allows high performance... so it isn''t much of a loss :) > > [nfs works, but performance bites when compared to a fully cached local > block device... anyone wanna start a new thread?]I just use a SAN with fibre channel.. works great. I''m using CLVM, so all the xen0 boxes see the block devices with the same names; also using GFS to share home directories and such within the domU''s. Beats the crap out of the NFS solution I used to use.. :) ------------------------------------------------------------------------ | nate carlson | natecars@natecarlson.com | http://www.natecarlson.com | | depriving some poor village of its idiot since 1981 | ------------------------------------------------------------------------ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tom Brown
2005-Oct-31 21:34 UTC
Re: Filesystems that support migration [Was: Re: [Xen-users] Re: Live Migration Config]
On Mon, 31 Oct 2005, Nate Carlson wrote:> On Sun, 30 Oct 2005, Tom Brown wrote: > > but then I haven''t managed to build a filesystem that could be migrated > > and allows high performance... so it isn''t much of a loss :) > > > > [nfs works, but performance bites when compared to a fully cached local > > block device... anyone wanna start a new thread?] > > I just use a SAN with fibre channel.. works great. I''m using CLVM, so alla brand name solution, or something cooked up?> the xen0 boxes see the block devices with the same names; also using GFS > to share home directories and such within the domU''s.I looked at trying to get GFS running, but it looked like getting it to work was going to be a lot of work, and I wasn''t sure if there would be patch conflicts with XEN.> Beats the crap out of the NFS solution I used to use.. :)That is encouraging to hear. I was considering looking at iSCSI and/or ATA over ethernet. Anyone else got any suggestions/tips? Hopefully I''ll actually have time to work on this tomorrow, so soliciting ideas today seems like a good idea :-) -Tom _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dirk H. Schulz
2005-Nov-01 09:05 UTC
Re: Filesystems that support migration [Was: Re: [Xen-users] Re: Live Migration Config]
Nate Carlson schrieb:> On Sun, 30 Oct 2005, Tom Brown wrote: > >> but then I haven''t managed to build a filesystem that could be >> migrated and allows high performance... so it isn''t much of a loss :) >> >> [nfs works, but performance bites when compared to a fully cached >> local block device... anyone wanna start a new thread?] > > > I just use a SAN with fibre channel.. works great. I''m using CLVM, so > all the xen0 boxes see the block devices with the same names; also > using GFS to share home directories and such within the domU''s.That is very interesting, thanks for opening a new thread. What linux flavor do you use for dom0? Do you then need CLVM inside the domUs or is it sufficient to have it in dom0? I looked up the CLVM project page but that does not contain any information. Could you point me to detailed docs, if possible? Dirk _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users