Cloudmin - 'Shutdown VM' reboots rather than starts / VNC security

Submitted by yorkukhosting on Sat, 11/13/2010 - 08:57

Hi,

When I choose the 'shutdown' option from within CloudMin with a Windows VM it forces a reboot of it rather than a graceful shutdown. Centos VM seems to shutdown without issue.

I have noticed that the 'graphical console' appears to be insecure. If I connect to say port 5900 or 5901 on the cloudmin box using a VNC Viewer I can access the corresponding VM console without any authentication. Unless I missing something this seems to be a big security issue.

Regards, Nathan.

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Sat, 11/13/2010 - 10:52

Does this still happen even if you use the forced shutdown option?

Regarding VNC, it should be password protected - when you access it from within Cloudmin the password is automatically given to the VNC client in your browser, but if you connect using a standalone program it should prompt for a password (which will typically be the same as the system's root password).

By the way, which virtualization technology are you using (KVM, open source Xen or Citrix Xen)?

Submitted by yorkukhosting on Sun, 11/14/2010 - 07:26

Citrix Xen is being used, there was definately no prompt when i used a standalone vnc client. The cloudmin install runs on centos 5 (32bit) and was installed using the installation script.

I will check what happens if i tick the force shutdown option.

Submitted by JamieCameron on Mon, 11/15/2010 - 00:26

Ok, looks like there may be a bug here with the Citrix Xen VNC connection ... I will update this bug with more details once it is worked out.

The VNC connection is only opened when the "Graphical Console" page is opened in Cloudmin, so if you don't use that page no un-protected VNC connection will be available.

Submitted by yorkukhosting on Mon, 11/15/2010 - 02:49

Thanks for the confirmation of the VNC bug.

I have retested shutting down a Windows VM and if I tick the 'force' option the VM is powered off. That would imply a bug with the non-force option as we should be able to gracefully shutdown a Windows VM?

Submitted by JamieCameron on Mon, 11/15/2010 - 13:37

Actually, for a windows VM which presumably doesn't use paravirtualization Cloudmin should be always doing a forced shutdown already. If you go to the Edit System page for this VM and looking in the advanced options section, is it shown as using HVM or PV ?

Submitted by yorkukhosting on Mon, 11/15/2010 - 14:19

Hi Jamie,

The Windows VM is HVM based rather PV but it has the XenTools installed. With XenTools installed XenServer can instruct the VM to gracefully shutdown the OS. From the command line

xe vm-shutdown uuid=XXXX-XXXX-XXXX-XXXX

Or a force would look like this:

xe vm-shutdown --force uuid=XXXX-XXXX-XXXX-XXXX

Regards, Nathan.

Submitted by JamieCameron on Mon, 11/15/2010 - 15:45

Cloudmin actually uses the command :

xe vm-shutdown uuid=XXXX-XXXX-XXXX-XXXX

does that work if run it manually?

Submitted by JamieCameron on Mon, 11/15/2010 - 17:51

I looked into the VNC issue some more, and found that there isn't actually any way to set a password for Citrix Xen VNC connections. However, the next Cloudmin release will only accept a VNC connection from the same IP that accessed the "Graphical Console" page, and will only allow a single connection. This will protect against un-authorized console access pretty well..

Submitted by JamieCameron on Tue, 11/16/2010 - 12:54

That's very odd ... does the "shutdown" operation in Cloudmin always just reboot the Windows VM?

Submitted by yorkukhosting on Tue, 11/16/2010 - 13:04

When I last tested it did just power down so that may be just a random glitch in xenserver. I will try some more tests to see under what circumstances the reboot rather than shutdown occurs.

I can confirm the command line as shown below does shutdown the Windows VM (with xentools installed) gracefully.

xe vm-shutdown uuid=XXXX-XXXX-XXXX-XXXX

Submitted by JamieCameron on Tue, 11/16/2010 - 14:08

That is the same command Cloudmin uses, so it should work ..

Submitted by yorkukhosting on Tue, 11/23/2010 - 14:22

I have just upgraded to 5.1 and now VNC doesn't seem to work. Nothing has changed since it was working in 5.0, other than the upgrade to 5.1. I have tried stopping iptables but this made no difference.

Submitted by JamieCameron on Tue, 11/23/2010 - 15:03

The 5.1 release added some security changes related to VNC.

If you check the log file /var/webmin/miniserv.error , does anything get logged when you try to access the "Graphical Console" ?

Submitted by yorkukhosting on Tue, 11/23/2010 - 15:38

Jamie,

The only thing being logged is:

[23/Nov/2010:21:34:20 +0000] miniserv.pl started [23/Nov/2010:21:34:20 +0000] PAM authentication enabled

Regards, Nathan

Submitted by JamieCameron on Tue, 11/23/2010 - 15:52

Ok, that looks harmless.

When you say VNC isn't working, what goes wrong exactly?

Submitted by yorkukhosting on Tue, 11/23/2010 - 16:02

The Java Applet loads but then returns the following error:

  "Network error: could not connect to server: server.example.com:5901"

(server.example.com is not the real hostname, removed from this post for security)

I have tried this with both IE8 and Firefox 3.x and the same issue occurs. I have rebooted the cloudmin box several times with no success. If I try to telnet to the port I receive no response, although based upon the changes you were going to make (single connection from 1 IP) that doesn't entirely surprise me.

Submitted by JamieCameron on Tue, 11/23/2010 - 16:12

Is server.example.com the hostname of your cloudmin master system?

Also, I presume port 5901 isn't blocked by a firewall or anything?

Submitted by yorkukhosting on Wed, 11/24/2010 - 15:43

'server.example.com' is the Cloudmin master, the ports are definately open both on the iptables firewall running on the master plus the hardware firewall. I have stopped iptables just in case, this made no difference.

Submitted by JamieCameron on Wed, 11/24/2010 - 22:53

Ok, I see the bug that can causes this now.

To fix it on your system, SSH into the Cloudmin master as root and edit the file /usr/libexec/webmin/server-manager/cvnc.cgi and change line 128 from :

print "<param name=port value='$vncport'>\n";

to :

print "<param name=port value='$masterport'>\n";

Cloudmin 5.2 will include this same fix.

Submitted by Issues on Fri, 12/10/2010 - 08:05

Automatically closed -- issue fixed for 2 weeks with no activity.