Planning to deploy a remote hosted mailer (Zimbra based) I need to make sure the local data on the machine is encrypted. Currently, the plan is to use the built in LUKS to encrypt /opt/zimbra and leave it at that, however, since I have no experience with encryption, I am on the lookout for additional options or ideas, especially in terms of disk performance and the possibility to actually boot the host without entering an access password.

Some details: 500 mailboxes, 8 CPU cores, 32Gb RAM, 8x SAS disks in raid10. RHEL6 OS

3 Answers 3


Roughly speaking, you can't. There is no good way to do what you want. All of the possible approaches have major drawbacks.

You can turn on LUKS encryption of the partition. However, this has two significant disadvantages:

  • Someone will need to enter the password in at the console each time the machine boots. If the machine gets rebooted, it will sit there hanging, waiting for someone to enter the password manually, before it can start the email server and access the encrypted data. For most scenarios, that's not acceptable.

  • More significantly, the scheme provides limited or no security. Suppose the server gets compromised, and the hacker gains control of the root account (or the account that the mailer runs under). Then the hacker will have all the same access that the mailer program does. In particular, this means the hacker will be able to access the decrypted emails -- so the encryption doesn't actually do any good against this threat. The only threat it protects is the possibility that the hardware might be lost or stolen; if the thief powers down the equipment, then they won't be able to regain access to the data, since they won't know the LUKS password.

If you think about it, there is no good way to avoid these security limitations -- they are pretty much unavoidable. If a hacker compromises your mailer, they'll be able to see all your email, in cleartext. (See also my answer elsewhere for more.)

Therefore, I think you need to think through carefully what you are trying to achieve. Cryptography is not magic pixie dust that you can sprinkle on a system to make it secure. By asking "how do I use cryptography?", you have zeroed in on a particular mechanism and implicitly assumed that cryptography is going to be the solution to your problem; but in this situation, that may not be the case. Therefore, I suggest you avoid such implicit assumptions and see if you can articulate what problem, exactly, you are looking to solve.

The standard way to think through your goals carefully is to work out what is your threat model. If you don't have a clear threat model, you're going to have a hard time devising a useful scheme. A threat model should identify what kinds of threats/attacks/risks you are trying to defend against, and which ones are out of scope. Once you have a threat model, one can start to consider what is the best mechanism. If you want to revise/update your question with a description of what you are trying to achieve and the threat model you have in mind, we can try to provide you with more helpful advice.

  • Thanks for the answer, indeed, the main threat I am trying to protect against is not hackers, but the possibility of easily accessing the data if the machine is taken away. Nothing illegal happening there, but in some countries, it doesn't have to be illegal, and the server will be placed in one of the less stable ones unfortunately.
    – dyasny
    Dec 11, 2011 at 10:05
  • @dyasny, OK, makes sense. In that case, LUKS encryption is probably about as good as it gets: or, at least, I can't think of anything significantly better.
    – D.W.
    Dec 11, 2011 at 19:03
  • I just keep wondering about performance. The Truecrypt website mentions native performance due to some technologies they implement. Haven't found anything of the sort for LUKS, but LUKS is native to the OS, and it makes sense to use it at least for the sake of KISS
    – dyasny
    Dec 11, 2011 at 19:44
  • 1
    @dyasny, My experience is that the performance overhead is not noticeable. Hard disk bandwidth tends to be in the range of 20-50MB/second. In contrast, most server CPUs can encrypt at a rate of hundreds of MBs per second, which may be why the encryption does not seem to be the bottleneck. You could always measure to see whether it leads to any detectable overhead in your setting.
    – D.W.
    Dec 12, 2011 at 1:57

The system you're suggesting is fundamentally at odds with itself. If a password is required to access the drive, then it must be accessible during the boot process. Either it must be stored somewhere or it must be entered in by hand.

If you can't reconcile that one point, then you can't do encryption on your server.

  • true, I will probably have to live with entering the password via the DRAC when the machine has to reboot
    – dyasny
    Dec 11, 2011 at 10:06

Not being specifically familiar with LUKS, I had a look at it's website. It does describe itself as hard disk encrpytion, however goes on to state "LUKS stores all setup necessary setup information in the partition header" - which means that it must implement encrption at the partition level rather than at the disk level.

So just to add to D.W.'s excellent answer above, and applying your description of the threat model, you could have the data held on a seperate, enrypted partition and delay mounting and startup of the relevant daemons while allowing the machine to boot up and enable ssh access (and notification of reboot to someone who can login and complete the startup).

  • sounds like something that might already have been implemented, any ideas if there's a ready package that sends a notification out when a LUKS partition awaits a password?
    – dyasny
    Dec 11, 2011 at 19:41
  • That can be as simlpe as a one line bash script in the init dir - hardly needs a package.
    – symcbean
    Dec 14, 2011 at 12:18

You must log in to answer this question.

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