TimeBandit
Cadet
- Joined
- Jun 7, 2012
- Messages
- 9
This is probably FreeNAS hacking at its finest... This howto is split into 3 sections:
I. Creating the encrypted volume - this is a one-time effort, semi-lengthy, but rock-solid works.
II. Reattaching/reconnecting - due to password entry constraints, manual intervention is required post-boot.
III. Technical Notes and Caveats - stuff put down here that didn't quite fit or as to not bogg-down the howto instructions, yet worthy to note for those that are interested.
At the time of this writing, those of us running the latest, non-beta, version of FreeNAS (aka 8.0.4) do not have native encryption functionality. Therefore, this howto is designed as an experimental 'hack' to leverage the abilities of the host OS (FreeBSD) in an effort to establish and share data on an encrypted volume via the FreeNAS platform.
*** Section I: Creating a new encrypted volume (one-time process) ***
This section is much by actual scenario example, meaning I use real values which may or may not be the same for you. I'll try to underline and/or color such values.
Scenario:
--> I have an existing ZFS raidz array called "pool".
--> I just bought and installed a new IDE drive called ada1.
--> I intend to use this new drive solely as my encrypted volume (no raid redundancy).
--> I will call my encrypted volume "secure".
--> My NAS system is running and I have console root access.
Here we go ...
1.a - Partition the new drive
Nothing odd here, except we are just making one full partition (entire drive).
# gpart create -s gpt /dev/ada1
# gpart add -b 128 -t freebsd-ufs /dev/ada1
# gpart bootcode -b /boot/pmbr-datadisk /dev/ada1
1.b - Initialize/Encrypt the partition
# gbde init /dev/ada1p1 -i
This will bring up a vi editor window where you can make a few config changes.
-> May want to change sector_size = 2048
Save and exit out of that vi session.
You'll now be prompted for a password to protect your partition - this is required, so chose a strong one !!
1.c - Establish the crypt/decrypt virtual device node
# gbde attach /dev/ada1p1
You'll will be prompted for your password.
On success, you should now see a new virtual device node called "ada1p1.bde" in /dev.
This is the crypt/decrypt portal for which to access the encrypted partition, thus making typical read/write actions completely transparent to the underlying encryption state of how data is actually stored on the drive itself.
Note: "ada1p1" is not to be used directly anymore, as it only contains the raw "encrypted" data from now on. So, note to self - ignore it !
1.d - Label and create a typical UFS volume
Now we must label and format the encrypted partion to standard UFS.
For the "-L" option, choose a common name to call your encypted volume (we will be refereing to this name often).
# newfs -U -L secure /dev/ada1p1.bde
You'll notice since we used the "-L", there is now another virtual node created in /dev/ufs named after the lable name we chose (aka secure).
It's basically just a pointer to /dev/ada1p1.bde, but important to point out (pun intended) because this is how FreeNAS will find/access the volume.
Moreover, since this pointer points to the .bde node, all encyption/decryption is totally invisible to FreeNAS and share protocols alike! Can you say "cool"!
1.e - Mount the encrypted node
Finally we need to mount the volume
Create a directory node to attach the mount point - call it the same name as your label above.
Note: /mnt is the location where FreeNAS established volume mount points, so we must adhere to that convention.
# mkdir /mnt/secure
# mount /dev/ufs/secure /mnt/secure
Congrats !! You now have a functional encypted volume - YAY! ... wait - not so fast. Now you must "tell" FreeNAS about it.
1.f - Get UUID
Let's start by getting the UUID of your partition for reference-sake (we will need this info later).
# gpart show -r /dev/ada1 (no ..p1 this time)
You might see somthing like this:
We're after partion #1, and my number was "516e7cb6-6ecf-11d6-8ff8-00022d09712b" (note: remember for a later step)
1.g - Update FreeNAS configuration database (aka PITA !!)
Make FreeNAS aware as to the presence of this new volume. There are four tables that need records added.
But 1st, make a backup copy of the FreeNAS config database !!
# cp /data/freenas-v1.db /data/freenas-v1.db-lastgood
Connect to the FreeNAS config database directly:
# sqlite3 /data/freenas-v1.db
==> Table(1): storage_disk
sqlite3> select max(disk_group_id)+1 from storage_disk;
I was returned a "2" !!yours may differ!!
sqlite3> select max(id)+1 from storage_disk;
I was returned a "4" !!yours may differ!!
Now using the uuid, the label name, these two values, and the drive root node insert the appropriate database record as follows:
sqlite3> INSERT INTO "storage_disk" VALUES('Disabled','Always On','{uuid}516e7cb6-6ecf-11d6-8ff8-00022d09712b',1,'Disabled','Auto','Member of secure ',2,'',4,'ada1');
==> Table(2): storage_diskgroup
sqlite3> select max(id)+1 from storage_diskgroup;
I was returned a "2" !!yours may differ!!
Now using this number, label, and disk_group_id from table 1, insert the appropriate database record as follows:
sqlite3> INSERT INTO "storage_diskgroup" VALUES(2,'secure','',2);
==> Table(3): storage_mountpoint
Now using the physical mount location, and both the disk_group_id and id you got in table 1, insert the appropriate database record as follows:
sqlite3> INSERT INTO "storage_mountpoint" VALUES('/mnt/secure',0,'rw,nfsv4acls',2,'',4);
==> Table(4): storage_volume
Now using the disk_group_id in table 1, and the label name, insert the appropriate database record as follows:
sqlite3> INSERT INTO "storage_volume" VALUES(2,'secure','UFS');
Leave the database session
sqlite3> .exit
Done. At this point, you can go to the WebUI and browse 'storage', and see your new volume name called 'secure'.
Now you are free to use the WebUI to create shares etc...
The only caveat is rebooting (see Section II).
*** Section II: Restoring the Encrypted Volume (after every reboot) ***
Probably the main reason FreeNAS hasn't been eager to offer encrypted volume support is that it seems counter-intuitive when such a platform prides itself on automation. The very nature of data protection is human intervention, so no matter what, booting and re-attaching to the encrypted volume, one must always enter a password manually to retain this security.
Because when booting, FreeNAS isn't expecting such a password prompt,, you'll notice your encrypted volume will be in a 'Degraded' status (offline). This is because it failed to automatically mount. So the following process must be repeated every time you want to access your encrypted volume post-boot, not all the time, just whenever you want to re-establish the encrypted share.
2.a - Attach the crypt/decrypt node
Console (or ssh) into the FreeNAS system, su to root user.
Reattach the unencrypted node:
# gbde attach /dev/ada1p1
Prepare and mount the volume
# mkdir /mnt/secure
mount /dev/ufs/secure /mnt/secure
2.b - Restart Services
Restart service that shared this volume, in my case, just CFIDs:
# service samba restart
Done
*** Section III: Technical Notes and Caveats ***
3.a - WHY do it
I know some of you out there might be asking why implement an encrypted share? The main reason is physical data protection, or loss of positive control of the media for which it's stored on. While there are already proven principles to protect data on a live systems, aka firewalls, ACL, permissions, live encryption, etc... volume encryption offers added security from physical loss, i.e. thief, and unwanted data-recovery. i.e., investigative evidence. So whether you are a business trying to ensure a disgruntled employee doesn't walk out the door with trade company secrets, or you are that paranoid skeptic that doesn't trust the government, aka afraid of Big Brother, there is something to be said for encrypting one's data storage. Furthermore, all those fancy solid-state drives everybody so badly wants prices to come down and capacities to go up (aka SSD)..... did you know these devices intentionally avoid re-writing/over-writing to the same sectors, rational in increasing overall device life-expectancy, thus these are prone to being full of old deleted files/content literally!
3.b - Offline Security
I think it's important to point out the obvious concept about this type of data protection. BDE partition-level encryption only protects offline data resurrection and re-access concerns, i.e., the NAS is stolen/confiscated, thus without the correct password and sector key, the data is virtually unrecoverable without the owner's consent. This is of course predicated on the notion that your NAS was either powered down or the BDE partition disengaged at some point in the exchange in physical possession. Retrospectively, BDE does not protect live file systems from the would-be hacker, intruders, etc... This is because by transparent design, the BDE virtual node always functions as an unencrypted portal into the entire encrypted partition.
3.c - Do it with Grace!
Graceful shutdown/reboot: It might be worth mentioning it would be better to properly disconnect from the encrypted partition as such:
# umount /mnt/secure
# gbde detach /dev/ada1p1
3.d - Do you know where you put the keys?
BDE sector key storage: I don't want to dig beyond the scope of this thread, but my implementation example above initializes the encryption volume without BDE's -L switch in conjunction with the gbde "init" & "attach" commands. These means the sector decryption key is stored at sector 0 (zero) by default. It's wiser to go ahead and implement the -L option which forces BDE to store the key at some arbitrarily random sector location. The disadvantage being that a key-offset file is also generated and then should be kept safe (another volume) in order to capitalize on this added key insurance, because even if you have an encrypted drive in your possession AND you know the password, you still can't access the drive unless you know which one, out of the million or so sectors, the key is on. Furthermore, a key sector looks no different from any other sector, hence the how secure and surmountable a proper BDE implementation can be. How do I know I lost the key to one of my own drives 4 years ago and still haven't broken into my drive. Can we say SOL.
3.e - Convert existing share
We can all agree that Section 1.g of my howto is probably the worst part, not to mention a high propencity to screwing up the entire FreeNAS config database (did you remember to back it up 1st !!). Consistency between the darn ID numbers between the four tables is the biggest issue. While I've tried to use font colors to help delineate how to derive the proper numbers and where they are inserted, I thought there might be a better way. Why not let FreeNAS build those records for you. i.e., configure the new drive as a plain UFS single volume, thus all the appropriate records are entered. Then go back and rebuild the volume as encrypted an simply 'update' a record or two after the fact
Let's say I configured a new UFS share called 'public' on a drive called 'ada1', and I want to remove it and setup an encrypted share called 'private'. Note: I have not tested this, but my thoughts would be as follows:
##### Retro-config strategy ######
umount /mnt/public
swapoff /dev/ada1p1
dd if=/dev/zero of=/dev/ada1p1 bs=1M count=100 <--- clear label meta-data (aka removes 'public' device node out of the /dev/ufs tree)
gbde init /dev/ada1 -i <--- install bde meta-data
gbde attach /dev/ada1
gpart create -s gpt /dev/ada1.bde
gpart add -b 128 -t freebsd-ufs -s 209715 ada1.bde
gpart add -t freebsd-ufs ada1.bde
gpart bootcode -b /boot/pmbr-datadisk /dev/ada1.bde
newfs -U -L private /dev/ada1.bdep2 <--- puts 'private' node in the /dev/ufs tree
Now login to sqlite and 'update' the records to reflect private verses puplic naming.
3.f - Future Feature ??
I sure hope the team reads this howto. Nor do I think it would take much to re-tap into this gbde functionality, seeing as they once had it in previous branches of FreeNAS development. Sure, I would offer to help, but I'm afraid I'm both a little too old-school to try Python, and not enough time to learn a new to me API they have chosen to drive their webUI. I did try, but it's obviously generated py code probably from some greater IDE/API design suite in which case such mods would be trivial at most.
3.g - More Thoughts??
Well, that's enough typing for one day (to include typos). I'll now turn this howto over to open discussion before I entertain any more ideas on the subject.
Have fun learning !
I. Creating the encrypted volume - this is a one-time effort, semi-lengthy, but rock-solid works.
II. Reattaching/reconnecting - due to password entry constraints, manual intervention is required post-boot.
III. Technical Notes and Caveats - stuff put down here that didn't quite fit or as to not bogg-down the howto instructions, yet worthy to note for those that are interested.
At the time of this writing, those of us running the latest, non-beta, version of FreeNAS (aka 8.0.4) do not have native encryption functionality. Therefore, this howto is designed as an experimental 'hack' to leverage the abilities of the host OS (FreeBSD) in an effort to establish and share data on an encrypted volume via the FreeNAS platform.
*** Section I: Creating a new encrypted volume (one-time process) ***
This section is much by actual scenario example, meaning I use real values which may or may not be the same for you. I'll try to underline and/or color such values.
Scenario:
--> I have an existing ZFS raidz array called "pool".
--> I just bought and installed a new IDE drive called ada1.
--> I intend to use this new drive solely as my encrypted volume (no raid redundancy).
--> I will call my encrypted volume "secure".
--> My NAS system is running and I have console root access.
Here we go ...
1.a - Partition the new drive
Nothing odd here, except we are just making one full partition (entire drive).
# gpart create -s gpt /dev/ada1
# gpart add -b 128 -t freebsd-ufs /dev/ada1
# gpart bootcode -b /boot/pmbr-datadisk /dev/ada1
1.b - Initialize/Encrypt the partition
# gbde init /dev/ada1p1 -i
This will bring up a vi editor window where you can make a few config changes.
-> May want to change sector_size = 2048
Save and exit out of that vi session.
You'll now be prompted for a password to protect your partition - this is required, so chose a strong one !!
1.c - Establish the crypt/decrypt virtual device node
# gbde attach /dev/ada1p1
You'll will be prompted for your password.
On success, you should now see a new virtual device node called "ada1p1.bde" in /dev.
This is the crypt/decrypt portal for which to access the encrypted partition, thus making typical read/write actions completely transparent to the underlying encryption state of how data is actually stored on the drive itself.
Note: "ada1p1" is not to be used directly anymore, as it only contains the raw "encrypted" data from now on. So, note to self - ignore it !
1.d - Label and create a typical UFS volume
Now we must label and format the encrypted partion to standard UFS.
For the "-L" option, choose a common name to call your encypted volume (we will be refereing to this name often).
# newfs -U -L secure /dev/ada1p1.bde
You'll notice since we used the "-L", there is now another virtual node created in /dev/ufs named after the lable name we chose (aka secure).
It's basically just a pointer to /dev/ada1p1.bde, but important to point out (pun intended) because this is how FreeNAS will find/access the volume.
Moreover, since this pointer points to the .bde node, all encyption/decryption is totally invisible to FreeNAS and share protocols alike! Can you say "cool"!
1.e - Mount the encrypted node
Finally we need to mount the volume
Create a directory node to attach the mount point - call it the same name as your label above.
Note: /mnt is the location where FreeNAS established volume mount points, so we must adhere to that convention.
# mkdir /mnt/secure
# mount /dev/ufs/secure /mnt/secure
Congrats !! You now have a functional encypted volume - YAY! ... wait - not so fast. Now you must "tell" FreeNAS about it.
1.f - Get UUID
Let's start by getting the UUID of your partition for reference-sake (we will need this info later).
# gpart show -r /dev/ada1 (no ..p1 this time)
You might see somthing like this:
Code:
=> 34 6406077 ada1 GPT (3.1G)
34 94 - free - (47K)
128 6405983 1 516e7cb6-6ecf-11d6-8ff8-00022d09712b (3.1G)
We're after partion #1, and my number was "516e7cb6-6ecf-11d6-8ff8-00022d09712b" (note: remember for a later step)
1.g - Update FreeNAS configuration database (aka PITA !!)
Make FreeNAS aware as to the presence of this new volume. There are four tables that need records added.
But 1st, make a backup copy of the FreeNAS config database !!
# cp /data/freenas-v1.db /data/freenas-v1.db-lastgood
Connect to the FreeNAS config database directly:
# sqlite3 /data/freenas-v1.db
==> Table(1): storage_disk
sqlite3> select max(disk_group_id)+1 from storage_disk;
I was returned a "2" !!yours may differ!!
sqlite3> select max(id)+1 from storage_disk;
I was returned a "4" !!yours may differ!!
Now using the uuid, the label name, these two values, and the drive root node insert the appropriate database record as follows:
sqlite3> INSERT INTO "storage_disk" VALUES('Disabled','Always On','{uuid}516e7cb6-6ecf-11d6-8ff8-00022d09712b',1,'Disabled','Auto','Member of secure ',2,'',4,'ada1');
==> Table(2): storage_diskgroup
sqlite3> select max(id)+1 from storage_diskgroup;
I was returned a "2" !!yours may differ!!
Now using this number, label, and disk_group_id from table 1, insert the appropriate database record as follows:
sqlite3> INSERT INTO "storage_diskgroup" VALUES(2,'secure','',2);
==> Table(3): storage_mountpoint
Now using the physical mount location, and both the disk_group_id and id you got in table 1, insert the appropriate database record as follows:
sqlite3> INSERT INTO "storage_mountpoint" VALUES('/mnt/secure',0,'rw,nfsv4acls',2,'',4);
==> Table(4): storage_volume
Now using the disk_group_id in table 1, and the label name, insert the appropriate database record as follows:
sqlite3> INSERT INTO "storage_volume" VALUES(2,'secure','UFS');
Leave the database session
sqlite3> .exit
Done. At this point, you can go to the WebUI and browse 'storage', and see your new volume name called 'secure'.
Now you are free to use the WebUI to create shares etc...
The only caveat is rebooting (see Section II).
*** Section II: Restoring the Encrypted Volume (after every reboot) ***
Probably the main reason FreeNAS hasn't been eager to offer encrypted volume support is that it seems counter-intuitive when such a platform prides itself on automation. The very nature of data protection is human intervention, so no matter what, booting and re-attaching to the encrypted volume, one must always enter a password manually to retain this security.
Because when booting, FreeNAS isn't expecting such a password prompt,, you'll notice your encrypted volume will be in a 'Degraded' status (offline). This is because it failed to automatically mount. So the following process must be repeated every time you want to access your encrypted volume post-boot, not all the time, just whenever you want to re-establish the encrypted share.
2.a - Attach the crypt/decrypt node
Console (or ssh) into the FreeNAS system, su to root user.
Reattach the unencrypted node:
# gbde attach /dev/ada1p1
Prepare and mount the volume
# mkdir /mnt/secure
mount /dev/ufs/secure /mnt/secure
2.b - Restart Services
Restart service that shared this volume, in my case, just CFIDs:
# service samba restart
Done
*** Section III: Technical Notes and Caveats ***
3.a - WHY do it
I know some of you out there might be asking why implement an encrypted share? The main reason is physical data protection, or loss of positive control of the media for which it's stored on. While there are already proven principles to protect data on a live systems, aka firewalls, ACL, permissions, live encryption, etc... volume encryption offers added security from physical loss, i.e. thief, and unwanted data-recovery. i.e., investigative evidence. So whether you are a business trying to ensure a disgruntled employee doesn't walk out the door with trade company secrets, or you are that paranoid skeptic that doesn't trust the government, aka afraid of Big Brother, there is something to be said for encrypting one's data storage. Furthermore, all those fancy solid-state drives everybody so badly wants prices to come down and capacities to go up (aka SSD)..... did you know these devices intentionally avoid re-writing/over-writing to the same sectors, rational in increasing overall device life-expectancy, thus these are prone to being full of old deleted files/content literally!
3.b - Offline Security
I think it's important to point out the obvious concept about this type of data protection. BDE partition-level encryption only protects offline data resurrection and re-access concerns, i.e., the NAS is stolen/confiscated, thus without the correct password and sector key, the data is virtually unrecoverable without the owner's consent. This is of course predicated on the notion that your NAS was either powered down or the BDE partition disengaged at some point in the exchange in physical possession. Retrospectively, BDE does not protect live file systems from the would-be hacker, intruders, etc... This is because by transparent design, the BDE virtual node always functions as an unencrypted portal into the entire encrypted partition.
3.c - Do it with Grace!
Graceful shutdown/reboot: It might be worth mentioning it would be better to properly disconnect from the encrypted partition as such:
# umount /mnt/secure
# gbde detach /dev/ada1p1
3.d - Do you know where you put the keys?
BDE sector key storage: I don't want to dig beyond the scope of this thread, but my implementation example above initializes the encryption volume without BDE's -L switch in conjunction with the gbde "init" & "attach" commands. These means the sector decryption key is stored at sector 0 (zero) by default. It's wiser to go ahead and implement the -L option which forces BDE to store the key at some arbitrarily random sector location. The disadvantage being that a key-offset file is also generated and then should be kept safe (another volume) in order to capitalize on this added key insurance, because even if you have an encrypted drive in your possession AND you know the password, you still can't access the drive unless you know which one, out of the million or so sectors, the key is on. Furthermore, a key sector looks no different from any other sector, hence the how secure and surmountable a proper BDE implementation can be. How do I know I lost the key to one of my own drives 4 years ago and still haven't broken into my drive. Can we say SOL.
3.e - Convert existing share
We can all agree that Section 1.g of my howto is probably the worst part, not to mention a high propencity to screwing up the entire FreeNAS config database (did you remember to back it up 1st !!). Consistency between the darn ID numbers between the four tables is the biggest issue. While I've tried to use font colors to help delineate how to derive the proper numbers and where they are inserted, I thought there might be a better way. Why not let FreeNAS build those records for you. i.e., configure the new drive as a plain UFS single volume, thus all the appropriate records are entered. Then go back and rebuild the volume as encrypted an simply 'update' a record or two after the fact
Let's say I configured a new UFS share called 'public' on a drive called 'ada1', and I want to remove it and setup an encrypted share called 'private'. Note: I have not tested this, but my thoughts would be as follows:
##### Retro-config strategy ######
umount /mnt/public
swapoff /dev/ada1p1
dd if=/dev/zero of=/dev/ada1p1 bs=1M count=100 <--- clear label meta-data (aka removes 'public' device node out of the /dev/ufs tree)
gbde init /dev/ada1 -i <--- install bde meta-data
gbde attach /dev/ada1
gpart create -s gpt /dev/ada1.bde
gpart add -b 128 -t freebsd-ufs -s 209715 ada1.bde
gpart add -t freebsd-ufs ada1.bde
gpart bootcode -b /boot/pmbr-datadisk /dev/ada1.bde
newfs -U -L private /dev/ada1.bdep2 <--- puts 'private' node in the /dev/ufs tree
Now login to sqlite and 'update' the records to reflect private verses puplic naming.
3.f - Future Feature ??
I sure hope the team reads this howto. Nor do I think it would take much to re-tap into this gbde functionality, seeing as they once had it in previous branches of FreeNAS development. Sure, I would offer to help, but I'm afraid I'm both a little too old-school to try Python, and not enough time to learn a new to me API they have chosen to drive their webUI. I did try, but it's obviously generated py code probably from some greater IDE/API design suite in which case such mods would be trivial at most.
3.g - More Thoughts??
Well, that's enough typing for one day (to include typos). I'll now turn this howto over to open discussion before I entertain any more ideas on the subject.
Have fun learning !
