From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 11 03:53:58 2014 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E1EC61C for ; Tue, 11 Mar 2014 03:53:58 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04B02AC9 for ; Tue, 11 Mar 2014 03:53:54 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s2B3rkNg000849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 10 Mar 2014 20:53:47 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <531E88C3.6030305@freebsd.org> Date: Mon, 10 Mar 2014 20:53:39 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ipfw@FreeBSD.org Subject: ipfw stateful and ICMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 03:53:58 -0000 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