From nobody@FreeBSD.org Thu Mar 31 23:07:14 2005 Return-Path: Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E041916A4CE for ; Thu, 31 Mar 2005 23:07:14 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id A017043D46 for ; Thu, 31 Mar 2005 23:07:14 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j2VN7EPP074139 for ; Thu, 31 Mar 2005 23:07:14 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j2VN7EOm074138; Thu, 31 Mar 2005 23:07:14 GMT (envelope-from nobody) Message-Id: <200503312307.j2VN7EOm074138@www.freebsd.org> Date: Thu, 31 Mar 2005 23:07:14 GMT From: Jonathan Dama To: freebsd-gnats-submit@FreeBSD.org Subject: ipf in 4.11 breaks POLA X-Send-Pr-Version: www-2.3 >Number: 79416 >Category: kern >Synopsis: ipf in 4.11 breaks POLA >Confidential: no >Severity: non-critical >Priority: medium >Responsible: darrenr >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Mar 31 23:10:06 GMT 2005 >Closed-Date: >Last-Modified: Tue Feb 28 09:50:05 GMT 2006 >Originator: Jonathan Dama >Release: 4.11-STABLE >Organization: ASCIT, inc. >Environment: FreeBSD donut.ugcs.caltech.edu 4.11-STABLE FreeBSD 4.11-STABLE #1: Tue Mar 22 00:12:05 PST 2005 root@donut.ugcs.caltech.edu:/usr/obj/usr/src/sys/BEARCLAW i386 >Description: ipf's interpretation of icmp rules has changed. This constitutes a POLA violation. See kern/73399 for a report of this problem against 5.3 as a regression versus 4.x. Original PR was closed because a simple rule rewrite resolves the issue. Some MFC has brought this regression into 4.x. As 4.x is a STABLE release branch, POLA holds; "simply change your configuration files" is not acceptable solution for stable branches in relationship to components of the base system. Problem summary: ipf cites a pass rule as grounds for blocking a packet. This applies specifically to protocol type icmp and the keep-state directive. >How-To-Repeat: Create a rule set such as: block in all pass in quick on lo0 from any to any pass out quick on lo0 from any to any pass out quick on fxp0 proto tcp from any to any flags S/FSRPAU keep state keep frags pass out quick on fxp0 proto udp from any to any keep state pass out quick on fxp0 proto icmp from any to any keep state pass in quick on fxp0 proto icmp from trustnet to any This results in the following activity: 31/03/2005 01:36:37.333242 fxp0 @0:3 p trustedip -> localip PR icmp len 20 84 icmp echo/0 IN 31/03/2005 01:36:37.333259 fxp0 @0:4 B localip -> trustedip PR icmp rule #4, "pass out quick on fxp0 proto icmp from any to any keep state" is cited as cause to block the reply packet. 1) This is textual nonsense. A pass-rule should never be cited as cause for dropping a packet. 2) This is behavioral change in 4.11-STABLE relative to earler 4.x releases, as such it constitutes a POLA violation. The echo reply should have matched rule #4 and been passed. >Fix: Only the original hack given by pr/73399, replace the keep-state icmp pass-rule with pass out quick on fxp0 proto icmp >Release-Note: >Audit-Trail: From: Spartak Radchenko To: freebsd-gnats-submit@FreeBSD.org, devteam@donut.ugcs.caltech.edu Cc: Subject: Re: kern/79416: ipf in 4.11 breaks POLA Date: Fri, 08 Apr 2005 21:58:19 +0400 The same applies to tcp rules. This ruleset worked OK in 4.8, 4.9, 4.10 (all outbound tcp connections, incoming connections on port 80): block in log all pass in quick proto tcp from any to any port = 80 pass out proto tcp from any to any keep state Yes, I know that such ruleset is not recommended in ipfilter how-to, but it worked anyway. And I think that "not recommended" doesn't mean "strictly prohibited". In 4.11 incoming connections to port 80 do not work any more. The ruleset must be modified: block in log all pass in quick proto tcp from any to any port = 80 pass out quick proto tcp from any port = 80 to any pass out proto tcp from any to any keep state -- Spartak Radchenko SVR1-RIPE From: Spartak Radchenko To: freebsd-gnats-submit@FreeBSD.org, devteam@donut.ugcs.caltech.edu Cc: Subject: Re: kern/79416: ipf in 4.11 breaks POLA Date: Fri, 08 Apr 2005 22:14:25 +0400 BTW, UDP is also affected. Here is my test ruleset for traceroute: block in log all pass in quick proto udp from any to any port 33434 >< 33690 pass out proto icmp from any to any keep state Host with this ruleset can be tracerouted from outside in 4.8, 4.9. 4.10. But not in 4.11. Counter for last rule is incremented for each outbound icmp unreach, however. Is it a bug or not? I am not sure. And this ruleset works in 4.11: block in log all pass in quick proto udp from any to any port 33434 >< 33690 pass out quick proto icmp from any to any icmp-type unreach pass out proto icmp from any to any keep state -- Spartak Radchenko SVR1-RIPE Responsible-Changed-From-To: freebsd-bugs->darrenr Responsible-Changed-By: kris Responsible-Changed-When: Sat Apr 9 00:44:05 GMT 2005 Responsible-Changed-Why: Assign to ipf maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=79416 From: Giorgos Keramidas To: Spartak Radchenko , freebsd-bugs@freebsd.org Cc: bug-followup@freebsd.org Subject: Re: kern/79416: ipf in 4.11 breaks POLA Date: Sat, 9 Apr 2005 04:02:39 +0300 On 2005-04-08 18:00, Spartak Radchenko wrote: > This ruleset worked OK in 4.8, 4.9, 4.10 (all outbound tcp > connections, incoming connections on port 80): > > block in log all > pass in quick proto tcp from any to any port = 80 > pass out proto tcp from any to any keep state > > Yes, I know that such ruleset is not recommended in ipfilter how-to, > but it worked anyway. The correct way to do the same thing is: block in log all pass in quick proto tcp from any to any port = 80 keep state pass out proto tcp from any to any keep state You're missing a "keep state" in the incoming rule. > And I think that "not recommended" doesn't mean "strictly prohibited". IMHO, it does mean "not guaranteed to work" though ;-) > In 4.11 incoming connections to port 80 do not work any more. The > ruleset must be modified: > > block in log all > pass in quick proto tcp from any to any port = 80 > pass out quick proto tcp from any port = 80 to any > pass out proto tcp from any to any keep state This is still wrong. From: Spartak Radchenko To: freebsd-gnats-submit@FreeBSD.org, devteam@donut.ugcs.caltech.edu Cc: Subject: Re: kern/79416: ipf in 4.11 breaks POLA Date: Sat, 09 Apr 2005 12:46:45 +0400 On Sat, Apr 09, 2005 at 04:02:39AM +0300, Giorgos Keramidas wrote: > You're missing a "keep state" in the incoming rule. >> And I think that "not recommended" doesn't mean "strictly prohibited". > IMHO, it does mean "not guaranteed to work" though ;-) Does it? Below is a quote from http://www.obfuscation.org/ipf/ipf-howto.txt --- cut --- Consider the following ruleset: pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 pass out quick on tun0 proto tcp from any to any keep state block in quick all block out quick all At first glance, this seems to be a good setup. We allow incoming sessions to port 23, and outgoing sessions any- where. Naturally packets going to port 23 will have reply packets, but the ruleset is setup in such a way that the pass out rule will generate a state entry and everything will work perfectly. At least, you'd think so. The unfortunate truth is that after 60 seconds of idle time the state entry will be closed (as opposed to the nor- mal 5 days). This is because the state tracker never saw the original SYN packet destined to port 23, it only saw the SYN ACK. --- cut --- IMHO, such behaviour is quite acceptable and even desirable. Blocking in pass rule is not. >> block in log all >> pass in quick proto tcp from any to any port = 80 >> pass out quick proto tcp from any port = 80 to any >> pass out proto tcp from any to any keep state > This is still wrong. But why? It does exactly what I want. As a rule, I don't like keep state on inbound connections. Especially with 5 days idle timeout ;) From: devteam@donut.ugcs.caltech.edu To: Spartak Radchenko Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/79416: ipf in 4.11 breaks POLA Date: Sat, 9 Apr 2005 20:10:55 -0700 > I know that such ruleset is not recommended in ipfilter how-to, but > it worked anyway. And I think that "not recommended" doesn't mean > "strictly prohibited". In 4.11 incoming connections to port 80 do > not work any more. Regardless, it is a POLA violation. I can understand changing the behavior going from 4.x->5.x, but not within the 4-STABLE series. POLA is one of the best features of FreeBSD. From: Giorgos Keramidas To: Spartak Radchenko , freebsd-bugs@freebsd.org Cc: bug-followup@freebsd.org Subject: Re: kern/79416: ipf in 4.11 breaks POLA Date: Sat, 9 Apr 2005 04:02:39 +0300 On 2005-04-08 18:00, Spartak Radchenko wrote: > This ruleset worked OK in 4.8, 4.9, 4.10 (all outbound tcp > connections, incoming connections on port 80): > > block in log all > pass in quick proto tcp from any to any port = 80 > pass out proto tcp from any to any keep state > > Yes, I know that such ruleset is not recommended in ipfilter how-to, > but it worked anyway. The correct way to do the same thing is: block in log all pass in quick proto tcp from any to any port = 80 keep state pass out proto tcp from any to any keep state You're missing a "keep state" in the incoming rule. > And I think that "not recommended" doesn't mean "strictly prohibited". IMHO, it does mean "not guaranteed to work" though ;-) > In 4.11 incoming connections to port 80 do not work any more. The > ruleset must be modified: > > block in log all > pass in quick proto tcp from any to any port = 80 > pass out quick proto tcp from any port = 80 to any > pass out proto tcp from any to any keep state This is still wrong. _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" From: linimon@lonesome.com (Mark Linimon) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/79416: ipf in 4.11 breaks POLA Date: Tue, 28 Feb 2006 03:49:22 -0600 ----- Forwarded message from Darren Reed ----- IPFilter now converts a "pass" rule into a block if, during processing the packet, it decides that it has the final matching rule but something else happens that means some sort of assumption about the packet being passed is bad. That "something else" might be a NAT proxy decided it wants the packet to be dropped or adding state fails with a rule that isn't "quick". I believe what was happening here is that in earlier versions of ipfilter 4.1 than 4.1.10, it would see that state couldn't be added (at the end of rule processing) and drop the packet - even with "quick" rules. Now, if "keep state" fails for a packet on a "quick" rule, the failure to add state becomes a reason to treat the packet as not matching the rule and we go to the next filter rule. In FreeBSD prior to IPFilter 4.x, if state failed to be added then the packet would still be allowed through. What is the difference here? If the original packet is allowed through, say it is a TCP SYN packet and no state is created then a SYN-ACK will be received and consequently blocked because there is no state. This can be a bit puzzling and also fails to enforce session limits, like it should, without impacting the system "inside." My real concern with this bug report is that the block ICMP packet should have been matched by state and wasn't. Is that still reproducible with FreeBSD-current ? Darren >Unformatted: