LINUX--NFS Quick Configuration tutorial and security policy

There are several ways to implement file sharing under Linux, and NFS is one of them. The Network File System (NFS) protocol was designed and implemented by Sun Microsystem in the 1980s to provide remote access to shared files. The protocol uses the Client/server model to implement a program running on one computer by using the sun-developed remote Procedure Call protocol (RPC Protocol) to invoke a subroutine running on another remote machine, and it provides an external data representation (XDR) Allows data to be exchanged on computers on different platforms. This protocol can be run on the TCP protocol or the UDP protocol, and on this basis, NFS requires the RPC command to be confirmed during the data transfer process and will be re-transmitted when needed.

1, the Principle of NFS

NFS is more complex, including many components that interact through special protocols. Different components use different configuration files and state files in the operating system. Describes the main components and configuration files for NFS.

650) this.width=650; "class=" Fit-image "border=" 0 "alt=" Network File system principle "src=" http://images.51cto.com/files/uploadimg/ 20101028/1414230.png "width=" 317 "height=" 280 "style=" border:0px; "/>
Figure Network File System principle

NFS is divided into servers and clients, each with its own kernel-level services: External Data representations (xdr,external data representation), remote procedure calls (Rpc,remote Procedure call), i/ o Monitoring program and lock monitoring program. Each host also has its own user-level services. Both kernel-level and user-level services depend on the capabilities of the host: the NFS client or the NFS server. Of course, you also depend on the configuration file for the different features used by each host (if the server is the/etc/exports configuration file, or the/etc/fstab profile if it is a client). If a host is both a server and a client, it needs to run a two-part service.

On the server side, the Portmap, MOUNTD, NFSD three monitor programs will run in the background. The PORTMAP monitoring program is used to register RPC-based services. When an RPC daemon starts, it tells the Portmap Monitor which port it listens on and what RPC service it is doing. When a client makes an RPC request to the server, it contacts the Portmap monitor to determine the port number to which the RPC message should be sent. The function of the MOUNTD monitor is to read the server-side/etc/exportfs file and create a list of hosts and networks that export the server's local file system, so that the client's hook (mount) requests are positioned to the MOUNTD Monitor (daemon). After verifying that the server does have permission to hook up the requested file system, MOUNTD returns a file handle for the requested mount contact. The NFSD monitoring program is used by the server to handle requests from the client side, because the server needs to process multiple client requests at the same time, so by default, eight NFSD threads will be started automatically in Linux. Of course, if the NFS server is particularly busy, it is possible for the system to start 30 threads according to the actual situation.

2. NFS Installation

In a networked environment, the commands to install NFS with Yum are as follows:

#yum –y Install NFS

3. NFS Configuration and use

After you install NFS, you need to configure it for normal use, including the server configuration and client configuration in two steps, which are explained in detail below.

Server Configuration

Edit the/etc/exports, listed in the file, to share the directory. The writing rule is: Shared directory host (parameters). And each rule occupies one line. For example:

/mnt/mp3 192.168.10.168 (Ro,sync, No_root_squash)

The above rules represent the sharing of the/mnt/mp3 directory with read-write synchronization to host 192.168.10.168. If the user logged on to the NFS host is root, then the user has the root user privileges of the NFS host.

The specific optional parameters are as follows:

1. RW: Read-Write permissions

2. RO: Read-only permissions

3. No_root_squash: A user who is logged on to an NFS host has root privileges if it is the root user

4. Root_squash: If the user who is logged in to the NFS host uses the directory as root, then the user's permissions will be compressed into an anonymous user, usually his UID and GID will become nobody that identity

5. All_squash: No matter what user is logged on to the NFS host, it will be re-set to nobody

6. Anonuid: The user who will log on to the NFS host is set to the specified userid, which must exist in/etc/passwd

7. Anongid: Same as Anonuid, but it becomes groupid.

8. Sync data in synchronous write memory

9. Async: Data is temporarily stored in memory and is not written directly to the hard disk

