[Snort-users] Snort/Barnyard2 performance with remote DB

turki turki_00 at ...131...
Wed Feb 29 18:52:18 EST 2012


Jason,

You mean:

Snort -->Barnyard2 (tcpdump format) ----- Remote system-------> Barnyard2 (convert to u2 format)--> DB




________________________________
 From: Jason Haar <Jason_Haar at ...15306...>
To: "snort-users at lists.sourceforge.net" <snort-users at lists.sourceforge.net> 
Sent: Wednesday, February 29, 2012 4:47:47 PM
Subject: Re: [Snort-users] Snort/Barnyard2 performance with remote DB
 
On 01/03/12 04:25, Mike Lococo wrote:
> A factor of 10 doesn't make a meaningful difference for me. For local
> DB's with lan latency, barnyard2 is already plenty fast for my use.
> For remote DB's with 200ms of latency to be feasible I'd need to see a
> factor of 100 improvement (remember we're starting from ~1 alert/sec
> for a link with over 200ms latency).
> ..
This is a great topic, as lately I've been thinking about centralizing
our world-wide SQL databases and this issue with latency will kill us.

How about this as a feature request? Get snort to rotate unified output
files after either a time or size threshold (like daemonlogger does),
and then use rsync to move those closed files to a central server, where
barnyard can then move them into the DB? Certainly not realtime anymore
- but if you are talking about centralizing high-latency separated
sensors into a single DB, I think we can safely say realtime isn't a
primary motivator anymore... Tricks with dnotify/etc could minimize the
delay too.

Actually, this could all be treated as a barnyard feature request?i.e. a
new output option for barnyard - unique filenames that another process
(rsync loop) manages. This would have the advantage that the local
barnyard could still do the realtime syslog alerting - it would just be
the DB entries that would lag...?

Hmmm, barnyard2 already has a tcpdump output option - could all this be
done with existing code? i.e. the "leaf node" barnyard2 does the syslog
and tcpdump output, we rsync the tcpdump files to the central server,
*somehow* turn them back into unified2 format and the central barnyard2
pushes them in (with the original sensor names of course).

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Snort-users mailing list
Snort-users at 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

Please visit http://blog.snort.org to stay current on all the latest Snort news!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20120229/4c013185/attachment.html>


More information about the Snort-users mailing list