Is UnRaid really unsecure?


Del

Recommended Posts

Hi

 

Ive read in these forums that "unraid is unsecure", but no real substance to what that means.

 

I'm an ITSec Pro, looking for a easy to use solution for the in-laws and (thought that) unraid met the bill very well, especially after they had positive comments after I showed them a quick demo. Its only a family Plex/music/photo server...

 

Assuming best practice is followed with users having minimal rights/strong password, shares Read Only unless RW strictly needed, no direct exposure to internet, kept up to date etc. how would you rate Unraids ability to repel an attack from a compromised device on the internal LAN?  

 

Also, can anyone comment on how Unraid security is handled recently? I read the policy sticky at the top of this board and it left me feeling quite concerned about how serious the developers are at keeping things up to date when a relevant CVE hits.

 

Thanks

 

Del

Link to comment

I feel like I should start with a disclaimer... this is my current personal opinion, it comes with no warranty or guarantee.  YMMV. etc. etc. 

 

Quote

I've read in these forums that "unraid is unsecure", but no real substance to what that means.

 

Typically what people mean is "don't expose unRAID to the Internet". It is designed for use in a "friendly" network, and doesn't have things like password lockouts or a firewall.  The WebUI, SSH, FTP, SMB would be examples of things not to expose to the net.

 

But if you are comfortable running Plex on Windows and exposing that to the Internet, then it shouldn't be any riskier to do the same on unRAID (preferably using Docker).  Same with nginx, openvpn, etc. (using non-standard ports when possible)

 

I am pretty sure that the main security scares people have had are because they put their server in the DMZ or otherwise exposed it to the Internet.  That and having another computer on their network get hit with ransomware.


I think your ideas for securing unRAID are spot on:

  • do not expose to the Internet
  • assign strong passwords to root and all users
  • use read only shares when possible
  • keep unRAID, all plugins, and all dockers current

To that I would add:

  • use dockers rather than plugins whenever possible (install the Community Applications plugin to help find apps to install)
  • if exposing dockers or VMs to the Internet, use non-standard ports when possible
  • install the Tips and Tweaks plugin so you can disable the built-in ftp and telnet servers (unfortunately, these are difficult to disable without the plugin)
  • install the Fix Common Problems plugin because it will notify you of repeated password failures (and many other potential problems)
  • consider installing the Ransomware Protection plugin, which makes your shares readonly if one of the bait files is deleted/modified
  • maintain backups that cannot be affected by ransomware
  • do not use the built-in Firefox browser if you can avoid it
  • keep all other computers on your network up to date with security patches / antivirus
  • keep your router current as well

And not really security related but worth mentioning:

  • always use a UPS.  It will save you a lot of headaches.
Edited by ljm42
add note about non-standard ports
  • Like 1
  • Upvote 5
Link to comment
1 hour ago, limetech said:

Like any computer system it can be more or less "secure".  Depends on what you want secured.

Note: please only use latest release.

Note2: next minor release (6.4) includes https support for accessing server.

 

Hi

 

Thanks for your reply. Good to hear about HTTPS access.

I'm a little confused about your first sentence though - I'm asking about how secure is the underlying OS?

 

Also, please could you address this part of my original query:

"Also, can anyone comment on how Unraid security is handled recently? I read the policy sticky at the top of this board and it left me feeling quite concerned about how serious the developers are at keeping things up to date when a relevant CVE hits."

 

Link to comment
1 hour ago, ljm42 said:

I feel like I should start with a disclaimer... this is my current personal opinion, it comes with no warranty or guarantee.  YMMV. etc. etc. 

 

 

Typically what people mean is "don't expose unRAID to the Internet". It is designed for use in a "friendly" network, and doesn't have things like password lockouts or a firewall.  The WebUI, SSH, FTP, SMB would be examples of things not to expose to the net.

 

Yep, I never expose any services outwards, except VPN server from a properly hardened endpoint.

 

Quote

But if you are comfortable running Plex on Windows and exposing that to the Internet, then it shouldn't be any riskier to do the same on unRAID (preferably using Docker).  Same with nginx, openvpn, etc.

 

I am pretty sure that the main security scares people have had are because they put their server in the DMZ or otherwise exposed it to the Internet.  That and having another computer on their network get hit with ransomware.

 

My biggest concern that would be a compromised machine on the internal network would then be able launch an attack against the Unraid server, which isn't designed for such an attack.

