S 5.17 Use of the NFS security mechanisms

Initiation responsibility: IT Security Management, Administrators

Implementation responsibility: Administrators

NFS ( Network File System) allows common use of files on a server from all computers (clients) which are integrated in the same network and have obtained the pertinent rights on the server. Every server can also be operated as a 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 an NFS client.

• On an NFS server every file system or directory which can be mounted by other computers 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 required should be exported.

• With the key words root=and access=, it is possible to precisely define the computers to which data systems are to be released for export. If no specific computers have been designated, the respective data system is approved for use by all computers, and this must be precluded at all events!

• For read-only file systems, and these include all executable files, the ro option ( read only) should be used.

• Normally, the user ID of the system administrator (UID0) will, for NFS queries, be reset to the number of the user nobody (UID -2 or 65534) so that files with the UID 0 cannot be accessed through NFS. This does not apply to files belonging to other privileged users, such as bin or daemon, a fact that 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 comprising files of these users must not be exported. Since any computer within the network can assume any ID 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 users::exists, and is effective, in the/etc/passwd. In this context, it must also be borne in mind that any user having root privileges on a networked computer (e.g. as a PC user) can, through NFS, also assume any group ID so that consequently no exported directory and no exported file should have group write-access rights and, moreover, only have read and execute rights to the extent absolutely necessary. In addition, attention should be paid to the fact that not only individual files, but all higher-level directories must be protected!

• The anon=-1option 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 privileges.

• In files such as /etc/fstab or/etc/vfstab, those file systems are listed which can be mounted by a command such as mount -a or mountall. This might also occur even without a query during booting. Therefore, an early check for correctness must be made of such a file.

• The /etc/exports and /etc/fstab files (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 by writing without authorisation.

• For mounting of exported file systems, the nosuid option must be used in order to prevent 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 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 programme.

• 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 NFS 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 and deletion of private keys when logging in and out;

• - the keyserv daemon must be run on every client;

• - the secure option must be used for mounting;

• - the clocks in all computers must be synchronised since the transmitted packets are provided with timing marks in order to prevent replay of messages