Permissions on /images NFS share
-
Hi All,
It has been a while since I have posted as FOG is working beautifully for us at the moment. I have actually been able to look at some proactive things like security on our infrastructure. This brings me to the point of this post.As a disclaimer, I am far from a security guru. In fact, I’m quite new to it. I am using a penetration testing solution to try to start figuring some of this stuff out. During my testing on the FOG server here, a few things popped up as critical/high level warnings. I was spooked at first but then I noticed that anything that was flagged had to do with the /images NFS Share.
The first flag was for “NFS Exported Share Information Disclosure”, basically saying that the /images share could be mounted by scanning the host. I figure this is like this so any host can pull from this share during capture/deployment. If this is the case, I am fine with it. If I screwed something up a while back with permissions and left a gaping hole in the security of this server, I’d like to find the best practice for setting permissions for this share. Ideally it would be moderately secure but (very importantly) still be able to image indiscriminately throughout our network. I can provide more info if needed, but I appreciate any input.
The second flag is also related to the /images NFS Share. This one also points to a permissions issue. “The NFS share is user mountable”
I appreciate the help guys and keep up the good work!
Like open source community computing? Why not do it for a good cause?
Use your computer/server for humanitarian projects when it is idle!
https://join.worldcommunitygrid.org?recruiterId=1026912 -
@fry_p The issue is really NFS v3 (period). NFS v3 is not a secure protocol at all.
The FOS engine uses nfs to capture and deploy images to the target computers.
The /images directory is read only. The /images/dev is read write.
Images currently being captured are written to /images/dev/<mac_address>
Once the capture is done, the FOS engine connects to FOG via FTP and moves the files from /images/dev/<mac_address> to /images/image name. Its a bit of ingenious code that does this since a linux move is just a rename of the directory path so there is no copying about of multi-gigibyte files once the upload is over.
With current NFS v3 the only option you have is that you can restrict who can mount the nfs share to a certain IP range. But anyone in that range can mount the share (using unix) without restriction.
So now you have to ask yourself what are the risks to having this share open to world read/write on /images/dev and world read on /images? Are you storing any PII or GDPR regulated data on those shares? What are your true risks here.
The better answer would be for FOG to support NFSv4 with kerberos authentication. That’s possible but not currently implemented in FOG. That setup also puts a bit more burden on the FOG server OS to have kerberos setup.
I have also thought about NFS via a SSH (TLS) tunnel. But that based on research seems to cause a serious performance impact of image throughput. I also thought about imaging over openvpn, but that would require FOS to support an openvpn client. This openvpn route does open some interesting possibilities, but from a performance standpoint I think NFSv4 is probably the right answer.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
Hey @george1421
Thanks for the reply and I apologize for the delay in my response. I am now 100% sure that there is little to no danger in having this open in my situation. Our images are free of any sensitive info and all licensing is done through KMS, so no possibility of stealing software activation codes either. I’m glad the project developers have NFS v4 on the feature radar for possible distant releases. Thank you for the thorough explanation and putting into terms someone like me can understand. Keep up the good work guys. -
@fry_p Clonezilla can handle cifs for source/target, so I’ve debated trying to make fog work with a AD secured share. Honestly, I’ve LOVE to be able to run fog as a service from a nano server instance using AD for security/auth…
-
@george1421 I imaged via FOS from a samba share once. I couldn’t see any performance impact. It’s really easy to setup a password protected Samba share also. FOS already has CIFS support built into the kernel. I think Samba is the easy short-term answer.
-
From a security standpoint I dont see using NFS for imaging as an issue. As mentioned you can set it to allow only from a specific IP range. That should be enough to prevent issues (if a adversary is already on that subnet you have bigger issues). Especially if you dont have sensitive data in the share and if your FOG server is behind a firewall.
Samba would have the ability to allow only connecting from approved users or groups, the problem with that is passing the credentials to connect.
In Clonezilla I used to capture and deploy via SSH, which I really liked, but havent had any issues with how FOG handles it via NFS.
Your first warning, as it seems you have figured out, is I think kind of a basic way NFS works. Client machines have to be able to see/query the server for the share to use it. The second warning is just an extension of that, whats the point in knowing the share is on the server if you cant mount and use it.