An attack on a internal PC is one thing, but to find out that other devices have been compromised really makes a bad day worse.

Its not just Cryptolocker style either; a compromised PC could drop a botnet onto other devices...

 

1 hour ago, ljm42 said:

I think your ideas for securing unRAID are spot on:

  • do not expose to the Internet
  • assign strong passwords to root and all users
  • use read only shares when possible
  • keep unRAID, all plugins, and all dockers current

To that I would add:

  • use dockers rather than plugins whenever possible (install the Community Applications plugin to help find apps to install)
  • install the Tips and Tweaks plugin so you can disable the built-in ftp and telnet servers (unfortunately, these are difficult to disable without the plugin)
  • install the Fix Common Problems plugin because it will notify you of repeated password failures (and many other potential problems)
  • consider installing the Ransomware Protection plugin, which makes your shares readonly if one of the bait files is deleted/modified
  • maintain backups that cannot be affected by ransomware
  • do not use the built-in Firefox browser if you can avoid it

 

Thanks for those extra tips; a bit shocking that telnet runs by default though!

 

1 hour ago, ljm42 said:
  • keep all other computers on your network up to date with security patches / antivirus
  • keep your router current as well

 

Yep, this is normal practice.

On the perimeter is Sophos UTM9, running IDS/IPS as well as web-proxy to try to catch stuff inbound, or at least get early notice of an issue.

 

1 hour ago, ljm42 said:

And not really security related but worth mentioning:

  • always use a UPS.  It will save you a lot of headaches.

 

This should be generic advice for anyone running a server. They are mega cheap now...

 

If I get a moment, I think I will run a Nessus scan and see what it uncovers, to get an understanding of what it looks like from the outside in...

 

Link to comment
1 hour ago, Del said:

My biggest concern that would be a compromised machine on the internal network would then be able launch an attack against the Unraid server, which isn't designed for such an attack.

 

It isn't that unRAID is inherently insecure, just that it isn't hardened.  At least that is my impression.

 

The possibility of malware on my Windows pc successfully infecting my unRAID system seems pretty low (knock on wood, I don't like putting that in writing!)  Also note that unless the malware was specifically designed to target the unRAID OS and its use of the flash drive, all you would have to do to get rid of the malware is reboot, since the OS is loaded fresh into RAM at each boot.

 

Much higher on the concern level (at least for me) is malware on the pc using SMB credentials stored on the pc to encrypt the data stored on unRAID.  This problem isn't unique to unraid, but that's why we're talking about read only shares and the Ransomware Protection plugin.

 

Either way, it is great to bring on people who have such a focus on security.  I think limetech has done some really great things in this area recently (the webui now has CSRF tokens) and I'm looking forward to seeing how https is implemented in the next release.  If you see problem areas, definitely report them and we can all benefit.

  • Like 1
Link to comment

Glad to hear about HTTPS support coming. 

 

Some other suggestions:

 

- Have a default root password vs just blank. 

- Force password to be changed on first login.

- ssh key support in the web interface.. more advanced users can do this today. 

- Run docker as its own user

- Run KVM as its own user

- Create a separate user account for the web interface that isn't root so you are not passing root creds over the network (although ssl sorta addresses this)

 

Even with that you should never stick an unraid box on a DMZ port. It's use case is inherently less secure than say a web server due to the attack landscape it exposes. (smb etc) Always use docker containers and only forward specific ports to it. Try and always use ports that are not default. Plex example: Use port 34121 on your router that points to 32400 on your internal plex docker. That way if some plex vuln comes out you have a little time to address it. The baddies will be scanning 32400 looking for them. YES you can still find it but that requires a full port scan on you and that is a lot slower then looking for plex by 32400. 

 

Another pro tip: Don't open SSH to your unraid server from the internets. If you really need to be able to ssh into your house create a small VM that you can use to connect to. Or better yet install the openvpn docker and connect that way. Never have direct connectivity on any port to your unraid box from the interwebs... always use a docker 

 

  • Like 1
  • Upvote 3
Link to comment
59 minutes ago, ljm42 said:

 

I think you might want to make it clear that those are feature requests, not things that can be done today.

 

Good idea on using non-standard ports, I'm going to add that to my list :)

 

Yes sorry those would be feature requests not something you can do sans the key based auth.

Link to comment
On 3/23/2017 at 2:43 AM, ljm42 said:

 

It isn't that unRAID is inherently insecure, just that it isn't hardened.  At least that is my impression.

 

And to be honest, I wouldn't expect Unraid to be fully hardened; its a risk/reward balance the end-user needs to accept.

 

Having done quite a bit of reading over these forums, my biggest concern is that the developers seem to have a head in the sand attitude to security. Yes, I fully accept that an Unraid box should never be connected to the internet, but the threat landscape has changed significantly recently and software running on an internal LAN needs to be implemented accordingly.

 

There seem to be quite a few security threads where the developers haven't bothered to reply when the questioning got too hard; my direct question above is another example (despite them answering other threads, proving they are online...)

 

On 3/23/2017 at 2:43 AM, ljm42 said:

The possibility of malware on my Windows pc successfully infecting my unRAID system seems pretty low (knock on wood, I don't like putting that in writing!)  Also note that unless the malware was specifically designed to target the unRAID OS and its use of the flash drive, all you would have to do to get rid of the malware is reboot, since the OS is loaded fresh into RAM at each boot.

 

I would be more concerned.

If your PC were to be infected with botnet software, it may not be apparent, but the attacker has full control over your PC and its network stack.

This could be used to scan the internal LAN for Linux hosts with open port 80 -- yep, thats Unraid.

The attackers can then directly attack your Unraid Linux box, using the Windows botnet infected PC as a lever into your network.

 

Its not just Windows PC's. Check out the recent huge Merai DDOS attack that compromised IoT devices (IP Cameras etc). The leaked code for Merai is freely available for download and I'm sure there are plenty of people using it to gain access to private LANs through an insecured IP Camera.

 

This is what I mean by the threat landscape has changed recently - the threat is now inside as well!

 

Don't get me wrong, i think Unraid is excellent. It ticks all the boxes I need for the in-laws media server and with the docker and KVM implementation, I'm even considering it as a replacement for a few ProxMox test servers, but reading the other threads on the forum makes me question the security commitment.

I guess spending time adding eye-candy and stuff like that is more profitable than mundane security stuff, which is a very short-sighted approach.

 

 

  • Like 1
Link to comment
5 hours ago, TOoSmOotH said:

If you really need to be able to ssh into your house create a small VM that you can use to connect to. Or better yet install the openvpn docker and connect that way. Never have direct connectivity on any port to your unraid box from the interwebs... always use a docker 

 

 

Personally, I would do it the other way around - prefer a VM dedicated to VPN rather than a Docker.

Reasoning is that if the VPN endpoint were compromised, if in a VM, there is another OS layer to get around.

 

Probably not a lot in it for home use though.

Link to comment
1 minute ago, Del said:

I guess spending time adding eye-candy and stuff like that is more profitable than mundane security stuff, which is a very short-sighted approach.

 

With all due respect man, this is unwarranted.  We take security very seriously.  Case in point: totally dropped development last month to incorporate CSRF protection as fast as possible and it was a hell of a lot of work.  We are team of 2 developers in unRAID OS core, and one of us can only spend half time at it because of other hats that must be worn.  Reality is 99% of CVE's do not affect unRAID directly.  Many are in components we don't use.  Many apply only to internet-facing servers.  We have always advised, unRAID OS should not be directly attached to the internet.  The day is coming when we can lift that caveat but for now VM's can certainly serve that role if you know what you are doing.

 

If you find a truly egregious security vulnerability in unRAID we would certainly appreciate an email.  We see every one of those, whereas we don't read every single forum post.  Send to [email protected]

  • Like 1
  • Upvote 9
Link to comment
24 minutes ago, limetech said:

 

With all due respect man, this is unwarranted.  We take security very seriously.  Case in point: totally dropped development last month to incorporate CSRF protection as fast as possible and it was a hell of a lot of work.  We are team of 2 developers in unRAID OS core, and one of us can only spend half time at it because of other hats that must be worn.  Reality is 99% of CVE's do not affect unRAID directly.  Many are in components we don't use.  Many apply only to internet-facing servers.  We have always advised, unRAID OS should not be directly attached to the internet.  The day is coming when we can lift that caveat but for now VM's can certainly serve that role if you know what you are doing.

 

If you find a truly egregious security vulnerability in unRAID we would certainly appreciate an email.  We see every one of those, whereas we don't read every single forum post.  Send to [email protected]

 

I do security stuff for a living and I would say there are no glaring vulnz with unraid. Just some best practices that need to happen (that I listed previously) that would help with the optics of its level of security. No matter what you do if someone wants to get to you they will. Forcing people to change the root password will help save them from themselves in some cases. 

 

30 minutes ago, Del said:

 

Personally, I would do it the other way around - prefer a VM dedicated to VPN rather than a Docker.

Reasoning is that if the VPN endpoint were compromised, if in a VM, there is another OS layer to get around.

 

Probably not a lot in it for home use though.

 

That is another option as well. If you want to go full tin foil I would stick it on another VLAN and make it pass through your firewall to access you LAN where you unraid box sits.

Link to comment
On 3/22/2017 at 1:42 PM, Del said:

Also, can anyone comment on how Unraid security is handled recently? I read the policy sticky at the top of this board and it left me feeling quite concerned about how serious the developers are at keeping things up to date when a relevant CVE hits.

 

Nobody is jumping on this, which I take as a good sign :)  As you saw in that other thread, this was a bit of a sore spot last year.

 

I recommend that you take a look at the changelog for 6.3.2:
  https://forums.lime-technology.com/topic/54959-unraid-os-version-632-stable-release-available/
to get an idea of how many components are updated due to CVEs and how often there are releases.  I feel like they've been doing quite well.

 

I just noticed that as of yesterday (3/23) there is a new issue for samba (SSA:2017-082-02):
  http://www.slackware.com/security/list.php?l=slackware-security&y=2017 
Let's keep an eye on this and see how long it takes @limetech to get in to unRAID.  (yep, I'm throwing down the gauntlet LOL)

 

  • Upvote 1
