noVNC missing Authentication and Security

[fffaraz]

I have installed latest version of Archipel Agent and Client from nightly builds.
Almost everything works fine.
But I think there is a security problem with VNC client.
Everyone in my network can access VM's vnc without any authentication using a noVNC client and connect to my Archipel agent server on port 6900, ...

Is it ok ?!!
Is it the way it should be or am I doing something wrong ?

I think Achipel agent should create and assign a random password using livbirt (or qemu's monitor console) and also websockify should start listening on the proxy port only for seconds after a request for VM's vnc console in Archipel Client.

[primalmotion]

you can set a password for the VNC screen in definition, and I think you can set a default password for all VMs

websockify should start listening on the proxy port only for seconds after a request for VM's vnc console in Archipel Client

Yep, this is planned.

[soulhunter]

Hi!

This was exactly what I felt when I was trying out archipel a few days ago, and was about to test the noVNC thing, so, fffaraz, thanks for trying that out! (that was exactly what I was going to do).

One of the reasons I wanted to try archipel is because I had the feeling that maybe it was tunneling VNC traffic over XMPP, is it such a bad idea to do that? (tunnel through XMPP), maybe that's just not a good idea, and maybe could overcomplicate things.

Another option is to use OTP, how dynamic can VNC passwords be? (ie, can we change the VNC password "on the fly"), the idea is:

1. On console access request, Archipel agent generates a random password.
2. The password is sent over XMPP to archipel client.
3. Client connects to VNC, and inform archipel agent that the password can now be invalidated.
4. If client doesn't connect on a given time, say, 30 seconds, the password would be invalidated.

Maybe using a constantly rotating password would work too, (similar to RSA token, but with alphanumeric passwords), we could make archipel agent rotate the password for each VM every minute, or two minutes, and when client needs to connect, it would receive the current password via XMPP. Of course, XMPP connection needs to be secure too.

Now, if we can't make the VNC passwords dynamic directly on libvirt, maybe we can implement a VNC authentication proxy on the websocket server, and we should be able to make it dynamic, I saw something like that on an old noVNC issue, here: novnc/noVNC#45 .

I think console access security is extremely important, as is XMPP security, because if you can get console access to a server, the server is likely yours! (usually you just need a reboot).

[soulhunter]

on a quick web search, maybe this VNC auth proxy: https://code.osuosl.org/projects/twisted-vncauthproxy

[fffaraz]

I think Archipel client sends a XMPP IQ to Archipel agent to receive ip and ports to connect.
In VNC plugin we can create and assign a random generated password to the vm for each request for vnc console.
the user should not be aware of the generated password for the session because archipel client receives the password in the iq result and can pass in to noVNC client without user interaction.
Also there is no need to change the password every other minute if the websocket proxy listens for the connection only a few seconds after receiving noVNC console iq request form archipel client.
I saw this behavior on some other virtualization GUIs for qemu.
and websocket proxy does not (and is not going to) support vnc authentication cause it is totally NOT aware of the protocol.

[soulhunter]

fffaraz, yes, as far as I know, archipel client request the connection parameters to archipel agent, and that's where the password exchange would happen.

In VNC plugin we can create and assign a random generated password to the vm for each request for vnc console.

What happen if two requests comes at the same time? : one of these would fail, because one of these would get a password before the other, and the one that got the password first would be refused (maybe a randomly-timed retry policy could fix that). What you suggest was my first thought: OTP approach, ie: login and close the door behind, but because of the collision possibility, I thought it could be simpler to just have a timed password rotation, and also requires less changes to current archipel logic, as it doesn't matter if the web socket servers are left listening always (we could even add client-cert authentication to web sockets too, if we want higher security).

As a matter of fact, we could do the password rotation even from a cron job :P (if we are thinking about non-intrusive solutions).

and websocket proxy does not (and is not going to) support vnc authentication cause it is totally NOT aware of the protocol.

This is not so important now, but on my message I said I there was one, read here: novnc/noVNC#45 , there was (or maybe is?) a websockify fork that supported VNC authentication, as a "man-in-the-middle". I thought on it because it could allow for more complex password rotation schemes, such as supporting two passwords during the rotation (to keep the old password valid for a few seconds after we started rolling the new one).

I just tested and I can change a VM's VNC password on the fly (used virt-manager to test), ie: without stopping it, however for it to be a "perfect solution", I would need it to support for the password to be kept valid for a few seconds after I change it (and the new password I apply should be valid too, ie: two passwords valid for a few seconds). Again, an automatic connection retry logic would solve this problem, because if noVNC gets access denied, archipel client would just call the agent again, get the password and reconnect, with the 2 minutes password rotation I'm thinking it should work.

Now, reading here:

http://libvirt.org/formatdomain.html

There seem to be a parameter "passwdValidTo", I wonder how does that one exactly work? If that one is able to keep a password valid, even if I changed it (and at the same time keep the new password I just assigned), it would be the perfect solution, however: not as important (as we can always just retry console connection, even manually at first :) ).

What do you think?

Ildefonso.

[iamacarpet]

Hello guys,

Just been having a look at this as we are trying to implement something to manage all our VMs and Archipel seems the best solution at the moment, but the VNC is currently the one big no-no we're hoping to invest some time in and create some patches.

So, so far we have two problems - The fact that the VNC has no authorization unless you set the VNC passwords manually, and the other being that you need direct access to the virtual machine host to allow VNC connections.

Our plan is to use the "UltraVNC Repeater" protocol - (see perl script implementing it here: wics.me/mk) and the noVNC ticket where support for it was merged here (wics.me/mm).

The tl;dr for those tickets is, it adds an extension to the protocol were when you connect, you specify an ID which is supposed to be the ID of the server you want to connect to - The repeater daemon will then forward you to the server whose IP you specified - So you can run it on a firewall / gateway and you can connect to multiple VNC instances in a different network which is behind a firewall just with one open port.

The ID field has a length limit of 250 chars from what I can see, so there is plenty of room to have a VNC instance ID and a one time password packed in there.

To tie this all together, we would need to have a database / flat-file way of storing the one-time-passwords and a lookup table of what server they allow connection to and write a custom repeater daemon capable of forwarding all the connections, hopefully many at once.

The agent would then need to be modified so the VNC gateway IP could be specified in the config file and an option to enable VNC gatewaying, and some way of communicating this data to the client - This would stick with Archipels modular design and make sure it could be used over many vast networks with multiple gateways.

As for the communication between the gateway and the archipel agent, this could have one static VNC password that only the gateway will ever know and doesn't need to be changed, or atleast rotated only every hour or so - Hopefully we can find a way of getting the repeater daemon to perform this authentication transparently.

What does everyone think?

I'll let you know how we get on if we get authorization to spend some time to look into it further.

[primalmotion]

I'm all for it.

Just keep in mind:

• This should be embedded in the same VNC module
• It should be completely optional

[primalmotion]

Also, you need to support live migration: VM can move from an hypervisor to another, the VNC proxy + patches should be able to handle this