From owner-freebsd-ipfw  Tue Jul 27  7:23:57 1999
Delivered-To: freebsd-ipfw@freebsd.org
Received: from aurora.sol.net (aurora.sol.net [206.55.65.76])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2DA8914BEC; Tue, 27 Jul 1999 07:23:32 -0700 (PDT)
	(envelope-from jgreco@aurora.sol.net)
Received: (from jgreco@localhost)
	by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id JAA90029;
	Tue, 27 Jul 1999 09:22:36 -0500 (CDT)
From: Joe Greco <jgreco@ns.sol.net>
Message-Id: <199907271422.JAA90029@aurora.sol.net>
Subject: Re: securelevel and ipfw zero
In-Reply-To: <Pine.BSF.4.10.9907262311020.35843-100000@janus.syracuse.net> from "Brian F. Feldman" at "Jul 26, 1999 11:12:37 pm"
To: green@FreeBSD.org (Brian F. Feldman)
Date: Tue, 27 Jul 1999 09:22:36 -0500 (CDT)
Cc: dillon@apollo.backplane.com, jgreco@ns.sol.net,
	hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> On Mon, 26 Jul 1999, Matthew Dillon wrote:
> > :Instead of zeroing it, how about raising the logging limit to (current +
> > :whatever the limit was)
> > :
> > : Brian Fundakowski Feldman      _ __ ___ ____  ___ ___ ___  
> > : green@FreeBSD.org                   _ __ ___ | _ ) __|   \ 
> > 
> >     The way I see it either some piece of software is monitor the counters,
> >     in which case the sysad does not need to clear them and does not need to
> >     look at log messages, or the sysad is monitoring the stuff manually and
> >     using the log messages.  In the one case the counters don't need to be
> >     cleared (and, indeed, should not be), in the other case the sysad may 
> >     want to clear them due to the manual monitoring.
> > 
> >     What we are really discussing here is the use of ipfw's counters in an
> >     unsophisticated setup.  The sophisticated setup is already handled.
> 
> That doesn't mean we shouldn't allow people to have an unsophisticated setup,
> just because a sophisticated one is available. It would be useful to have
> a per-firewall-rule counter, decrement it on each match if logging and
> set, and be able to reset to something higher.

This doesn't work the way you say.

If there was a single global VERBOSE_LIMIT counter, yes, it'd be trivial to
monitor for it to max out and then raise the limit.  However, with the
current design, what will happen is ... let's say you have ten log rules.
Your intruder spends a few days puttering and in the meantime gets your
auto monitoring system to raise the limit to 100,000 in 100-increment steps,
by beating on Rule #1.

Now, all of a sudden, Rule #2's counter is still at 0 and the limit is at
100,000...  do you see the potential for damage, or need I point out #3-9?

What you describe would be fine if there was a single global VERBOSE_LIMIT,
but in that event I'm not sure what difference there would be between doing
this limit-raise thing and just resetting the counter.

... Joe

-------------------------------------------------------------------------------
Joe Greco - Systems Administrator			      jgreco@ns.sol.net
Solaria Public Access UNIX - Milwaukee, WI			   414/342-4847


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message