Re: Re: FW: NFR Features

[Dave Goodrum <dgoodrum () 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
-----------------------------------------------------------------------------
M,

5.0 is in Early Release right now, and in production in several
environments.  

While running queries from the GUI Console is still available, we have
added functionality to export the database out of the NFR database
engine, and into some other database program (i.e. Oracle, SQL).  This
allows greater manipulation of the data collected by the NFR IDAs
(Intrusion Detectoin Appliances).  

This also takes the burden of crunching detailed queries off the NFR box
and places it into a box dedicated to crunching database numbers. 
That's very helpful when you consider the fact that some people may have
data going back a LONG time that they want to query.  This is especially
helpful if running a standalone IDA that must crunch it's own database
numbers.

Terminology is important here, so let's outline the architecture of NFRs
distributed system.  The IDA(s) sit on a wire and sniff it (a NIC with
no IP address in permiscuous mode (the monitor NIC)).  It then uses a
second management NIC (this one has an IP address and would hopefully
sit on a separate secure network) to report any alerts back to a
Central.  This Central doesn't do any sniffing, but rather is a
collection & management point for the IDA(s).  The third component is
the GUI Console, which is runs on any Windows 9x,NT,200 machine.  The
GUI Console talks to the Central, where it is used to make changes to
the IDA(s) (like turning off/on filters), configure alerting, run
queries, setup users, etc.  
I should point out that you do not have to run in a distributed
architecture.  If you choose, you can manage your IDA(s) separately, but
this can prove burdensome when manageing multiple IDAs, and querying
will affect the performance of the IDA to sniff the wire, since a
standalone has to crunch it's own database numbers.  With a central, the
central does the number crunching.

So to say that you can have a separate Report Engine instead of running
the Report Generator from the Console is very true.  Your "Report
Engine" can be almost any ODBC compliant database server. 

Hopefully I didn't overanalyze your question.  I've probably raised more
questions that answered, but eventually we'll get to the bottom of it. 
:)

Dave Goodrum
NFR PreSales Engineer

p.s.  If you want to see this in action, go to our website and look at
our show schedule.  We usually have a distributed system at our shows,
and run attacks on the wire so that people can see NFR in action.

mht () clark net wrote:
> I thought 5.0 was due out in Feb '00??  So are you saying one can have a
> separate Report Engine instead of running the Report Generator from the
> Console???
>
> /m
>
> At 03:17 PM 9/14/00 -0400, Dave Goodrum wrote:
> > 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
> > -----------------------------------------------------------------------------
> >
> > See reponses below from NFR  *****
> >
> > > -----Original Message-----
> > > From: owner-ids () uow edu au [mailto:owner-ids () uow edu au]On Behalf Of
> > > Carric Dooley
> > > Sent: Wednesday, September 13, 2000 10:49 AM
> > > To: ids () uow edu au
> > > Subject: IDS: NFR Features
> > >
> > > > Maybe Marcus or someone over there can answer these questions:
> > > >
> > > > 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, we support multiple NICs but don't usually recommend it.
> >
> > The only times I've recommended this configuration is when we want an
> > IDA (Intrusion Detection Appliance) to monitor a failover segment.  i.e.
> > only one NIC will actually be gathering data at a time.  The second NIC
> > would start seeing traffic if one segment failed and the other kicked
> > in.
> > *****
> >
> > > > 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.?
> >
> > *****
> > In our 5.0 product you can do an ODBC export from our Central to a
> > database server of your choice (probably Oracle or SQL).  From there,
> > you can generate whatever kind of report you want.  We do also have some
> > basic canned reports in our 5.0 product listing things like:  top 20
> > attackers, top 20 attackees, top 20 types of attacks, etc.
> >
> > "What is our Central", you may ask.  In short:  In a distributed
> > environment, you may have many IDAs scattered across the network.  Each
> > of these can be set to report it's results back to a single Central.
> > This central, then does all the alerting/reporting/querying.  This also
> > allows for completely centralized management of the IDAs scattered
> > around the network.
> >
> > For more information you can download our documentation from www.nfr.net
> > *****
> >
> > > > It has been a while since I played with the product, and I was just
> > > > wondering.
> >
> > > >