Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jul 1999 13:44:16 -0600
From:      Nate Williams <>
To:        Joe Greco <>
Cc: (Matthew Dillon), hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG
Subject:   Re: securelevel and ipfw zero
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> > :So, I've a box that I have an ipfw ruleset on.  The firewall should not be
> > :changeable during runtime, and the box runs at securelevel=3.
> > :
> > :In order to prevent DoS disk-fill attacks, I also have specified

FWIW, as you pointed out below, this was put in specifically to avoid a
DoS attack.

> > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter,
> > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT
> > :events and then you lose logging (ideally I'd zero nonzero rules once every
> > :N minutes).
> > :
> > :Comments?
> > 
> >     Playing devil's advocate, someone might be using those counters for
> >     accounting purposes.  That's about as worse a scenario as I can think
> >     of, and I can't imagine this sort of situation would be prevalient.
> > 
> >     I'd say that the counters should be clearable at high secure level.
> Then there should be a separate counter for logging purposes...?  I do not
> care if the accounting counters do not clear (ever), since things like MRTG
> are designed to deal with that situation.


> However, it seems bad that you
> would not be able to clear your counter for logging purposes, just in case
> you actually _did_ mean that you want bad packets to be logged.


> I will also note that it would be acceptable, to me at least, to maintain a
> global (rather than per-rule) limit for the verbose limit.  In general, I
> would think that someone who uses the limit facility is trying to avoid a
> DoS style disk-space attack.

Agreed, see above.

> Having a per-rule limit means that you
> actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit
> (assuming an attacker exploits multiple rules) rather than a limit of 

I disagree.  I have *tons* of firewall rules, and I don't want to have
to recompile my kernel if I modify my script at a later point and make
the rules 'more verbose'.

Case in point, I may at one time want to 'log' all connections to a
particular port, and then later ignore (no longer log) all the
connections to that port *except* to a particular host.  Or, the reverse
may be true.  In these cases, I don't want to have to recompile my
kernel to allow 'more logging' of the information.

I think a 'per-rule' limit works best, instead of a global limit.  This
also works well in the case of rootkit attempt breakins, since they tend
to hit one rule multiple times, and then another multiple times, etc...

With a 'global' limit, I may end up 'limiting out' on the first rule,
and then miss all the rules hit later on with the attack.

> It also makes it more difficult to code in a bunch
> of "log" rules, since your periodic "zero" script has to know the number of
> each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you
> get a bunch of
> /kernel: ipfw: Entry rule1 cleared.
> /kernel: ipfw: Entry rule2 cleared.
> /kernel: ipfw: Entry rule3 cleared.
> each time you do this.

Or, you do like I do, and have a cronjob 'zero' out the entire log
ruleset everynight right after it sends the results to me to analyze.

However, at times (during breakins I happen to catch, or during ruleset
debugging sessions) I still want to have control over individual rules.

> I would rather see something like
> /kernel: ipfw: logging limit reached, suspending.
> # /sbin/ipfw zerolog
> /kernel: ipfw: logging limit reset, resuming.

This is essentially what I do.  But, you can do 'ipfw zero' which
accomplishes the same thing.

However, this is really a side-issue.  The last thing I'll say is that I
think a 'global' counter is a bad idea, and this is from using IPFW for
years in a real/deployed FreeBSD firewall situation.  It would cause me
more trouble than it's worth, and provide 'less' flexibility than
currently exists (which I use).

The real issue from your first email is '*should* ipfw rules be
'zero-able' at securelevel 3'.  I'm of two minds.  The paranoid
administrator can't think of any bad things that could occur, but I can
imagine something bad happening if someone were allowed to do this,
although it's not completely concrete.  I don't have the brain-cells to
dedicate to thinking about the full implications of a 'bad-guy' zeroing
out my rules.

On the other, the firewall administrator who actually has to use this
darn system is less worried about breakins and such, thinking that if
someone compromised my system at high securelevels, they could do more
damage to my system in other ways than by zeroing out my firewall

But, then again if we're in securelevel 3, we shouldn't let *anyone* do
anything to the system, since we're paranoid about anything negative
happening to my system.

In other words, I'm not sure what is the 'right' thing to do here.


To Unsubscribe: send mail to
with "unsubscribe freebsd-ipfw" in the body of the message

Want to link to this message? Use this URL: <>