From owner-freebsd-hackers  Thu Jun 19 06:50:19 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id GAA27880
          for hackers-outgoing; Thu, 19 Jun 1997 06:50:19 -0700 (PDT)
Received: from pandora.hh.kew.com (ahd@kendra.ne.highway1.com [24.128.53.73])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA27873
          for <hackers@FreeBSD.ORG>; Thu, 19 Jun 1997 06:50:16 -0700 (PDT)
Received: (from ahd@localhost)
	by pandora.hh.kew.com (8.8.5/8.8.5) id JAA03034;
	Thu, 19 Jun 1997 09:50:02 -0400 (EDT)
Date: Thu, 19 Jun 1997 09:50:02 -0400 (EDT)
From: Drew Derbyshire <ahd@kew.com>
Message-Id: <199706191350.JAA03034@pandora.hh.kew.com>
To: ahd@kew.com, archie@whistle.com
Subject: Re: Adding a new feature to 2.2 series?
Cc: hackers@FreeBSD.ORG, julian@whistle.com
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> From archie@whistle.com Thu Jun 19 01:44:07 1997
> > If you're hacking the code, add a wish for the ipfw command line
> > side, although not for 2.2.x ...
> > 
> > Consider parsing the port and IP address fields for the contents
> > of /etc/services, /etc/hosts and /etc/network.  I find the requirement
> > to use numerics to be extremely error prone.  I presume this is
> > currently done because NIS and DNS are not presumed to be available
> > when ipfw is run and the stock gethostbyname, etc. would attempt
> > to access these services.
>
> DNS/NIS are not required to use /etc/services as far as I know,
> so that's not the reason..

On SunOS and Solaris, /etc/services will definitely use NIS if you tell it
to.  I don't use NIS in my BSD environment, so I can't be sure.  Correction, 
I can RTFM the 2.2.1 man page:
 
NIS INTERACTION
     Access to the NIS services.byname map can be enabled by adding a single
     ``+'' on a line by itself in the /etc/services file. This causes the con-
     tents of the NIS services map to be inserted at the location where the
     ``+'' appears.

Of course, using NIS on a true firewall strikes me as a really dumb idea, since
that's fairly easy to hack compared to local system access.

> I was under the impression that this was done for security reasons,
> i.e., if someone hacks (ie modifies) your /etc/services, they can
> then render your TCP and UDP packet filtering useless..
>
> Of course, if they can do this, they can probably hack ipfw too ..

Agreed.  If they hack /etc/services, most attacks would kill the
underlying the service anyway, since for example SMTP won't be real
useful on port 1025.

> I agree, at least it should be enablable via a command line option.
> I'll look at adding this to the patch.. shouldn't be hard. Comments?

I don't object if you wait for -current on this part, especially if it 
adds IP address parsing as well.

-ahd-