bonienl Posted December 9, 2017 Share Posted December 9, 2017 unRAID 6.4 introduces encrypted volumes and allows individual disks to be protected by encryption. The passphrase or keyfile which is used to unlock encryption is not permanently stored on the system itself, this means that upon a system start one has to re-enter the passphrase or re-select the keyfile. Until then the array can not start and the GUI will report a "missing key". But what if we want to auto-start the array and not keep a local copy on the system itself? It kind of defeats the protection scheme to store a local copy, i.e. when your system get stolen, you don't want to include the keys to allow access. The solution I have come up is to download the keyfile during startup from a different system in my local network which is in a different part of the house. In my case I am using an arbitrary .png file, but you could also store a passphrase and have this copied over. In my go file I added the following lines to download the keyfile from a remote SMB share before starting emhttp. # auto unlock array mkdir -p /unlock mount -t cifs -o user=name,password=password,iocharset=utf8 //192.168.1.123/index /unlock cp -f /unlock/#/some.png /root/keyfile umount /unlock rm -r /unlock Of course the remote share must be accessible when the system starts and surely this approach can be cracked, but it is definitely safer than just keeping a local copy of the keyfile on the unRAID server itself. Remember that once the array is started, the local keyfile may be deleted if you really don't want to keep the key while the system is operational. Perhaps my idea is useful for others wanting to do something similar 3 1 1 Quote Link to comment
beckp Posted January 25, 2018 Share Posted January 25, 2018 What a great suggestion. I think I am going to try this on my next build. I am going to use an inexpensive Raspberry Pi Zero W loaded with DietPi OS as my remote server. It's non-obtrusive size can be placed anywhere within wi-fi distance. Technically my "DietKeyLimePi" only needs to be available at boot up time. DietPI is an extremely lightweight Debian Jessie OS. It can be configured to be a headless samba server and have SSH capability. Power consumption is under a watt at idle. Quote Link to comment
SpaceInvaderOne Posted April 1, 2018 Share Posted April 1, 2018 gave me an idea to use wget and ftps Quote Link to comment
jbrodriguez Posted April 1, 2018 Share Posted April 1, 2018 right, what @gridrunner said, would it be possible to just wget/curl a passphrase (in the local network) instead of getting it from a smb share ? Quote Link to comment
bonienl Posted April 2, 2018 Author Share Posted April 2, 2018 A small variation if you want the key to be not locally present on the system when operational, the key is only needed during startup of the array. In the go file the following is included before starting emhttp. # auto unlock array install -D /boot/custom/bin/fetch_key /usr/local/emhttp/webGui/event/starting/fetch_key install -D /boot/custom/bin/delete_key /usr/local/emhttp/webGui/event/started/delete_key install -D /boot/custom/bin/fetch_key /usr/local/emhttp/webGui/event/stopped/fetch_key # start webGUI /usr/local/sbin/emhttp & The above makes use of the built-in event system of unRAID. These events are created: starting : this event is called before the array is started and is used to fetch the key from a remote source started : this event is called after the array is fully operational and is used to delete the key locally. stopped : this event is called after the array is stopped and is used to fetch the key again from a remote source The script "fetch_key" can be any method to obtain the key remotely, e.g. using a mount method or a FTP (wget) method as explained in the video of @gridrunner The script "delete_key" is a simple file to delete the key locally. fetch_key #!/bin/bash if [[ ! -e /root/keyfile ]]; then mkdir -p /unlock mount -t cifs -o user=name,password=password,iocharset=utf8 //192.168.1.99/index /unlock cp -f /unlock/somefile.png /root/keyfile umount /unlock rm -r /unlock fi delete_key #!/bin/bash rm -f /root/keyfile You can start and stop the array as usual, and the key will be automatically fetched each time, provided that the remote service is up and running. The files "fetch_key" and "delete_key" need to be stored on your flash device. I've created the folder /custom/bin to hold my custom scripts, but one is free to choose their own source folder, please update the lines in the go file accordingly. 1 Quote Link to comment
ijuarez Posted April 6, 2018 Share Posted April 6, 2018 (edited) On 4/2/2018 at 8:01 AM, bonienl said: A small variation if you want the key to be not locally present on the system when operational, the key is only needed during startup of the array. In the go file the following is included before starting emhttp. # auto unlock array mkdir -p /usr/local/emhttp/webGui/event/starting mkdir -p /usr/local/emhttp/webGui/event/started mkdir -p /usr/local/emhttp/webGui/event/stopped cp -f /boot/custom/bin/fetch_key /usr/local/emhttp/webGui/event/starting cp -f /boot/custom/bin/delete_key /usr/local/emhttp/webGui/event/started cp -f /boot/custom/bin/fetch_key /usr/local/emhttp/webGui/event/stopped # start webGUI /usr/local/sbin/emhttp & The above makes use of the built-in event system of unRAID. These events are created: starting : this event is called before the array is started and is used to fetch the key from a remote source started : this event is called after the array is fully operational and is used to delete the key locally. stopped : this event is called after the array is stopped and is used to fetch the key again from a remote source The script "fetch_key" can be any method to obtain the key remotely, e.g. using a mount method or a FTP (wget) method as explained in the video of @gridrunner The script "delete_key" is a simple file to delete the key locally. fetch_key #!/bin/bash if [[ ! -e /root/keyfile ]]; then mkdir -p /unlock mount -t cifs -o user=name,password=password,iocharset=utf8 //192.168.1.99/index /unlock cp -f /unlock/somefile.png /root/keyfile umount /unlock rm -r /unlock fi delete_key #!/bin/bash rm -f /root/keyfile You can start and stop the array as usual, and the key will be automatically fetched each time, provided that the remote service is up and running. attaching my fetch_key, using ftps (redacted ftp ip) fetch_key.bash Edited April 6, 2018 by ijuarez example Quote Link to comment
bonienl Posted April 6, 2018 Author Share Posted April 6, 2018 You need to change to Linux format. See Edit -> EOL conversion = Unix (LF) Quote Link to comment
ijuarez Posted April 6, 2018 Share Posted April 6, 2018 (edited) 30 minutes ago, bonienl said: You need to change to Linux format. See Edit -> EOL conversion = Unix (LF) thank you, will do fetch_key Edited April 6, 2018 by ijuarez change to Unix LF Quote Link to comment
jbrodriguez Posted April 6, 2018 Share Posted April 6, 2018 (edited) Although bonienl doesn't mention it, and it was what I was actually asking for (which I failed to properly express), you can scp to a remote server if you have a public key and get the passphrase key, so the deterrent would be to have the remote server down (so you can't get the private from a remote location) .. but I'd defer that to more cryptographic minded guys Edited April 6, 2018 by jbrodriguez Quote Link to comment
ijuarez Posted April 7, 2018 Share Posted April 7, 2018 So i tested the modification and it well, however I notice that my keyfile somehow ended in /boot/custom. I was under the impression that the keyfile was hidden at all time? i will deleted but it seemed odd. Quote Link to comment
bonienl Posted April 7, 2018 Author Share Posted April 7, 2018 Change your fetch_key file to this #!/bin/bash if [[ ! -e /root/keyfile ]]; then wget --ftps-implicit --user=<name> --password='<password>' ftp://<url or IP>/files/keyfile -O /root/keyfile fi Replace <name>, <password> and <url or ip> with your actual username, password and ftp server address Quote Link to comment
ijuarez Posted April 9, 2018 Share Posted April 9, 2018 On 4/7/2018 at 4:29 AM, bonienl said: Change your fetch_key file to this #!/bin/bash if [[ ! -e /root/keyfile ]]; then wget --ftps-implicit --user=<name> --password='<password>' ftp://<url or IP>/files/keyfile -O /root/keyfile fi Replace <name>, <password> and <url or ip> with your actual username, password and ftp server address Thanks for the help Quote Link to comment
bamhm182 Posted May 1, 2018 Share Posted May 1, 2018 Thanks for the info! I have been toying around with running 2 unRAID servers (One on a Dell R710, one on my primary Desktop w/ VM's getting passed hardware) and I took what you did and built upon it. We will call these servers U1 and U2. Both have a static IP and are plugged into a switch. U2 has a share named U1-key and U1 has a share named U2-key. Both have corresponding secure accounts. If both are on and I reboot U1, upon boot it reaches out to U2 and gets its key. If both are on and I reboot U2, it reaches out to U1 and gets its key. If both are off, I boot both and manually start the array on U2 (much faster boot time) and by the time U1 is up, it pulls its key from U2. Seems to be working well for me so far. Best of all, with this setup, if both are off (as would happen if someone walked off with my server rack), both keys are on encrypted drives, so the neither of them should be able to be booted without my key. Quote Link to comment
bonienl Posted May 1, 2018 Author Share Posted May 1, 2018 47 minutes ago, bamhm182 said: Thanks for the info! I have been toying around with running 2 unRAID servers (One on a Dell R710, one on my primary Desktop w/ VM's getting passed hardware) and I took what you did and built upon it. We will call these servers U1 and U2. Both have a static IP and are plugged into a switch. U2 has a share named U1-key and U1 has a share named U2-key. Both have corresponding secure accounts. If both are on and I reboot U1, upon boot it reaches out to U2 and gets its key. If both are on and I reboot U2, it reaches out to U1 and gets its key. If both are off, I boot both and manually start the array on U2 (much faster boot time) and by the time U1 is up, it pulls its key from U2. Seems to be working well for me so far. Best of all, with this setup, if both are off (as would happen if someone walked off with my server rack), both keys are on encrypted drives, so the neither of them should be able to be booted without my key. Very thoughtful solution, but I am wondering if there is a security flaw. ? If somebody takes steals both the servers U1 and U2. Next connect and power them up on some local network then key exchange/unlock would take place as normal? Quote Link to comment
JonathanM Posted May 1, 2018 Share Posted May 1, 2018 4 minutes ago, bonienl said: Very thoughtful solution, but I am wondering if there is a security flaw. ? If somebody takes steals both the servers U1 and U2. Next connect and power them up on some local network then key exchange/unlock would take place as normal? Chicken and egg. Take a closer look at his scenario, it requires one of the servers to be fully started with the key before the other will auto start. The only exploit this is vulnerable to is a high level government type exploit that keeps the servers running seamlessly with synchronized switchover power while they are being transported. Quote Link to comment
bonienl Posted May 1, 2018 Author Share Posted May 1, 2018 7 minutes ago, jonathanm said: The only exploit this is vulnerable to is a high level government type exploit that keeps the servers running seamlessly with synchronized switchover power while they are being transported. I guess we are not talking about the average unRAID user when such an extensive operation is required by the government Quote Link to comment
ken-ji Posted May 1, 2018 Share Posted May 1, 2018 14 minutes ago, jonathanm said: The only exploit this is vulnerable to is a high level government type exploit that keeps the servers running seamlessly with synchronized switchover power while they are being transported You'd be surprised. A well prepared team of three can do this and transfer the entire Rack (still powered up running on batteries) across the block between buildings. We did something similar before, but decided to power down in the end lessen the risk of corrupting data. The trick is that most high end server deployments have redundant power inputs at the rack level, so you can unplug one input, move the rack, plug it in and unplug the remaining one, rinse and repeat. This will also let you swap UPS/batteries while keeping the system running. . Quote Link to comment
pwm Posted May 1, 2018 Share Posted May 1, 2018 32 minutes ago, ken-ji said: This will also let you swap UPS/batteries while keeping the system running. I have been moving servers between rooms using this trick. Very useful to have redundant PSU on machines. Next step up in security is to have the machine geo-locked - have it listen for BluTooth, WiFi or similar and unmount if the geofence test fails. Quote Link to comment
bonienl Posted May 1, 2018 Author Share Posted May 1, 2018 4 minutes ago, pwm said: Next step up in security is to have the machine geo-locked - have it listen for BluTooth, WiFi or similar and unmount if the geofence test fails. What about a motion detector in the case? Quote Link to comment
pwm Posted May 1, 2018 Share Posted May 1, 2018 1 hour ago, bonienl said: What about a motion detector in the case? Could work, but not easily. If you use IR movement sensors and have a glass side panel, you are likely to trig it yourself. And if you haven't, then the IR detector wouldn't notice anything until you open the case. So it would then have to be some kind of orientation/vibration sensor that detects that the case is lifted up. Mercury switches are easy to use, but forbidden in most parts of the world. So next step then would be either switches with a rolling ball, or stepping up to semiconductor sensors - 3D compass or 3D accelerometers or similar. But it would still take a bit of work to make the sensor trig if the computer is carried away but not trig if you just want to dust the machine or replace a HDD. Quote Link to comment
ken-ji Posted May 1, 2018 Share Posted May 1, 2018 You probably want a GPS/Cell tower sensor instead. It won't trip in the same locality (adjacent room, up from the basement, etc) but still be able workout that its being moved a bit of a distance away. Quote Link to comment
pwm Posted May 2, 2018 Share Posted May 2, 2018 7 hours ago, ken-ji said: You probably want a GPS/Cell tower sensor instead. It won't trip in the same locality (adjacent room, up from the basement, etc) but still be able workout that its being moved a bit of a distance away. A Bluetooth beacon works quite well, since it's usable on both laptop and desktop machines - it's easy to add a USB receiver for machines that hasn't BT built in. Right now, I can have my Linux machines lock down if I walk outside range with phone or headset. And with a fixed BT beacon at home/office, a laptop that is moved outside the range of the beacon will lock down. I haven't figured out how to get the same functionality on my Windows machines yet. The advantage with BT is that I can walk around to a neighbor room with a laptop without it activating the lock screen. Quote Link to comment
bamhm182 Posted May 4, 2018 Share Posted May 4, 2018 Upon reading through the rest of the posts, I decided it wasn't NEARLY secure enough. Now I just need to figure out the steps to have my cellphone's presence on the LAN prompt the server to request that I insert and touch my YubiKey U2F. If my phone is not present, the server wouldn't care about the YubiKey. Only after the YubiKey is inserted and verified, will the server care about its attached retinal and finger printer scanners, which are the final key to decrypting the first server. Now the only way to get anything off of there is to... Steal me as well? God forbid I need to ask someone to boot my servers while I'm out of town because of a power outage. Haha Quote Link to comment
JonathanM Posted May 10, 2018 Share Posted May 10, 2018 On 5/4/2018 at 6:42 AM, bamhm182 said: attached retinal and finger printer scanners, which are the final key to decrypting the first server. Just an FYI, in the USA, you can be compelled by a court to provide biometrics, you CANNOT be compelled to reveal a password, as fifth amendment protection is applied to things you know, vs. things you possess such as keys or fingerprints. It would be best to add a passphrase to your well rounded security protocols. A fully formed sentence is good, lots of characters so little chance of brute force, and it can be quite memorable to yourself as well. "Twelve purple elephants dancing in the moonlight." 1 Quote Link to comment
pwm Posted May 10, 2018 Share Posted May 10, 2018 I think the optimum would be if ControlR or similar would support handing over parts of the required secret - so the phone could be used to manually enter a partial sign-on to acknowledge the startup of the server. A bit similar to how you use phone apps when doing two-factor login to banks etc. I'm not worrying about any police - but I'm constantly wary of the almost infinite number of security holes constantly being found, and I don't want some two-bit hacker being able to retrieve full key material just by a bit of luck and some hole in some software module. And it's too easy to sneak in keyboard loggers. The only way to ever get reasonable security is by designing systems with multi-factor login - it's way harder for someone to be able to listen to both a PC keyboard and a mobile phone. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.