From owner-freebsd-current  Fri Jun 28 05:15:35 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id FAA29308
          for current-outgoing; Fri, 28 Jun 1996 05:15:35 -0700 (PDT)
Received: from shogun.tdktca.com ([206.26.1.21])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA29301;
          Fri, 28 Jun 1996 05:15:33 -0700 (PDT)
Received: from shogun.tdktca.com (daemon@localhost) by shogun.tdktca.com (8.7.2/8.7.2) with ESMTP id HAA06076; Fri, 28 Jun 1996 07:16:49 -0500 (CDT)
Received: from orion.fa.tdktca.com ([163.49.131.130]) by shogun.tdktca.com (8.7.2/8.7.2) with SMTP id HAA06069; Fri, 28 Jun 1996 07:16:49 -0500 (CDT)
Received: from orion (alex@localhost [127.0.0.1]) by orion.fa.tdktca.com (8.6.12/8.6.9) with SMTP id HAA12846; Fri, 28 Jun 1996 07:18:18 -0500
Message-ID: <31D3CD89.66FE4FE9@fa.tdktca.com>
Date: Fri, 28 Jun 1996 07:18:17 -0500
From: Alex Nash <alex@fa.tdktca.com>
Organization: TDK Factory Automation
X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i586)
MIME-Version: 1.0
To: rbezuide@mikom.csir.co.za
CC: nate@mt.sri.com, phk@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: IPFW bugs? (fwd)
References: <Pine.BSI.3.91.960628054750.20070K-100000@Venus.mcs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> I tried this rule because I haven't seen anything like this
> before ...

Forget that you ever saw it -- it's evil! :)

> duzi# ipfw list
> FireWall chain entries: 128 0
> 65000 accept all from any to any
> 65535 deny all from any to any
> duzi# ipfw add 21 pass log all from any 53 to any via ed0
> 00021 accept log all from any 53 to any via ed0
> duzi# ipfw list
> FireWall chain entries: 192 0
> 00021 accept log all from any 53 to any via ed0
> 65000 accept all from any to any
> 65535 deny all from any to any
> duzi# ipfw delete 65000
> 
> Connection gone .....
> 
> According to this .. it is "seems" :) impossible that rule
> 21 can cause *EVERYTHING* to go through !

There's a logical explanation for that...I just can't think what
it is right now.

But seriously, if you look in src/sys/netinet/ip_fw.c, the
port checking is the very last thing done.  Before it gets
to that pointit does this:

                /* If wildcard, match */
                if (f_prt == IP_FW_F_ALL)
                        goto got_match;

Therefore, anything with a protocol of ALL never gets to the
port checks.

> Another thing .. if you are able to delete the default rule
> then you do not "I think" :) have the latest ipfw, user level
> and kernel.

This is a legitimate concern as this particular fix has only
been in -stable since Monday.

Alex