Subject: security/9077: default packet filters for network service daemons
To: None <>
From: None <>
List: netbsd-bugs
Date: 12/29/1999 21:03:41
>Number:         9077
>Category:       security
>Synopsis:       default packet filters for network service daemons
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    security-officer (NetBSD Security Officer)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 29 21:03:00 1999
>Originator:     Erik E. Fair
	<a href="">NetBSD Security Office</a>
>Release:        NetBSD 1.4.x
System: NetBSD 1.3.2 NetBSD 1.3.2 (CESIUM) #0: Sat Sep 12 19:30:08 PDT 1998 root@:/usr/src/sys/arch/sparc/compile/CESIUM sparc

	Some class of IP network services that NetBSD can offer are
	principally for local consumption only, for some definition
	of "local" (e.g. RPC services like NFS).

	Unfortunately, NetBSD's implementation of these services
	tends to open them up to the world by default when they
	are turned on. This is a bad default.

	While the TCP wrappers can take care of this problem, they
	must be configured manually, and that means another copy
	of the network numbers and other configuration data, which
	needs to be changed when a network is renumbered.

	I propose that the daemon's default behavior be modified
	to only respond to IP packets from attached networks (i.e.
	for all the network numbers on attached interfaces), which
	could be overridden by a command line option or configuration
	file option, as appropriate for the daemon.

	This would make exposure of network services an explicit
	decision, rather than an implicit decision.

	I suggest that the IP network numbers and netmasks be
	obtained by scanning the network interfaces, rather than
	from manual configuration, and that a library subroutine
	be written to do this to leverage the code across multiple

	It is possible that the TCP wrappers code could be modified
	to do this, with an additional configration flag added to
	its initialization routine, settable in the code on a
	per-daemon basis.

	This PR is intended both as a reminde to me to look into this
	(or to someone else if I drop the ball), and to elicit discussion
	from the community at large.