Re: Recording slow scans

["Marcus J. Ranum" <mjr () nfr net>]

Bennett Todd wrote:
> Right now it looks like the most actively-developed and researched IDS is
> NFR, but NFR has gotten backed into a kind of icky pickle; while people are
> encouraged to play with it, as soon as they try using it they discover it
> can't keep up with a busy net, and are told to buy the commercial one, as it
> is apparently faster --- enough so to be useable.

Yup, it's driving us nuts too. We wanted people to be able to play
with NFR and learn from it and get useful stuff done, but we found
out the hard way that out-of-the-box UNIX can't cut it for busy
networks. For non-busy networks, even, we have problems because
frankly, the average experience level of network managers has dropped,
in the last few years, due to the rapid explosion of networking.
In other words, the clue-density of the Internet has dropped, and
NFR (in its source form) requires clue. What can the vendor do but
tell someone to buy the commercial version, when they E-mail you
and say, "your software sucks. I have the source. what is this
'make' thing? and I didn't read any of the directions especially
not the release notes where it says that the OS I am trying to use
is wretchedly slow at packet capture."

Those factors hurt us more than they do anyone else. :(
But that's on the business side. 

We have some stuff that will be out in a while that caters to
the performance problem as well as the setup problem. But it'll
most likely be available only in the form of a commercial product
evaluation version.

> > (2) significant kernel bloat and subsequent requirements for machines;
> > (3) all IDS solutions are part-kernel, part-user programs;
>
> Sure --- but I think the point was to shove enough of the screening decision
> logic down to the bottom of the stack to help performance, is all. As for
> kernel bloat, if the bloat's too bad, why then don't use it, I don't expect to
> see this kind of goo included by default until and unless people start using
> it really widely.

Kernel bloat isn't the issue. It's cost to maintain kernel mods
that is. I don't care where my code runs as long as it runs fast
and as long as it's relatively portable. The bad news is that to
do high speed networking you need to make optimizations that are
inherently unportable, because the code you get from the vendors
is NOT GOOD ENOUGH. We'd *LOVE* to be able to sell NFR on Solaris
but it'd mean either that we have to replace DLPI or pray that
Sun fixes it. Neither of those options is attractive.

> > (4) you have to convince the right people that it is worrthwhile (and
> >     they might (rightly) say "use NFR" or some such).
>
> "use NFR" is only an option if (a) you don't need to track a busy net, or (b)
> you don't care about open source. Some of us do care about open source.

You can track busy nets with NFR. You just can't do it on any of
the operating systems *YOU* have. We've spent upwards of $400,000
in engineering costs to fix packet capture routines. You're welcome
to spend the same effort and fix whatever UNIX you prefer and guess
what? NFR will handle busy networks for your platform and you'll
have source. Nobody else even gives you the source. Nobody else
will give you close to as much as we do.

I'm sorry if I seem unsympathetic but whining about the fact that
a company isn't nice enough to put itself out of business by giving
you everything you want for free just isn't jerking tears of pity
out of me right now.

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr