*New 11.3 series Release:
2019-10-05: XigmaNAS - released, 11.2 series are soon unsupported!

*New 12.0 series Release:
2019-10-05: XigmaNAS - released!

*New 11.2 series Release:
2019-09-23: XigmaNAS - released!

We really need "Your" help on XigmaNAS https://translations.launchpad.net/xigmanas translations. Please help today!

Producing and hosting XigmaNAS costs money. Please consider donating for our project so that we can continue to offer you the best.
We need your support! eg: PAYPAL

Simple guide to creating encrypted, thin provisioned zvol's easily mounted from windows or linux desktop

Encrypting information and help
Forum rules
Set-Up GuideFAQsForum Rules
Post Reply
Posts: 4
Joined: 29 Nov 2014 23:22
Status: Offline

Simple guide to creating encrypted, thin provisioned zvol's easily mounted from windows or linux desktop


Post by nomizfs » 04 Apr 2015 19:03

Foreword: Most server-side encryption solutions for ZFS based fileserver are based on FDE, ie full disk encryption of the ZFS pool, where the encryption layer sits between the physical disk and the ZFS filesystem layer. This is generally a very bad idea, as it entails cumbersome boot scripts that must be executed before the zpool is imported, and is also very prone to disastrous consequences and catastrophic data loss, especially in the case of disk failure and other low-level ZFS events.

Using encrypted zvol's on top of the ZFS layer is a much more elegant approach, and gives all the same features as FDE as zvols can easily be exported as standard block devices over iscsi etc. More ramblings about this is found in the latter sections of this guide.

This guide is divided into several sections, the first section describes the minimal, most simple solution, second section describes integrating keepass for key and password management. In the 3rd and 4th sections i wrote some thoughts and ramblings about pros and cons of this, and some thoughts about future improvements. Please help improve and give feedback, especially concerning the sudo issue.

Please note this guide creates geli encrypted zvol with passphrase only, and no keyfile. The reason for this is explained in sections 2 and forward.

This guide assumes user has passwordless SSH access to the fileserver, using ssh keys in /user/.ssh/authorized_keys. This is not mandatory, but provides a more user friendly approach. set up SSH key based authentication and optionally use putty pageant key agent. (putty key agent needs you ssh secret keyfile in .ppk format, find a guide on the web on how to create one by importing your key into PUTTYgen and exporting in .ppk format, then load the key into pageant).

There are many guides on the net on how to do this, but remember the standard linux ssh-copy-id will not work because that script assumes the destination server uses bash, and nas4free uses sh, so you will need to manually add the key to .ssh/authorized_keys.

