Here’s a quick writeup on setting up Network Block Device (NBD) drivers to attach an encrypted hard drive to a remote Openwrt Wifi router for disk-level encryption across a network, without needing to store the encryption key on the remote system. Sure, you could use any sort of linux box, but Openwrt allows a low power, compact solution, with an old WIFI router that you might already have lying around. All the cool kids will want to dedicate a Raspberry Pi for the purpose but the Pi doesn’t come with Wifi, an enclosure, and a power supply, and you probably don’t already have one in your junk pile. Sometimes it’s tough being cool, or so I’m told.

Background:

(When in doubt, encrypt. When not in doubt, get in doubt.)

I wanted to have a remote backup solution based on a simple linux box (with a hard drive). For privacy/security I chose to use disk-level encryption. To lower power consumption I used an Openwrt (http://openwrt.org) box with an attached 2.5″ drive. Using physically small hardware also allows the setup to be somewhat discrete, which can be useful given that it provides some protection against one of the failure modes of a backup: i.e., theft or other types of seizure.

What I ended up with was an old Netgear WGT634U router running Openwrt, with an attached USB enclosure containing a 2.5″ (laptop style) hard drive.

Now, here’s the interesting part: to avoid having to store the hard drive encryption key on the actual backup hardware itself, I used Network Block Device (NBD) drivers so that my host machine could treat the disk sectors on the remote backup machine as if they belonged to a local disk on the host machine. In this way, only the host machine needs the disk encryption keys; the remote backup machine only ever sees encrypted data blocks being read from or written to the backup drive.

Well, why is all this a good thing? (Or skip ahead a few paragraphs if you don’t need to be sold on remote backups generally, and encrypted backups in particular.)

So, for starters, backup is generally a good thing. Even local backup is good but backup at a remote location is better. This remote location could be a different room in the house, the attic, a barn, somebody else’s house across town, your holiday cottage in the Hamptons. (The more remote the better, within reason, for disaster recovery.) A local hard drive backup is handy for sure but it doesn’t protect against some scenarios, such as fire, flood, earthquake, theft or other seizures.

A downside of remote backup is that you lose control over some aspects of the setup. Even assuming you trust the normal users of the remote location with all your unencrypted banking/medical/personal secrets, you may also end up trusting the burglar who steals the computer equipment. So, encryption is also good.

Disk-level vs. file-level encryption:

I prefer to use disk-level encryption instead of deciding on a file-by-file basis what needs to be decrypted. This lets me setup encryption once and then forget about it, except at system bootup where I’ll need to supply the disk encryption key. It also lets me use simple tools like rsync to copy only recently-changed files across a (potentially) slow internet connection.

The downside of disk-level encryption is that the remote backup host needs to know the disk encryption key to be able to read/write the files to its local disk. It’s not the end of the world, but it’s an extra level of nuisance and means that the disk encryption key needs to be supplied each time the backup machine is booted. There’s also the risk that if the machine is compromised, the backup disk is there, mounted on the system in all its unencrypted glory, just waiting to give up your files.

So, that would be bad.

One fix for this would be to return to file-level encryption, and use OpenPGP/GnuPG, or other conventional encryption, to secure the files being sent to the remote system. Sure, that would fix the problem of the remote end needing to know the key, and mounting unencrypted filesystems from encrypted disk, but then we’re back to using file-level encryption which is a bit of a hassle. Besides, there’s another way.

Using Network Block Device (NBD) drivers:

 

The Linux NBD drivers allow the creation of a virtual hard drive on the local machine which is really the physical hard drive on the remote machine. Yeah, so? Well, now only the host machine needs to know the disk encryption key because it’s accessing /dev/nbd0 as if it’s a local physical hard drive, even though the data is being packaged up (in its encrypted form) over the network to the remote machine. The remote backup host just sees encrypted blocks of data being read to/from its hard drive. Even if the remote host is compromised it doesn’t even have any unencrypted data to give up, or even an encryption key; it nevers sees any keys or unencrypted data.

HOWTO:

I’m using a Netgear WGT634U router. It’s a spare router I’ve had lying around since I upgraded to the more powerful Netgear WNDR3800 as my main router. You can use whatever Openwrt box you might have lying around or grab an old router and head over to http://openwrt.org to see if (and how to) you can install Openwrt. (I’m not going to delve into how to get openwrt up and running; there’s plenty of other places that will do a better job of that.)

My WGT634U is running a slightly old version of Openwrt, Backfire (10.03.1, r29592). The router probably doesn’t have the oomph to run the most recent editions but the old versions seem to be perfectly stable and usable. (During the recent OpenSSL heartbleed vulnerability kerfuffle I was gratified to learn that the openwrt version was old enough to not be affected by heartbleed.)

Make sure your system has the ndb drivers. Mine didn’t by default and I had to go through the process of reconfiguring and rebuilding the whole openwrt system. After several failed attempts to get this to work, I realized that the process had already gone far enough to create the /usr/sbin/ndb-server binary so I just copied it to my vanilla openwrt system and that seemed to work just fine. (But don’t ask me to send you a copy because I’ll just die of facepalming; the population that is security minded enough to use ndb for whole-disk remote encryption shouldn’t have a high overlap with the please-send-me-a-binary-file-to-run crowd.)

Once you’ve got ndb-server on the remote host, check you’ve got nbd-client on your host machine (on Ubuntu: apt-get install nbd-client).

Then, however you want to do it, create a partition on the USB hard drive to use for the backup partition, or you could use the whole device instead of partitioning. (Use whatever tools you like for this, and choose your partitioning scheme. I use fdisk, and usually create a small vfat partition as the first primary partition and put a couple of harmless files in there so the disk will seem somewhat normal if plugged into a Windows machine. I then create another primary partition, using the rest of the disk space for the encrypted partition.)

Once you’ve created the backup partition on the USB drive, on your remote backup host:

nbd-server 2001 /dev/sda2 (Where 2001 is an arbitrary TCP port, and /dev/sda2 is the local USB-attached hard drive partition on my openwrt box.)

On your local machine:

(modprobe nbd, if necessary; for example on openSuse)

nbd-client wgt8 2001 /dev/nbd0 (Where 2001 is the TCP port on the server machine, and /dev/nbd0 is one of the available nbd devices)

Non-encrypted test; in case you need to fall back to a simpler test case:

mkfs.ext4 /dev/nbd0 (To create an ext4 filesystem on the virtual ndb0 device.)

mount /dev/nbd0 /mnt9

umount /mnt9

nbd-client -d /dev/nbd0 (To disconnect the nbd device, but doesn’t remove the actual /dev/nbd0 node itself.)

Using encryption:

cryptsetup -c twofish-cbc-essiv:sha256 -s 256 create nbd_ST847364_2 /dev/nbd0

(Creates dm-crypt device, /dev/mapper/nbd_ST847364_2 (I like to name my devices by disk ID), attached to /dev/nbd0, attached to the disk on the remote machine. You’ll need to supply an encryption password.)

mkfs.ext4 /dev/mapper/nbd_ST847364_2 (To create an ext4 filesystem on the virtual ndb0 device. NOTE: not on /dev/nbd0 directly!)

mount /dev/mapper/nbd_ST847364_2 /mnt9 (Mount it someplace.)

Now try creating a couple of files and then unmount the whole thing and try it again to check it worked:

Unmounting: umount /mnt9

cryptsetup remove nbd_ST847364_2

nbd-client -d /dev/nbd0

Troubleshooting:

• Check your firewall rules in case they’re blocking access.
• Depending on your host system you might need to make sure the nbd module is loaded (modprobe nbd).
• Check you haven’t mistyped ‘nbd’ as ‘ndb’! I did this a bunch, probably due to having databases on my mind too much.
• If you’re powering the backup hard drive from the router USB port directly, it might be taking too much power, causing unpredictable glitchyness. Try an external power supply if this seems to be the case, in particular if you’re having trouble booting the router with a hard drive attached.I had this problem, and even tried the published hack for increasing the available USB power (https://forum.openwrt.org/viewtopic.php?id=14082), but ended up using a separate power supply for the external hard drive.

For extra cool:

• My setup assumes a simple wired ethernet connection, but it would certainly be straightforward to use the Wifi interface instead so no physical network access would be needed. This would allow the remote box to be in a separate structure, perhaps a friend’s apartment/house, or just a barn or other building within Wifi range.
• For extra security, don’t leave the device in an obvious place. It’s small enough to keep out of sight in a discreet location. Just make sure there’s adequare ventilation for the small amount of heat generated.
• Okay, this isn’t really extra. You should be running some kind of firewall on your remote backup host. Exactly how you have it configured will depend on whether you’ve got the host attached via ethernet or Wifi, or whether you’ve got a VPN connection.
• Instead of a spinning hard drive, you could use an SSD or even a hefty USB flash drive for backup storage if the capacity is enough for your needs. Generally people have an old spare drive sitting around around that is bigger (and cheaper) than whatever fancy new solid-state drive they might buy for a project.
• It’s recommended to write your encrypted partition with random data before formatting it the first time. If not done, it will be obvious which disk blocks contain data and which don’t. It’s a minor refinement but also a low-cost one, and is generally good practice when dealing with encrypted partitions. (You will probably find this easier/faster/better to do on a Desktop-style linux box rather than the Openwrt machine, which lacks computational power and perhaps entropy.)
• Use a plug-in timer so that the remote location wakes up in the middle of the night, pings the primary location to signal it to start a backup/sync sequence.
• Depending on your hardware, you might be able to use hdparm to spindown an inactive USB drive. This command worked for me, well except it didn’t because it only worked when the hard drive was directly connected on a SATA interface, but not when it was in its USB enclosure. hdparm -S60 /dev/sdX