Subject: Re: restricting NFS (and associated services) to one IP address
To: None <tls@rek.tjls.com>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: netbsd-users
Date: 10/09/2006 10:26:21
On Mon, 9 Oct 2006 08:46:13 -0400, Thor Lancelot Simon <tls@rek.tjls.com>
wrote:

> On Mon, Oct 09, 2006 at 08:36:03AM -0400, Steven M. Bellovin wrote:
> > On Mon, 9 Oct 2006 05:01:15 -0700, "Andy Ruhl" <acruhl@gmail.com> wrote:
> > 
> > > I just used pf to block everything I didn't want one of my interfaces to see.
> > > 
> > > Sorry for being dense, but why does this cause a problem with the
> > > portmapper in your setup? I don't seem to have any problems, but I
> > > don't have a large number of NFS clients either...
> > > 
> > There are no guarantees about what port numbers are assigned.  Today, on
> > one particular reboot, it used the ports I mentioned.  A code change or a
> > boot order change could change that, which would silently leave the
> > services exposed.
> 
> Were I you, I'd personally consider installing a "default block" set of
> rules on the interface on which I didn't want RPC services to appear.

I might.  I haven't yet, because the machine is otherwise very
minimally-configured -- there isn't enough to be worth blocking, except
for all the goo surrounding NFS.  Adding that for this purpose strikes as
unaesthetic.  Besides, there are other, more subtle implications to such
solutions -- details in a forthcoming paper.
> 
> But you probably don't want to do that.  It would be easy enough to adjust
> portmap, mountd, and the kernel NFS server to bind only a specified IP
> address.  Why not give it a try?
> 
Right now, I'm gathering data -- I'm confirming my impression there's no
easy, clean way to do it.  The next question is how best to fix it.  The
obvious way, as you say, is to modify various programs.  Since there are
at least five to change here -- rpcbind, rpc.mountd, rpc.statd, rpc.lockd,
and the kernel NFS driver -- and more if I wanted to be able to protect
other RPC-based services, I wonder if there's a more general solution
possible.  Can there be something chroot-like for network interfaces?  Or
should that be network addresses?  Should there be such a thing?  Is the
proper answer some generic service in the RPC libraries?  If so, how are
the parameters passed from userland? Environment variables?  Entries
in /etc/hosts.allow and /etc/hosts.deny?  How does the kernel server check
those files?  When, how, or if do standing services, such as lockd, notice
changes?

I have a lot more questions, and very few answers at this point.  For now,
let it suffice to say that this echoes a point I've made before -- a
"secure OS" is one that makes it easy to write secure applications.


		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb