Subject: Re: restricting NFS (and associated services) to one IP address
To: Chuck Swiger <>
From: Steven M. Bellovin <>
List: netbsd-users
Date: 10/09/2006 14:40:42
On Mon, 9 Oct 2006 11:05:40 -0700, Chuck Swiger <> wrote:

> On Oct 9, 2006, at 10:37 AM, Steven M. Bellovin wrote:
> > On Mon, 9 Oct 2006 10:21:57 -0700, Chuck Swiger <>  
> > wrote:
> >> With regard to NFS and RFC services involving portmap, please
> >> understand that these services predated the notions of network
> >> security and firewalls needed today, and that these services are
> >> basically completely insecure.
> >
> > Given how long I've been working on network security and firewalls --
> > close to 20 years -- I think I understand that *very* well.  (I also
> > understand that many modern protocols aren't really any better, but  
> > that's
> > a separate rant.)
> I've seen a post or two from you on Bugtraq, firewall-wizards and  
> elsewhere, agreed; but your question about "default deny" surprised  
> me enough to discard prior assumptions about any specific level of  
> knowledge you might have.  More to the point, other readers of this  
> mailing list are going to have a wide range of knowledge and might  
> benefit from understanding the intrinsic lack of security found in  
> NFS/portmap/etc.

I also co-authored the first book on firewalls, in 1994...  But your point
point about others' knowledge is well taken.

As for 'default deny' -- it's certainly the proper policy for a firewall.
It's much less clear that hosts should be configured to drop all incoming
packets not matchable to an outbound packet.  (Yes, I know that that's what
Windows XP SP2 does.  See Section 4.7 of Richard Clayton's dissertation,
at, for one
example of the problems this can cause.)

In any event, my machine effectively does do 'default deny', in that it
returns a TCP RST or an ICMP Port Unreachable for packets addressed to
services that aren't running.
> >> It is not prudent or advisable to try
> >> to combine routing/firewall functionality and filesharing on the same
> >> machine; if your multihomed system is being used to route or NAT
> >> traffic, then, if at all possible, you should not configure it to
> >> operate as a fileserver as well.
> >>
> > Who said anything about routing, firewalls, or NAT?  Not I.
> You stated that you had a multihomed machine which you wanted to use  
> for filesharing but over only one interface.  You also stated "An  
> obvious approach is to use pf or ipf....", which certainly appears to  
> mean that you did say something something about using firewalls.

The purpose of a firewall is two-fold: to protect machines that can't
protect themselves, and to provide protection at scale.  I have a small
number of similar machines, so scale isn't the issue.  The question is
whether or not the machine can protect itself.  We've already established,
I think, that most of the services I mentioned have no access control, let
alone a more sophisticated way of ignoring packets from unwanted sources.
I was contemplating using pf or ipf -- as I frequently do -- for host
security.  For example, my preferred IM client (psi) listens on port 8010
for file transfer.  That's not a service I need or want, but there's no
way to disable it that I've found.  Instead, I use a packet filter to
block it.  That's a lot harder to do with RPC services, for reasons we
both understand.
> Or did someone else write Message-id:  
> <>...?

I didn't explain all the steps in my reasoning.
> > The situation is more like this.  I have several machines A, B, and C
> > that are exposed to the Internet.  They also need to share files among
> > themselves via NFS, on a separate LAN.  I want to make sure that nasty
> > packets don't get to the NFS-related services on these machines.
> I would not want to run NFS filesharing on an machine directly  
> connected to the Internet without having a firewall in the way.

Ah -- but why?  I agree that one shouldn't run NFS without *something*
blocking those services.  Must it be an external box?  Or does NetBSD have
the ability to do it itself?
> > I could, I suppose, create machine D, which is only on the back end  
> > LAN; it
> > could be the common file server.  For various reasons, that's not an
> > ideal solution, though I may resort to it.
> That's probably the best solution in terms of security, however.

It may be the best answer today.  I'm still looking for a better answer
for tomorrow...
> > It also leaves open the question of keeping fake responses away  
> > from the NFS clients on A, B, and C.
> Use a firewall to block IP loose and strict source routing, as well  
> as the (presumably) RFC-1918 subnet being used for your LAN, so that  
> traffic on your internal LAN cannot be spoofed from outside.
Presumably, setting net.inet.ip.forwsrcrt=0 will accomplish that.  There's
also net.inet.ip.checkinterface.

We seem to be talking past each other, and the tone has turned a bit
unpleasant.  Let's both calm down and assume that each of us knows what
we're talking about.

		--Steven M. Bellovin,