Security Position on File System Mounting
The Yale IT Security position towards NFS mounts is that NFS will not be used in the production environment with the exception of where NFS is required due to interdependency between two hosts. It is not the correct tool to use for a simple data transfer. In acknowledging the need for a brokered data transfer utility, the recommendation from IT Security is to utilize other transfer mechanisms such as SCP over SSH.
- Mounting databases can create deadly embraces (file lockouts) if there is any overlap.
- Allows 24x7 access, unless you force the dismount upon logout.
- Mounting mechanisms allows for unencrypted traffic across the network
- If you mount an entire File System (FS):
- This could cause more access then intended as the entire FS could be replaced or modified.
- Potentially allows users to restore deleted files
- If you have the SUID bit set then a user is given a higher access then the rights indicate on the device.
- User IDs (UIDs) need to be kept synchronized, otherwise a user can access someone else's files inappropriately.
- Root can be any other user on remote files systems.
While it is imperative for applications to comply with the principle outlined in the Position section, IT Security recognizes that there could be situations where an exception to the policy is required for an application to function. This section covers the requirement for soliciting and implementing the exception.
- If need to do a file System mount with NFS or Samba, then you must document the following:
- The reasons why this is required.
- What other efforts have been performed to search for another way.
- Why the systems requiring a mount are dependent on each other.
- How the systems are tightly coupled and are interdependent on each other.
- The vendor requirement for this need
- You must have this request approved by your department manager.
- Then this request needs to go to the Systems group for a technical review. They will determine if other alternatives could be implemented. Once they are satisfied that there is no alternative, they will pass the request on to the Information Security Officer (ISO).
- The ISO will review this request and determine if the risk exposure is acceptable for the University or if there needs to be a Senior Leader approval due to the increase in exposure. At that time the ISO will let the requestor know the results.
If approval is granted then you need to use the Configuration Parameters below:
allows clients to access filesystems located on remote servers as though the filesystems were resident on the clients. This allows a filesystem to be stored in one common location and exported to many clients at once instead of replicating it across many systems.
- Because NFS presents such a target of opportunity for attackers, the NFS daemons will not be allowed to run unless NFS is actually being used.
- The NFS version of 3 or 4 need to be used.
- Always use TCP rather than a UDP as TCP is stateful and controlling it is easier.
- The servers with the FS being mounted are both to be behind an ITS Data Center firewall. They can be behind 2 different ITS firewalls but they both must be protected.
- The 2 systems will need the same administration group. The NFS system uses UID numbers to reduce the risk that inappropriate access is not granted to both systems. The need to be administrated by the same group or person ensures users and UID are in sync.
- The export configuration file (either /etc/exports or /etc/dfs/dfstab) will be protected against unauthorized modification. These files contain all the directories being exported and any restrictions, attributes, or options associated with them.
- These files will be owned by Root, not world or group writable, and have a file permission of 644, or more restrictive.
- Access to exported filesystems must be restricted to local hosts via the export configuration file.
- The NFS server must be configured to disallow access from client requests that do not include a UID.
- NFS clients will use the nosuid and nosgid options to mount filesystems to prevent setuid and setguid executables from gaining root access on the client system. If a mounted filesystem has any suid executable scripts or programs, a user who invokes the executable takes on the uid of the executable's owner (typically a privileged user like root).
- NFS exports will run with the secure option set (default setting). This ensures non-root users cannot open a spoofed NFS dialogue on a non-reserved port.
- Port monitoring will be enabled. Port monitoring causes NFS requests that do not come from privileged ports (i.e., ports 1-1024) to be rejected. This integrity checking prevents system users from writing RPC-based applications that attempt to defeat the NFS client access control checking.
- The secure_locks option (option ensures user permissions are checked prior to file access) will be set on Linux versions that offer it.
- NFS server logging will be turned on. This enables a NFS server to provide a record of file operations that are performed on its filesystems.
- File systems will be exported as read only to prevent them from being modified or replaced. Any exceptions will need prior authorization.
- For Solaris systems the secure option of Secure RPC should be enabled (requires NIS or NIS+). This allows NFS to use DES (Data Encryption Standard) for encrypting the authentication session between the server and client.
- The owner of exported system files and directories will be Root.
is a utility allowing file and printer sharing between UNIX and Microsoft Windows operating systems. Samba was created to provide an interface to give the look, feel, and functionality of Windows and enable UNIX systems to become part of a Windows domain, allowing file, directory, and printer sharing. If the Samba utility is required, use the following security configurations:
- If Windows sharing is not a requirement then the Samba utility and SMB (file/printer sharing) should be removed or not installed
- Only use the Samba Web Administration Tool (SWAT) with SSH port forwarding. This tool to administer Samba needs a Root logon and runs as a service on port 901, so by using SSH the root logon will be encrypted.
- The /etc/samba/smb.conf file (Samba uses as the configuration file) will be owned by Root, have a group owner of root, with permissions of 644, or more restrictive.
- The smbpasswd utility will be owned by root, with a group owner of Root, with permissions of 600, or more restrictive.
- The /etc/samba/smb.conf file will be configured to allow access to systems on the local network subnet masks and the loopback address, require the user access mode (each user has an individual password), password encryption, and have shares defined with guest set to No.