The Network File System (NFS) protocol defines a way for co-operating systems to share filesystems. Today, everyone seems to refer to NFS mounts as shares.

NFS is based on the RPC (Remote Procedure Call), a protocol that defines how machines can make calls to procedures on remote machines as if they were local.

NFS implementations consist of more than just a single NFS server process. In fact, they require mountd, statd, and lockd. These daemons have had a plethora of problems— especially statd.

NFS is an insecure protocol that you don't want to run. Trust me.

Full details of NFS v2 can be found in RFC 1094. NFS v3 is defined in RFC 1813.

NFS Risks

· If you're running an unsupported or unpatched version of NFS, you're dead in the water if someone takes a shot.

· Misconfigurations are common with NFS. Sharing system-related filesystems is asking for trouble.

· Weak authentication is used. The requests can be spoofed or sometimes proxied through the local portmapper.

· No encryption is used, so your darkest secrets go across the network in plaintext.

· NFS-related daemons commonly run as root. An exploitable security hole can leave you with a root compromise on your hands.

· Watch your defaults! The file / etc / exports (or / etc / dfs / dfstab) controls which filesystems you share and with whom. Unless you specify otherwise, your implementation might default to using insecure options or giving write access by default.

Securing NFS

Don't run it! Solve security headaches in one fail swoop—turn if off! OK, so you want this functionality? Read on…

· Is NFS the right file-sharing mechanism for what you want? Given its security problems, examine your file-sharing requirements. For example, if you want a mirror of some files, you could just buy another disk (they are cheap these days) and use rdist over SSH to make replicas to other systems. If you can find a way around using NFS, then do so.

· Avoid using NFS for sensitive information and never run Internet-facing NFS servers.

· Firewall NFS to limit your exposure on the wider network.

· Stay up to date with vendor security patches! NFS-related patches seem to come out thick and fast. If your vendor isn't supplying patches, this could be "a Bad Thing." They might simply not be patching known holes.

· Share filesystems on a need-to-have basis. Restrict this to read-only sharing wherever possible. Always specify nosuid as an option, to ensure that the set-id bit is not honored on files created on exported filesystems.

· Remove any references to localhost in your exports file.

· Do not self-reference an NFS server in its own export file.

· Limit export lists to 256 characters (including expanded aliases if aliases are in use).

· Consider using a replacement portmapper that won't forward, or proxy, mount requests. .

· Where read-only sharing is possible, consider mounting a locally exported filesystem as read-only (that is, in / etc / vfstab or similar).

NFS version 4 is the next generation of NFS. Production ready implementations are not readily available as yet. See http: / / www.nfsv4.org for more information.

Alternatives to NFS include AFS (http: / / www.contrib.andrew.cmu.edu / ~shadow / afs.html) and CODA (http: / / www.coda.cs.cmu.edu / ).