With the skyrocketing demand to use the Network File System (NFS) for sharing AS/400 files with UNIX computers, you should be concerned with NFS network security on the AS/400. A secure NFS environment can only be achieved within a closed network of trusted users, but, since such a scenario is rare, many implementations provide ways for you to reach a reasonable level of security. To alleviate your fears and have a more secure AS/400 NFS server, I offer a few commonsense AS/400 NFS security measures.
Restrict NFS commands to certain users. Commands like Start NFS Server (STRNFSSVR), End NFS Server (ENDNFSSVR), Change NFS Export (CHGNFSEXP) and its alias (EXPORTFS), and Add Mounted FS (MOUNT) are all shipped with PUBLIC(*EXCLUDE) authority. Any user given access to these commands also needs *IOSYSCFG special authority. These commands are intended only for system administrator use and should not be distributed.
Export only what you need to. By definition, exporting a path exports all subdirectories beneath it. So, if you need to share data in the /results/data and /finances/data directories, it would be unwise to export /. Export the two paths separately for better security.
Set appropriate permissions on the exported files. This security measure is related to the underlying file system, but, when it comes to file sharing, it is the most important measure to observe. NFS requests allowed by the server will always be mapped to an existing profile, so set up the permissions for those users on the appropriate files and directories. Only give public authority to noncritical data and attach access lists to objects for specific users.
Export only to those who need access. Besides the default file system security provided by the underlying AS/400 file system, NFS on AS/400 provides another layer of security with the ability to restrict access to exports to a specified list of clients. These restrictions are applied through the ACCESS= option on the EXPORTFS command or specified in the /ETC/EXPORTS file. This option only allows clients or netgroups on the ACCESS= list to have their NFS requests processed. If you dont include this option on your export commands, NFS automatically exports the file system to all clients. In addition, the RW= option allows you to specify a list of clients who have read-write access to the exported file system; other clients will have read-only access. The RO option allows all clients who have access to the export to have read-only access. Within the UNIX
security framework, NFS on AS/400 gives you the ability to restrict export access as tightly as you need it to be.
Keep UIDs consistent across a network. NFS authority is based on user and group IDs, not names and passwords. Every AS/400 user profile has a UID associated with it, as do profiles on other NFS systems. When a user accesses a file in a mounted file system on his local client machine and the request for the operation is sent to the server, his UID is also sent as part of the request. The server attempts to match the UID of the request with the UID of an existing profile on the server machine. Thus, you could have a UID of 219 (which represents a user profile for Joe) on your client AIX machine map to the UID 219 (which, in this case, is associated with user profile Bob) on your AS/400 server. To avoid this situation, administrators should ensure that profiles created for a user on each system have the same UID. The AS/400 provides the QSYCHGID API that allows administrators to change the UIDs of existing user and system profiles that own objects. See AS/400 System API Reference V4R3 (SC41-5801) for more information.
Dont allow root access unless absolutely necessary. By default, root access is not allowed from a client that has been exported to. This means that if a UID in an NFS request maps to a user on the AS/400 server that has All Object special authority (*ALLOBJ) the request will not be authorized under that profile. Instead, the UID of the request will be mapped to the anonymous user or rejected. The ROOT= option list on the EXPORTFS command (or EXPORTS file) allows the root mapping (superuser or all-object user) to go through for requests originating from clients in the list. Use this option with care.
If you desire, customize the anonymous user profile. If a request comes into the server with a UID that does not match any UIDs on the system (or, as stated above, the matching UID has *ALLOBJ special authority and the request originated from a host not on the ROOT= list), then that request may be mapped to the anonymous user profile. By default, this profile is the QNFSANON user, which is shipped with limited authorities. This profile can be modified, or a different anonymous profile can be chosen for an export by using the ANON= option on the EXPORTFS command. For example, specifying ANON=540 tells the server to map anonymous requests to the user profile whose UID is
540. Specifying ANON=-1 tells the AS/400 server to reject all anonymous requests. Use a pcnfsd authentication service on a trusted Unix server for PC clients. PC OSs usually arent shipped with the UID/GID profile scheme that NFS requires. In the case of PC clients, a separate authentication service should be used to validate client requests and map them to appropriate UIDs. One such service is the pcnfsd daemon that comes with most UNIX servers. This is the daemon that many PC NFS products will look for on the server by default. The AS/400 does not come with this daemon, so it is necessary to find the configuration dialog in the PC NFS product and point the authentication server to a machine on the network that has this daemon running. Otherwise, you can only obtain anonymous access from PC clients.
Its Time to Implement
To achieve and maintain a secure network of hosts utilizing NFS, it is important to understand the NFS security model. A high level of security can be attained by properly configuring your exports as well as making appropriate choices for file permissions and UID mappings. These tips should give you a better understanding of the issues involved with NFS security and the basics on how to easily implement these commonsense measures.
Reference
AS/400 System API Reference V4R3 (SC41-5801)
Related Reading
OS/400 Network File System Support V4R1 (SC41-5714-00) OS/400 Integrated File System Introduction V4R3 (SC41-5711-02) Exploring NFS on AS/400, Redbook (SG24-2158-00)
LATEST COMMENTS
MC Press Online