Fellow selfhoster, do you encrypt your drives where you put data to avoid privacy problems in case of theft? If yes, how? How much does that impact performances? I selfhost (amongst other services) NextCloud where I keep my pictures, medical staff, …in short, private stuff and I know that it’s pretty difficult that a thief would steal my server, buuut, you never know! 🤷🏻‍♂️

  • brygphilomena@lemmy.world
    cake
    link
    fedilink
    English
    arrow-up
    19
    ·
    1 year ago

    Nope. This isn’t part of my threat model.

    I don’t have sensitive data and stealing a drive would be inconvenient for a thief.

  • Avid Amoeba@lemmy.ca
    link
    fedilink
    English
    arrow-up
    13
    ·
    1 year ago

    Have you tried secure-erasing a disk?

    Absolutely yes, I do enctypt my drives so I don’t have to ever do that again. This isn’t as critical for SSDs but it’s still a good idea. Even if you keep the key stored on the same system, securely deleting a tiny file is way easier than a whole disk.

  • AtariDump@lemmy.world
    link
    fedilink
    English
    arrow-up
    12
    ·
    1 year ago

    I used to until I realized that I’ve got bigger threats to worry about.

    And like someone else mentioned, if I have to do data recovery for some unknown reason I want to make sure the data’s not encrypted.

    • peregus@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      2
      ·
      1 year ago

      Why? If you store the key in your password manager shouldn’t be a problem to mount the drive on another PC, decrypt it and save data. Or am I missing something?

        • peregus@lemmy.worldOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          Why? What would be the problem?

          P.s. Why did you link to the Anti Commercial-AI license?

          • onlinepersona@programming.dev
            link
            fedilink
            English
            arrow-up
            5
            arrow-down
            1
            ·
            1 year ago

            Why? What would be the problem?

            On linux, you’re probably using LUKS. That has a header with the keys at the beginning of each encrypted volume. If those keys (or key if you only have one) is corrupted and you don’t have a backup of that, you’re fucked.

            The next problem is that data recovery tools mostly don’t support decryption. They scan regions or the entire drive for recognizable things like partition headers, partition tables, file types, etc. if those are encrypted, well…

            If you are able to decrypt a partition, then it might work as it will show up like any other device in /dev/mapper/ and you could do recovery /dev/mapper/HDD. However, I have no idea what data corruption does to encryption algorithms. If one part of what is being decrypted is faulty, what does that do to the entire thing?
            This mostly comes from a lack of knowledge on my part. IIRC encryption depends on hashsums -> if you change what’s being decrypted/encrypted, the entire hashsum is incorrect and thus all the data shouldn’t be able to be decrypted. But I might be wrong - I’ll gladly be wrong on this.

            Anti Commercial-AI license

            • peregus@lemmy.worldOP
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              On linux, you’re probably using LUKS. That has a header with the keys at the beginning of each encrypted volume. If those keys (or key if you only have one) is corrupted and you don’t have a backup of that, you’re fucked.

              I got it, thanks! I will rely on SnapRaid form redundancy and on backups on multiple devices/locations.

          • WolfLink@lemmy.ml
            link
            fedilink
            English
            arrow-up
            3
            ·
            1 year ago

            The way you recover data from a totally dead drive is use a program that scans every byte and looks for structures in the data that look like files e.g. a jpeg will have a header followed by some blocks of content. In an encrypted drive everything looks like random data.

            Even if you have the key, you can’t begin searching through the data until it’s decrypted, and the kind of error that makes it so your drive won’t mount normally is likely to get in the way of decrypting normally as well.

  • asbestos@lemmy.world
    link
    fedilink
    English
    arrow-up
    12
    ·
    1 year ago

    How do you even encrypt a server so that it doesn’t require human intervention every time it goes down/restarts?

    • ShortN0te@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      How do you even encrypt a server so that it doesn’t require human intervention every time it goes down/restarts?

      The only time my Server goes down, is when i manually reboot it. So waiting a minute or two, to ssh into it and entering the passphrase is no inconvenience.

    • ClemaX@lemm.ee
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      Files could be decrypted by the end user. The OS itself could remain unencrypted.

    • hperrin@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      TPM, but it’s a pain in the ass and breaks a lot. The new version of Ubuntu should handle it better, but if you’re not on Ubuntu, that won’t help you.

    • Pika@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      TPM is a good way, Mine is setup to have encryption of / via TPM with luks so it can boot no issues, then actual sensitive data like the /home/my user is encrypted using my password and the backup system + fileserver is standard luks with password.

      This setup allows for unassisted boot up of main systems (such as SSH) which let’s you sign in to manually unlock more sensative drives.

  • ShortN0te@lemmy.ml
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    1
    ·
    1 year ago

    I use full disk encryption for every server (and other computers).

    Encrypting your data drives is a must for everyone imho. Encrypting the OS is a must for me🤷‍♂️

    • n3m37h@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      3
      ·
      1 year ago

      My PC weighs 80+ lbs, live 8km from town, surrounded by farm land and there are only 3,400 in town and I live 30 min from a city of 40,000 and 40 min from another city of 70,000 and my internet is 20/10 mbps

        • JustEnoughDucks@feddit.nl
          link
          fedilink
          English
          arrow-up
          7
          ·
          1 year ago

          I think he is saying that his physical attack surface is very small since he is remote, so maybe he doesn’t bother?

          Either way, encrypting drives is simply always good if you ever resell the computer or upgrade drives.

        • n3m37h@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          FreeAin’t no one stealing my shit, even via internet to upload 40tb would take 1 year 5 days at max speed in actuality it would be 1 year 8 months… Fuck I miss my 1.5G fibre connection…

  • zarenki@lemmy.ml
    link
    fedilink
    English
    arrow-up
    9
    ·
    1 year ago

    Yes.

    My home server has dropbear-initramfs installed so that after reboot I can access the LUKS decryption prompt over SSH. The one LUKS partition contains a btrfs filesystem with both rootfs and home as subvolumes. For all the other drives attached to that system, I use ZFS native encryption with a dataset that decrypts with a keyfile from that rootfs and I have backups of an encrypted copy of that keyfile.

    I don’t think there’s a substantial performance impact but I’ve never bothered benchmarking.

  • markstos@lemmy.world
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    1 year ago

    In addition to “encryption at rest”, also consider that your devices might be exploited over the internet, so attackers may be able to access the decrypted state that way. To guard against that, you may wish to encrypt certain documents with an additional password, even if they are sitting on an encrypted file system.

    Recall that within a month, the widely SSH was exploited and a backdoor added to every machine. I had upgraded to that SSH version. I didn’t run an SSH server on that box, but it goes to show that even those who take precautions can end up exploited!

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      The XZ vulnerability was stopped in its tracks and did not really affect the majority of systems.

      I also have a hard time believing local file encryption can be that effective. All they need to do is capture your keystrokes.

      • markstos@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        It’s defense in depth. If I encrypt a rarely used file, capturing my keystrokes will eventually work, but it might be weeks or months before I return to decrypt that file. In the meantime, I might have realized I was hacked and restore the system.

    • peregus@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      1 year ago

      That’s why I use most of the services via Wireguard (except Nextcloud that is behind Cloudflare and MQTTs that’s completely exposed)

  • JoeKrogan@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    ·
    1 year ago

    On laptops yes, on my server no. Most of the data is photo backups and linux ISOs form over the years.

  • tired_n_bored@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    No. I run my servers on low quality shit and I expect them to break any time. Never had to perform a data recovery but if I need, I’ll thank myself I didn’t encrypt my pics

    • peregus@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      2
      ·
      1 year ago

      If someone raids my house I have bigger fish to fry. Sure, but if it’s “free”, why not do it? My main worry was about performances, but since I’ve read that with AES-NI it doesn’t impact that much and since it seems not to be that complicated (let’s hope! 😁).

  • Gooey0210@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    1 year ago

    Yes, all, no matter what data is, it’s not hard and doesn’t have any consequences, but protects from many inconvenient accidents

  • Pyrosis@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    Yup and negligible. If I’m forced to contend with a windows environment bitlocker is utilized.

    I also utilize a ram disk in a windows os. Imdisk in windows. I migrate temp files and logs into the ram disk. It saves on disk writes and increases privacy.

    If pretty straightforward to encrypt if utilizing Linux right from install time.

    As for my server I too utilize nextcloud. However, the nextcloud data is on a zfs dataset. This dataset is encrypted.

    I did this by installing nextcloud from docker running within a proxmox container. That proxmox lxc container has the nextcloud dataset passed into it.

    • peregus@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      I did this by installing nextcloud from docker running within a proxmox container. That proxmox lxc container has the nextcloud dataset passed into it.

      That’s almost what I’m doing (I’m using a VM in Proxmox where I install all my Docker containers). Right now I’m thinking about encrypt only the data volume (a NFS share from Proxmos host) since all the sensible data will be there.