by redmail.netbsd.org with SMTP; 1 Jan 2000 20:05:08 -0000
	by  orchard.arlington.ma.us (8.8.8/8.8.8) with ESMTP id PAA29784;
	Sat, 1 Jan 2000 15:05:06 -0500 (EST)
	by thunk.hamachi.org (8.8.8/8.8.8) with ESMTP id PAA04510;
	Sat, 1 Jan 2000 15:04:56 -0500 (EST)
Message-Id: <200001012004.PAA04510@thunk.hamachi.org>
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
To: fair@clock.org
cc: gnats-bugs@gnats.netbsd.org, tech-security@netbsd.org
Subject: Re: security/9077: default packet filters for network service daemons 
In-Reply-To: Message from fair@clock.org 
   of "Wed, 29 Dec 1999 20:59:54 PST." <19991230050004Z27461-26015+11@cesium.clock.org> 
Date: Sat, 01 Jan 2000 15:04:56 -0500

> 	This PR is intended ... to elicit discussion 
> 	from the community at large.

Even allowing service to the "local subnet" by default is excessively
liberal in many common cases.  

Several cases come to mind:

	- typical cable modem service where the demarc point is a
	  layer-2 bridge, since the "local subnet" may extend to include systems
	  outside the "site" (including your neighbors).

	- mobile nodes (laptops, etc.) which may connect to suspect or
	  even potentially hostile networks.

	- wireless subnets, where anyone within RF range can join the
	  network.

In other words, administrative boundaries != topological boundaries.

IMHO, the default "out of the box" config should run no network
services.  If we're going to take the belt and suspenders approach (to
protect you even if you accidentally enable services you shouldn't
have), we should change the default configuration for services like
nfs, etc., to deny service to all remote systems until configured
otherwise, not to specially grant access to systems which appear to be
connected to the same wire.

					- Bill