Re: NFS Over Private Network

From: Casper Dik (
Date: 03/30/04

To: Simon Thornton <>
Date: Tue, 30 Mar 2004 08:49:59 +0200

>I can understand the comment about old code but I've never had issues
>with the version of rpcbind on production systems. Normally I do not
>allow NFS due to the many security issues associated with it. Sometimes
>though, it has to be allowed, short of putting in a firewall between the
>systems, there is little the native OS provides that covers portmap

One issue is that the version of RPC Wietse's rpcbind is old and
contains a number of security vulnerabilties which has since
been patches in Sun's version. It also doesn't support IPv6.

Having said that, we do understand that customers want a tcp wrapped
rpcbind; it should appear in a Solaris Express release near you in
a short while.

(If you are not familiar with the Solaris Express program: you can now
download development versions of Solaris 10 directly from Sun and
take it for a test drive at

As for NFS security issues: in reality there are none if you don't
configure it with the default "big hole" setting. With DH Secure RPC
or Kerberos based GSS_API RPC, NFS can be made pretty much as secure
as anything else. Also, starting with Solaris 2.6, having file handles
is no longer sufficient; you need to be sending packets from an address
which the file is exported to (exports are checked on each access rather
than at mount time only).

Combine that with IPsec or just configure the specific ports to require
IPsec and you have the guarantee that the packets are coming from the
right host.

>As a side feature, the ability to save portmap settings across across
>sessions is very useful, it saves the need to reconfigure the firewall
>rules whenever portmap is restarted.

Statefiles are a standard feature of rpcbind; but it doesn't allow you
to "save state across sessions" if you mean "across reboot" or "across
program invocations". Rpcbind merely registers services; it does not
assign addresses; when a server restarts it will determine itself
whether a new port is used or the same.

>I consider it more valuable that access to the portmapper is recorded
>and/or restricted than relying on the RPC apps to protect themselves.
>Many canned RPC exploits do not work if they cannot access the
>portmapper to find the application.


>As with all changes, you have to test it in your environment and assess
>the risks associated with replacing the native utility with another.
>What is acceptable in one place may not be in another.

There are cases were the non-standard rpcbind broke stuff but I'm not
sure whether those were cases of mere misconfiguration or actual
bugs in our old code.


Relevant Pages

  • Re: tcpwrapped rpcbind/portmap?
    ... A wrapped version of rpcbind does *not* prevent remote attacks ... of individual rpc services, it merely makes it a bit more difficult ... to determine which rpc port numbers your services are at. ... One concern I have is that Sun recently released a security patch ...
  • RE: tcpwrapped rpcbind/portmap?
    ... libwrap.a and it listens on UDP and TCP ports 111, ... are UDP connects to rpcbind wrapped? ... > attacks of individual rpc services, it merely makes it a bit ... > One concern I have is that Sun recently released a security ...
  • [GIT pull] Please pull the following NFS client updates
    ... commit f839c4c1991cc9b580ae38f98f54554938a7f49c ... Note that all the NFS operations use their own locking, ... Ditto for the rpcbind client. ... SUNRPC: Support registering IPv6 interfaces with local rpcbind daemon ...
  • Re: selinux stops nfs?
    ... Restart with "rpcbind -w" ... Now SElinux is in permissive mode. ... And restarting nfs gives the same error all over again. ...
  • [opensuse] Re: umounting stale nfs mounts
    ... with an nfs mount I could restart ... reboot the server. ... Now, however, with Suse 11.0 & 11.1, there no longer is portmap under ... But some scripts look to load portmap OR rpcbind -- and seem to give preference to ...