I've posted about this elsewhere but with the forum reorg this seems a better place. Has anyone considered attempting full volume encryption of the unRAID server or the data disks? Something along the lines of TrueCrypt style encryption. This would require a password at boot-up obviously but would prevent stealing of the data from the server when the disks were at rest. My concern is primarily someone taking my server and benefiting from the data on-board. Obviously this would do nothing for an intruder on my network but that's okay as I do not wish to fool with getting my various pieces of hardware access to the server - for HTPC in particular this is a hassle.

 

Thoughts?

 

TrueCrypt does appear to have console packages for 32 and 64bit Linux. Unfortunately I'm not sure how I would set this up for either of my servers. This also brings up questions on how you would add disks into the server and get them encrypted, this could force you to do additional manual labor. Likewise swapping in a larger disk for a replacement could be a problem - I think. Any other potential gotchas?

I've posted about this elsewhere but with the forum reorg this seems a better place. Has anyone considered attempting full volume encryption of the unRAID server or the data disks? Something along the lines of TrueCrypt style encryption. This would require a password at boot-up obviously but would prevent stealing of the data from the server when the disks were at rest. My concern is primarily someone taking my server and benefiting from the data on-board. Obviously this would do nothing for an intruder on my network but that's okay as I do not wish to fool with getting my various pieces of hardware access to the server - for HTPC in particular this is a hassle.

 

Thoughts?

 

TrueCrypt does appear to have console packages for 32 and 64bit Linux. Unfortunately I'm not sure how I would set this up for either of my servers. This also brings up questions on how you would add disks into the server and get them encrypted, this could force you to do additional manual labor. Likewise swapping in a larger disk for a replacement could be a problem - I think. Any other potential gotchas?

Have you looked at encfs, a userland encryption system.

See it here: http://www.arg0.net/encfs and here: http://www.arg0.net/encfsintro

 

It allows you to do what I think you are asking for.

 

You run it with two parameters, an empty directory to use as a mount-point for the encrypted contents, and an empty directory that will hold the clear-text when accessed through the encfs file system.

 

There is a package for encfs in the unMENU package manager so installation could not be easier.  

You can install it with two button clicks. One to download it and the support libraries, the other to install it.

 

You do need to invoke enfcs on the command line when you first start the server to give it your password.  

When you re-invoke it on the same directories, you need to give it the same password.  It holds the encrypted password in a hidden file in the encrypted directory.

 

A sample session is show here:

first I create two directories.  They can be any names. One will be used as the mount-point, the other to hold the encrypted files.:

root@Tower:/tmp# mkdir joe
root@Tower:/tmp# mkdir joe-secret

then, I invoke encfs with those two directories as arguments (you must use full paths to the directories):

root@Tower:/tmp# encfs /tmp/joe-secret /tmp/joe

It responds with:

Creating new encrypted volume.

Please choose from one of the following options:

enter "x" for expert configuration mode,

enter "p" for pre-configured paranoia mode,

anything else, or an empty line will select standard mode.

?>

 

Standard configuration selected.

 

Configuration finished.  The filesystem to be created has

the following properties:

Filesystem cipher: "ssl/aes", version 3:0:2

Filename encoding: "nameio/block", version 3:0:1

Key Size: 192 bits

Block Size: 1024 bytes

Each file contains 8 byte header with unique IV data.

Filenames encoded using IV chaining mode.

File holes passed through to ciphertext.

 

Now you will need to enter a password for your filesystem.

You will need to remember this password, as there is absolutely

no recovery mechanism.  However, the password can be changed

later using encfsctl.

 

New Encfs Password:

Verify Encfs Password:

 

I typed my password, and then re-typed my password.

 

Now I can do whatever I like in the non-encrypted directory, create files, directories etc.

To start with, there is nothing in the directories.

root@Tower:/tmp# ls -l joe*

joe:

total 0

 

joe-secret:

total 0

I'll copy my config/go file to the plaintext directory

root@Tower:/tmp# cd joe

root@Tower:/tmp/joe# cp /boot/config/go .

root@Tower:/tmp/joe# ls -l

total 4

-rwxr-xr-x 1 root root 612 Jan  9 21:11 go*

 

If I look in the encrypted directory I see this:

root@Tower:/tmp/joe# cd /tmp/joe-secret

