Date: Fri, 28 Jun 1996 07:18:17 -0500 From: Alex Nash <alex@fa.tdktca.com> To: rbezuide@mikom.csir.co.za Cc: nate@mt.sri.com, phk@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: IPFW bugs? (fwd) Message-ID: <31D3CD89.66FE4FE9@fa.tdktca.com> References: <Pine.BSI.3.91.960628054750.20070K-100000@Venus.mcs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31D3CD89.66FE4FE9>