Building a Fully Encrypted NAS On OpenBSD

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."

Comments

Netcraft...

[Anonymous Coward]

mistermark's failed hard drive only further confirms that BSD is, in fact, dying.

One link in the chain...

[Architect_sasyr]

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.

Re:One link in the chain...

[Yggdrasil42]

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?

An explanation

[Anonymous Coward]

Kdawson clearly killed the other editors, and is now posting all stories. If you see anyone else posting, it's actually kdawson using their account. Look for more dupes, April Fool's Day jokes, and Slashvertisements soon.

needs usability

[r00t]

Right from the initial install, by default, this should work.

Encrypted backups should be default and easy, with reminders.

You need multiple keys: whole-system, per-user, and swap. The swap key gets replaced at boot with something random.

Ultimately, it needs mandatory encryption. This would exclude OpenBSD; you need a mandatory policy framework like SE Linux to make it happen. Mandatory encryption means that normal users are prohibited from removing data from the machine without first encrypting it in an approved way. This most likely solves part of the backup problem. It also reduces the insider threat, while still allowing transfer of data between secure machines.

freenas...

[Tmack]

Meh...

1. download FreeNAS
2. install to USB/CF drive (it needs ~32Mb)
3. configure * reboot on the USB/CF drive (or if your mobo cant boot to those, maybe a CD or spare HD)
4. ?
5. Profit!

Tm

Pretty Useless

[mvdwege]

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

[DamnStupidElf]

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:USB drives?!?

[gardyloo]

USB was o.k. last year, but with 20GB/sec effective transfer rate at most, it simply doesn't do a large modern HDD justice anymore.

    Jeeeeezus! Either I'm way behind the times, or your "GB" was meant to be perhaps a thousand times smaller.

Re:Been looking for something like this

[JayAEU]

Just make sure you don't follow TFA's recommendation regarding the choice of identical drives for the RAID array, which would make the whole point of redundancy moot.

Identical drives are just that, identical. This means that they also are very likely to fail at the same time or may not survive a RAID reconstruction process to rebuild the other failed drive.

My advice would be to make them identical only in size and maybe the interface, but for the love of God, do pick different manufacturers and production months for the drives.

Re:USB drives?!?

[hmallett]

When is your next book "More Typo's I found on the Internet" coming out?
It's late and nitpick stuff like this has been driving me nuts all week.

There shouldn't be an apostrophe in Typos...

Suggestions

[LuSiDe]

OpenBSD on a fileserver? Firewall, sure. Fileserver w/RAID and disk encryption, no way. I would leave that task to FreeBSD (FreeNAS) or Linux (CryptoBox, Openfiler). If you are desperate for encrypted FS + RAID you can use MD + LUKS (Linux) or GRAID5 + GELI (FreeBSD) those are all available via FreeNAS, CryptoBox, and Openfiles. Suffice to say both have proven their stability, have a rich set of features (e.g. LRW), and are simple to set-up. The end-user NAS solutions are pretty sophisticated and have good web interfaces.

20 MB/sec is quite a shit performance IMO however if you don't use gigabit it'd be good enough. With GELI there is about 55% overhead compared to plain text. I haven't compared LUKS to plain text hence can't compare. On a side note, I doubt its useful to encrypt data you're receiving from distributed areas, nor that its useful to put such data in a RAID. A NAS doesn't run BitTorrent. If you're paranoid whereas you share your data over SMB, that might be the weakest point.

For our ricer folk, a nice, expensive RAID controller is necessary. For the smart people among this planet: do software XOR by getting an EE (or SFF) dual core AMD which are cheap and have a a low 10 idle W and have a low TDP (the SFF has 35W TDP). Get 4 Samsung SpinPoint T166 SATA (silent, low power, best bang for buck) and you have 1,5 TB RAID. All in all this costs about 650 EUR (probably less in USA) w/all hardware new including case, 2 * 1 GB RAM (2 * 0,5 GB would suffice too), and PSU. I should know, I bought and build such machine.

Forget ZFS for now. OpenSolaris has bad hardware support, and it is only partly ported on FreeBSD 7.0-CURRENT where it isn't stable and a bug in it takes the whole system down. While it does have a rich set of features, it also doesn't support encryption yet, although the feature has been planned for a year and perhaps on FreeBSD it can be used together with GELI. Performance of ZFS is also not to write home about compared to GRAID5. ZFS isn't mature yet. Nor is FreeBSD 7.0-CURRENT, ofcourse. It'll be part of FreeBSD 7.0 however, as an experimental feature.

Re:OK

[thc69]

WTF
IsA
NAS
?

http://en.wikipedia.org/wiki/Nas