Security concerns
-
So, I’ve tested Fog and it’s great but I’m concerned about the lack of security for the NFS image folder.
By default, from my test, anyone that has LAN access (same as fogserver) could simply connect to the “advertised” NFS ip/path you see on the deploying screen ("using image from 192.168…/images/nameofimage) and copy the files for future investigation from another linux.
Why secure the web interface with SSL, login page and MySQL passwords when you could simply copy the entire structure remotely and reclone from another FOG install ?
I’ve lurked the forums searching for NFS security to find answers. Maybe I’m wrong, I don’t know?
- NFS is faster
- No security needed in intranet
- Don’t put FOG on the public side
- Use an IP filter or limit IPs in exportfile
- SMB is slower and not native to Linux
What are the solutions ? You’d think students would not try anything but in fact they will.
- Are the DD images crypted on the fly ?
- Is there a way to hide, on screen, the NFS path used when deploying ? That way, you can randomize a NFS folder. (security thru obscurity)
I’m just trying to secure the image depot and it’s strange nobody cares ? Maybe the users don’t know their files aren’t secure at all?
Thank you for your time.
-
@masterofus said in Security concerns:
I’ve lurked the forums searching for NFS security to find answers. Maybe I’m wrong, I don’t know?
- NFS is faster
- No security needed in intranet
- Don’t put FOG on the public side
- Use an IP filter or limit IPs in exportfile
- SMB is slower and not native to Linux
I can not refute anything you found. It is as you listed. NFSv3 is insecure (more on this later). That is why a FOG server should never be connected to a public internet.
What are the solutions ? You’d think students would not try anything but in fact they will.
Especially CS students.
- Are the DD images crypted on the fly ?
The image files are not encrypted, but they are compressed/decompressed dynamically. You can’t just technically read the file and get anything of value out. Consider that this is a disk sector copy, with block crc hashing, that is compressed and packed into a partition based image file. Its not a simple as a straight DD dump. If you knew what you were doing, could you extract the disk image, Yes. If you knew what you were doing, could you mount the extracted partitions, yes. So what would you have? FOG is not a backup solution.
So I just have to say this part, so what if someone gets a copy of the image? What harm will it cause? There should be no PII or user created data in it. It should be just a clean image. So what are the risks. We want to make sure we put the effort into the project where its going to return the best results based on the investment of time.
- Is there a way to hide, on screen, the NFS path used when deploying ? That way, you can randomize a NFS folder. (security thru obscurity)
Hiding the NFS path, that’s possible since if its printed, the print command can be removed. We’d have to identify where in the imaging process its being displayed. Can you randomize the nfs folder, no since nfs doesn’t work that way. You would have to restart the nfs server on the fog server every time you wanted to change the export path.
If you only allowed imaging from a specific network, yes you could add the IP filters on the nfs export to limit who could connect to the nfs share.
I’m just trying to secure the image depot and it’s strange nobody cares ? Maybe the users don’t know their files aren’t secure at all?
You have to consider that the majority of the sites that use FOG is for windows based imaging, not linux. So in the case of NFS, MS Windows is a bit ignorant of the protocol (yes I know you can add services to allow NFS). So since windows can’t nativly communicate with an NFS share then that data is pretty protected. As well if the windows box does get ahold of the image file, they will have a 25GB blob. What will they do with it? In the linux world, someone with the intent and a bit of skill could extract the image file.
Now one of the things I experimented with was NFSv4. I have imaged computers with NFSv4. The structure of NFSv4 is a bit different than v3 so its not a straight migration but it can be done. Moving to NFSv4 would go a long way to increase the security of the FOG imaging, plus make creating firewall rules much easier since nfsv4 uses a single data port for communications.
So the final thought is this. What you have pointed out is definitely a flaw in the FOG imaging environment, here in the year 2022. Security should be the primary focus. But with limited developer resources at the moment some of these advanced security features are on the roadmap but not being actively implemented.
-
Hi George,
“Hiding the NFS path, that’s possible since if its printed, the print command can be removed.”
By removing the [IP/PATH/] and just showing the [image name] would be enough information to validate the active task on the computer and would limit any leaked information to a spying eye, say, looking thru the door bay. I don’t think NFS shares are broadcast on the network (or by querying the server), is it? Someone would need to know the actual folder name before mounting it.
“Now one of the things I experimented with was NFSv4.”
That’s a good idea. I think you can use ACL with NFSv4.
If we go real simple, limiting access to the share would prevent any image leaks. I don’t think it’s a problem sending the user:pass in plain text (cmd) to each LAN computer when deploying. As long as it’s invisible on the clients screen.
I’ll try to come up with something on my side.
-
@masterofus said in Security concerns:
I don’t think it’s a problem sending the user:pass in plain text (cmd) to each LAN computer when deploying.
Wouldn’t that be more or less security by obscurity. Pretty similar to what we have right now? Someone keen to grab an image can eavesdrop and get the credentials. Sure the hurdle is a little bit higher than before but not high enough for anyone keen enough. I don’t want to take a swipe at you. I think it’s important to discuss this and find a more secure solution than what we have right now.
There was an interesting discussion on this topic in the forums and I am wondering if using SSH would be the best compromise.
-
@MasterOfUs Now that I have had a good sleep I figured that proposing to use SSH is just raising the hurdle once more but not solving the concern. Why? Because some kind of secret (probably SSH key) needs to be included in the FOS inits to authenticate when connecting. Even if this is done properly (random generated key pair) we can not prevent an attacker from loading the FOS init manually and extracting the secret, right?
So making it secure would mean the user needs to enter a connect passphrase manually on each deploy/capture.
