On Mon, 9 Oct 2006 11:05:40 -0700, Chuck Swiger <cswiger@mac.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 <cswiger@mac.com>  
> > 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 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
both understand.
> 
> Or did someone else write Message-id:  
> <20061009002448.c893eefd.smb@cs.columbia.edu>...?

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, http://www.cs.columbia.edu/~smb