All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Encrypt Only selected partitions - CentOS
last few days, I was trying to figure out a way to do Full Disk Encryption for Kimsufi/ Online. I was unable to find a good way to get it setup as we do not have access to a KVM console where we can input the startup password for opening the encrypted disks. (I saw a guide for Debian, but I am more comfortable with CentOs)
So, I am wondering if there is anyway to keep the boot partition open, but, mount other partitions like home/ swap/ data after boot which are encrypted? I am going to probably thinking of setting up a new partition called /data which will need to be encrypted and all will be saved here.
I am simply trying to keep my data away from direct view, should the disk be replaced or should my server be compromised (if the partitions are not mounted upon boot, of course). I am not looking for a way to auto mount my encrypted partitions. I will do that manually after every reboot.
What are my options here? If there is still any hope to use NetBoot and try to give a password to do FDE with Luks, I will take that 100%. Thanks in advance
Comments
Hm, TrueCrypt containers?
http://nixware.net/install-truecrypt-on-linux-centos
Simply ssh in when system is booted, manually mount and you will be prompted for a password.
Example fstab entry:
At ssh:
Any good for you?
Not super familiar with LUKS but don't they need to be 0 0 instead of 1 2 ? I'd expect that to try to mount them on boot and ask for the password.
Usually when you use LUKS, there are two steps:
cryptsetup luksOpen ...)mount ...There are ways to wrap this into a unified script but if you're typically doing this once per boot or relatively rarely, the security-convenience tradeoff may not be really useful.
The fstab entries will be
/data ... 0 0as pointed out above by @skorous (you don't want to auto mount them).If you setup it up like this, then the mount point will not be auto mounted at boot and you have to mount it on demand via steps 1 and 2 above.
There are not-very-elegant ways to have dropbear setup so that you can ssh into the machine after it is booted to unlock the partitions if you want FDE - but remember that there's really no security you're going to get since the unlocked container can be tampered with to modify dropbear (etc.) to "steal" your password (assuming it's a dedi - if it's a VM there are probably much easier ways as discussed in other related threads on LET).
If you want to have multiple mounts encrypted (including swap), the right way is to have LVM on top of LUKS - so one key will unlock the LVM volumes and thereafter you can mount all your different mount points. LUKS can also be resized (typically grown) dynamically so there's no net loss here convenience wise.
Of course if you do this rarely, you can always have a painfully long password (or even key file) that is pasted/scp'd via SSH only when required.
Hope this helps.
^ re. mount values; quite likely, as I only pasted from a live system.
I'm not paranoid enough to have encrypted swap (I know, I know).
Hmm, never thought about this. But TrueCrypt is no longer secure, per their page. http://truecrypt.sourceforge.net/
Thnx.
Sure, this looks good. My only concern is Kimsufi creates a swap partition already as a part of its template install. So, would this conflict?
TBH, I am trying to do DropBear or its equivalent on CentOS, however, not successful in locating a good tutorial/ guide. I understand that there is a false sense of security as you suggested because of tampering. I am simply trying to find an elegant balance where it would take some decent efforts to get hold of my data. I am simply planning to put some scanned documents on the server, on nextcloud and access them. This is one reason why I do not want to encrypt my files locally first before uploading.
If there was a KVM available, setting up FDE would not be a challenge at all, and I would be able to enter the passphrase upon boot.
Thanks!
What you can do (to keep things simple and yet secure, at least as best as possible), is to have an encrypted LUKS partition where you have all your Nextcloud files/repository etc. If you want you can possibly also redirect or cleverly symlink some paths from /var/log/whatever to the encrypted mount to prevent even log leakage (for Nextcloud). Ensure that Nextcloud is not auto started (or even better, install it into something like /opt and have /opt as the encrypted mount). This way Nextcloud will not be able to start without the unlocked partition and you should be safe as far as the typical/casual use case is concerned (for snooping eyes, disk-at-rest etc.). You're still going to have to be careful because when unlocked, your machine is still vulnerable to other penetration attempts due to poor security or vulnerabilities. So ensure that you do lock it down thoroughly.
The enforced swap can be commented out in fstab and/or reconfigured.
This gets around the issues presented here, in terms of static security, IMHumbleO. Bolstered with CSF, of course.
I use NextCloud with inbuilt encryption, for remote backups, on both my SYS-ARM (dedi) & KS-7 (Proxmox) boxes.
(I have zero interest in NextCloud features, other than encrypted file storage, with associated add-ons, such as retention.)
This is interesting. I was under the impression that the E2E encryption was not ready for production use. How are you using this? Thanks
Absolutely. I can start off with this and see later what else can be enhanced. I totally understand the inherent risks which come with exposing something on the Internet.
I have never used anytime of LVM/ LUKS partitioning.
This is my current setup I have:
fdisk -l
`
Disk /dev/sda: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xfc0a7073
Device Boot Start End Blocks Id System
/dev/sda1 * 4096 40962047 20478976 83 Linux
/dev/sda2 40962048 42008575 523264 82 Linux swap / Solaris
`
[root@sd ~]# df -h
Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda1 20G 1.9G 17G 11% / tmpfs 788M 0 788M 0% /run/user/0I would like to utilize all the remaining space to be encrypted and mounted after I boot. Any suggestions on how I can do that? Thanks!
I'm using server-side (NextCloud) encryption only at this point. The backups are rsync'ed over webdav (https) and (after I complained to cPanel, to get it working) WHM. This gives short-term backups (WHM) in addition to archived backups (rsync).
Note that I use debian/webmin/virtualmin on these particular NextCloud instances - easier to setup with OVH restrictions, IME.
Oh. Good. Do you have nextcloud setup on a luks partition?
cryptsetup luksFormat...cryptsetup luksOpen...pvcreate,vgcreate,lvcreate) on the LUKS unlocked container from (3)If you're happy with just one gigantic partition, you can skip 4 and just directly create an ext4 (or other) FS on the LUKS container.
Hope this helps.
Didn't see the point/advantage in double encryption - the files are already encrypted on the server by NextCloud.
Ahh, I see.
Now, I could remove the earlier pre existing swap / temp partition also, correct? Not sure if nextcloud exposes any data in swap or tmp
Thnx
Yes - and you can manually mount it if you want encrypted swap.
Awesome, will try. Thnx