Better unRaid Security

[tr0910]

Right now I have no security beyond a strong root password set up for my unRaid box.  This makes it easy to access for everybody.  But, I want to put a 2nd unRaid backup server in a location nearby that isn't as secure as I would like it to be.  If somebody steals my backup server with unRaid key plugged into it and boots it up, they will have a working system that will very simply cough up all my goods even to a noob.  How do I at least partially secure that backup server?  (nuclear security not necessary)

 

1. Encrypt it?  (the big hammer, but very resource intensive - truecrypt anyone??)

2. Pull the unRaid USB key from the server while it sits idle and shut down.  (Likely I'll forget to pull the key.)

3. Force the server to get a key file from somewhere else on your lan before it will successfully boot.  (Is this possible at all?)

 

In the past I have taken backup servers offsite without the unRaid key in them.  Thus if someone tries to plug them in, they won't even boot up.  Not very high level security, but good enough for most curious folks.  Option 3 is interesting if possible.  It would replicate the security I had before.

 

(This backup server will sit quiet and shut down most of the time, only starting up automatically once per week to backup the main server.)

[prostuff1]

Crashplan does an encryption on anything it backs up.

[trurl]

Without encryption it is not necessary to boot unRAID to read your data. Just booting Linux would suffice.

[tr0910]

I'm OK with just making it difficult. Just want to protect from curious folks so if the server is stolen, I'm not likely to be blackmailed by thugs with images of me partying.

 

Sent from my mobile

 

 

[boof]

1. Encrypt it?  (the big hammer, but very resource intensive - truecrypt anyone??)

 

You could encrypt the data before you put it on your primary server. Though if using truecrypt you woul dhave to be careful about the consistency of the container depending on how you do your backup.

 

unMenu has an encfs plugin which might suit you better - you could run this only on the backup for sensitive locations.

 

Or - as suggested - use crashplan with your second server as a target and encrypt. I do this, it works well.

 

2. Pull the unRaid USB key from the server while it sits idle and shut down.  (Likely I'll forget to pull the key.)

3. Force the server to get a key file from somewhere else on your lan before it will successfully boot.  (Is this possible at all?)

 

In the past I have taken backup servers offsite without the unRaid key in them.  Thus if someone tries to plug them in, they won't even boot up.  Not very high level security, but good enough for most curious folks.  Option 3 is interesting if possible.  It would replicate the security I had before.

 

As has been suggested none of this helps as they have access to the physical unencrypted disks. Anyone can read the data off them at that point. I'm not really sure what your concern is if you think that it just being difficult is enough of a barrier. If the hardware goes walkies you have no idea who has taken it, why - or who they have sold it onto and thus what they might be doing with it. I would imagine there is a decent market in trawling 'used' hard disks for personal information.

 

If your second server is just a backup server does it even have to be unraid? Your encryption options within unraid are limited whereas if you drop the unraid requirement full disk encryption becomes much more viable if running other OS'

 

Personally I would go for the crashplan suggestion - it will sort out the encryption *and* the transfer of your backups in one go. There are caveats (which a forum search will reveal) but it works and is, relatively, fire and forget.

[limetech]

Won't protect from someone physically stealing it, but you can check if your motherboard bios provides a feature where you have to enter a password to boot.  For example, the x9scm-f has this feature.

[NAS]

We discussed a while back some light encryption for this very purpose however in retrospect it seems like a maintenance nightmare.

 

However it is not beyond the realms of possibility to create something that could remotely blank a stolen box when it is connected back into the internet.

 

Again though that could get risky but it would be possible.

[tr0910]

However it is not beyond the realms of possibility to create something that could remotely blank a stolen box when it is connected back into the internet.

 

But until it was connected to the internet, it would be completely open wouldn't it??  Could we keep it from booting unless it was able to "call home to Mommy"?? 

 

Most of the risks we face with our servers are the casual thieves. 

 

  - Hmm, I wonder what's on here??  Oh well, massive errors booting up, must be junk.  Throw it in the garbage. 

 

Data remains safe 99.9% of the time.  Good enough for me.

 

I would rather have a simpler, security that just refuses to boot unless it finds some kind of key file.  Won't protect against the knowledgeable but will certainly protect against 99.9% of the risks.  Should we have nuclear secrets stored and Russian hackers with a key to our house, we shouldn't be storing our data on unRaid anyway.  Just keeping our data safe from everyone that hasn't heard of ReiserFS is a good start.

 

Truecrypt can use a key file as well as having password options.  I like this key file option because we can encrypt external drives that get carried about in pockets, and might get left in some McDonalds.  Since the key file only exists on the computers that this external drive is supposed to be plugged into, someone getting their hands on an external while it is intransit, will only be able to reformat it, and enjoy it as an empty drive.  On the other hand, when the drive is used as planned, nobody is bothered to enter yet one more password and the data remains safe. 

 

Could we implement a remote key file for unRaid for security like Tom uses a usb key file for licensing purposes?  This key file would be somewhere else on the network, and once a server was stolen, it would render the server 99.9% safe.

[ijuarez]

I'm OK with just making it difficult. Just want to protect from curious folks so if the server is stolen, I'm not likely to be blackmailed by thugs with images of me partying.

 

Sent from my mobile

 

Is this code for Naked pictures!  :)

[tr0910]

Won't protect from someone physically stealing it, but you can check if your motherboard bios provides a feature where you have to enter a password to boot.  For example, the x9scm-f has this feature.

 

I have these servers starting up via IPMI in the middle of the night, so there is no one to enter a password on bootup.

[NAS]

What you are trying to achieve is beyond the scope of an off the shelf product. In the security world physical access is the ultimate hack. OK so that is a bit of a carte blanche statement but in most instances it is true.

 

The way to stop physical theft is to physically secure.

[JonathanM]

  - Hmm, I wonder what's on here??  Oh well, massive errors booting up, must be junk.  Throw it in the garbage. 

 

Data remains safe 99.9% of the time.  Good enough for me.

If you never shut it down, you could just rename bzroot or another critical boot file after it's up successfully, and copy it back before a planned reboot. You could do all that with scripting, and as long as you never crashed the machine, you would be secured against somebody pulling the plug and leaving with the whole server. They would get one clean boot, and unless they were literate enough to shut down safely, it would never boot again without intervention. Downside, you would have to physically access the usb stick to repair it if an unclean shutdown didn't allow the script to copy the boot file back.

[tr0910]

If you never shut it down, you could just rename bzroot or another critical boot file after it's up successfully, and copy it back before a planned reboot. You could do all that with scripting....

 

Hmmm, interesting idea, only it will spend almost all its life shutdown.  I just need to have it copy bzroot from somewhere else on the network prior to booting.  I wonder if you could have a preboot copy process like that?

[limetech]

Maybe set up the bios to boot from a network tftp server, and the usb flash device would only be used to store your config?  This might be possible - this way if someone powers on the server and it's not on your network it won't boot, and it won't even boot from the flash....

[JonathanM]

If you never shut it down, you could just rename bzroot or another critical boot file after it's up successfully, and copy it back before a planned reboot. You could do all that with scripting....

 

Hmmm, interesting idea, only it will spend almost all its life shutdown.

Even so, the thieves would only get one good boot, and when they figured out that it wasn't going to give them a nice gui on the console, they would probably shut it down by pulling the power anyway, and that would be all she wrote unless they are computer savvy thieves, in which case the point is moot.

[tr0910]

Maybe set up the bios to boot from a network tftp server, and the usb flash device would only be used to store your config?  This might be possible - this way if someone powers on the server and it's not on your network it won't boot, and it won't even boot from the flash....

 

Off to PXE land we go....

[NAS]

I think we are putting the cart before the horse.

 

First we need to define the threat to be mitigated.

 

In my view we are looking for a means to stop the machine booting when not in its original location.

 

Note this is not the same as securing the data as even the dumbest thief who we mitigated against powering it on could sell it on to "the guy who fences this stuff" or break it up and sell on the disks..

 

The only option to deal with the later is encryption and that isnt on the cards.

 

There are many simpler ways to solve the former short of requiring people to do PXE. For instance just fingerprint the DG and fail to boot if it doesn't match the trusted signature. Even testing the MAC of the DG would be enough to deal with the threat defined above

[tr0910]

In my view we are looking for a means to stop the machine booting when not in its original location.

 

There are many simpler ways to solve the former short of requiring people to do PXE. For instance just fingerprint the DG and fail to boot if it doesn't match the trusted signature. Even testing the MAC of the DG would be enough to deal with the threat defined above

 

Well summarized....

 

DG = Default Gateway?

[NAS]

yes sorry DG = default gateway

[tr0910]

yes sorry DG = default gateway

This would require Tom to implement wouldn't it?  How would you check for a Mac signature during boot?

 

Sent from my mobile

 

 

[RobJ]

Just a simple idea, only good to keep the curious and ignorant out - modify the syslinux.cfg boot file.  Move the "menu default" line to the Memtest section, shorten the timeout to 3 seconds ("timeout 30"), and test.  Once you have figured out exactly what arrow keys are required to boot UnRAID, then add the "console 0" command to turn off the display (at least I *think* that is what it does!).  Or instead of the console command, use the Display file command to display your own dummy screen, see the Syslinux wiki.

 

I haven't tested any of this!  It hopefully should boot quickly to the Memtest tool, unless they know the precise arrow keys to quickly hit.

[jbartlett]

Any DG reference would need to be configurable on the flash not hooked up to the UNRAID box. Last thing people need is to implement DG security and then have their router fail.