Re: Enterprise rollout - 50+ Distributed sensors with centralized managment / alerting / analysis

[Jason Haar <Jason.Haar () trimble co nz>]

Shon wrote:

> I'm looking for some enterprise implementation advise.
> We have around 50 field offices that we'd like to
> deploy Snort in, along with a fairly large corporate
> office deployment. The 50 field offices are WAN
> connected, usually with a T-1/VPN solution.
>
>  

Sounds similar to us. We have Snort running all over the world.

> My question is how to deploy Snort so that I can
> manage the alerts/reports from all of these sensors in
> one location?
>
>  

Don't we all ;-)

> From what I've seen the most common solution is to
> have the sensors all log to a common DB, but I assume
> this solution is impractical over WAN connections with
> limited bandwidth. So how do I get around this? 
>
>  

Yup - you don't want snort blocking due to slow network SQL calls.

And that's where barnyard comes in. We run all snort's "local" and use 
the syslog output processor to trigger real-time alerts, and local SQL 
backends for the regional IS group to access ACID interfaces. But we use 
Barnyard to "merge" all those logs into a central SQL server for doing 
cross-WAN analysis. You set up snort to log in the binary format, then 
write a cronjob to rsync those files to the central "barnyard server", 
which then uses barnyard to push that new data into the central SQL 
database.

BTW: even though it's in place - it's almost unusable. The sheer volume 
of SQL records makes "browsing" interfaces like ACID effectively 
useless. You really have to figure out just what kind of information you 
want to get from your centralized NIDS logs, then write a SQL script 
that will get the results you want.

I feel the centralized database doesn't hold much advantage over 
individual databases for most uses. Obviously it'd be nice to go to one 
app and see all data - but the volume... The big advantage is that it's 
basically the only way you can see if someone it trying to find a weak 
point in *your company's network* - instead of just one part of it. e.g. 
someone running Nessus against one of your DMZes is one thing, one IP 
address running Nessus against 15 of your DMZes in 8 different countries 
is a sign you have a *serious* enemy on your hands. Only 
cross-correlation via centralized logging gives you that functionality. 
However, it's sad to say that these days even that has false positives. 
We had one incident where a Korean IP address attacked our DMZes in 3 
different countries (in a 2 day period) - and it ended up been CodeRed 
from a well-connected machine... Sad.

Jason


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
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