From owner-freebsd-security Sun Jul 30 16:42:28 2000 Delivered-To: freebsd-security@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id A761237B516; Sun, 30 Jul 2000 16:41:49 -0700 (PDT) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id JAA14229; Mon, 31 Jul 2000 09:41:12 +1000 (EST) From: Darren Reed Message-Id: <200007302341.JAA14229@cairo.anu.edu.au> Subject: Re: log with dynamic firewall rules In-Reply-To: <3984B371.A5BF509E@math.missouri.edu> from "stephen@math.missouri.edu" at "Jul 30, 0 06:00:01 pm" To: stephen@math.missouri.edu Date: Mon, 31 Jul 2000 09:41:11 +1000 (EST) Cc: billf@chimesnet.com, jmb@hub.freebsd.org, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from stephen@math.missouri.edu, sie said: > Bill Fumerola wrote: > > > > I fear the dynamic rule code, or I'd attempt to figure it all out > > and come up with something better, but: > > > > > Now wait five minutes and the dynamic rule times out, and it stops > > > working. Well, that is OK I suppose - you shouldn't have left it so long. > > > > [boa.internal-billf 18:52:25] > > < /home/billf > sysctl -a |grep dyn > > net.inet.ip.fw.dyn_buckets: 256 > > net.inet.ip.fw.curr_dyn_buckets: 256 > > net.inet.ip.fw.dyn_count: 0 > > net.inet.ip.fw.dyn_max: 1000 > > net.inet.ip.fw.dyn_ack_lifetime: 300 > > net.inet.ip.fw.dyn_syn_lifetime: 20 > > net.inet.ip.fw.dyn_fin_lifetime: 20 > > net.inet.ip.fw.dyn_rst_lifetime: 5 > > > > ... it is a controllable behavior. > > Yes, I knew that. (I alluded to it at the end of my message.) > Although it is not controllable unless you are > root. There must have been some thought given to these default > values, and why they are right. Make net.inet.ip.fw.dyn_ack_lifetime > too big, and you begin to defeat its purpose. Make it too small, > and you have the problem I describe. Then again, maybe there wasn't. The timeout's above resemble nothing useful except arbitrary numbers pulled out of a hat. The timeouts used by IP Filter tend to be somewhat more realistic, with all (except RST/established) being 2*MSL. The established timeout is at 5 days. On top of this, the size of the state table (say with 6000 entries) does not make IP Filter behave like there are 6000 rules. I would go on to say that the "state" tracking in ipfw is a far cry from that in IP Filter (which is maturing rather nicely!). Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message