Re: Should I encrypt servers at my home lab?
On 10/4/25 11:39, whiteman808@paraboletancza.org wrote:
Hey.
I've started building my home lab and currently I'm going to host
stuff like nginx, jabber server, mail, git hosting.
The stuff I want to specially protect will likely be in e-mail and
jabber conversations contents, and situations when someone is
forgetting to encrypt them are not rare. I mean mostly received e-
mails or friends who misconfigure their Jabber clients.
I want to protect against burglary and (most probable) against
unwanted access to disk contents when I give my hardware to the
service to repair it. I'm also doing torrenting (I personally don't
like copyright law and support copyleft related movements) and want
to protect also against seizing hardware by police (never happened
in my home but not impossible).
Do you think that it's good idea to do full disk encryption on my
server? Is remote unlocking server by supplying password through
dropbear-based ssh in initramfs secure?
Thank you, whiteman808
On 10/4/25 12:03, whiteman808@paraboletancza.org wrote:
I forget to mention I live in democratic country at EU, not in
authoritarian to clarify my threat model.
Not sure if I did good taking into account worst possible secenario
(not actually probable most of the time) in my security threat model
analysis.
October 4, 2025 at 8:39 PM, whiteman808@paraboletancza.org wrote:
On 10/4/25 18:23, whiteman808@paraboletancza.org wrote:
What do you think about implementing FDE on home NAS server? Does it
make sense or is it better to stick with solutions like Cryptomator,
GnuPG?
On 10/4/25 18:25, whiteman808@paraboletancza.org wrote:
I want to store on NAS a lot of random downloaded stuff like movies,
music and also my backups of servers.
Meh too fast typed sent :/
Encrypting "at-rest data" is the starting point -- e.g. the disks are
powered off and an adversary tries to access the computer and/or disks.
AIUI self-encrypting drives (SED) provide encryption that is always on,
using a cryptographic processor, a big random internal key, and a
user-provided password. If the password is unset (empty string), the
drive acts like an ordinary unencrypted drive. But once you set the
password (via BIOS/UEFI Setup or software), the only options are to
enter the password (e.g. you are prompted by the BIOS/UEFI during POST),
to change the password (via Setup), or to recover the SED (via Setup;
clears the password, generates a new internal key, and renders the old
data inaccessible). When I tried moving a password-enabled SED between
computers, I could not unlock the SED in the destination computer. I
needed to clear the password in the source computer, move the SED, and
then set the password in the destination. This could cause problems in
a disaster recovery scenario where a motherboard fails. Changing the
password does not re-encrypt the data, so it is a fast operation.
The Debian installer can build an Debian OS disk with encrypted root
(e.g. LUKS with a password) and/or encrypted swap (e.g. dm-crypt with
random key). I have been doing this for many years. You will need an
unencrypted boot filesystem somewhere, either the same disk or some
other device. Debian will prompt for the root password during boot.
Disks encrypted with LUKS can be moved to other computers and will boot
as expected with the password. Changing passwords does not require
re-encrypting data.
For data drives, LUKS works. There are several choices for passwords.
RTFM crypttab(5) and cryptsetup(8) for more information.
Securing a home server for remote access from the Internet is more
complex. Starting ideas include an edge router/ firewall with pinholes
and port forwarding, a VPN or SSH pre-shared keys for the connections,
strong passwords everywhere, and regular snapshots/ backups/ images.
David
Reply to: