Sane security defaults


unRate

7 posts in this topic Last Reply

Recommended Posts

 

While the current system is great for the average home network as a media server storing non-critical and non-confidential information on a private network, with a few changes, it could be ready for so much more...

 

Where I'm coming from: I'm new to unraid, and I am a long time Linux-user with widows as a side OS I avoid as much as possible. Currently I've been setting up a VFIO system, and because I won't just be using it to store media but to actually be my daily driver, I have certain security concerns with the current default configurations.

 

The following is a list of changes I've compiled, largely from http://kmwoley.com/blog/securing-a-new-unraid-installation/ and somewhat ordered by importance:

- SMB 1 disabled by default

- FTP and Tellnet disabled by default

- HTTPS enabled with a self-signed cert out of the gate (love the cert authority setup though!)

- make it more clear how to encrypt new drives (can't choose to encrypt when adding the device, has to be changed in the default filesystem setting)

- new shares not exported by default, and when exportrd, Private by default

- Don't export the USB boot media!!! (At least not by default and add an are you sure if you try to enable it)

- firewall such as UFW installed and enabled by default with only TCP port 80 and 443 set to LIMIT and whatever SMB uses opened. GUFW could be pulled from for the GUI. And providing quick check boxes for common ports would make it easy, possiblity auto enabling when you enable a core service.

- Docker Isolation through Linux namespaces / subuids

- allow tagging more shares for direct Linux VM mounting to prevent the need to pass through /mnt/user

- better multiple-user support, it's a server, right? So people other than root should be able to ssh in and access the UI; ideally root login would be disabled with use of a wheel group instead

- don't use 777 permissions by default, ideally users + groups, but at a minimum there is no reason for most things to be read, write, and execute by default!

- support for openvpn

- support for multiple different encryption keys


And add other lurking issues to this. Even if you're not exposing a system to the public internet, a lot of these things can still cause problems if the system is up 24/7. There is no such thing as a "friendly environment" outside air-gapped systems, and my daily driver will definitely not be air gapped.

 

Anyway, if you've made it this far and feel like this is a list of complaints, I'm sorry. I do like unraid and I already feel excited for where it's going.

Link to post
  • 6 months later...

Necro. Sorry. I almost posted on the original thread ... https://forums.unraid.net/topic/80192-better-defaults/ but this seems the better place to take the idea forward.

 

Coming from a long history of working on similar projects (not recently ... but as far back as working at Cobalt before they were bought by Sun). I completely agree that running Dockers/VMs as unprivileged users as well as running commands through sudo with an unprivileged admin were things I just sort of expected to find when I started with Unraid recently.

 

There've been a couple of comments from Lime that make me worry.

 

* It's "an Appliance" so lower security than a custom built server is expected.

 

Yes. But Internet appliances have been around a long time and there are appliances going back to the late 90s that did more in regards to user privileges (Cobalt Qube and Raqs were actually built to fulfill the place a modern Unraid system fits a user today). Dockers didn't exist back then but the concepts aren't that much different than breaking out of a virtual web site and gaining access. VMs existed back then but weren't used in the same ways they are now.

 

* 'It shouldn't be possible to "break out" of a container and as far as I know this isn't possible. Otherwise it will be a security vulnerability of Docker itself.'

 

Sure. Same can be said of running a web service as root. If the service is vulnerable and broken, the vulnerability is the fault of the service. It's the job of the host to use sane defaults to proactively limit the damage done if it happens. Not to the point of making the system arcane to work on ... but 'sudo' and wheel groups aren't arcane, they're well documented for decades and these days it's actually weird to not need to use them.

 

And as pointed out in the original thread, there have been at least proof of concept attacks against Docker. At that point companies have 2 directions to go: "Docker's fault, sorry" or "no worries, even if it happens we've done the work to protect you".

 

I DO know the pain that can be caused to your support group if you change some basic paradigms. Going back to Cobalt for a second, our first generation of appliances were not secured well and we had to make some core changes. That changeover was full of support calls. But ... this was back when things weren't well documented on the Internet and most users had never even heard of Linux. Once that process was done supports' life, as well as the consumers', was much much easier. Because most day to day problems simply didn't occur anymore.

 

In reading a number of replies from Lime it really feels to me like there is an inherent inertia involved because of the hesitance to change a long established product. I get that. I get it well enough that I'm not expecting these changes to be made. But I can still hope for them. I can make some of the changes I feel are needed (disabling Telnet, SMB v1, changing root password) very easily. Other things like making Unraid support a non-privileged user to run specific highly integrated tasks? No way.

 

And ... I'm a brand new user. I bought my Pro license a day ago after configuring everything and knowing what I was getting into. So I'm 100% not saying Unraid isn't a good product. I'm just saying the security could improve.

 

I would never expect these types of core changes in a point patch. I don't expect them in the next major patch. I'm just lending a voice to consider them at the point where the next major release is defined after this point to consider them.

 

 

Link to post
  • 3 months later...
  • 2 months later...

This feature request contains to many things that are not security related and all these points should be part of additional feature requests:

- make it more clear how to encrypt new drives

- allow tagging more shares for direct Linux VM mounting to prevent the need to pass through /mnt/user

- better multiple-user support

- support for openvpn

- support for multiple different encryption keys

- FTP disabled by default (look here)

 

This leaves these points, which I like to comment:

 

- SMB 1 disabled by default

There is not reason for that, as SMB1 is only a security problem for Windows servers. Adding an option to select the minimum SMB version, maybe, but should be part of a different feature request.

 

- shares not exported by default, Private by default

Yes.

 

- Don't export the USB boot media

Yes.

 

- don't use 777 permissions by default, ideally users + groups

Why?

 

- Docker Isolation through Linux namespaces / subuids

Why?

 

- firewall such as UFW installed and enabled by default

Really needed for local usage? This would be a huge project as it must respect all ports used by docker containers and vms.

 

- HTTPS enabled with a self-signed cert out of the gate

Not needed for local usage. Some people prefer not spreading their public IP to a DDNS provider.

 

 

Link to post
  • 4 weeks later...
On 11/28/2020 at 1:54 AM, mgutt said:

- firewall such as UFW installed and enabled by default

Really needed for local usage? This would be a huge project as it must respect all ports used by docker containers and vms.

@mgutt - this is becoming a must for any administrator. For two reasons: 
Malware/ransomware traversing the network once a device is infected. Having ufw could minimse the possibility.
Children.. Those things are getting smarter everyday and those that are interested will dive into any machine to see what they can find.

 

The above is just my point of view. For others running Unraid in their business, they will have a lot more reasons.

My use case: Limit inbound traffic to port 443 where nginx will forward to Authelia, or the likes..

Link to post
4 hours ago, Maximus88 said:

Malware/ransomware traversing the network once a device is infected. Having ufw could minimse the possibility.
Children.. Those things are getting smarter everyday and those that are interested will dive into any machine to see what they can find.

I still don't see the point. If a client in your network is infected, how does a firewall installed on your NAS help to stop the malware. It does not as you do not route your complete traffic through your NAS. The only thing that it does is to block incoming traffic on your NAS.

 

But why should you do that? By default all ports on your Unraid server are closed (Linux default), except the ones where a service is listening (lsof -i -P -n | grep LISTEN). This means you enable SSH and port 22 is open and if you disable it, its closed. Of course you could limit with UFW all ports to a specific local subnet or a specific IP address, but by that your infected local client is on the whitelist as well. 

 

If we are talking about limiting brute-force attacks on SSH, WebGUI, etc, this should be implemented in Unraid itself I think. I created a separate Feature Request for that.

Link to post
  • 3 months later...

I agree with this.
The big one I came to post myself, but will state here instead.  disable root login to webui and SSH. force user to create their own username.  especially with the recent news of hacks and such... they would need to "crack" a username and a password, instead of just a password.

 

Link to post

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.