10. Insecure allows unauthorized access from this machine.

Client Configuration

The client configuration is relatively straightforward and requires only the Mount NFS file system with the following command:

#mount-T NFS 192.168.10.168:/home/mnt/mp3

The above command hooks the remote shared directory to the local/home directory, where the user can manipulate the directory directly to obtain a remote shared resource.

Start the NFS service

#service portmap start# Service NFS Start

The following is a concrete example of the security Configuration for NFS. Suppose that there is a directory named/popgame directory on a website that can be opened to NFS clients for download sharing, and this server IP address is: 202.168.10.8, it can open directory to the host's IP address is 202.168.10.10, 202.168.10.13 (of course can be provided to more servers, and their IP address can be various, now the example is a bit like the situation in the LAN, but the same principle). Then we need to write the server-side/etc/exports file first:

We first enter the directory/etc, then VI exports, then we will go to the editing interface of the file, we enter the following content:

/popgame 202.168.10.10 (RO) 202.168.10.13 (RO)

We can clearly see that the directory/popgame can only be exported to the IP address of the above-mentioned clients, and their permissions can only be read-only, because they just need to share the ability to download the game simply, do not need to have the ability to create directories, modify the file, and if provided, There will be security implications. Next configure the client's/etc/fstab file, enter the file you will need to add the following content, the original file on the content is not arbitrarily changed, otherwise it will affect the system configuration, affect the file system:

202.168.10.8:/popgame/mnt/game NFS ro 0 0

The/mnt/game directory is where you want to hook the/popgame directory on your server to a local directory on your client, that is, when you share the NFS file system, you can access the shared file by accessing the local directory/mnt/game. Because there are now two clients, each platform should be configured as above.

After the configuration is complete, you need to attach the server's NFS to the local client on the client, as shown in the following command:

Mount–t NFS 202.168.10.8:/popgame/mnt/game

It is important to note that before executing a command, you must first turn off the firewall on the local client, or you will not be hooked up successfully. The reason is that the firewall will block the remote procedure call. Now you can safely use the remote network resources.

Finally, let's look at the security issues that need to be noted in use.

4, the use of the need to pay attention to the safety issues

In general, we want to protect NFS, the first is to close the biggest loopholes. In the operating system, when the system starts, there will be a lot of background system service programs are running, and some ports are open by default. If this situation is not handled, on the one hand will be unnecessary to consume a large amount of system resources, on the other hand, will bring security risks to our system. Therefore, to protect NFS, we must address the following issues:

Consider overall security, deny all access, and provide access only when needed. In other words, do not export NFS to any host, but should only export it to the desired host, especially to avoid exporting the file system to untrusted hosts. And to try to use the read-only (RO) permission to export the file system, try not to use (RW) or (no_root_squash) permissions;

Do not provide too many root user accounts. In particular, it is important to ensure that no user has a root user account for the NFS client, because if so, the client will have the highest privileges and will cause a great security problem, which can modify anything it wants to modify, which is obviously unsafe. and the (Root_squash) and (RO) options should be used on NFS servers;

Try to hook up the file system with the read-only (RO) option by using the restrictive NFS client side hook option, and do not allow the UID binaries (nosuid), Devices (Nodev), and execution Files (noexec) to be set unless it is necessary to do so.

to strictly control the exported catalog file. This mainly includes the number of exports and the export security options. The number of exports depends on the actual situation, avoiding excessive and unnecessary options everywhere. In addition, to strictly control the export security options, the security options are the above described as read-only (RO), writable (rw), root user Squeeze (Root_squash) and other options, so that each directory has its own access, and usually this is also very reasonable, This is almost impossible because all of the directory access permissions to export are the same. For example, now there are three directories on the NFS server that need to be exported, one is/popmusic, one is/doc, and one is/digest. Of these three directories, the first directory and the third directory not only allow the client to share, but also allow the client to upload its own files, but the second one is only allowed to read, so that the first and third directories will be set to RW, and the second can only be set to Ro.