root@Tower:/tmp/joe-secret# ls -l

total 4

-rwxr-xr-x 1 root root 620 Jan  9 21:11 MmBoBDX,AcYc5CSCGGXOcyt8*

root@Tower:/tmp/joe-secret# od -c M* | sed 5q

0000000   : 360 346 201 022 023  \r   4 206 005 033 250 201 004   Q   W

0000020 230 216 326 230 365 322   L 273 367   `   W 266     377   h   3

0000040 337   Y  \n 313   Q   . 206   e   0   E 331 016 267 016 354   q

0000060 251   y 256   !   L   N 372   = 346 236 210 373 373 323 004 244

0000100 373 031   [   U 220 222 335 226   p 340  \t 373 334   = 336 337

 

while everything in the plaintext directory looks quite normal

root@Tower:/tmp/joe-secret# cd ../joe

root@Tower:/tmp/joe# ls -l

total 4

-rwxr-xr-x 1 root root 612 Jan  9 21:11 go*

root@Tower:/tmp/joe# cat go | sed 5q

#!/bin/bash

# Start the Management Utility

ulimit -n 20000;/usr/local/sbin/emhttp &

PATH=$PATH:/boot/custom/bin

#cache_dirs -w -B -e Pictures -e data -d 3

 

You can see the fuser mount by typing

mount

encfs on /tmp/joe type fuse.encfs (rw,nosuid,nodev,default_permissions)

 

You can un-mount it by typing

fusermount -u /tmp/joe

 

listing the two directories now shows this:

root@Tower:/tmp# ls /tmp/joe*

/tmp/joe:

 

/tmp/joe-secret:

MmBoBDX,AcYc5CSCGGXOcyt8*

To gain access once more you just type the same command as you did the first time:

root@Tower:/tmp# encfs /tmp/joe-secret /tmp/joe

EncFS Password:

 

It will prompt for the password once more.   and you are able to get to the files once more through the plaintext directory.

 

Only issue at all, if you create the directories for it to use on the unRAID protected disks, it will be necessary to un-mount the encrypted file system before you can stop the unRAID array.  The encfs will keep the unRAID array from being stopped otherwise.

 

This will be easier once we get pre-unraid-stop events in unRAID 5.0, but as long as you remember to un-mount the encrypted file system your files should be safe.

 

From the encfs manual page:

Nobody should need to warn you that you should keep backups of important data. Storing data in an encrypted filesystem makes it even more important that you keep backups because it complicates the possibility of data recovery! I can’t remember the last time I had to dig out my backups, and I use encfs everyday. But bugs have been found in the past, so I try and remember to make backups periodically even though I don’t expect to ever use them (at least not until my hard drive fails).

 

Note about backups: In order to decrypt a file, two things are required (besides the encrypted file data): the password, and the “.encfs6” control file at the top level of the raw encfs filesystem.   You should check your backups periodically, otherwise you don't know if they are any good.

 

The control file contains the filesystem parameters, in addition to encrypted key data which is different for every filesystem.. You need both the password and this control file in order to access the data. If you loose either one, there isn’t anything I can do to help. Your password should be considered important data. If you’re not sure you can remember it, then back it up (in a secure manner – either in a password keychain program, or in a secure location).

 

I hope this helps...

 

Joe L.

 

Have you looked at encfs, a userland encryption system.

See it here: http://www.arg0.net/encfs and here: http://www.arg0.net/encfsintro

 

It allows you to do what I think you are asking for.

 

 

Thanks for the clear write up. Can this go onto an unraid share instead of an actual disk? This way it could grow larger than the size of a single disk.

 

Also, how could I add the unmount command to a shutdown script? I have the ups package setup to shut the server down and it would be essential for this to occur in the event of a long power cut

 

thanks again

Will it be possible to put the encryption on an unraid share rather than a specific disk?

 

thanks

Will it be possible to put the encryption on an unraid share rather than a specific disk?

 

thanks

I think somebody else said you could.  Obviously, no one encrypted file could span a physical disk, and the control files it creates to hold the encryption key would only be on one disk. 

 

I've never tried it.  Again you'll need to stop the added encryption file system before attempting to stop the unRAID array.

 

Joe L.

Yes you can, with all the caveats Joe L. pointed out above and appreciate you'll see a hit in performance for the double layer of fuse if going via user shares.