NFS is a network filesystem:-
It works well for sharing file systems between multiple clients, but is slower then some other network filesystems (samba).It is also more fault tolerant then most other network file systems. NFS4 uses TCP, earlier versions use UDP.
With NFS, when a file or directory is shared from a remote machine, it appears to be part of your filesystem. Every time you access the NFS-linked filesystem, files are transparently delivered to the your machine over the network.Everything behaves like for local filesystem (except for some delays)
NFS is based on a client-server model. One computer works as a server and offers filesystems to other systems. This is called exporting or sharing and the filesystems offered are called "exports." The clients can mount server exports using an extension of mount command used to mount local filesystems.
File systems shared through NFS software can also be mounted automatically. Autofs, a client-side service, is a change directory intercept mechanism that catches the cases when user changes to NFS directory and transparently mounts it. the list of mount points should be provided to Autofs as a configuration file.
Essentially any I/O operation on s program notifies the automount daemon, automountd, and it mounts it and then if there is long period of inactivity unmounts it. The automountd, daemon transparently performs mounting and unmounting of remote directories listed it Autofs configuration file on an as-needed basis. The NFS is in turn based on the Remote Procedure Call (RPC) protocol. For this reason, the RPC server daemon must be running for NFS to be implemented. You can check whether RPC is active by issuing this command at the shell prompt:
The NFS service makes the physical location of the file system irrelevant to the user. You can use the NFS implementation to enable users to see all the relevant files regardless of location. Instead of placing copies of commonly used files on every system, the NFS service enables you to place one copy on one computer's disk and have all other systems access it across the network. Under NFS operation, remote file systems are almost indistinguishable from local ones.
Writable NFS-sharable file systems should generally be a separate disk or partition (on server). By having file systems on a separate partition of a harddisk, we can ensure that malicious users can not simply fill up the entire harddisk by writing large files onto it. This will then be able to crash other services running on the same harddisk. Prevent normal users on an NFS client from mounting an NFS file system (on server)
NFS controls who can mount an exported file system based on the host making the mount request, not the user that will actually use the file system. Hosts must be given explicit rights to mount the exported file system. Access control is not possible for users, other than file and directory permissions. In other words, once a file system is exported via NFS, any user on any remote host connected to the NFS server can access the shared data. To limit the potential risks, administrators can only allow read-only access or squashing users to a common user and groupid. But these solutions may prevent the NFS share from being used in the way it was originally intended.
Additionally, if an attacker gains control of the DNS server used by the system exporting the NFS file system, the system associated with a particular hostname or fully qualified domain name can be pointed to an unauthorized machine. At this point, the unauthorized machine is the system permitted to mount the NFS share, since no username or password information is exchanged to provide additional security for the NFS mount. The same risks hold true to compromised NIS servers, if NIS netgroups are used to allow certain hosts to mount an NFS share. By using IP addresses in /etc/exports, this kind of attack is more difficult.
Wildcards should be used sparingly when granting exporting NFS shares as the scope of the wildcard may encompass more systems than intended.
Once the NFS file system is mounted read-write by a remote host, the only protection each shared file has is its permissions. If two users that share the same userid value mount the same NFS file system, they will be able to modify each others files. Additionally, anyone logged in as root on the client system can use the su - command to become a user who could access particular files via the NFS share.
To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script.
You need several daemons to support NFS activities. These daemons can support both NFS client and NFS server activity, NFS server activity alone, or logging of the NFS server activity. To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script. There are six daemons that support NFS:
It works well for sharing file systems between multiple clients, but is slower then some other network filesystems (samba).It is also more fault tolerant then most other network file systems. NFS4 uses TCP, earlier versions use UDP.
With NFS, when a file or directory is shared from a remote machine, it appears to be part of your filesystem. Every time you access the NFS-linked filesystem, files are transparently delivered to the your machine over the network.Everything behaves like for local filesystem (except for some delays)
NFS is based on a client-server model. One computer works as a server and offers filesystems to other systems. This is called exporting or sharing and the filesystems offered are called "exports." The clients can mount server exports using an extension of mount command used to mount local filesystems.
File systems shared through NFS software can also be mounted automatically. Autofs, a client-side service, is a change directory intercept mechanism that catches the cases when user changes to NFS directory and transparently mounts it. the list of mount points should be provided to Autofs as a configuration file.
Essentially any I/O operation on s program notifies the automount daemon, automountd, and it mounts it and then if there is long period of inactivity unmounts it. The automountd, daemon transparently performs mounting and unmounting of remote directories listed it Autofs configuration file on an as-needed basis. The NFS is in turn based on the Remote Procedure Call (RPC) protocol. For this reason, the RPC server daemon must be running for NFS to be implemented. You can check whether RPC is active by issuing this command at the shell prompt:
rpcinfo -p
The NFS service makes the physical location of the file system irrelevant to the user. You can use the NFS implementation to enable users to see all the relevant files regardless of location. Instead of placing copies of commonly used files on every system, the NFS service enables you to place one copy on one computer's disk and have all other systems access it across the network. Under NFS operation, remote file systems are almost indistinguishable from local ones.
Writable NFS-sharable file systems should generally be a separate disk or partition (on server). By having file systems on a separate partition of a harddisk, we can ensure that malicious users can not simply fill up the entire harddisk by writing large files onto it. This will then be able to crash other services running on the same harddisk. Prevent normal users on an NFS client from mounting an NFS file system (on server)
NFS controls who can mount an exported file system based on the host making the mount request, not the user that will actually use the file system. Hosts must be given explicit rights to mount the exported file system. Access control is not possible for users, other than file and directory permissions. In other words, once a file system is exported via NFS, any user on any remote host connected to the NFS server can access the shared data. To limit the potential risks, administrators can only allow read-only access or squashing users to a common user and groupid. But these solutions may prevent the NFS share from being used in the way it was originally intended.
Additionally, if an attacker gains control of the DNS server used by the system exporting the NFS file system, the system associated with a particular hostname or fully qualified domain name can be pointed to an unauthorized machine. At this point, the unauthorized machine is the system permitted to mount the NFS share, since no username or password information is exchanged to provide additional security for the NFS mount. The same risks hold true to compromised NIS servers, if NIS netgroups are used to allow certain hosts to mount an NFS share. By using IP addresses in /etc/exports, this kind of attack is more difficult.
Wildcards should be used sparingly when granting exporting NFS shares as the scope of the wildcard may encompass more systems than intended.
Once the NFS file system is mounted read-write by a remote host, the only protection each shared file has is its permissions. If two users that share the same userid value mount the same NFS file system, they will be able to modify each others files. Additionally, anyone logged in as root on the client system can use the su - command to become a user who could access particular files via the NFS share.
To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script.
You need several daemons to support NFS activities. These daemons can support both NFS client and NFS server activity, NFS server activity alone, or logging of the NFS server activity. To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script. There are six daemons that support NFS:
- mountd Handles file system mount requests from remote systems, and provides access control (server)
- nfsd Handles client file system requests (both client and server)
- statd Works with the lockd daemon to provide crash recovery functions for the lock manager (server)
- lockd Supports record locking operations on NFS files
- nfslogd Provides filesystem logging. Runs only if one or more filesystems is mounted with log attribute.
No comments:
Post a Comment