# User for file sharing

## LIsLinuxIsSogood

(EDIT: Modified)

Hello, I just recently started using the nfs server on my desktop (gentoo, emerge info below)...I use it to watch movies over the network, which are streamed or whatever to my fire tv stick, or  also my laptop.  Since it seems like I could be missing the protection needed for the server to not open a "vector" here for exploits... I would like to implement some changes to heighten measures for securing the server box as I would hate to have the system exploited because I wanted to watch some streaming videos on my local network (if that is even possible, I assume this is unlikely given the natural firewall that each box represents at this point!)  Somehow, these are the ideas I am considering to implement:

1) To be assigning a new user and group and granting permissions to the files/folders in this share?  

*But does this work even in theory since it could limit the other regular users from accessing that folder, which may be ok if root still has ability to access the files for modification purposes.  And does this use of root to manage these files present another risk of its own perhaps...

2) The  main concern is system security exploits, and what I would like to know is other tools (network related??? -- maybe if iptables would help to improve the NFS server...also really any of the servers like SSH or FTP  beefing up security to the box in that way....and patching up any potential PC exploits...any suggestions are welcomed.  

Here is my emerge info for the server...

https://paste.pound-python.org/show/hNgKlSgh0wmX3WiLiyLH/

Thanks much!

----------

## NeddySeagoon

LIsLinuxIsSogood,

Tell us about your network topology and the restrictions from getting from one segment to another.

I have a boundary firewall with four network interfaces.

The internet.

WiFi

Wired

DMZ, which gets carefully controlled incoming connections.

Nothing is allowed out from anywhere unless its expressly permitted.

Wired can connect to anywhere.

WiFi can connect to anywhere except wired. (Wifi is not to be trusted)

DMZ is for publicly accessible services. 

You will have something like the above.

Do you have untrusted users on your network. (Children count as yes, they know no fear and will just try things)

Is your NFS server available from the outside world?

The right answer is no for lots of reasons.

----------

## LIsLinuxIsSogood

The NFS server is not available (at least in theory) to the outside world.  There are no routes to easily get in there in other words, since the links to it are all local, I often don't even have the machine connected to a gateway at all.  But since that can change at times, and I would imagine the main concern would be coming from somewhere on the internet that the network is sort of the crucial point here....so as requested:

1.  Every device that is on the network has either 1 or 2 basic network interfaces, either a wireless and a ethernet, or just a wireless (for the gadgets, like iphone and firetv stick) 

2.  The desktop server is no exception to that and has 2 NICs, which as I mentioned is only sometimes connected to the internet but usually accessible to all the machines via a route (whether wireless or wired depends)

3.  The wireless router as well as the ethernet plugging cabapility for the laptop and desktop are only there as a resorting to for printing and stuff like that, and generally since I have a limited internet connection at home I don't use the router that much anyway, since it's primary role was to route packets going through the gateway.

I know it isn't a typical situation, but that is why I would like to take the added measures to secure the NFS service.  Please help!

----------

## NeddySeagoon

LIsLinuxIsSogood,

If your firewalling and segregation is good enough, NFS is fine on a trusted network with trusted users.

Given sufficient paranoia, you can tunnel NFS over ssh.

If you want to do that, look at sshfs instead.

Is the threat NFS itself or any access?

NFS can be protected (not secured) by only sharing read only, sharing as group nobody user nobody.

The user nobody has no disk access.

```
man exports

man nfs
```

are both good reads.

----------

## LIsLinuxIsSogood

Ok, so started reading and I already have another question...since I often use different network addresses for the interfaces on the machines I am wondering if having the export file allow connections from all addresses using the '*' (asterisk) for addressing poses any security concerns itself, considering this has at times been necessary so that I could include two different subnets to the share.  Maybe there is a preferred way that involves identifying two different ip ranges, like in the 10.0.0.0 subnet and in the 172.168.x.x subnet

I forgot to mention one use of the NFS server is so that I can save files right onto my servers hard drive while working on my laptop.   That is one of the reason that the different subnets issue has come up, since it is often a direct ethernet cable that connects them...although I would like to know how this could be done using another protocol perhaps.  Does this appear to be a situation that could be handled by PPP or some other tunnel between the two machines?

Also, does the use of * in exports file seem to be a threat?  Besides the fact that the server isn't exposed to specific incoming traffic according to my estimates, at least...one thing that I don't understand is how downloading or streaming in general from the internet consitutes a protected or secured way of dealing with the files that then get saved or executed on any of the hosts.

Doesn't this open up a path for attacks...what in general secures against that?

----------

## krinn

If you want "more than one range", specify them in the nfs server, but don't allow any IPs to access it!!! (that's what * do)

