From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 11 08:06:38 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7003C53F; Tue, 11 Mar 2014 08:06:38 +0000 (UTC) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id DC46D26A; Tue, 11 Mar 2014 08:06:37 +0000 (UTC) Received: from nskntcmgw08p ([61.9.169.168]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20140311080629.HPQA26993.nskntmtas02p.mx.bigpond.com@nskntcmgw08p>; Tue, 11 Mar 2014 08:06:29 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nskntcmgw08p with BigPond Outbound id c86V1n00F29zwdD0186VS8; Tue, 11 Mar 2014 08:06:29 +0000 X-Authority-Analysis: v=2.0 cv=b8MwE66x c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=6I5d2MoRAAAA:8 a=KRYVWgrIeV_SfOQ2490A:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=OUIiSCU4Aon4Tw1b:21 a=8090jt6BRmlbcaYK:21 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s2B86hSj014186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 19:06:44 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <531EC3E6.8030604@heuristicsystems.com.au> Date: Tue, 11 Mar 2014 19:05:58 +1100 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Julian Elischer , ipfw@freebsd.org Subject: Re: ipfw stateful and ICMP References: <531E88C3.6030305@freebsd.org> In-Reply-To: <531E88C3.6030305@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 08:06:38 -0000 On 11/03/2014 2:53 PM, Julian Elischer wrote: > It has annoyed me for some time that icmp packets refering ot an > ongoing session can not be matched by a dynamic rule that goversn that > session. > > For example, if you have a dynamic rule for tcp 1.2.3.4 port > 80 from 5.6.7.8 port 10000 then a returning icmp packet giving > "destination unreachable" and holding the appropriate header > in it's data segment should probably be allowed to go through > back to the originator. > > Briefly looking at the code I see no sign of this and I haven't seen > any sign of it in action so I hope I'm not going to get a > "but it already does that" response. > > My way of approaching it would be to change the dynamic rule code so that > it checks that the ICMP destination address matches the source address > of the packet fragment in the 'data' section, and then match the data > segment > packet header with the dynamic rules instead of the icmp packet itself. > > I would also add a sysctl to disable this behaviour, because there is > always > someone who doesn't want any change you care to name. > > The only way you can allow get icmp packets back to the originating > sender > at the moment is to just allow them through without any major filtering. > That leaves you open to a large attack window. > > anyone have violent objections? > > (I'm currently rewriting the firewall rules at $DAYJOB and I think I'd > like to have this, > but as we're on 8.0 I'll have to wait a while before I can use my own > patch :-) > > Julian > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > Julian, That's a good idea, and I appreciate the feedback opportunity. May I suggest a sysctl to enable the behaviour, rather than one to disable it. For two reasons: so that existing ipfw sites don't find the need to change or amend existing firewall rules (we typically open icmp 3 and 11); and how do you envisage "ipfw show" will display this compound behaviour? Regards, Dewayne.