From: gpalmer@westhill.cdrom.com
To: "Frank ten Wolde" <franky@pinewood.nl>
Cc: hackers@freebsd.org
Subject: Re: Order of rules in ip_fw chain 
In-Reply-To: Your message of "Fri, 15 Dec 1995 13:02:16 +0100."
             <9512151302.ZM27077@pwood1.pinewood.nl> 
Date: Fri, 15 Dec 1995 15:28:46 -0800
Message-Id: <15305.819070126@westhill.cdrom.com>
Sender: owner-hackers@freebsd.org
Precedence: bulk

"Frank ten Wolde" wrote in message ID
<9512151302.ZM27077@pwood1.pinewood.nl>:
> 1) I would suggest adding the following lines of code in 
>    .../sys/netinet/ip_fw.c, line 879:
> 
> 	ifdef IPFIREWALL 
> 	int
> 	ip_fw_ctl(stage, m)
> 	    int stage;
> 	    struct mbuf *m; 
> 	{
>   
> 	    if (securelevel >= 2) {			NEW
> 	        return (EPERM);				NEW
> 	    }   					NEW
> 	    if (stage == IP_FW_FLUSH) {
> 	        free_fw_chain(&ip_fw_chain);
> 	        return (0);
> 	    }   
> 	    ...

>    This would prevent any changes in the fw chain when running in
>    very secure level.

Nice idea, but running at secure levels >>0 is not something I want to
look at yet. If nothing else, the only reason I would do it would be
to set the sappend flag on the log files to prevent people tinkering
with them, but how would you rotate them? :-( Taking the machine
offline is NOT an option.

> 2) I noticed that the order in which the fw checks incoming packets is
>    *not* the same as the order in which the packet rules were added.
>    IMHO this should be fixed.  I have not had the time (yet) to have
>    a look at the source myself, but will do so in the next few weeks.

This is documented, and I have to agree with the authors idea that
most people do NOT know what they are doing when playing with the
firewall stuff and need some handholding. He does agree with me,
however, that we need an ``I know what I'm doing'' flag which inserts
the rules into the chain in the order they are submitted.

> 3) I would suggest modifying ipfw.c to give some more informative
>    message if the setsockopt call fails.  Now it only lists something
>    like "getsockopt failed", but it does not give you the reason.
>    A simple perror("") would do the trick I suppose.  I will try and
>    have a look at the source code in the near future.

Definately.

Gary