Subject: Re: restricting NFS (and associated services) to one IP address
To: Chuck Swiger <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 10/09/2006 14:40:42
On Mon, 9 Oct 2006 11:05:40 -0700, Chuck Swiger <email@example.com> wrote:
> On Oct 9, 2006, at 10:37 AM, Steven M. Bellovin wrote:
> > On Mon, 9 Oct 2006 10:21:57 -0700, Chuck Swiger <firstname.lastname@example.org>
> > 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
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 http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-653.html, 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
> 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
> > 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
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, http://www.cs.columbia.edu/~smb