Re: NFS Over Private Network

>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
>access.

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 http://www.sun.com/solarisexpress/)

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. 

Indeed.

>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.

Casper