Link to comment
1 hour ago, ljm42 said:

I just noticed that as of yesterday (3/23) there is a new issue for samba (SSA:2017-082-02):

 

Good example.

 

"Exploitation of this bug has not been seen in the wild."

https://www.samba.org/samba/security/CVE-2017-2619.html

 

This is a vulnerability that we will get to but does rise to the level of "drop everything you're doing right now and push this fix out".  Each new release requires shutting down and rebooting, so we are not going to generate releases every time some random CVE shows up.  There has to be a balance where reason and logic is employed.

  • Like 1
  • Upvote 1
Link to comment

Ah, the slackware site had fewer details so it looked more dangerous:

All versions of Samba prior to 4.6.1, 4.5.7, 4.4.12 are vulnerable to
a malicious client using a symlink race to allow access to areas of
the server file system not exported under the share definition.

Based on the full details I'd agree it doesn't need an emergency fix -- not that you need my approval or anything :D

 

But once the gauntlet has been thrown it can't be picked back up (that's a rule, right?)  I think we can still use this to gauge the timelines for less serious CVEs

Link to comment
4 hours ago, limetech said:

We have always advised, unRAID OS should not be directly attached to the internet. 

 

Okay, I guess I'm an idiot but what exactly does this mean, my server is Ethernet connected so that I can run it headless, in my mind that means it is connected to the internet. I could boot to the GUI open a browser (if I wanted to) and surf websites normally. I'm assuming that any docker such as plex has internet access too so I'm confused about how to not have the server "directly attached to the internet".

Link to comment
46 minutes ago, Dissones4U said:

 

Okay, I guess I'm an idiot but what exactly does this mean, my server is Ethernet connected so that I can run it headless, in my mind that means it is connected to the internet. I could boot to the GUI open a browser (if I wanted to) and surf websites normally. I'm assuming that any docker such as plex has internet access too so I'm confused about how to not have the server "directly attached to the internet".

 

You may have an Internet connection, but you are almost certainly behind a NAT router, not directly connected to the Internet.  Normally, that NAT router is the only machine that faces the Internet, has a direct connection, and is under constant attack by numerous bots roaming the IP's of the Internet.  You only have a local IP for your local network.  Only the router has your true IP that is seen on the Internet.  When your browser or NTP service (or other Internet need you may have) needs to see something on the Internet, it makes a connection to an Internet server, and your router notes that connection and allows that server to respond, using the associated ports of your connection.  The router will route those responses back to your machine, and not any other.  The outside bots and servers cannot attack or connect to your machine, because they can't even see it, and they don't know your local IP.  The only contact that outside machines can have with your machine is strictly through connections your machine initiates first, through your router.

 

Now if you *did* want to put your server directly on the Internet, most routers have a setting where they can put any machine into a 'DMZ', a special unprotected zone, which means the Internet is directly connected to any machine you choose!  And the router won't block any Internet traffic then, but allow all of it to come through to you.  But I would strongly advise you to first disconnect ALL of your drives, and backup your boot drive, because you will be very rapidly attacked!  Never use the DMZ unless you have a lot of security experience!

  • Upvote 2
