Re: NFR Features

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

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owner () uow edu au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
-----------------------------------------------------------------------------

> Is NFR able to monitor multiple segments from a single box?  i.e. will it
> support multiple NIC's with multiple instances of the packet driver on a
> single engine?

Yes, but we generally prefer not to unless they're relatively
low bandwidth. It also depends on the network topology; if
the same packet flows across both segments then it looks like
a duplicated packet and the reassembly engine flags it as such
(which is the correct behavior but is non-intuitive)  so depending
on what you're trying to do it either works fine or it's not
recommended.

> What solution do you have for consolidated reporting accross multiple
> engines?  Does your mgt console do reporting?  Do you use a Crystal Reports
> engine, etc.?

All NFR products can forward their data to an NFR central,
which collects it for further access. We like that for reasons
of data redundancy and also because it offloads query processing
from the individual sensors. Sensors can, however, be completely
standalone if you prefer and you can use the console GUI to
query either the sensor or the central securely over a network.

On the central (as of version 5.0 which is going gold sometime
this week) you can have data automatically uploaded into an
ODBC database, if you like, or you can query the results out of
our database into a reporting tool (you can pull things out as
.CSV) We've got a PERL query driver for UNIX machines (centrals
run on UNIX that can be used to remotely query a sensor, or
that can pull from the central itself and generate various
activity summaries. Lastly, there's a Windows-based tool coming
out with 5.0 that you can run on a Wintel system, which periodically
contacts a sensor or a central, queries data out of it and
uploads what's new to ODBC databases.

We didn't build something like Crystal Reports into our product
because we didn't want to limit your options. If you want to do
reports in a windows-oid environment, the best approach would
be to have the Windows ODBC gateway running, shove things into
ODBC, then report from the database until you're purple in the
face. ;)  If you're a UNIX guy, you can just suck the stuff
straight into PERL and go to town from there.

Hope this helps!

mjr.
-----
Marcus J. Ranum
Chief Technology Officer, Network Flight Recorder, Inc.
Work:                  http://www.nfr.net
Personal:              http://www.ranum.com