S 5.17 Use of the NFS security mechanisms

Initiation responsibility: IT Security Officer, Administrator

Implementation responsibility: Administrator

NFS (Network File System) allows common use of files from all computers (clients) which are integrated in the same network and have obtained the pertinent rights on the server. Each server can also be operated as client and vice versa. It has to be ensured that every computer works only with the function assigned to it. Thus, for instance, it is not necessary to start the mount daemon mountd or the NFS daemon nfsd on a NFS client.

• On a NFS server, every file system and/or directory which can be mounted by other computes must be entered in a file (e.g. /etc/exports or /etc/dfs/dfstab). The following requirements apply in this case:
  • Only file systems absolutely necessary should be exported.
  • With the key words root= and access=, it is possible to precisely define the computers to which file systems are to be released for export. If no specific computers have been designated, the respective file system is approved for use by all computers, and this must be avoided by all means!
  • For read-only file systems, and these include all executable files, the ro (read only) option should be used.
  • Normally, the user ID of the system administrator (UID 0) will, for NFS queries, be reset to the number of the user nobody (UID -2 and/or 65534) so that files with the UID 0 cannot be accessed via NFS. This does not apply to files belonging to other privileged users such as bin or daemon, a fact which will also have to be borne in mind in the context of the division of administrator roles (S 2.32 Establishment of a restricted user environment), i.e. file systems with files comprising files of these users must not be exported. Since any computer within the network can assume any IP and, for instance, any PC user has root privileges under DOS, mapping of root to nobody should not be disabled, and it should be ensured that the entry nobody:*:-2:-2:anonymous user:: in the /etc/passwd exists and is effective. In this context, it must also be borne in mind that any user having root privileges on network computer (e.g. as PC user) can, via NFS, also assume any group ID so that consequently no exported directory and no exported file should have group write rights and, moreover, should only have read and execute rights to the extent absolutely necessary. In addition, attention should be paid to the fact that only individual files, but all higher-level directories must be protected!
  • The anon=-1 option should be used to prevent anonymous queries. anon=0 (root) should never be used as this makes it possible for any user to access files with root rights.
• In files such as /etc/fstab or /etc/vfstab, those file systems are lists which can be mounted by a command such as mount -a or mountall. This might also occur even without a query during booting. Therefore, the file must be checked for correctness in good time.
• The /etc/exports and /etc/fstab files (and/or similar files on other systems) are system files to which only the system administrator may have access.
• File systems to be exported should be installed on a separate disk or partition so that, for instance, a user will be prevented from filling the system disk from another computer by writing without authorisation.
• For mounting of exported file systems, the nosuid option must be used in order to prevent the execution of suid programs on the client.
• Where possible, the NFS daemon should be configured in such a way that it will automatically carry out a check of the port numbers in order to ensure that only packets from the privileged ports 0 - 1023 will be accepted.
• For the identification of files, so-called file handles are used between client and server, which can be guessed easily. Therefore, they should be randomised by means of the fsirand program.
• Where available, SECURE-NFS should be used to ensure that data will be transmitted in encrypted form. In this respect, the following steps are important:
  • generation of keys for all users;
  • deletion of the public key for the user nobody;
  • rpc.ypupdated must not be run on the NIS master server;
  • transfer of the public key map to all computers before SECURE-NFS is started;
  • use of keylogin and keylogout for the generation of private keys when logging in and out;
  • the keyserv daemon must run on every client;
  • the secure option must be used for mounting;
  • the clocks on all computers must be synchronised, since the transmitted packets are provided with timestamps in order to prevent messages from being restored.

Review questions:

• Is it ensured that every server and every client only operates with the functions assigned to it?
• Are the files systems and/or directories which can be mounted reduced to the minimum necessary in the /etc/exports and/or /etc/dfs/fstab files?
• Are the file systems and/or directories which can be mounted only released for certain IT systems and/or users while taking the defined authorisation structure into account?
• Use of SECURE-NFS: Are the security mechanisms and settings for SECURE-NFS used?