Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Building a Fully Encrypted NAS On OpenBSD

Posted by kdawson on Sun Jul 15, 2007 10:51 PM
from the peace-of-mind dept.
Data Storage Operating Systems BSD
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."
+ -
story

Related Stories

[+] BSD: Encrypted Fileserver with Bittorrent Web Interface 266 comments
mistermark writes "I built a fully encrypted (samba) fileserver with a web interface for managing torrent downloads on it. All I used is OpenBSD 3.6 and its package collection, except for the TorrentFlux-interface (which you need to install separately). Anyway, it can be built using binary packages only. I included a rough HOWTO on how to make one of these yourself."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Building a Fully Encrypted NAS On OpenBSD 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Netcraft... (Score:5, Funny)

    by Anonymous Coward on Sunday July 15 2007, @10:59PM (#19873049)
    mistermark's failed hard drive only further confirms that BSD is, in fact, dying.
  • Wow, that was a pretty in-depth how-to. It even has a mechanism (via cron) to notify you within 15 minutes if a drive fails. This sounds like a pretty interesting solution. I think I may have to give it a try with a spare box I have laying around. Thanks mistermark. I'm impressed.

    • 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 repli

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

        What?

        OpenBSD:
        Provides a command l

        • Is it just me, or is there something that needs rethinking in the statement: "How is an approach that uses a standard Unix utility... shockingly unexceptional"? (emphasis mine) Either the phrasing was unintentional, or one person on this site is having problems understanding "exceptional".

          By-the-by, most simple functions can be performed via webmin or some other admin tool, in a way that is platform-agnostic to the user. Well, when the module is written correctly, that is. A number are very poor. However,

      • So he made a few mistakes which you consider stupid. TBH, as soon as anyone says "NAS" without considering RAID and backups, I think they're on a path to pain.

        But at the end of the day, no matter how many things you think about, no matter how much effort you go to, there is always something that gets missed. AFAICT, he's only got one power supply and no UPS on there, and on any large filesystem I'd consider journalling (or Soft Updates on OpenBSD) a must these days.

        You can build a system in which nothing
        • Exactly. I don't think this is supposed to be some replacement for a large corporate NAS. Then again, I didn't read the article. But if you want a file server for your home use, and you want it to be encrypted, then there's probably not a lot wrong with what he's doing. RAID mirroring makes the cost of storage double, so I could see why a home user might back away from that. Also, a UPS, while nice, probably isn't completely necessary, because a little bit of downtime while the power is off probably isn

          • Re: (Score:3, Interesting)

            by Amouth (879122)
            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 workin

  • One link in the chain... (Score:4, Insightful)

    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.

      • Re:One link in the chain... (Score:5, Insightful)

        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?
  • Although, since the OS is just there to boot and allow access to data, I was thinking of using a 1GB CF card to put the OS on. I like the RAID 1 setup the instructions are easy to follow, but how about other RAIDs?

    • Re: (Score:3, Interesting)

      by JayAEU (33022)
      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 m

      • Re: (Score:3, Informative)

        by CastrTroy (595695)
        Actually, Identical drives are in fact, not identical. What they are is built to the same specifications. They actually use different atoms and molecules to make up the components of the drive. They were most likely manufactured on different days, or at least at different times. If you took two drives from the same production line, and put them through the exact same usage, I imagine the probability of them both breaking within the same week to be somewhere close to zero, maybe even close to requiring t

        • Is it not the case that you need to get identical sector sizes, too?


          Not really, the physical sector size only matters when doing a hardware RAID, but even then, most modern controllers cope quite well with different disk.

          Some people claim that identical sector sizes help performance somewhat, but so far, I haven't been able to reproduce any evidence for this.
      • It looks like what I want, especially the spin-down of unused drives and the separate use of each disk.
        What I like less is the mandatory use of ReiserFS. Any idea if they plan to support other filesystems?

        Do you have actual experience with this product?

  • needs usability (Score:4, Interesting)

    by r00t (33219) on Sunday July 15 2007, @11:25PM (#19873191) Journal
    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.
    • I think you just described Windows Vista Bitlocker.

    • Re: (Score:3, Interesting)

      by jd (1658)
      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 construc

  • Any idea if OpenBSD supports Sun's ZFS filesystem?

    -metric
    • I do have an idea, the answer is no. The timeframe for it's support is when Sun releases ZFS under an ISC-style licence.
        • OpenSolaris has bad hardware support, and while Pawel did a terrific job the port for FreeBSD 7.0-CURRENT isn't quite there yet. ZFS requires a lot of RAM and indeed 64-bit (FreeBSD/AMD64) is recommended. You'll need at least 1 GB RAM, with 512+ MB dedicated to ZFS. You'll need to fine-tune via sysctl.

          The EPIA is nice but probably too slow for ZFS. At the vey least you can only use it as fileserver and will have to delegate other applications to other computers. Why not get a cheap, low-power dual-core AMD

  • freenas... (Score:5, Informative)

    by Tmack (593755) on Sunday July 15 2007, @11:46PM (#19873301) Homepage Journal
    Meh...

    1. download FreeNAS [freenas.org]
    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

      • I could not really find out whether FreeNAS supports encryption
        Latest FreeNAS supports 'encryption' (ahem, i meant disk encryption) via GELI.

  • Pretty Useless (Score:5, Insightful)

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

    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: (Score:3, Insightful)

        by mvdwege (243851)

        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

  • Suggestions (Score:4, Informative)

    by LuSiDe (755770) on Monday July 16 2007, @04:50AM (#19874439)
    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 [wikipedia.org] (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.

    • An explanation (Score:3, Funny)

      by 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.
    • FreeNas does encryption now?
      • It does not. If we read through the article we do find, however, that the author suggests FreeNAS for a NAS, OR CryptoBox [cryptobox.org] for hardware encryption. IMHO neither solution leads to the extension into a full blown server that the OpenBSD option gives.

        My $0.02 AU

    • Well, it's already done. It's called FreeNas [freenas.org]. Typical OSS advocate. Re-inventing the wheel... yet again.
      Considering how much the BSDs share code with each other, it's worth considering how much OpenBSD reinvented and how much they shared with FreeBSD which allowed FreeNas to "already do" this

    • Re:USB drives?!? (Score:4, Funny)

      by gardyloo (512791) on Monday July 16 2007, @12:28AM (#19873483)
      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.
    • Shit I don't know what crappy USB enclosures you're using, but dam man, get something decent.
    • Use dm-crypt with LUKS in the aes-cbc-essiv:sha256 mode (should be the default). There are policy issues and known plaintext attacks against loop-AES unless you the multi-key setup which _isn't_ the default... by the times the issues were widely known people were using LUKS because key management is more flexible.

      • Re: (Score:2, Informative)

        by kwark (512736)
        What! You are saying that Ubuntu doesn't do this on install? Even the Debian Installer has support for these kind of setups.
    • Uhhh....You can do that with FOSS. It just doesnt have a pretty GUI.

    • Re: (Score:2, Informative)

      by Kryten107 (1128675)

      Hopefully in the coming years some open source projects will get started to do what Home server will be doing.

      Take a look here: http://www.ubuntuhomeserver.org/ [ubuntuhomeserver.org] Yes, I know, it's Ubuntu, but the point is that there are some people in the community that are trying to make it happen. Almost all the necessary services exist, it's just a matter of gluing them together and slapping a decent GUI on it.

      • Not YET there isn't - as he said, he's looking *forward* to it. A quick Wikipedia or Google search using "Windows Home Server" [wikipedia.org] will get you your info...

        Really though it won't be worth it at all - more than likely I'm thinking it will be retail only (HP, Dell, etc). Also, being Server '03, I'm guessing its gonna take a bit more power to run than what a cli install of Linux or BSD can make do with, meaning less options of older underpowered machines to use which can be found for dirt cheap...

        • Re: (Score:3, Interesting)

          by drinkypoo (153816)

          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 t

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.