Securing your virtual servers

From my previous post it must be obvious that I am sometimes concerned about security. This post is the start of my investigation into securing my servers.

Irrational paranoia and tin foil hats aside, there are valid reasons for wanting to do this.

The problem

1) Protect your data against the man. Now this is not as ridiculous as you might think. We trust out lives to google, dropbox and various companies. Although we are generally well protected we have heard of rumours of data being made available to government agencies. Any big company with lots of useful data will eventually have this problem. But, this is the tin foil hat scenario.

2) Keeping data secure from theft. My email accounts are very important to me. Without email I am not connected to the rest of the world. From getting my CV out to prospective employers to bank statement. My life is stored in email. My on line accounts can be reset via email. If a nefarious character happens apon these details it would be very inconvenient. What about all my files? My work documents, or more important, our company intellectual property. Securing a server in such a way that its data is not available in case of theft is very important.

3) Cool factor. Yes, my data is encrypted, from flash disk to server. It’s awesome, my one friend will appreciate this…

Recall Digital Oceans recent announcement that old data from past droplets might be available to new droplets as the SSDs are not scrubbed. We trust our data to unknown entities, and as in this case there was no malicious intent but potentially valuable data was exposed to the world. Fortunately they are very forthcoming and very quickly let their users in on the potential risk. It just bring home the reality that we are responsible for security, not our service providers.


So what do we need to make our lives better? My laptop is encrypted and as such I am reasonable sure the cost of extracting the data is greater than its worth. The password is changed regularly as part of my security regime. But for a server this is not ideal.

So we need the following:

1) Encryption. This is the obvious requirement.

2) No passwords. Now here is the sticky part. How do you decrypt an encrypted partition without a TPM? The password cannot remain on the disk as it is then available to any semi computer literate person. You don’t want to type it in every time. Imagine having to log onto your VSphere client every time the VMWare servers is taken down for maintenance.


