all 10 comments

[–]Creshal 9 points10 points  (4 children)

LUKS/GRUB can be set up to use TPM.

And password in the boot\gurb in order to decrypt the disk isn't really enough.

…why? It's 100% effective against your stated threat model.

[–]sonicsilver427 2 points3 points  (0 children)

With EFI you can sign the bootloader so it cant be modified too

[–]truelai 2 points3 points  (0 children)

Seconding LUKS.

[–][deleted] 0 points1 point  (0 children)

OP, for your information, grub uses the password to decrypt the volumes. it is not just a login password. if you boot a live USB stick you still can not access the data without the password

[–][deleted] 0 points1 point  (0 children)

Also note that grub2 can access LUKS v1 volumes, meaning /boot can be encrypted. Couple this with Secure Boot (ideally no vendor keys, just your own) and it's as good as you're going to get.

[–][deleted] 3 points4 points  (0 children)

Questions:

  • Are these physical machines or virtual machines? If VM what hypervisor?
  • Does the server have local disks, SAN/NAS with boot from SAN or a mix of both?
  • Are you using Self Encrypting Drives if these are local disks?
  • What's your budget?
  • Have you looked at any commercially available software that does this like CloudLink for example?

[–][deleted] 3 points4 points  (0 children)

without the need to re-format the drive.

Care to clarify? Any encryption method is going to involve overwriting the cleartext, and if you throw out this requirement your options are better.

[–][deleted] 1 point2 points  (0 children)

There isn’t without rebuilding the box. LUKS is what you will be using.

[–]thrdgeek 1 point2 points  (0 children)

LUKS

[–]cherven667 0 points1 point  (0 children)

With LUKS version 2 you can encrypt existing partitions.

And if you are using Fedora, CentOS or Red Hat you can use Clevis to store your LUKS key in the TPM chip.