Subject: Re: restricting NFS (and associated services) to one IP address
To: Byron Servies <bservies@pacang.com>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: netbsd-users
Date: 10/09/2006 00:59:09
On Sun, 8 Oct 2006 21:41:35 -0700, Byron Servies <bservies@pacang.com>
wrote:

> 
> On Oct 8, 2006, at 9:24 PM, Steven M. Bellovin wrote:
> 
> > I have some machines with two Ethernet interfaces.  I'd like to run  
> > an NFS
> > server, but I want to restrict it to access via just one of the two
> > interfaces.  I don't see any easy way to do that.
> >
> > An obvious approach is to use pf or ipf, but that doesn't play well  
> > with
> > portmapper.  On my other NFS machine, I see UDP and/or TCP ports 1016,
> > 1017, 1018, 1019, 1020, 1021, and 1022 in use at the moment, for  
> > rpcbind,
> > mountd, lockd, and statd.  rpcbind apparently supports
> > host.allow/hosts.deny, but it isn't clear if that applies to  
> > packets sent
> > directly to the other services.  Any better suggestions?
> 
> 
> Hi there!
> 
> I suggest you re-read 'man 5 exports' a little more closely.  You can  
> restrict NFS exports to NIS groups, netgroups, individual IP  
> addresses, networks, etc.  right in the /etc/exports file itself.    
> Here is the example block from the manual page:
> 

I'm very familiar with that and should have mentioned it.  Not to put too
fine a point on it, but I don't trust that mechanism; it's far too
low-assurance for me.   I want to keep the packets away from the services
entirely.

/etc/exports primarily restricts the behavior of mountd.  It does nothing
for statd, lockd, and rpcbind.  These services have had security problems
in the past; see, for example,
	http://www.cert.org/advisories/CA-1996-09.html
	https://www.kb.cert.org/vuls/id/18287
	http://xforce.iss.net/xforce/xfdb/5050
	http://www.sfu.ca/~siegert/linux-security/msg00212.html

and of course http://www.ciac.org/ciac/bulletins/l-040.shtml -- a worm
based in part on rpc.statd.  Beyond that, it isn't clear to me how early
in the game mountd validates packets against that file; the later it is,
the more likely it is that an early bug can cause trouble.

If I can force those services to bind to a specific IP address, rather than
to INADDR_ANY, I can use a nice, simple rule on the second Ethernet to keep
*all* such packets far away from the service.  *Then* I'll create an
exports file that still restricts NFS access to the addresses I trust...


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