You should pay attention to some control problems during the setup of the directory under the exported file system. In general, you should have access to a consistent directory and files as the parent directory, subdirectories, and access rights inconsistent to open a separate directory for export, which is actually a management of the granularity problem. For example, the existing four directories are exported, in turn,/direct1,/direct2,/direct3,/direct4. The first two directories access is read-only, and the latter two is readable, then, we can do this when exporting, the/direct2 as a subdirectory of the/direct1, put into the/direct1 to export, and then set the share permissions to read-only, the same, you can/direct4 As a subdirectory of the/DIRECT3, set its share permissions to read-write, and then export. This way, the client does not appear when accessing the server data, and in one directory, the permissions of the entire parent directory are not the same as the subdirectories. Solve the problem of this setup, sharing is also more convenient, and easy to manage.

5. graphical configuration of Server for NFS

In the red Hat Enterprise Linux 5 system, if you are configuring Server for NFS, you can also use the NFS graphical configuration method, which is straightforward and quick.

1.1 NFS Server Configuration window

Enter the System-config-nfs command at the shell prompt to open the Server for NFS Configuration window, shown in 1.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/49/A8/wKioL1QX8KCSkISKAABZuFm5-sE831.jpg "title=" 10.jpg "alt=" Wkiol1qx8kcskiskaabzufm5-se831.jpg "/>

1.2 Adding an NFS Share

In the Server for NFS Configuration window, if you want to add a shared directory, you can click the Add button in the toolbar to open the Add NFS Share dialog box, shown in 2.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/49/A7/wKiom1QX8JfiXVenAABhkZYRURg376.jpg "title=" 20.jpg "alt=" Wkiom1qx8jfixvenaabhkzyrurg376.jpg "/>

The options in the Basic tab are as follows.

(1) "Contents" text box: refers to the directory to be shared, such as/tmp/.

(2) "Host" text box: refers to the host to share the directory.

(3) Basic Permissions option group: Specifies whether the shared directory should have read-only or read/write permissions.

First enter the directory path you want to share in the Directory text box, or click the Browse button to open the Select a Directory dialog box, where you can select a system directory to share.

Return to the Add NFS Share dialog box and enter the hostname (that is, localhost or the IP address of the Server for NFS) as the NFS server name in the Host text box. Select a permission for the shared directory in basic permissions, and the system defaults to read-only permission.

1.3 General Options

Go back to the Add NFS Share dialog box, click the General Options tab, and open the General Options tab, shown in 3.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/49/A8/wKioL1QX8LqD40HlAABkeeEsxnY249.jpg "title=" 30.jpg "alt=" Wkiol1qx8lqd40hlaabkeeesxny249.jpg "/>

On this tab, the user can select the appropriate check boxes as needed, and the system defaults are generally retained. The functions of each check box are as follows.

(1) Allow connections from ports above 724: services started on ports less than 724 must be started as root, select this check box to allow users other than the root user to start the NFS service. This check box corresponds to insecure.

(2) Allow unsafe file locking: No lock request required, this check box corresponds to Insecure_locks.

(3) Disable subtree check: If a subdirectory of a file system is exported, but the entire file system is not exported, the server checks whether the requested file is in the exported subdirectory. This check is called "subtree check" (subtree checking), select this check box to disable subtree checking. If the entire file system is exported, select the check box check to increase the transfer rate. This check box corresponds to No_subtree_check.

(4) Synchronous write as required: enabled by default, this check box does not allow the server to reply to requests before they are written to disk. This check box corresponds to sync. If this check box is cleared, the sync option is used.

(5) Immediately force synchronous write operation: Do not postpone write to disk, this check box corresponds to No_wdelay.

Reference: http://os.51cto.com/art/201010/231717_all.htm

This article is from the "--" blog, please be sure to keep this source http://57388.blog.51cto.com/47388/1553331

LINUX--NFS Quick Configuration tutorial and security policy