Security concerns

This page will document all security concerns related to Archipel. It's a must-read if Archipel is going to be used by more people than just you.

This tutorial assumes you are running Archipel in production environment. Thus, each Archipel agent has got its own public IP and a real domain - no /etc/hosts hacking please. We assume XMPP server runs on a different machine.

If there's anything more that needs to be covered in this article, feel free to include it or contact Nowaker on freenode/#archipel.

Changelog:

• 2013-12-21 - XML-RPC security vulnerability resolved, follow [https://github.com/ArchipelProject/Archipel/wiki/_preview#xml-rpc--xmpp](these instructions)

"define" and "xmldesc" permissions on the virtual machine

Untrusted user should not be given the "define" permission. It allows user to edit the XML descriptor of the virtual machine where they can set all they want. In worst case, local disk on host (e.g. /dev/sda) can be mounted read-only to virtual machine and all the data can be read.

"xmldesc" permission is about reading the virtual machine XML descriptor. That is, user won't be able to access the "Definition" tab if not given an "xmldesc" permission.

• "define" and "xmldesc" - user is able to define the virtual machine as they want
• "xmldesc" only - user can access the Definition tab in read-only mode
• "define" only - user can't access the Definition tab, as they can't access the XML

There is also enable_block_device_access setting in /etc/archipel/archipel.conf but it doesn't do anything useful while the user can edit the XML directly.

Encrypted XMPP

All XMPP traffic on ports 5222, 5269 and 5280 should be encrypted.

User needs to remember changing the BOSH proxy URL when accessing Archipel client for the first time. "https" should be used, not "http". (e.g. https://xmpp.example.com:5280/http-bind)

Use this ejabberd config to encrypt all channels but XML-RPC. We have analyzed all the traffic from/to XMPP server with tcpdump and it's proved safe.

{listen, [
  {5222, ejabberd_c2s, [
    {access, c2s},
    starttls,
    {certfile, "/etc/ejabberd/cert.pem"},
    {max_stanza_size, 65536000}
  ]},

  {5269, ejabberd_s2s_in, [
    {max_stanza_size, 65536000}
  ]},

  {5280, ejabberd_http, [
    http_bind,
    http_poll,
    web_admin,
    tls,
    {certfile, "/etc/ejabberd/cert.pem"}
  ]}
]}.

{route_subdomains, s2s}.
{s2s_use_starttls, true}.
{s2s_default_policy, allow}.    
{s2s_certfile, "/etc/ejabberd/cert.pem"}.

XML-RPC @ XMPP

Enabling XML-RPC allows anyone on the Internet to control your XMPP server, which is far from what you want to achieve. If you want XML-RPC in Archipel you should encrypt all XML-RPC traffic. You should also allow only your hypervisors' IPs to interact with XML-RPC. However, ejabberd_xmlrpc module supports neither SSL nor IP whitelists, so we must use some 3rd party software as proxy. We will use nginx here.

We tell ejabberd_xmlrpc to listen on localhost only in ejabberd.cfg:

{listen, [
  {{4560, "127.0.0.1"}, ejabberd_xmlrpc, []},

Then we configure nginx to proxy all XML-RPC traffic to ejabberd_xmlrpc.

http {
  server  {
    listen 1.2.3.4:4560;
    ssl on;
    ssl_certificate /etc/ejabberd/cert.pem;
    ssl_certificate_key /etc/ejabberd/cert.key;
    location / {
      proxy_pass http://localhost:4560;
      proxy_set_header X-Real-IP $remote_addr;
      allow 1.2.3.4;
      allow 2.3.4.5;
      deny all;
    }
  }
}

Finally, we have to modify Archipel agent configuration to support XML-RCP over SSL.

# XMLRPC API ONLY : Use SSL for xmlrpc, need a ssl proxy as
# xmlrpc module does'nt hanle SSL. Read more information on the wiki
xmlrpc_sslonly		= True

This change makes XML-RPC traffic SSL secured and available only to the hypervisors.

Encrypted VNC

KVM runs an unencrypted VNC for a virtual machine if told so in VM XML descriptor. That connections are unencrypted and you should not be exposed to the Internet, that is - set it to listen on 127.0.0.1 only.

Archipel agent runs an encrypted proxy for each VNC on a 69xx port. They should listen on 0.0.0.0 so it's open for connections from the browser. But still, every VNC should be password-protected as well. Leaving VNC without a password makes your tty console freely exposed to the Internet, and you can connect to it with any NoVNC web client.

Perfectly shaped VNC configuration should look like this in the UI:

% netstat -ant | grep -i listen
tcp        0      0 127.0.0.1:5907          0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:6907            0.0.0.0:*               LISTEN     

Archipel agent is given a sample VNC certificate by default but you should not use it as everyone has got the same. Replace it with yours in /etc/archipel/archipel.conf VNC section for each agent and ensure only SSL is used:

vnc_certificate_file = /etc/archipel/your-cert.pem
vnc_only_ssl = True

When using a trusted certificate, make sure that the VNC URL Archipel client connects to matches the domain from certificate. While it doesn't cause any security holes, it will prevent any warnings about untrusted certificates from appearing. The easiest way is to check it in the web browser console (Ctrl+Shift+J in Chrome). If the domain is wrong, change it to machine_ip = example.com in archipel.conf (don't be fooled by the property name).

2013-02-17 13:01:49.721 Cappuccino [info]: VNC: connecting to example.com:6907  using SSL: true (checkRate: 217, FBURate: 1413)

Running Archipel agent as non-root

TBD. Please read page Installation-serviceuser for instructions.

Kerberos

A Kerberos-based operation mode of Archipel is good for the following reasons:

• no more passwords stored in clear-text
• there are a few scenarios where there is communication between 2 hypervisors which totally bypass the permission system, this could be abused
• Archipel already uses SASL, SASL has a Kerberos mode of operation
• ejabberd also supports kerberos, even though it needs to be compiled separately
• ...

Misc

• StartSSL provides signed certificates free of charge.