Securing NFS
-
Hey,
We recently had a penetration test done at my work where it was listed that the fog server has overly permissive NFS in where they were able to gain access to the images directory.
I’ve done a bit of reading on what can be done to tighten up security but a few solutions I’ve seen such as Kerberos seem like it could potentially have impacts to how the fog server operates.
I came across NFS security on the fogwiki - https://wiki.fogproject.org/wiki/index.php?title=FOG_security#Securing_NFS suggesting more to come soon however this was mid 2016, just wondering if there might have been an update?
I don’t know a great deal in this area but I keep thinking that by securing it, will I then run into issues when trying to upload/deploy an image onto a random device?
There’s also a section on ‘securing your images’, by doing the two steps mentioned in that section, would this in a way cover off ‘securing NFS’? I imagine it stops being able to connect to the images directory of the fog server without account access but if that was the case, wouldn’t that cover the securing NFS? Probably not that easy, my understanding in the area in minimal so I’m understanding the basics without fully understanding how it works.
-
NFS is kind of an old technology. While there are some things that can be done to secure it, it is only stop-gap type fixes (meaning immediate fixes, but not quite true corrections).
For example, one of the biggest permission issues with NFS is the fact that the server runs as root. I’m sure you can change that, but whoever the ID of the nfs share is has total access to the filesystem. So let’s say, you set your NFS share with a user id of root (UID 0), any system that mounts that filesystem in read-write mode that has the UID = 0, has full reign on those files. There isn’t a nice mechanism to correct for this. Kerboros is an option, but it’s fairly complex to incorporate and I’ve never seen it actually done.
While there are some minor things we can do to help secure it (which we kind of do already: read write is only allowed in the /images/dev folder, where the /images folder is read only) it would not be a good tool to use if you really are worried about access control over the /images folder. You should, ultimately, be using Samba, or some other sharing utility that has access control. (Not a simple thing to implement in the current state of FOG sorry.)
-
Agree with all Tom’s points, NFS is not a simple protocol to harden.
What I recommend is VLANing your FOG network so it is manually exposed via your switch configs. Does require managed switching, but will accomplish the task.
-
@fishfox said in Securing NFS:
Agree with all Tom’s points, NFS is not a simple protocol to harden.
What I recommend is VLANing your FOG network so it is manually exposed via your switch configs. Does require managed switching, but will accomplish the task.
Yeah that was kind of what I was thinking as I believe you can restrict access to particular IP ranges and then just having it on another VLAN range which is accessible from my desk - given I usually do all imaging at my desk.
Kind of thought the below would be the response but figured I’d ask the question as you guys know a lot more then me.
-
@dylan123 There are a few ways to do this – either have selective routing on your layer three devices to the FOG network or just hard switch clients to a FOG VLAN with its layer two environment. Either should work from a compliance perspective.
-
You also have to ask your self “What are the risks of having nfs on your fog server configured this way?” Is the data contained in your images a high value target? Do they conain PII or PCI or regulated data? How could the data contained in these multi-gigabyte images be used against your company or for financial gains of the hackers?
Yes the fog server’s nfs shares are a bit open. You can restrict access with NFS v3 to a range or subnet of IP addresses. NFSv4 could be implemented but other than ticking off a check box what is the real value of the activity? What are you trying to protect?
I can’t answer these questions for you, its based on what your company is trying to protect and the risks of doing something vs nothing.