I would need to factory reset the whole server for that, which would be … highly inconvenient for me. It took me quite a long time to get everything working, and I don’t wanna loose my configuration.

This is your actual problem you need to solve. Reinstalling your server should be as convenient as installing a basic OS and running a configuration script. It needs to be reproducible and documented, not some mystery black box of subtle configurations you’ve forgotten about ages ago. A nice, idempotent configuration script is both convenient and a self-documenting system for tracking all the changes you’ve ever implemented on your server.

Once you can do that, adding whatever encryption you want is just a matter of finding the right sequence of commands, testing it (in another docker perhaps) and then running your configuration script to migrate your server into the desired state.

You can use cryptsetup-reencrypt to encrypt an existing disk in place with LUKS. Then you just have to modify the initramfs/bootloader/fstab to point to the new configuration. See https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encrypt_an_existing_unencrypted_file_system

Encrypting your disk only provides at-rest protection, meaning there are entire swathes of physical attacks it provides zero protection against. Tons of stuff a malicious actor can do during runtime with physical access that you’d never notice. it quite literally only protects against thugs smashing your door in and physically walking away with the disk.

So if you’ve painted yourself into a corner with a baby’s first config, what you can do to step up your level of data protection (until you can redo your setup properly) is creating an encrypted filesystem or filesystem image (use fallocate to create a large empty file, then connect it to a loopback device, encrypt with LUKS, and use it as a virtual filesystem), rsync your data directory to it, and then unlock/mount it at boot under the directory where Nextcloud is configured to store your data. It’s god-awful, but this should be more or less transparent to Nextcloud if you do it right, and then at least your data directory gets at-rest encryption, and tbqh if someone is smash and grabbing your hard drive they are probably more interested in your data than they are your OS config.

I wouldn’t say this is an acceptable or preferable alternative to FDE, but it sounds like you’re still figuring out the best ways to set these things up, and this will get you more protection than none. But, realistically, you should probably not worry about it too much and should think about the security of your setup as a learning exercise/study in best practices.

Luks full disk encryption and encrypted offsite backups. This protects from most common smash and grab scenario.

I had issues where system upgrades would loose encryption keys and full restore from backup was my only option. Nextcloud have issues with encryption, some features are not available if you enable it (don’t remember which ones now).

Generally speaking if someone has physical access to your system you’re screwed. There are many ways that physical access can be used to get access to your data including denying you access to your data.

Full disk encryption. It wnt do anything if the server is powered on and they plug in a flash drive, but if it were to have the physical disks taken out or the server is powered down and moved.

Disable removable media. Might be able to do it in the bios, but I’d not, you should be able to in the OS.

Easiest one though is to lock the door to the room. Or to the rack if you have it in a rack.

I would need to factory reset the whole server for that, which would be … highly inconvenient for me. It took me quite a long time to get everything working, and I don’t wanna loose my configuration.

It sounds like your configuration is not sufficiently backed up.

Data you care about (that includes software configuration files) should be backed up at least three times on two different mediums with one copy being stored off-site (3-2-1 rule).

Also, how should I access the device when I don’t see anything? Is there a workaround or something when I want to reboot without a monitor and keyboard?

There are two ways that I have found for this:

• Initrd SSH: Just run an sshd inside your initrd. After reboot, you connect from another machine and enter your decryption password through SSH.
• TPM unlock & measured boot: You use a TPM to measure whether your bootloader, kernel, initrd are all valid and then the TPM releases the decryption key to the kernel; automatically unlocking LUKS.

if you go down the luks route, an option to look at is Clevis/Tang for automatic unlocking on a trusted network. I have a tang server running in the cloud, firewalled to my home IP, so if my server reboots in my house, it auto unlocks, but if you steal it and try to turn it on anywhere else, it won’t be able to auto unlock, and will require a password.

I should write that config up somewhere as a guide.

Just put in another disk or create a new partition, encrypt it with LUKS, move your data there, mount it in the place where it was before. You’ll have to SSH into the server and decrypt it after each reboot, but no pne will be able to plug in your disk or change boot parameters and just get in without the encryption password. It won’t protect, however, against an attacker with frequent physical access who can manipulate the system and wait for you to type in the encryption password.

I understand a complete server reset would be inconvenient.

I’m quite fond of veracrypt: It offers good encryption and is transparent when mounted.

You can create and mount a container file with veracrypt, copy your existing data in there and replace the original folders with appropriate symlinks. I think thats the best tradeoff for good protection and convenience

deleted by creator