Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
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 More

Building a Fully Encrypted NAS On OpenBSD

Comments Filter:

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

    by Anonymous Coward on Sunday July 15, 2007 @11: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.

    • Re: (Score:3, Interesting)

      by ComputerSlicer23 ( 516509 )

      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

      • Comment removed based on user account deletion

        • Re: (Score:2)

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

        • I believe the mdadm tools on Linux actually block the system call until on a change in the status. I didn't state that clearly. So you get immediate notification, RAID re-builds. I wrote something that checked every 2 minutes on all of our RAID devices (Nagios and scripting are great). Generally mdadm and it's alerts informed me once I had those setup, soon enough that could go in and disable the Nagios alerts prior to it noticing.

          Kirby

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

    by Architect_sasyr ( 938685 ) on Monday July 16, 2007 @12:04AM (#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.
  • 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

        • 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 the "Heart of Gold".

          If you took 10 drives, though, the probablility of 2 of them failing within a week of each other is probably around .5.

  • needs usability (Score:4, Interesting)

    by r00t ( 33219 ) on Monday July 16, 2007 @12:25AM (#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.

    • Re: (Score:2)

      by BuR4N ( 512430 )
      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

      • Re: (Score:2)

        by r00t ( 33219 )
        The point is to protect off-site data. You can copy the data to a DVD-R, but you don't get the key. Take that DVD-R to another secure system which has the key though, and you can read the data.

  • ZFS (Score:2, Offtopic)

    by hitchhacker ( 122525 )

    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.

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

    by Tmack ( 593755 ) on Monday July 16, 2007 @12:46AM (#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

    • Kind of deal killer.

      • Ahem:

        FreeNAS is a free NAS (Network-Attached Storage) server, supporting: CIFS (samba), FTP, NFS, AFP, RSYNC, iSCSI protocols, S.M.A.R.T., local user authentication, Software RAID (0,1,5) with a Full WEB configuration interface. FreeNAS takes less than 32MB once installed on Compact Flash, hard drive or USB key.

  • Pretty Useless (Score:5, Insightful)

    by mvdwege ( 243851 ) <mvdwege@mail.com> on Monday July 16, 2007 @01: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 @02: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

        • Re: (Score:2)

          by Bishop ( 4500 )
          Using disk or volume encryption is part of a layered security approach. Even in secure facilities things are stolen.

          Physical security mitigates the threat of an attacker gaining physical access to the machine. Disk encryption mitigates the threat of an attacker gaining access to the disk (e.g. theft). File encryption mitigates the threat of an attacker gaining access to the running system (e.g. over the network). For good security you should use all of these tools.
        • 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.

          Unless you want to pay to have someone shred your used hard disks, encryption is really the only safe way to keep the data on them secure. If you want warranty replacement on dead disks, you'll probably have to send them back for an RMA with the data still on th

          • Re: (Score:2)

            by mvdwege ( 243851 )

            The key only exists on the server, the clients never see it. They just see a normal mount via NFS, SMB, or whatever.

            That makes even less sense. How does the server authenticate the client? If the server just decrypts and serves up the data to any client that connects, what's the use of encrypting? And if the server requires authentication to serve up the data, it could implement access controls just as easily. That leaves you with keeping data secret from other users/the administrators/someone with a warr

            • Re: (Score:2)

              by BLKMGK ( 34057 )
              BINGO! I've been reading the comments here wondering when the F someone was going to ask this. If someone runs off with my personal NAS then yeah I'm protected. If someone kicks in my door and logs in via a workstation or using their machine having observed my password this does NOTHING. Perhaps I could have a key secured on my workstation which is kewl but what about my XBMC'd XBOX? My aTV? My just about anything HTPCish that's like an appliance that wants to access it? Couldn't I just as easily have a PGP
              • BINGO! I've been reading the comments here wondering when the F someone was going to ask this. If someone runs off with my personal NAS then yeah I'm protected. If someone kicks in my door and logs in via a workstation or using their machine having observed my password this does NOTHING. Perhaps I could have a key secured on my workstation which is kewl but what about my XBMC'd XBOX? My aTV? My just about anything HTPCish that's like an appliance that wants to access it? Couldn't I just as easily have a PGP
            • That makes even less sense. How does the server authenticate the client? If the server just decrypts and serves up the data to any client that connects, what's the use of encrypting? And if the server requires authentication to serve up the data, it could implement access controls just as easily. That leaves you with keeping data secret from other users/the administrators/someone with a warrant. That's what per-user encryption is for.

              The server authenticates clients the same way a traditional setup does,

      • Re: (Score:2)

        by bfields ( 66644 )

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

        If, as the original poster suggests, a large number of people in your organization have to have access to the key for this to work, then it doesn't really add much security--stealing the key off someone may not be any harder than stealing the drive.

        There's really no advantage to having

        • If, as the original poster suggests, a large number of people in your organization have to have access to the key for this to work, then it doesn't really add much security--stealing the key off someone may not be any harder than stealing the drive.

          The server has a single key which uses it encrypt/decrypt the data on the disk. It sends plaintext to the users, or optionally uses some other encrypted protocol to get the data to the clients. The users don't see the hard disk key. Other access controls are n

      • 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

        • When users leave, their keys and passphrases should be deactivated so they can't use them later to gain unauthorized access. This is nontrivial because it implies that every file they've ever had the key for need to be re-encrypted with a new random key, which is a lot of processing. Practically speaking, it's better to assume that anyone who has access to the data has actually copied every available bit of plaintext and key material and plan the threat model and security around that assumption. In light of

  • Suggestions (Score:4, Informative)

    by LuSiDe ( 755770 ) on Monday July 16, 2007 @05: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.

    • Re: (Score:2)

      by Bishop ( 4500 )
      Good recommendations on the hardware and software. A low power AMD X2 3800+ is a fantastic cpu for home servers. An AMD system beats Intel on price, and generally consumes less power at idle. The Intel Core 2 may be faster, but home servers are typically limited by hard drive speeds not cpu.

      On the software side it is hard to recommend OpenBSD for a file server. OpenBSD has traditionally lagged FreeBSD, NetBSD, and Linux when in come to file system access, and it would seem to still be the case. While anecdo
      • Honestly though, for the average user running SMB mounts over a 100bps LAN, the CPU matters fuck-all. Having an AMD X2 3800+ or Intel Core2Duo in your server gets you dicksize bragging rights, a lighter wallet, and not much else.

        I used to run a minimal linux installation - and later OpenBSD - on an old P100 as a home server, and with decent NICs the bottleneck was always either the theoretical LAN speed or SMB. I now run an OpenBSD Samba server on a 600MHz VIA Samuel 2 Mini-ITX system, and that's only so I
  • I looked at a FreeBSD NAS project (don't remember the name though- I've slept since then. FreeNAS?) that looked really neat. Booted from USB key so only data was on the drives. I was impressed what with I ready until I hit the part in the docs where it didn't work with Silicon Image 311x SATA chipsets. The most common fudging chipsets out there. Linux has no problems with that chipset but the FreeBSD has major ones?

    That totally harshed my buzz on the thought of the project and put FreeBSD on the "still not

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close