The best compromised I have come across is Mandos (

The diagram above is from the Mandos project web site.

In order to get the password entered during boot, someone, or something needs to type it in. Now there is no reason this cannot be automated. I have a server abroad, and a server locally. It is immensely unlikely that international and local fiends will band together to compromised both servers. So using this newly found confidence the one server is used to serve passwords to the other.

And the awesome part is that this process works both ways. Once again, both servers are very unlikely to bounce at the same time so as long as one is up, the other will be able to get it’s decryption keys from the other.

The how

Now to do this, it is possible that we can just get one server to ssh in to the other and decrypt and mount a remote partition. However, Mandos has made the process very simple and added some security features to boot.

On the client side (device needing the password to decrypt and boot) we install mandos-client conveniently available in most repositories. On the server we install mandos (the server package). Unfortunately, as my machines are geographically inconvenient the ubuntu 12.04 package, version 1.4.something did not have the required networking hooks available so I ended up installing v1.5 from ubuntu 12.10.

The process below assumes an ubuntu installation with full disk encryption configured during the initial install.


# dpkg -i mandos_1.5.5-1_all.deb

Edit the mandos config file to listen on a specific port (/etc/mandos/mandos.conf):

port = <port>


root@hydra:~# dpkg -i mandos-client_1.5.5-1_amd64.deb

root@hydra:~# mandos-keygen –type RSA –force –password

During this process the client will ask for the password that will be used to decrypt and mount the partition. This password will be encrypted and made available to copy to the server as demonstrated below.

Back to the server

The above command will output some text, including a piece that will be familiar GnuPG. This text is copied directly to the server config file (/etc/mandos/clients.conf)

;# OpenPGP key fingerprint
;fingerprint =  7788 2722 5BA7 DE53 9C5A  7CFA 59CF F7CD BD9A 5920
;# This is base64-encoded binary data.  It will be decoded and sent to
;# the client matching the above fingerprint.  This should, of course,
;# be OpenPGP encrypted data, decryptable only by the client.
;secret =
;        hQIOA6QdEjBs2L/HEAf/TCyrDe5Xnm9esa+Pb/vWF9CUqfn4srzVgSu234
;        REJMVv7lBSrPE2132Lmd2gqF1HeLKDJRSVxJpt6xoWOChGHg+TMyXDxK+N
;        Xl89vGvdU1XfhKkVm9MDLOgT5ECDPysDGHFPDhqHOSu3Kaw2DWMV/iH9vz
;        3Z20erVNbdcvyBnuojcoWO/6yfB5EQO0BXp7kcyy00USA3CjD5FGZdoQGI
;        Tb8A/ar0tVA5crSQmaSotm6KmNLhrFnZ5BxX+TiE+eTUTqSloWRY6VAvqW
;        QHC7OASxK5E6RXPBuFH5IohUA2Qbk5AHt99pYvsIPX88j2rWauOokoiKZo
;        t/9leJ8VxO5l3wf/U64IH8bkPIoWmWZfd/nqh4uwGNbCgKMyT+AnvH7kMJ
;        3i7DivfWl2mKLV0PyPHUNva0VQxX6yYjcOhj1R6fCr/at8/NSLe2OhLchz
;        dC+Ls9h+kvJXgF8Sisv+Wk/1RadPLFmraRlqvJwt6Ww21LpiXqXHV2mIgq
;        WnR98YgSvUi3TJHrUQiNc9YyBzuRo0AjgG2C9qiE3FM+Y28+iQ/sR3+bFs
;        zYuZKVTObqiIslwXu7imO0cvvFRgJF/6u3HNFQ4LUTGhiM3FQmC6NNlF3/
;        vJM2hwRDMcJqDd54Twx90Wh+tYz0z7QMsK4ANXWHHWHR0JchnLWmenzbtW
;        5MHdW9AYsNJZAQSOpirE4Xi31CSlWAi9KV+cUCmWF5zOFy1x23P6PjdaRm
;        4T2zw4dxS5NswXWU0sVEXxjs6PYxuIiCTL7vdpx8QjBkrPWDrAbcMyBr2O
;        QlnHIvPzEArRQLo=

Obviously the above is the commented example in the config file. Paste your own right at the end of the file.

The client in question resides on a VMWare server in a datacenter in Johannesburg. This means, no entropy on the VM. For the client I had some fun assisting the VM with generating the required entropy – I leave that investigation up to the reader.


service mandos restart


At this point you should be able to test whether mandos can return your password to the client.

root@hydra:~# /usr/lib/mandos/plugins.d/mandos-client –connect=<ip address>:<port> –pubkey=/etc/keys/mandos/pubkey.txt –seckey=/etc/keys/mandos/se
ckey.txt ;echo

If it returns the password it worked, otherwise, add –debug to the above command line to get some more information regarding the problem at hand.

The next step is getting Mandos to collect the password automatically at boot. This is more tricky as networking is not yet up. This means somewhere in initramfs the network configuration needs to be specified. Fortunately Mandos comes prepared (this is why I needed to install version 1.5.5 r1).

Client (/etc/mandos/plugin-runner.conf)

–options-for=mandos-client:–connect=<server ip>:<server port>

The above line tells mandos to connect to the server on the specified port (the same port configured on the server above). Next up is networking.

We need to create a script /etc/mandos/network-hooks.d/ethernet


set -e

modprobe e1000 # Substitute for your network module
ip link set dev eth0 up
ip addr add <client ip> dev eth0
ip route add <gateway ip> dev eth0
ip route add default via <gateway IP> dev eth0
ip link set dev eth0 down

case “${MODE:-$1}” in

I just copied the bridge script example and stripped what I don’t need. Not very elegant, but it works. Remember to chmod +x /etc/mandos/network-hooks.d/ethernet.


The last step is to install an initramfs with the new parameters.

root@hydra:~# update-initramfs -k all -u

I think that was it. Now the server boots without asking for a password prompt.
As soon as I disable networking, or switch of the Mandos server, the client stops at the password prompt.

Leave a Reply

Your email address will not be published. Required fields are marked *