From owner-freebsd-hackers Thu Aug 2 10:25: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id CE09E37B401; Thu, 2 Aug 2001 10:24:59 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f72HOjf73349; Thu, 2 Aug 2001 13:24:45 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 2 Aug 2001 13:24:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Eugene L. Vorokov" Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ipfw "established" option In-Reply-To: <200108020739.f727dbY02620@bugz.infotecs.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As Bill Fumerola has indicated, and I thought I'd follow up in with a bit more detail, the behavior you're seeing is the result of a bug in the FreeBSD IPFW code. FreeBSD did a direct comparison of the TCP header flag field with an internal field in the IPFW rule description structure. Unfortunately, at some point, someone decided to overload the IPFW rule description structure field to add a flag representing "ESTABLISHED". They used a flag value that was previously unused by the TCP protocol (which doesn't make it safer, just less noticeable). Later, when that flag was allocated for ECN (Endpoint Congestion Notification) in TCP, and Linux began using ECN by default, the packets began to match ESTABLISHED rules regardless of the other TCP header flags. This bug was corrected on the RELENG_4 branch, and security advisory for the bug was released. This was, needless to say, a pretty serious bug, and good example of why you should be very careful to compare only the bits you really mean to, and should seperate packet state from protocol state in management structures, as well as make use of extensive testing to make sure rules actually have the effect you describe. I understand a number of such tests are available for the ipfilter firewall module--it might make sense to modify them to test similar functionality in IPFW. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 2 Aug 2001, Eugene L. Vorokov wrote: > Hello, > > I've found some strange issue regarding ipfw. I have freebsd 4.2-RELEASE. > Guess I have rules: > > 1 allow tcp from any to 195.210.139.22 established > 2 deny tcp from any to 195.210.139.22 > 2 allow all from any to any > > The intention is to allow the machine itself connect outside and accept > responces once connection is established, but deny attepmts to connect > to this machine from outside. I was thinking that first packet which tries > to establish TCP connection should never match rule 1. > > However, I've found that it depends on which operating system tries to > connect in ! When I try this from machine with freebsd 4.3-RELEASE, it gets > dropped as expected. tcpdump on my machine says: > > 11:15:01.841594 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] > 11:15:04.911908 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] > 11:15:07.804934 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] > > Okay, that's fine. But then I try the same from Linux machine (2.4.5). > I am able to successfully telnet in ! tcpdump says: > > 11:15:51.479203 195.230.76.28.39925 > 195.210.139.22.21: S [ECN-Echo,CWR] 4162184178:4162184178(0) win 5840 (DF) [tos 0x10] > 11:15:51.479466 195.210.139.22.21 > 195.230.76.28.39925: S 2404031587:2404031587(0) ack 4162184179 win 17520 (DF) > 11:15:51.565124 195.230.76.28.39925 > 195.210.139.22.21: . ack 1 win 5840 (DF) [tos 0x10] > 11:15:51.590818 195.210.139.22.21 > 195.230.76.28.39925: P 1:58(57) ack 1 win 17520 (DF) [tos 0x10] > 11:15:51.648107 195.230.76.28.39925 > 195.210.139.22.21: . ack 58 win 5840 (DF) [tos 0x10] > > Firewall logs also say that the initial packet matched the rule 1 > and was passed. > > Why is it like that ? Am I missing something ? > > Regards, > Eugene > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message