Chapter 13: Networking Configuration

Overview

The fourth category tab in Webmin is for Networking-related configuration. Specifically, this is where you'll find the modules to configure inetd or xinetd, iptables, NFSexports, NIS client and server, and network interfaces. The Networking category was introduced in Webmin version 1.0, so if for some reason you are using an earlier Webmin revision (upgrade already; it's free!), these modules will be found under other category tabs.

NFS Exports

The NFS Exports module lists all exported directories. Clicking Add a new export will bring you to the Create Export page, as shown in Figure 13-1.

Figure 13-1: Create NFS export

In the preceding figure, you can see that the module allows you to select a directory to export, and choose a number of options for that directory and to whom the directory should be exported.

Export Details

The following options configure the location, type, and permissions of the directory to be exported:

Directory to export

This is simply the full path to the directory you would like to export.

Active?

An export may be disabled when it is not needed by selecting no. Otherwise the export will always be active and available as long as the NFS server is running.

In the next few fields it is possible to select access controls to dictate which machines or users on the network will be permitted to mount the exported directory.

Everyone

Specifies that anyone may mount the directory. This is similar to an anonymous FTP server.

Caution 

Use extreme caution when exporting a directory to everyone. If your local network is not protected by a very good firewall, it will be possible for outsiders to mount your exported directory. It may also be possible for outsiders to stage a denial-of-service attack against your server, as NFS is not renowned for its reliability in the face of determined attackers. It is always a good idea to restrict NFS exports to just those machines that need access, and additionally to implement a firewall to block anyone outside of your local network from even attempting to connect to your NFS server.

Host(s)

Allows you to specify a host name or IP that may mount the directory. Wild cards are accepted in this field as well, so that names of the form *.company.com can be entered to match all hosts in the company.com domain.

WebNFS clients

WebNFS is a relatively new protocol that has been developed by Sun, who also created NFS, and is designed for file sharing across the Internet. It allows users to browse exported directories using a familiar web browser as the interface. It has largely been ignored by the mass market in favor of WebDAV, but it may have its uses in some environments. If you will be supporting WebNFS clients with this export, select this option. Not all operating system variants support this option, or if support is provided it may not be complete or stable.

Netgroup

If your local network uses NIS services, you may use netgroups to specify access to exports. Any existing group name may be specified here.

Network

To export to all hosts on a given network, enter the network number and netmask. This may be a full network class, or it may be a smaller subnet.

Make symbolic links relative?

On NFS mounted directories, symbolic links can pose a problem, due to the change in where a directory might be mounted on the client machine. For example, a directory located on /home/nfsusers on the NFS server may be mounted on the client on /home. If a symbolic link on the server points to /home/ nfsusers/joe/work, the link will be broken on the client machine if the link is not converted to a relative link. If made relative, the link will become joe/work and will work fine on the client machine. This option corresponds to the link_relative switch.

Clients must be on secure port?

The effect of turning this option on is that NFS will insist upon a connection on ports below 1024. This does improve security in some circumstances, but may interfere with Windows clients mounting the exported directory. In reality, security of most current NFS variants in use is relatively weak, providing only mediocre authentication methods and no data encryption.

Note 

In UNIX systems, software run by a normal user is not permitted to bind to a port below 1024. This means that only the root user on a multi-user system can start services that run on ports below 1024. The security implication of this is that when you connect to a UNIX server on a port below 1024 (such as making an NFS connection when this option is enabled) you may have some assurance that the NFS server is one being operated by the administrator of the server. If the NFS server has normal users, and NFS connections are not forced to be made on low ports, it might be possible for a malicious user to operate an illicit NFS server whose only purpose is to obtain access to parts of the network he should not have access to. As discussed earlier, Webmin is often run on port 1000 or some other sub-1024 port in order to avoid this risk for the Webmin server.

Export Security

In the Export Security section you can specify several other security options, including the ability to treat some UIDs and/or GIDs as untrusted users. This section also provides fields for declaring what user and group name will be used for the untrusted users' permissions.

Access mode

The exported directory may be mounted for reading and writing, or just for reading. This option correlates to the ro and rw switches in the exports file.

Deny access to directory?

Normally, when a directory is exported, all of its subdirectories will be exported with the same access rules. This is usually exactly what is desired, as in the case of exporting home directories to users via NFS. Obviously, the users will need to access everything in their own home directory, including subdirectories thereof. This option explicitly denies access to a directory, when the connecting client matches the export rules in this export. This can be useful to explicitly disallow access to a subdirectory of a directory that is exported in another rule. This option corresponds to the noaccess directive.

Trust remote users

NFS provides a simple trust model, wherein some users will be trusted, all users will be trusted, or no users will be trusted. To be more explicit, when another computer on the network connects to your NFS server, the UID of the user attempting to access the exported directory is included in the negotiation process. Depending on the configuration of this option, the user may be able to use files with the same permissions as if he were working on the local machine, assuming other configuration details don't prevent it. If either Everyone or Everyone except root are selected, all normal users will be able to use the files on the NFS export as though they are working on the local machine. The root user will have this same ability only if the Everyone option is selected. In the case of exporting user home directories, it makes sense to enable the Everyone except root option. The Nobody option means that the connecting user will always be treated as the untrusted user. This option sets the no_root_squash and all_squash directives. The default is Everyone except root, which correlates to the implicit root_squash directive.

The untrusted user is a user that is used specifically for NFS, but it is very similar in function to an anonymous user on an FTP server. This can be useful for many situations where some or all client machines are not directly under the control of the administrator of the NFS server. A common use for such exports is system boot images and anonymous access to file or document repositories.

Don't trust UIDs, Don't trust GIDs

If there are specific user IDs or group IDs that should be treated as the untrusted user, they may be specified here. The IDs may be specified as a range, such as 0-500, or as a comma-separated list or a combination of both. Most UNIX variants reserve some subset of UIDs and GIDs for system-specific users and groups, like nobody and lp. It may be useful to distrust a user claiming to be one of these system users or groups. This option correlates to the squash_uids and the squash_gids directives, respectively.

Treat untrusted users as, Treat untrusted groups as

This option specifies the user ID and group ID to which an untrusted user or group is mapped to. If unspecified, the untrusted UID or GID will be set to the default of the NFS server. This varies somewhat between NFS versions, but it is safe to assume the default is a user or group with very limited permissions, and is usually an appropriate choice for the system on which it is running.