remember to set the correct permissions for .ssh and authorized_keys (see http://www.openssh.com/faq.html#3.14 )

Once you have a working SSH key based login setup, we can move forward:

Section 1: Creating a remotely mountable encrypted zvol with optional AES-NI hardware encryption support:

you will need SSH access to nas4free, and root password.

1. Enable SSH service in Services|SSH

2. Create zvol in Disks|ZFS|Volumes|Volume. specify maximum size, leave compression off, and optionally enable thin provisioning. In this example i will call the zvol encrypted_zvol

3. We assume user has a existing CIFS/SMB share of /mnt/pool/share. The encrypted vol will be mounted on /mnt/pool/share/encrypted_zvol, and thus visible as a directory under the CIFS/SMB share. Login via SSH, create the mount point for the zvol, and then switch to root:

Code: Select all

[user@nas4free ~]$ mkdir -p /mnt/pool/share/encrypted_zvol
[user@nas4free ~]$ sh -
4. Initialize the zvol provider with 4K sectorsize:

Code: Select all

nas4free: ~ # geli init -s 4096 /dev/zvol/pool/encrypted_zvol
Here you provide a passphrase. Again, in later sections we will integrate keppass into this process, providing access without manually typing a passphrase. keeppass will provide the function of encryption key and passphrase management, instead of geli. If you don't plan to use keeppass, use a passphrase generator to generate a long random passphrase here, which you can write down on a piece of paper and store somewhere etc.

If you plan to use keeppass (recommended) you can create an entry and with keeppass integrated password generator create a very long password that uses uppercase, lowercase, digits, underline and special characters. make the password long (say 64 chars or more) and save the entry in keeppass. then use copy / paste to provide geli with the password.

5. (OPTIONAL) check if your CPU supports intel AES New Instructions based hardware accelerated encryption, and enable support for it in nas4free:

nas4free: ~ #dmesg | grep AESNI

if you get an output, your CPU supports AES-NI and you can enable it in System|Advanced|loader.conf

Variable: aesni_load
Value: YES

confirm hardware encryption is enabled by rebooting server and typing geli list after you completed the steps #6 below. If support is enable and working it will state Crypto: hardware. If not, it will state Crypto: software.

6. Attach the geli provider, create a UFS filesystem on it, and mount it. make sure it becomes visible on your share, and copy some text files to it, and try opening them, to verify it's working correctly.

Code: Select all

nas4free: ~ # geli attach /dev/zvol/pool/encrypted_zvol
nas4free: ~ # newfs /dev/zvol/pool/encrypted_zvol.eli
nas4free: ~ # mount /dev/zvol/pool/encrypted_zvol.eli /mnt/pool/share/encrypted_zvol/
7. Detach and unmount the zvol, and switch back to user:

Code: Select all

nas4free: ~ # umount /mnt/pool/share/encrypted_zvol
nas4free: ~ # geli detach /dev/zvol/pool/encrypted_zvol.eli
nas4free: ~ # exit
8. Create mounting and unmounting scripts in your user home dir, make them executable and then logout:

Code: Select all

[user@nas4free ~]$ mkdir -p .scripts
[user@nas4free ~]$ cd .scripts
[user@nas4free ~/.scripts]$ nano -w mount_encrypted_zvol.sh
copy the following code and save (ctrl+X, yes)

Code: Select all

echo "enter root password and geli passphrase" & su root -c 'geli attach /dev/zvol/pool/encrypted_zvol && mount /dev/zvol/pool/encrypted_zvol.eli /mnt/pool/share/encrypted_zvol'

Code: Select all

[user@nas4free ~/.scripts]$ nano -w unmount_encrypted_zvol.sh

Code: Select all

echo "enter root password" & su root -c 'umount /mnt/pool/share/encrypted_zvol && geli detach /dev/zvol/pool/encrypted_zvol.eli'

Code: Select all

[user@nas4free ~/.scripts] chmod +x mount_encrypted_zvol.sh
[user@nas4free ~/.scripts] chmod +x unmount_encrypted_zvol.sh
[user@nas4free ~/.scripts] exit
9. In putty, create mounting and unmounting sessions, with the following properties:

mounting session:
  • SSH - Remote command: .scripts/mount_encrypted_zvol.sh
  • SSH - Auth - Enable agent forwarding
  • Window - Behaviour - Window title: mount encrypted zvol (optional, for keepass autotype and global hotkey support)
  • Session - Host name: your nas4free server ip
save session as 'mount encrypted zvol'

unmounting session:

same as above but with Remote command: .scripts/unmount_encrypted_zvol.sh, Window title: unmount encrypted zvol

save session as 'unmount encrypted zvol'

10. Create putty shortcuts for both sessions, and save them in a directory on the desktop or wherever: (in my screenshot above i used the bitlocker icons found in \windows\system32 for extra leetness, and created a toolbar to access the links):

in C:\Program Files (x86)\PuTTY, right click putty.exe and create shortcut (twice). rename the shortcuts to 'mount encrypted zvol' and 'unmount encrypted zvol' respectively. right click the shortcuts, preferences, and add the target:

"C:\Program Files (x86)\PuTTY\putty.exe" -load "mount encrypted zvol" to the mounting link, and "C:\Program Files (x86)\PuTTY\putty.exe" -load "unmount encrypted zvol" to the unmounting link.

11. Testing the scripts

You can now test running the mounting link, it should open up a SSH window asking for root password, geli passphrase, and then exit. Open an additional SSH session and verify the scripts are working with the mount command.
When everything is fine it's time to add autotype and hotkey support in keepass:

Section 2: Adding keepass auto-type and global hotkey support:

run the mounting script, and before typing root password and geli passphrase, alt-tab to keepass, edit the geli passphrase entry, in the Auto-type tab add a custom sequence for specific windows: from the dropdown box choose the putty window titled 'mount encrypted zvol' and define the sequence as {Password}{ENTER}

now you could also add a keepass entry for the root password, and define a custom sequence to that too. as the mounting script uses both root password and geli passphrase, both using the same titled putty windows, using the keepass global hotkey (CTRL+ALT+A) would popup a selection window where u can simply doubleclick first the root password then the geli passphrase.

the unmounting script only uses root password, and so using the global hotkey would just unmount and exit.

Further integration of keepass:

download and install the Keeagent and Winkee plugins from http://keepass.info/plugins.html

I haven't had time to test the Keeagent plugin but i plan to, and the Winkee plugin would integrate keepass database with windows login authentication, basically allowing the desktop user to control the zvol without having to type anykind of password, except his windows login credentials. (even omitting the need for root password at the cost of some security, as discussed below in the ramblings)

Section 3: Options for omitting the need for root password:

Option #1: create a SSH key based login for root, and edit the putty sessions to login as root instead of user. On embedded nas4free install the root dir is not persistent, so you need to create a directory for you root SSH authorized_keys on the zfs pool or some other persistent storage, and mount it to /root/.ssh:

"zfs set mountpoint=/root/.ssh poolname/datasetname/root/.ssh"

Option #2: It's never advisable to be able to login as root for user tasks, and the above root SSH key based example would only be viable in a scenario where root and user is the same person working on a local network. A more elegant way would be to allow user to use the mount command, which is done by adding vfs.usermount=1 to System|Advanced|sysctl.conf

however, in order to allow user to attach a geli provider, from what i've gathered it could be done using special permissions in the sudoers file. (I've gathered this much based on this post: https://forums.freebsd.org/threads/geli ... ser.19932/ )

the poster there does not expand on exactly how to configure sudo to allow geli operations, and also, sudo is not included in nas4free, so here is where i would ask for any tips or workarounds:

one way would be to have a startup script to download and install sudo, and maybe from persistent storage apply a sudoers file containing the needed permissions for geli operations. this however would still require 2 passwords, user password and geli passphrase.

if anyone has a more elegant solution for this i would be happy to edit this guide, and use it myself, all tips welcome!

Section 4: Useless Ramblings:

zvol's are great, and with the coming of 10gbit ethernet and more, running diskless server and workstation nodes booted from zvols over iscsi becomes a more and more viable solution for large and small infrastructures. (for example latest intel broadwell-D SoC chipset now has 2 x 10 gbit ethernet controllers integrated in the chipset, motherboard manufacturers need only slap a couple of connectors on the PCB, see http://www.servethehome.com/intel-xeon- ... -x552-nic/ and http://www.servethehome.com/broadwell-d ... formation/ )

why encryption: most ppl tend to think that encryption is used to hide some data, and if you have nothing that needs hiding, it's useless. I disagree. Encryption provides a equally if not more important aspect to your data, ie it provides control of your data. Just as you have the right to invoke the 5th when interrogated by the authorities, and just as you have the personal choice of what to say or not to say to whom, encryption provides that same control to your data, regardless if it is secret or not. This is an extremely important aspect of IT security, often completely overlooked.

One of the biggest issues with traditional FDE based workstations and servers has always been that they can't be booted without providing the encryption key physically on location, they can't be booted and rebooted remotely, and the key management is done by the end-user which opens a gazillion potential security risks (secretaries using the same passwords at home, for email, lost or stolen usb tokens etc)

also simple usability issues like having to manually type a long passphrase in a preboot environment, not being able to copy/paste the passphrase. These kinds of issues are killers, because security is just as much about real world usability in daily routines as it is about key and password management.

in a corporate environment, diskless workstations booted over 10GB ethernet over iscsi, and backed by encrypted zvol's with hardware AES-NI support is a major step forward. It allows for the complete control of employee data by the administrator, the ability to do periodic snapshots of each end users complete OS, mitigating such threats and cryptolocker malware etc. For example Administrator can script the ZFS server to attach the encrypted zvol's at 8:55 am and then boot emplyee workstations remotely via WoL for example, filtering access based on MAC address, dramatically reducing the risk of unauthorized access by attackers to company data outside of normal work hours, the risk of physical data theft etc.

Integrating keepass with windows login credentials, while the keepass database exists on the remote zvol, and end user only has to use one password and id-card to access workstation, while keepass autotype provides access to vpn, email, encrypted data shares, bank login with OTP support, that represents real world usability. after logging into the workstation, normal end users should never have to type any additional passwords, and keepass represents a real viable solution to integrate everything this way, providing strong authentication to all various services without the risk presented by ordinary users due to weak passwords, stolen or lost usb keys etc.

without real world usability that's dead easy for even the most novice end user, we can never have real world IT security. keepass global hotkey is a small step in this direction. manually typing passwords should have been a thing of the past along time ago. With smartphones everywhere, we need a linux PAM module that instead of asking for password/key, renders a QR code on the screen which is the challenge, the user hold up his smartphone to the screen, the smartphone camera reads the challenge and sends the matching response over tcp/ip. Add OTP to that and we're getting somewhere. No manual typing should be used in authentication in this day and age.

That's it.. so many ramblings :) Again i appreciate any tips on how to improve the guide, and comments etc.scripts
You do not have the required permissions to view the files attached to this post.

Post Reply

Return to “Encryption”