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.

"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

Certificates

Please be sure to use trusted certificates. If your certificate are not trusted by a Root CA, don't forget to install your custom CAs (root CA and intermediate) to your client machine and servers.

A good presentation of TLS can be found (here)[http://chimera.labs.oreilly.com/books/1230000000545/ch04.html]

StartSSL provides signed certificates free of charge (but with some limitations)

Configuration

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

User needs to remember changing the BOSH/websocket proxy URL when accessing Archipel client for the first time:

• Using bosh https should be used, NOT http. (e.g. https://xmpp.example.com:5280/http-bind)
• Using websockets wss should be used, NOT ws. (e.g. wss://xmpp.example.com:5280/xmpp)

Use this ejabberd config to encrypt all channels but XML-RPC.

## ejabberd c2s
    -
        port: 5222
        module: ejabberd_c2s
        certfile: "/etc/ejabberd/ejabberd.pem"
        starttls: true
        max_stanza_size: 65536000
        shaper: c2s_shaper
        access: c2s

## ejabbed s2s
    -
        port: 5269
        module: ejabberd_s2s_in
        max_stanza_size: 65536000

## ejabberd http/s and websocket/s
    -
        port: 5280
        module: ejabberd_http
        request_handlers:
          "/xmpp": ejabberd_http_ws
        certfile: "/etc/ejabberd/ejabberd.pem"
        starttls:  true
        web_admin: true
        http_bind: false


s2s_use_starttls: required_trusted
s2s_certfile: "/etc/ejabberd/ejabberd.pem"

Safe and encypted 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.yaml:

listen:
    -
      ip : "127.0.0.1"
      port: 4560
      module: ejabberd_xmlrpc
      access_commands:
            xmlrpcaccess:
                all : []

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 XMPPServer module 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:

% 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

Please read page Installation-serviceuser for instructions.