From owner-freebsd-security@FreeBSD.ORG Sun Mar 23 15:47:44 2014 Return-Path: Delivered-To: freebsd-security@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 DFA0198A; Sun, 23 Mar 2014 15:47:44 +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 96CD17E6; Sun, 23 Mar 2014 15:47:44 +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.8/8.14.8) with ESMTP id s2NFlgbD004437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 23 Mar 2014 08:47:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532F0217.6050507@freebsd.org> Date: Sun, 23 Mar 2014 08:47:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brett Glass , RW , freebsd-security@freebsd.org, ipfw@freebsd.org Subject: Re: URGENT? References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <201403231500.JAA00968@mail.lariat.net> In-Reply-To: <201403231500.JAA00968@mail.lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:47:44 -0000 On 3/23/14, 7:56 AM, Brett Glass wrote: > At 11:33 PM 3/22/2014, Julian Elischer wrote: > >> in ipfw that's up to you.. >> but I usually put the check-state quite early in my rule sets. > > I don't, because I want packets to touch as few rules as possible > for the sake of > efficiency. One "check state" can cause an awful lot of work to be > done! check state is a hash ;ookup and generally doesn't cause a lot of work. it's about the equivalent of 2 simple rules I would guess so if you save two rules by using check state, then you win. > > In my IPFW rule sets, I divide the work up by interface, and so > there's a > "check-state" only for interfaces and directions (in vs. out) to > which automatically > generated rules will apply. I do the same. first thing my rule set does is break the packet flow into N*4 separate sets of rules, where N is the number of interfaces. Each interface gets two sets of rules.. one for incoming and one for outgoing. each of these it further divided into two smaller sets. One for packets that are for or from THIS machine, and one that is for packets no for or from this machine) incoming, for me incoming NOT for me outgoing from me outgoing NOT from me each of these sets can then have rules. however since we know some of the information already it doesn't need to be tested again so the rules there tend to be "from any to any" because we already know who it's for (or from, depedning on the direction) > The problem is that this is still inefficient, because there's only > one batch of > automatically generated rules, containing some that will never apply > in certain > situations. My rule sets would be more efficient if I could divide > the automatically > created rules into multiple batches, and do "keep-state N" and > "check-state N" to check > only the batch that needed to be tested in a particular spot. This > ought to be a relatively > easy patch, and I've thought many times about coding and submitting > it. "N" would default > to zero, so the old behavior would be preserved if there was no "N" > at the end so as not > to violate POLA. > >> I am working on a new rc.firewall that is much more efficient. >> the trouble is that the script to make it do what I want is a bit >> more complicated. >> I'll put it out for discussion later. maybe tonight. > > Would like to see it! see other emails for sample output. > > --Brett Glass > >