Basically, if you specify a range that is not a network range, you're a totally crazy.

----------

## Hu

To build on Neddy's first post in this thread, if you care about securing resources, you should structure this as a fail-secure design.Disallow everything.Enumerate specific permitted uses and allow those, with as much specificity as you can tolerate: use per-host, per-port rules at minimum.  For example, permitting NFS for the desktop should not necessarily permit NFS (even read-only) to other hosts (unless those other hosts also have a specific reason to use NFS).If a host is multi-user, try not to allow anonymous protocols from it, since you cannot distinguish different users on the peer if the protocol is anonymous.Never use wildcards.  Use netmasks only to group hosts that have identical permissions.Export read-only except for hosts that have a legitimate need to write back to the share.  Read-only restrictions should be enforced in the server configuration, so that no user, even root, on the client can write.

----------

## Ant P.

You only need to keep tcp 2049 + tcp/udp 111 open if you use NFSv4 (and I'm not sure about the latter), so disable NFS2 and NFS3 support entirely.

----------

## NeddySeagoon

LIsLinuxIsSogood,

Wildcarding the Private Network Ranges is comparatively safe from the outside world, since these ranges cannot be routed to you over the internet and if you send them out, eventually you will get a nastygram from your ISP. You router should drop them.

With IPv6, its a whole new can of worms, since IP addresses beginning with a 2 are global, that is, on the internet unless you do something about it.

Everything denied except that which is expressly permitted is always a good approach to security.

----------

## LIsLinuxIsSogood

 *Quote:*   

>  you're a totally crazy.

 

I am offended....actually I'm not offended it was just a joke! (EDITED on Friday, January 26 2:28 pm PST)Last edited by LIsLinuxIsSogood on Fri Jan 26, 2018 10:28 pm; edited 2 times in total

----------

## LIsLinuxIsSogood

Thanks for the great suggestions, by Neddy and others, I have just a couple of follow ups

 *Quote:*   

> Export read-only except for hosts that have a legitimate need to write back to the share. Read-only restrictions should be enforced in the server configuration, so that no user, even root, on the client can write.
> 
> 

 

This seems particularly helpful and useful, but true as well.

 *Quote:*   

> With IPv6, its a whole new can of worms, since IP addresses beginning with a 2 are global, that is, on the internet unless you do something about it. 

 

I didn't know that!

 *Quote:*   

> You only need to keep tcp 2049 + tcp/udp 111 open if you use NFSv4 (and I'm not sure about the latter), so disable NFS2 and NFS3 support entirely.

 

Why would I disable the support to those, in terms of security are you saying there is a potential problem there?

Also, Hu one thing I didn't get exactly about your more detailed answer is whether or not the hosts or users are the ones being authorized to connect.  Since both could easily be "spoofed" in a hack scenario so that is sort of one aspect of the protecting against a threat I'd like to get more into, such as not just the read-only permissions, but also the ability of users to access the NFS server, not just hosts.  

Specifically with something like my firetv stick which i don't know what user it has on it to access the server, but it seems to work given the current settings.  I would like to not change that is working but wouldn't mind knowing a bit more about how to change the server setting to better protect.  If it is just using the ip addressing is that enough?

----------

## Hu

 *LIsLinuxIsSogood wrote:*   

>  *Quote:*   You only need to keep tcp 2049 + tcp/udp 111 open if you use NFSv4 (and I'm not sure about the latter), so disable NFS2 and NFS3 support entirely. Why would I disable the support to those, in terms of security are you saying there is a potential problem there?

 There may or may not be an issue there, depending on how it's configured, whether you are current on security patches, etc.  However, building on my earlier suggestion to disallow everything not specifically required, if you can get all your authorized NFS clients to use NFSv4, then why leave open NFSv2 / NFSv3 if no one has a legitimate need for it?  Lock them out so you do not need to worry whether you secured them properly.

 *LIsLinuxIsSogood wrote:*   

> Also, Hu one thing I didn't get exactly about your more detailed answer is whether or not the hosts or users are the ones being authorized to connect.  Since both could easily be "spoofed" in a hack scenario so that is sort of one aspect of the protecting against a threat I'd like to get more into, such as not just the read-only permissions, but also the ability of users to access the NFS server, not just hosts.

 Users where possible, hosts where necessary.  If the peer is expected to be multiuser-aware (mostly: shared Windows laptops, or Linux systems that allow ssh or for which users timeshare the console), and you can get the peer to express the user identity in the transport protocol, then implement the access control in the transport layer.  For example, if you don't want daughter@laptop to have the same access as wife@laptop, so if host laptop can tell you which person is using it, you should use that to enforce that daughter@laptop not access resources she should not.  As a counterpoint, if daughter@laptop and wife@laptop are supposed to have equal access (which for a media share, might be true (or might not if there are R-rated movies you don't want daughter@ to watch alone)), then there is no point caring which person is on the laptop.

 *LIsLinuxIsSogood wrote:*   

> Specifically with something like my firetv stick which i don't know what user it has on it to access the server, but it seems to work given the current settings.  I would like to not change that is working but wouldn't mind knowing a bit more about how to change the server setting to better protect.  If it is just using the ip addressing is that enough?

 For a simple device like a FireTV stick, it's probably impossible to get it to tell the server which people are using it.  IP limitation (and maybe port if you want to be very cautious) is the best you can do there.  Then you need to decide whether the FireTV stick has permissions equal to the union of all people (meaning, if anyone who uses the FiveTV stick is permitted to watch this content, then the FireTV is permitted because it might be under control of an authorized user) or the intersection of all people (meaning, FireTV can only watch content that is approved for the whole family).  That decision depends on policy and trust: do you trust each person to respect the security boundaries or do you want those boundaries enforced by the system?

----------

## LIsLinuxIsSogood

I think I understand, since firetv stick is a simple device (simple in the sense of the stock system on it, and if it is not a rooted device, which it is not because otherwise i would have something completely else like a rapi or some other small device which doesn't actually have to be so simple).  But I digress.  The configuration on the server side makes sense in terms of securing the service, I agree.  I just wanted to know a bit more about NFSv2 and v3, which are not in use but I will have to read up on the differences.  Thanks again!

On a completely unrelated topic, I have a question about granting access to files on the file system so that I can not have to run the command or program as root.  The tool specifically I want help with has a gui component, which is attempting to read disk usage of disks, but to be able to do so it needs to have at the very least read (and) execute permissions to every location.  Which it does not. Currently only root has that.  How do I alter my file access control to give another user these permissions, and maybe should I also probably create a new user/group for so that I will not need to be messing with or changing anything about my regular everyday user file permission stuff?

----------

## LIsLinuxIsSogood

I just checked my kernel, since that is where NFS server was built into, and NFSv3 is a "forced" option of NFS server.  So there goes the idea of somehow eliminating that unless I build the server outside of the kernel, which could be another option.

EDIT: I am on kernel 4.14.8-gentoo-r1  from the gentoo-sources branch of sys-kernel/

----------

## NeddySeagoon

LIsLinuxIsSogood,

You can build the NFS server kernel to support only NFS v4.

That makes using the server to net boot a diskless system a PITA but it may not matter to you.

 *LIsLinuxIsSogood wrote:*   

> I am on kernel 4.14.8-gentoo-r1 

 

Eww. Spectre and meltdown will haunt you. That's a whole new topic though.

----------

