Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Data Storage Operating Systems BSD

Building a Fully Encrypted NAS On OpenBSD 196

Posted by kdawson
from the peace-of-mind dept.
mistermark writes "Two years ago this community discussed my encrypted file server. That machine has kept running and running up until a failing drive and a power outage this last week. So, it's time to revise everything and add RAID to it as well. Now you can have an on-the-fly encrypting/decrypting NAS with the data security of RAID, all in one. Here is the how-to."
This discussion has been archived. No new comments can be posted.

Building a Fully Encrypted NAS On OpenBSD

Comments Filter:
  • by Architect_sasyr (938685) on Sunday July 15, 2007 @11:04PM (#19873085)
    One step in the long process. Kudo's and gratitude for putting this up, it will certainly make my process easier.

    I wonder, are there any full HOWTO's on this? 802.1x and IPSec both come to mind. The protection is useless if the server is powered on of course.
  • Pretty Useless (Score:5, Insightful)

    by mvdwege (243851) <mvdwege@mail.com> on Monday July 16, 2007 @12:26AM (#19873471) Homepage Journal

    Seeing as that he uses per-volume encryption, this is pretty useless. It makes his 'server' pretty much a single-user NAS box, because as soon as another user gets an account to access the file server, they get access to the data.

    Data encryption on a fileserver only makes sense if it is done on a per-user level. This is not News for Nerds, as this is basically just another implementation of how to encrypt your local disk.

    Mart
  • Re:Pretty Useless (Score:5, Insightful)

    by DamnStupidElf (649844) <Fingolfin@linuxmail.org> on Monday July 16, 2007 @01:35AM (#19873733)
    Seeing as that he uses per-volume encryption, this is pretty useless. It makes his 'server' pretty much a single-user NAS box, because as soon as another user gets an account to access the file server, they get access to the data.

    As long as the server remains physically secure, and assuming there aren't gaping root privilege holes in the security, the files on the disk are still protected by the file system permissions. As long as the users can trust the admin, they don't have to trust each other.

    Data encryption on a fileserver only makes sense if it is done on a per-user level. This is not News for Nerds, as this is basically just another implementation of how to encrypt your local disk.

    Databases with private information like credit card or social security numbers should be on encrypted disks. Not to protect against users, but to protect against the drive being replaced or stolen before it can be wiped (secure wiping is not necessarily secure either, especially as drive technology advances, since what was wiped 5 years ago may be easily readable now).

    There's really no advantage to having a server encrypt and decrypt each user's data with a different key. The server will have to know all the keys to perform the decryption at least (public keys allow secure encryption without the server knowing the private key), so it's only as secure as encrypting the entire drive and then relying on filesystem permissions. Root will always be able to read any files that are encrypted/decrypted on the server itself. If clients encrypt their files before storing them on the server, then the server can safely store everything in plaintext.
  • Re:Pretty Useless (Score:3, Insightful)

    by mvdwege (243851) <mvdwege@mail.com> on Monday July 16, 2007 @03:22AM (#19874169) Homepage Journal

    There is really no advantage to encrypting data if you have other means to restrict access to a server.

    Volume encryption only makes sense if there is a significant risk of losing physical control over the volume, i.e. on portable media. If your hypothetical server with private information is not in a secure datacenter, you're doing something wrong.

    So, considering that a fileserver will have some form of access control anyway (in case of this NAS box, the locks on his house), why encrypt the entire volume in the first place? The first insecure client that connects makes the whole exercise moot, not to mention giving out the key to multiple users. And if there is no access control, neither physical nor logical, then it is just a local disk connected to a network instead of directly to a (S)ATA/SCSI bus. And local disk encryption is old hat.

    Mart
  • by Yggdrasil42 (662251) on Monday July 16, 2007 @04:11AM (#19874323) Homepage
    Thanks for clarifying the OP's error, but why the patronizing tone?
    Most people on the planet don't speak English natively, and a large part of the Slashdot population is from that group.

    Since you can't tell if the OP does or does not belong in that group, being a little less harsh would make the world a nicer place. Why not start there?

6 Curses = 1 Hexahex

Working...