> > You get *better* information on per-rule limits than on a global limit.
>
> No, you simply get a finer-grained ability to select.
Which is almost always better.
> > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > month of bad packets in it.
> >
> > If you're an admin on today's internet, you'd realize that there is *NO*
> > way to get save a month worth of bad packets. Heck, at least once/week
> > I can't even store a day's worth of bad packets (I assume when we say
> > bad packets, we're talking about the
>
> If I'm an admin on today's internet (and I am), of course I realize that
> I'm not going to save a month worth of all bad packets, but I _can_ choose
> to hold onto a reasonable amount of logging information, which is what we
> are discussing.
Sure, but you can't call 'tossing 4/5 of the information that I receive
in a totally arbritary manner' useful logging information. A global
count would allow you to log information in a totally arbitrary manner.
In that case, why have separate log rules? You may not ever get to see
them if the limits are hit, so why not just one single rule to catch
everything you want to log, since there's no guarantee that you'll see
any logged information from the other rules.
You might get something, but it's totally arbitrary and based upon known
'scripts' on what information is logged.
Finer grained logging gives you *better* information, since it's more
detailed. If you don't care about details, then why are you logging at
all?
> That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it
> allows you to sample the beginning of each 5 minute period, and you
> ought to be able to calculate the space required in a manner that
> allows you to guarantee that you have sufficient space.
I can't speak for the author, but as one of those involved in the
discussion this wasn't even on the radar screen. The purpose of the
option was to make DoS attacks less likely. It wasn't intended to
provide you a good 'sampling' of attack packets on your system.
Security is not effectively done by sampling. Sampling is too easy to
thwart, and too often misses intrusions that are easily done by not
doing sampling. :)
And, because IPFW is so low-cost, there is very little reason to do
sampling. Sampling is often done when 'real-time' monitoring is too
expensive.
What I'm hearing is that you want to change FreeBSD from doing
'real-time' monitoring to doing polling. The latter can be implemented
from the former, but not vice-versa. We would be losing flexibility and
usefulness by moving towards a 'polling' model.
My advice to you is to quit 'polling' for packets (because as you've
implied, you're not interested in the most of the information anyway),
and use a *MUCH* smaller limit on your rules, and limit the number of
rules you have, and you'll have almost the same result.
> Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 100000,
> and you reset the counter every 5 minutes, you still _ought_ to be able to
> determine that you require 2GB of disk space per day to keep those records.
Great, but why even log data when you *plan* on throwing much of it
away, in a totally arbitrary fashion. Why even bother?
> (And if you're getting 100K rejectable packets every 5 minutes, something
> is seriously wrong)
Rejectable != log it. I reject alot of packets (most of them) and I
don't care to log them. People do stupid things that aren't worthy of
being logged, and there are alot of stupid people on the net doing
things that aren't malicious that I don't care about.
And, if you've got 100K 'logged' packets every 5 mins, then you better
plan on having 2GB of disk-space/day if you care about saving them.
Otherwise, if you don't have that much disk space, then don't reset
every 5 minutes, since you can't keep the information. Either way you
throw away information. With per-rule limits you have a much better
idea on what kinds of information you are throwing away. (Fine-grained
control).
> > If you're logging that much information, then you're logging too much
> > information. In any case, you've got information overload, so adding a
> > global limit on the rules means you're losing as much (or more)
> > information than you're logging, which is just as bad (or worse).
>
> No. You're not necessarily logging too much information. I do log a whole
> bunch of shouldn't-happen scenarios, because if they do happen, it means
> something is either horribly broken or somebody is doing something horribly
> wrong.
You might not see that happening since you're global rule was hit in the
first 30 seconds by someone doing a POP3 scan of your entire network,
followed by a breakin you missed.
> I don't want an event such as an outbound source 10-net address to
> happen... in theory it can't because I filter at my borders and use no
> 10-net stuff internally. But I damn well want to know if it happens
> ANYWAYS.
You will have a very small chance of noticing it with a global limit.
If you're truly concerned that you can generate 100K/sec of logging and
want 5 minute resets (or whatever), then build your system with 18GB of
disk and live with it. Otherwise,
> > If you're worried about logging too much information, then don't reset
> > your counters every 5 minutes. Besides, you're losing information if
> > you're max'd out every 5 minutes anyway, so it really doesn't matter
> > when you zero out your counters.
>
> You just argued my point for me, thank you. I _want_ to see the things that
> I choose to log, and by definition once I pass IPFW_VERBOSE_LIMIT, then the
> information is beyond the point of being useful.
True, but the information you gather that you are losing is totally
arbitrary with a global counter. With individual counters, you tend to
lose information on similar attacks, and in a DoS attack the information
is mostly redundant.
> > > I don't know what you mean by "make the rules 'more verbose'" but what I
> > > am advocating is not any change in what currently exists... I am talking
> > > about limiting the number of entries possible in a manner that would seem
> > > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT.
> >
> > IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most
> > attacks don't hit the entire system on every rule in order to do a DoS
> > attack. Even so, each rule with eventually 'limit-out' and the system
> > will no longer log packets. This is a 'bad thing' from a security
> > standpoint, since at that point we are losing information.
>
> Okay, so what YOU really want is to not set up an IPFW_VERBOSE_LIMIT at all,
> and that's perfectly valid as well.
That's not what I said. You *must* have this to avoid DoS attacks.
> > The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still
> > allowing *MAXIMUM* data collection when a DoS attack is not happening.
> >
> > It's not there to make your logfiles small. If you want small logfiles,
> > turn of IPFW logging altogether.
> >
> > (I'm actually serious here.)
>
> Oh, that's a f'ing crock. What _I_ really want is to be able to GET the
> god damn information when the system is in securemode 3 and the damn IPFW
> has stopped logging due to the VERBOSE_LIMIT. You think I'm interested in
> turning OFF IPFW logging?
Yes, I think you are. You expect to lose information, and you don't
care to know what kind of information you are losing. With per-rule
counters, at least I know what kind of information I'm losing.
> The stated rationale behind adding VERBOSE_LIMIT, when it was added, was to
> reduce or eliminate the chance of a DoS attack. Now, the best way to
> eliminate the chance of a DoS attack is _algorithmically_. Giving someone
> a mechanism that allows them to determine the maximum resource commitment
> for a given scenario eliminates the chance for that DoS attack. Giving
> someone a mechanism that may use a variable quantity of resources is the
> typical programming practice that leads to a resource starvation DoS.
Let's see.
1) You know your IPFW rule limits
2) You know how many rules log
3) You know how often your counters are zero'd.
Therefore, you can algorithmically determine how many resources are
required (worst case) to not fill up your disks.
No problem. You have everything you need to do the job. We haven't
done anything different with a global counter *EXCEPT* make the kind of
information you lose in a DoS attack totally arbitrary.
And, in most DoS attacks, they tend to hit a single rule. You're still
able to gather information on subsequent attacks that are unrelated to
the first attack.
A win-win situation.
In any case, you aren't going to convince me that a global counter is
better than a per-rule counter. No way, no how, so I'm going to drop
the discussion.
> What I absolutely need is a way to clear out the VERBOSE_LIMIT
> counter.
I've not argued for/against this ability at securelevel 3. I'm of two
minds. There are valid arguments both ways, and without more feedback
from others, I'm certainly not going to code up something or apply
patches that I don't feel comfortable with.
But, I'm interested in the results, since this is an issue that I face
on a regular basis, hence my postings.
Somehow, a discussion about zero-ing out firewall counters degenerated
into a global vs. per-rule counter argument, and that's 'counter' to the
original problem. :) :)
> > One could argue that accounting numbers in a firewall shouldn't be
> > trusted, but I won't argue that point since the firewall is often the
> > most 'natural' place to stick network accounting software.
>
> If you can't trust something in the kernel, then you just can't trust
> anything at all.
It isn't the kernel that's zero'ing the counters. :)
> > > Well, the 'right' thing is clear: pull the limit count out of the
> > > accounting count. This solves both the problem of zeroing accounting
> > > counters and potentially messing with other things, and also of letting
> > > people do anything 'negative' in securelevel 3.
> >
> > Is it the 'right' thing to do? I think that someone messing with the
> > 'logging' rule counts could be just as dangerous as someone messing with
> > the accounting counts.
>
> It is no more dangerous
Agreed. But it's 'just as dangerous', and letting people mess with the
counters in securelevel == 3 *IS* the issue. Should it be allowed?
Yes, it's nice to do. But, the point of high securelevel is to avoid
*ANYTHING* (even useful things) that might compromise the integrity of
the system. And, the IPFW counters constitute part of the integrity of
the system. Is it part of the system that should be modifiable? I
don't know, there are issues on both sides of the argument. Neither
side is compelling enough (in my mind) to change the existing behavior.
I, and somebody zeroing (the only thing they should
> > Again, if you're paranoid enough to have securelevel 3, you've got to be
> > paranoid enough to assume that someone *HAS* root access on your box,
> > and is going to do anything nasty they could.
>
> Yes, but causing additional logging to happen is going to be something that
> is likely to _attract_ my attention.
If they've got root, they can also mess with your logfiles.
> > > By pulling the limit count out into a separate entity, nothing
> > > 'negative' can happen (because stopping the logging process is
> > > definitely negative, and being able to restart it without messing with
> > > other stuff is positive).
> >
> > I'm not sure this is an acceptable change either, but I'll leave that
> > discussion to the networking folks.
> >
> > > Now that we are agreed that the limit count needs to be divorced from the
> > > accounting count, we can debate whether it should be a per-rule or global
> > > limit.
> >
> > Hold on to your horses, Hoss. I haven't agreed to that. Don't be
> > putting words in my mouth. :) :)
>
> Well, then, how do you "fix" this problem?
I don't know if it's a problem that should be fixed. The side-effects
of the fix are potentially as bad as the existing problem.
It's not a bug, it's a feature. :) :)
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
