4

One of my customers has requested that their web server is encrypted to prevent offline attacks to highly sensitive data contained in a mysql database and also /var/log. I have full root access to the dedicated server at a popular host. I am considering 3 options -

  1. FDE - This would be ideal, but with only remote access (no console) I imagine this would be very complex.

  2. Xen - installing XEN and moving their server within a XEN virtual machine and encrypting the VM - which seems easier to do remotely.

  3. Parition - encrypt the non-static partitions where the sensitive data resides e.g. /var /home etc.

What would be the simplist approach that satisfies the requirements?


2
  • What type of servers do you have? If your servers allow access to the console access via the network something like the Dell DRAC, then you would be able to remotely provide the pass-phrase to unlock the system.
    – Zoredache
    May 10, 2010 at 3:04
  • @Zorecache: True about the DRAC. However, note that you'd need a secure connection to the DRAC, otherwise an attacker could sniff the pass-phrase and break the encryption...
    – sleske
    May 10, 2010 at 10:50

2 Answers 2

6

It would be worth checking with the host to see if they can either hook up an IP KVM or install a remote access card (IPMI, HP iLO, iDRAC, or RAS as appropriate) to provide an encrypted remote console.

With any FDE solution, you will necessarily have to have an unencrypted system bootstrap. At a minimum, this will consist of the MBR, bootloader, kernel, and initrd.

It is possible to network enable the FDE bootstrap system by using something like Mandos or using an entire OS installation and then switching to the real OS by remotely running custom scripts that utilise the power of pivot_root, chroot (or kexec) after cryptsetup and mount.

Using Xen and having a VM with encrypted storage is similar to using an entire OS for bootstrapping, but with less mucking around and easier maintenance. The only disadvantage in this approach is the virtualisation overhead.

The block device approach (LV, partition, or loopback) is certainly easy to get going, especially if you are trying to make the change on a production system.

Now the advice part: If you can get remote console access (full KVM, not serial) and you are building up a new machine, then go with FDE. All current distributions support it in the installer and it will be the least maintenance option.

Otherwise:

  • Don't even contemplate using FDE. A remote access bootstrap system will just be too fragile, and when it breaks, it will be a nightmare to fix. Don't try to convert a live system on the fly unless you really really really know what you are doing.

  • If you are building a new machine for this security upgrade and the virtualisation overhead is acceptable, then go for approach 2. It will be the most sane option for yourself and any other future sysadmin to understand/maintain. With this approach, you can use the OS provided installer encryption within the VM rather than encrypting the storage on the host if you want (pro/cons to both approaches wrt to maintenance/migration/etc).

  • If you have to make this change on the production system (which I highly recommend against. Make the client pay for a proper migration with a second system), then go with approach 3 and use a LUKS formatted block device (preferably a logical volume).

  • Under any of these scenarios, the base system or bootstrap code can obviously be trojaned so that the encryption key will be revealed. Don't waste your time trying to mitigate this risk unless you have a lot of time on your hands and your customer has money to burn. If you do have to mitigate it, then you would want to install something like Osiris.

Keep in the back of your mind that the data is going to be so much more at risk from software bugs, backup systems, misconfiguration, bad passwords, etc..

2

First of all, note that you do not need to create separate partition for encrypting data; you can use a loopback mount to mount a file as an (encrypted) partition.

But more importantly, you need a clear threat model. What exactly is your client afraid of?

Normally, a hosted server should only be accessible to authorized customer staff and some specialized staff of the hosting provider. Are they afraid the hosting provider will try to copy data behind their backs? Are they afraid of physical break-ins? Do they want to protect from casual snooping, or from a sophisticated attacker, possibly with repeated access?

This will influence what solution they need. E.g. just encrypting the data means the operating system is still vulnerable to the installation of a trojan while the system is offline. An attacker could take the system offline, install the trojan, the restart; afterwards they could copy data off the encrypted area while it is accessible.

Also, any encryption solution will need a key / passphrase to be supplied to unlock the encryption. When will that be provided? How? What secure channels do you have? What if for example the system becomes unbootable and needs to be recovered? Someone trusted to have the key will then have to be physically present; will that be feasible?

Without answering all these (and more) questions, there is no reasonable answer.

Of course you can just deploy some kind of encryption and be done with it, but that may fail to protect from an attack and only cause unneccessary cost and a false sense of security.

Note: There's a nice discussion on encrypting data on a server here: Auto-booting and Securing a Linux Server with an Encrypted Filesystem

4
  • The client is afraid of sensitive competitive data being stolen via some form of coercion against staff of the data center. They want additional security to prevent someone walking off with their data. There is no possiblity of human assistance with key management at the data center. I would need to input the passphrase on reboot to decrypt the neccessary partitions. A FDE solution would be ideal as it gaurds against attacks like those mentioned with the trojan however I do not know how this could be achieved using remote access. All I can think of is using XEN and encrypting a domu VM. Thanks
    – Michelle
    May 9, 2010 at 22:08
  • If the client is afraid of hosting staff being coerced then they are out of their minds to let someone else run their hardware. There's some serious paranoia with a steaming-hot side of delusion here.
    – pboin
    May 10, 2010 at 1:49
  • I agree; all encryption solutions I know of can be circumvented by a sophisticated attacker with full physical access (if need be by directly reading data from the running system using probes). So you'll need to explain to your customer what encryption can or cannot prevent, and discuss what makes sense.
    – sleske
    May 10, 2010 at 10:47
  • 2
    Finally, if your customer is going to such lenghts to protect their data, they might want to hire a dedicated data security consultant. The tradeoffs and possible risks are probably too complex to discuss exhaustively on serverfault.com...
    – sleske
    May 10, 2010 at 10:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .