On Oct 8, 2006, at 9:59 PM, Steven M. Bellovin wrote:

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

My apologies.  That is a pretty different question.

It is possible to run NFS over a standard TCP port without using  
rpcbind.  I have even read treatments of running NFS of SSH using  
this facility.  Here is one, but I can't get the link up right now:

http://www.howtoforge.com/nfs_ssh_tunneling

but I have read it in the O'Reilly book, too.  Perhaps something like  
that is what you are looking for.

Byron