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

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.

Re:needs usability

[jd]

Mandatory encryption won't help a whole lot. Mandatory access controls that utilize encryption might help some - it doesn't protect off-site data but DOES limit the device you copy data onto, as the device must be authorized to hold the data. It is then the problem of the device as to how to protect things. Not perfect, but a major improvement, as it means Joe "The Spy" User can't copy onto an unauthorized device to decrypt later at Evil HQ, and Fred "The Idiot" Flintstone can't copy top secret DoD construction plans onto public FTP servers. As has happened, according to reports.

(The point of MAC is that MAC requires that there be explicit permission given by someone who has the authority to give that permission. It is not implicit, unlike DAC where anything not expressly prohibited is implicitly allowed.)

The encryption thing can be improved on a little, if it is not secret key -or- uses an OTP calculator that only resides on authorized machines. The latter is getting a little into security through obscurity, but still works to a degree if the calculator is any good and the underlying crypto is sufficiently strong. As async encryption is slow, you'd probably want a crypto accelerator, but there are countless such systems. Don't blame the algorithms if you don't want the solutions.

Re:Pretty In-depth

[ComputerSlicer23]

I'm shocked the raid tools for OpenBSD aren't better then that. Not a dig at it, OpenBSD generally prides itself on exceptional tools. OpenSSH, CARP (their replacement for VRRPD), their firewall tools and everything else. Linux has a system call that can be used to monitor the status of a RAID array. It can kick off an arbitrary command, including starting up recovery and/or e-mail alerts. Technically the system call doesn't, but the mdadm tools that use the system call can.

I really hope somebody replies telling me, I'm an idiot and that OpenBSD has exactly such tools. Well and they really exist, as opposed to the clever slashdot behavior of telling me I'm an idiot and be completely wrong.

Kirby

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:Not really a very fair description

[Amouth]

interestingly I have had localized brown outs in parts of my house....

I have underground power and water got into the line.. and one of the legs would drop in voltage for no reason.. so instead of 2 120v legs coming in I had 1 120 and 1 60v leg.. when say the heater would cut on power would bleed across from one leg to the other and things would work but when it turned off anything that was on the 60v side would brown out..

it was odd as hell.. if I unplugged my fridge then half the house would start working again .. none of it made since - that is until I realized that my power meter wasn't working (one of the new digital ones).. as soon as I turned off the main breaker the power meter would boot up and be good.. so I called the power company.. they strapped a solid state transformer to my house for a week so I could live off of 1 120v leg until they could repair the line...

but due to over doing UPS's .. none of my computers ever lost power.. hell I was online playing games during the last few hurricanes..

Re:Software RAID

[drinkypoo]

The only advantage to buying a RAID controller is that you get a lot of connectors. Otherwise, if you have any even fairly decent CPU, and you're not doing anything but shoveling data and maybe some logging, the main processor beats the living shit out of almost any CPU on any RAID controller. There are limited exceptions but those cards are highly spendy. And keeping a lot of data off of the interface bus. Hardware RAID controllers are all about delegation. Get the data off the bus and onto the card as fast as possible, without sending it over the bus multiple times. Which is less of a concern in the days of boards with 30+ PCIe lanes. [...] Instead of being able to tell the controller "write these X bytes of data" and only sending X bytes across the PCI bus, with Software RAID, you're probably looking at at least 2x (RAID1) up to 4x (RAID5) the bandwidth usage to write data.

It's true that the more computation is involved, the more serious the bus bandwidth issue gets. This is an excellent reason to build software-based RAID systems with Hammer-core processors today; they have their own memory controllers onboard. Thus the RAID processing doesn't involve a bunch of bandwidth over the only bus interface on the chip.

Also, the more cache you have, the less times the processor is actually going to go to main memory, which reduces the bus bandwidth used in RAID computations. So the ideal situation (to do this on the cheap anyway) is to use the cheapest K7-n processor you can find that has a lot of cache, and get the best of all worlds. (Plus HT links are faster in the newest processors, yes?)