Link to comment
6 hours ago, Del said:

Having done quite a bit of reading over these forums, my biggest concern is that the developers seem to have a head in the sand attitude to security. Yes, I fully accept that an Unraid box should never be connected to the internet, but the threat landscape has changed significantly recently and software running on an internal LAN needs to be implemented accordingly.

 

There seem to be quite a few security threads where the developers haven't bothered to reply when the questioning got too hard; my direct question above is another example (despite them answering other threads, proving they are online...)

...

This is what I mean by the threat landscape has changed recently - the threat is now inside as well!

 

Don't get me wrong, i think Unraid is excellent. It ticks all the boxes I need for the in-laws media server and with the docker and KVM implementation, I'm even considering it as a replacement for a few ProxMox test servers, but reading the other threads on the forum makes me question the security commitment.

I guess spending time adding eye-candy and stuff like that is more profitable than mundane security stuff, which is a very short-sighted approach.

 

Del, I see you have only been here a few days, so I'll go easy on you!  ;)   But you have seriously jumped too quickly to some very wrong assumptions about Lime Technology!  As a long-time user, and I think I can speak for many other veteran users, your conclusions are totally different from ours.  To have drawn some of your conclusions, you could not possibly have taken the time to review the numerous Release Notes, for the close to a hundred odd releases we have had.  Tom has always been very responsive to users needs.  As you said yourself, the 'threat landscape' has changed recently, in the last 2 years I think, and that's when unRAID began closely following the CVE's.  I just checked and it was early to mid 2014 when they began, specifically for security reasons, adding patches and patched programs to the distro.  Before that, they had been just staying current with Slackware.  Yes there are frank discussions now and then, but I wouldn't draw too many conclusions from that.  They're based on a history of respect.

 

Tom and Jon aren't around here that often, a bit more at the moment because of some issues that have cropped up.  But they can be gone for weeks at times, and they only monitor a subset of the boards.  In a way, we don't need them!  Things run pretty smoothly around here.  If you do need a response from them, it's best to email them directly at support.  Otherwise, it could be a week or 2, if they even check the board you posted on.

 

Also, I've never seen them duck a hard question.  If there's no response, they either haven't seen it yet, or others have answered.  Or they missed it, Tom does seem to skim read at times.  I did find your question above, and I have to say that's not a quick one.  To fully answer is more like writing a white paper!  They're busy, give them time.

  • Upvote 1
Link to comment
3 hours ago, RobJ said:

Now if you *did* want to put your server directly on the Internet, most routers have a setting where they can put any machine into a 'DMZ', a special unprotected zone, which means the Internet is directly connected to any machine you choose!  And the router won't block any Internet traffic then, but allow all of it to come through to you.  But I would strongly advise you to first disconnect ALL of your drives, and backup your boot drive, because you will be very rapidly attacked!  Never use the DMZ unless you have a lot of security experience!

Never misunderstand these consumer-router-exposed-host-thingys as a DMZ! Almost all of them simply open the firewall for that host, but dont add any rules between the exposed host and your LAN. Better use two routers in cascade.

  • Upvote 1
Link to comment
14 hours ago, ljm42 said:

But once the gauntlet has been thrown it can't be picked back up (that's a rule, right?)  I think we can still use this to gauge the timelines for less serious CVEs

 

After thinking about this some more... if a CVE isn't important enough to change the development timeline then there is no point in counting the days until it is fixed, as it all depends on when during the development cycle the CVE was found.

 

i.e. if the next release is in 8 days (completely random number there folks) that doesn't mean the release happened 8 days after the CVE, it means the CVE happened 8 days before the release.  And there will probably be other non-critical CVEs in the release that waited longer, and maybe some that were shorter.

 

The only real metric is whether or it not is included in the next release.

 

As Neo might say "there is no gauntlet"

Link to comment
2 minutes ago, ljm42 said:

if a CVE isn't important enough to change the development timeline then there is no point in counting the days until it is fixed

 

But a CVE can definitely alter the development timeline and make us publish a release before something else is done.  In this case we weigh how many people are complaining about not having a new release that addresses CVE's vs. how many people will complain that a new stable release does not contain the feature request or bug fix they were expecting. ::)

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.