RE: distributed snort

[Fraser Hugh <hugh_fraser () dofasco ca>]

> -----Original Message-----
> From: meling [mailto:meling () scan-associates net]
> Sent: Tuesday, October 02, 2001 11:18 PM
> To: snort-users () lists sourceforge net
> Subject: [Snort-users] distributed snort
>
>
> Hi,
>
> I'm developing a distributed intrusion detection architecture using 
> Snort on the IDS sensors. We're targeting to deploy > 50 sensors on 
> multiple networks. These sensors will push the alert logs to 1 central
> console, where data crunching and analysis will take place.
>
> My questions are:
>
> 1. How feasible it is to send alert logs from 50 sensors to 1 
> central console? 
>    The central console will have several different components 
> in itself,
>    such as data parsing, etc.

Decide if the central console is used for analysis or alerting. If it's
going to be used for alerting, consider a separate private LAN to connect it
to the sensors, since some attacks detectable by the sensors may also be
disrupting communication with the console, blocking vital alerts. 

That's not always possible. I've configured our sensors to make decisions
about the importance of an event on their own and do the paging themselves
(each has a phone line and paging software) regardless of whether it can
communicate with the central console. Background transfers of events to a
central repository is OK if it doesn't need to be realtime. 
 
> 2. What is the most efficient way to make sure that Snort is 
> runnig 24x7 on
>    the sensors? Is tcpserver any good? 

I've outfitted the sensors with Netsaint to monitor the operation of the OS
and applications running on them (ie. Snort). It can be configured to
re-start the apps if necessary, and it also feeds the paging software if
there's a problem. In addition, t can be installed on the central console to
monitor (from a single spot) the health of all the sensors.

> 3. What are the best data consolidation techniques available? 
> My concern is 
>    that when too many data are displayed from various sensors on the 
>    monitoring console, security analyst will tend to ignore them. 

I have yet to find a single solution for reducing the number of alerts
generated by IDS systems, and have resorted to a series of automated
processes, which includes things as simple as a table of alerts that I'm
currently investigating that's cross referenced each time Snort adds an
alert to the database, and as complex as control-chart theory from the
process automation world to look for significant activity either for a host
or for an alert. Alerts that float to the top through this process notify
security personnel that there's something that needs to be looked at, and
also cut a trouble ticket that's used to keep an audit trail for followup
investigation. It's the final output of this process hat we end to look at,
not the raw data collected by Snort.

I'm also looking event correlation software, both commercial and free. "sec"
(Simple Event Correlation tool) from http://kodu.neti.ee/~risto/sec is a GPL
script that can be used to do some compression and hi/low limit thresholding
to reduce the number of alerts you'll see.

> Your input are very much appreciated.
>
> --mel
> http://ini2.net/mel 
>
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users