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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[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.

[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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[LIsLinuxIsSogood]

[LIsLinuxIsSogood]

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

[Hu]

[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.