Permissions on /images directory

[jhorner]

Hi, I’m working on hardening my Fog server (Ubuntu 14.04) and ran a vulnerability scan with Nessus. The highest severity result was “NFS Share User Mountable” relating to the /images directory that Fog uses. I’m wondering if changing permissions or configuring NFS differently will break Fog. Are there other methods to secure this directory that won’t impact Fog?

I’m assuming these shares are open so that hosts being imaged can access it. What’s the worst that could happen? I’m imagining a scenario where an attacker copies an image, deploys it, and are then able to take their time to enumerate local creds.

Here are the complete scan results:

Description

Some of the NFS shares exported by the remote server could be mounted by the scanning host. An attacker may exploit this problem to gain read (and possibly write) access to files on remote host.

Note that root privileges were not required to mount the remote shares. That is, the source port to mount the shares was bigger than 1024.
Solution

Configure NFS on the remote host so that only authorized hosts can mount the remote shares.

The remote NFS server should prevent mount requests originating from a non-privileged port.
Output
The following NFS shares could be mounted without root privileges :

• /images

  • Contents of /images :
    • .
    • …
    • .mntcheck
    • 2035Wonetime
    • 2037W
    • Win10
    • Win10Silver
    • Win10Gold
    • Win10TestPreSysprep
    • dev
    • postdownloadscripts

• /images/dev

  • Contents of /images/dev :
    • .
    • …
    • .mntcheck

[Wayne Workman]

The Worst That Could Happen by changing permissions and the way NFS allows mounts is the actual Imaging process may just simply not work. You won’t crash your server or anything like that.

If you’re good enough with shell script then you can modify the fog init upload and download Scripts to use cifs instead of NFS and then password protect a Samba share on your server.

I’ve been planning on creating a fork of the fog inits for some time in order to allow for Imaging / Samba more easily for everybody but I just haven’t done it yet.

Another option you could do, although more oversight involved, is to only run the NFS service on the fog server when you need to image and when you are not Imaging simply disable it.

One last option which is probably the most complex but may offer some level of obfuscation would be to set up the fog firewall to only allow Communications from MAC addresses that are known.

The samba option is probably the most simple and most secure. I have successfully image with fog using samba before but I was in putting in the commands to manually mount and then starting the fog Scripts manually afterwards.

[george1421]

If your clients connect from a certain subnet/address range you can limit what devices can connect to your FOG server.

For example if you always build your workstation on a build up network, you can then configure linux on the FOG server to only allow nfs mounts from that specific build up subnet. The /images share is only used as read only from the server perspective. The /images/dev share is write only and used during image capture. If you only capture images from a specific subnet then you can also constrain access to that share.

From a security perspective any client you deploy to has to be able to mount and read from the /images share. For image capture clients have to be able mount and write to /images/dev.

You can additionally constrain access to the fog server by enabling the linux firewall and only opening up specific ports to specific subnets/network addresses. There is a pinned tutorial on how to setup the linux firewall in the fog forum.

[jhorner]

Thank you both for your knowledge and suggestions. I have a couple of routes to explore. Thanks!